TCP/IP protocol basics 4 (TCP/IP security)

Different TCP/IP layers provide different security. For example, a virtual private network is provided at the network layer and a secure connection service is provided at the transmission layer. The following describes the security of TCP/IP at different levels and the methods to improve the security of each layer.

I. Security at the Internet Layer

The idea of standardizing security protocols on the Internet layer has long existed. Some schemes have been proposed over the past decade. For example, "Security Protocol 3 (SP3)" is developed by the US National Security Agency and the standard Technology Association as part of "secure data network system (SDNS. "Network layer security protocol (nls p)" is a security protocol standard developed by the International Organization for Standardization for "connectionless network protocol (CLNP. "Integrated NLSP (I-NLSP)" is a unified security mechanism proposed by the National Institute of Science and Technology, including IP and CLNP. SwIPe is another security protocol for the Intenet layer, which is proposed and implemented by Ioannidis and blazze. All these proposals have more in common than differences. In fact, they all use IP Encapsulation technology. In essence, the plain text package is encrypted and encapsulated In the outer IP header, which is used to select a route for the encrypted packet on In ternet. At the other end, the outer IP header is split, the packet is decrypted, and then sent to the receiving location.

The Internet Engineering Task Force (IETF) has licensed the Internet Protocol Security Protocol (IPSEC) Working Group to standardize the IP Security Protocol (IPSP) and the corresponding Internet Key Management Protocol (IKMP. The main purpose of IPSP is to enable users who need security measures to use the corresponding encryption security system. This system can not only work under the current public IP address (IPv4), but also in the new version of the IP address (IPng or IPv6. This system should be unrelated to algorithms. Even if the encryption algorithm is replaced, it will not affect the implementation of other parts. In addition, the system must be able to implement a variety of security policies, but it should avoid negative impact on those who do not use the system. According to these requirements, the IPSEC Working Group has developed a specification: Authentication Hea der (AH) and encapsulation Security load (ESP ). In short, AH provides the authenticity and integrity of the IP package, and ESP provides the required content.

Ip ah refers to a piece of Message Authentication Code (MAC), which has been calculated in advance before the IP packet is sent. The sender uses an encryption key to calculate AH, and the receiver uses the same or another key for verification. If the receiving and receiving sides use a single key system, they use the same key. If the receiving and receiving sides use a public key system, they use different keys. In the latter case, the AH system can provide undeniable services. In fact, some fields that can be changed during transmission, such as the time-to-live domain in IPv4 or the hop limit domain in IPv6, must be ignored in AH's computing. RFC 1828 sets for the first time that the MD5 Algorithm with a key should be used for AH calculation and verification in the sealing state. At the same time, both MD5 and sealing statuses are criticized for being too weak in encryption, and there are alternative solutions.

The basic idea of ip esp is to encapsulate the entire IP package, or encapsulate only the data (Transport State) of the Upper-layer protocol in ESP, and encrypt most of the data in ESP. In the MPs queue status, a new IP Address Header (plain text) is appended to the currently encrypted ESP. This header can be used to Route IP packets over the Internet. The receiver removes this IP header, decrypts the ESP, processes it, and removes the ESP header, then, the data of the original IP package or higher-level protocol is processed as that of a common IP package. RFC 1827 defines the ESP format. RFC 1829 specifies that the Data Encryption Standard (DES) is used for ESP encryption and decryption in the CBC state ). Although other algorithms and statuses can also be used, the export control of such products in some countries is also a factor that cannot be ignored. In some countries, even private encryption is restricted.

The AH and ESP systems can be used together or separately. No matter how it is used, it will not escape the attack of transmission analysis. People do not know whether there are economic and effective means to combat transmission analysis on the Internet layer. However, there are few Internet users who really take transmission analysis seriously.

In August 1995, the Internet Engineering leading group (IESG) approved the RFC for IPSP as a recommendation standard for the Internet standard series. In addition to RFC 1828 and RFC 1829, there are two experimental RFC files that stipulate that the security hashing algorithm (SHA) is used to replace MD5 (RFC 1852) in the AH and ESP systems) and use ternary DES to replace DES (RFC 1851 ).

In the simplest case, IPSP configures the key manually. However, when IPSP develops in a large scale, it is necessary to establish a standardized key management protocol on the Internet. This key management protocol specifies the key management method as required by the IPSP security regulations.
Therefore, the IPSEC Working Group is also responsible for Internet Key Management Protocol (IKMP), and the standardization of several other Protocols has been put on the agenda. Among them, the most important are:

Standard Key Management Protocol (MKMP) proposed by IBM )"
"Simple Key Management (SKIP) for Internet Protocol" proposed by SUN )"
Phil Karn's "Photuris Key Management Protocol"
"Secure Key Exchange Mechanism (SKEME)" proposed by Hugo Krawczik )"
"Internet security regulations and key management protocols" proposed by NSA"
The "OAKLEY key decision protocol" proposed by Hilarie Orman"

Here, we need to emphasize again that the similarities of these protocol drafts are more than differences. Apart from MKMP, both of them require an existing and fully operable Public Key Infrastructure (PKI ). MKMP does not have this requirement because it assumes that both parties already know a Master Key, which may be manually released in advance. Sk ip requires the Diffie-Hellman certificate, while other protocols require the RSA certificate.

In September 1996, IPSEC decided to use OAKLEY as the mandatory key management method under the ISAKMP framework, and SKIP as the priority for IPv4 and IPv6 implementation. At present, some vendors have implemented the integrated ISAKMP/OAKLEY solution.

The basic idea of the Photuris and Photuris-like protocols is to use the Diffie-Hellman key exchange mechanism for each session key, and then use the signature exchange mechanism to confirm the Diffie-Hellman parameter, make sure that no man-in-the-middle is attacked. This combination was initially proposed by Diffie, Oos chot, and winne in a "site-to-site (STS)" protocol. In Photuris, a so-called "cookie" exchange is added. It can provide the "anti-logging" function to prevent denial of service attacks. Since the Diffie-Hellman password exchange mechanism is used for each session key, the Photuris and Photuris-like protocols can provide back-to-traffic protection (BTP) protection) and complete forwarding Security (perfect-forward secrecy, PFS ). Essentially, this means that once an attacker cracks a long-term private key, such as the RSA key in Photuris or the Diffie-Hellman Key in SKIP, all of its attackers can impersonate the owner of the cracked password. However, attackers may not be able to crack the information sent and received by the owner in the past or in the future.

It is worth noting that SKIP does not provide BTP and PFS. Although it adopts the Diffie-Hellman key switch, the exchange is implicit. That is to say, the two entities know each other's long-term Diffie-Hellman public key in the form of a certificate, to implicitly share a CMK. This CMK can be used to export keys that encrypt the group key, which is used to encrypt the IP packet. Once the long-term Diffie-El lman key is disclosed, any communication protected by the key will be cracked. In addition, the SKIP is stateless and is not based on security regulations. Each IP packet may be encrypted and decrypted individually. In the final analysis, different keys are used.

The failure of SKIP to provide BTP and PFS has aroused criticism within the IPSEC Working Group. The Protocol has also been expanded to provide BTP and PFS. However, the expanded SKIP protocol version is a compromise between the stateless nature of the Protocol provided by BTP and PFS. In fact, SKIP with BTP and PFS functions is very similar to Photuris and Photuris-like protocols. The only major difference is that SKIP (still) requires the original Diffie-Hellman certificate. Note: At present, RSA certificates are easier to implement and carry out business than other certificates on the Internet.

Most IPSP and their corresponding key management protocols are implemented based on Unix systems. The implementation of any IPSP must be entangled with the source code of the corresponding protocol stack, and the source code can be used on Unix systems, probably because of this. However, if you want to use and adopt security protocols more extensively on the Internet, you must have a corresponding DOS or Windows version. One of the challenges for implementing Internet-layer security protocols on these systems is that there is no public source code resource for implementing TCP/IP on the PC. To overcome this difficulty, Wagner and Bellovin implement an IPSEC module that works like a device driver and is completely under the IP layer.

The main advantage of Internet layer security is its transparency. That is to say, the provision of security services does not require any changes to applications, other communication layers, and network components. Its main disadvantage is that the Intern et layer generally does not differentiate packages belonging to different processes and corresponding regulations. For all packages destined for the same address, it will be processed according to the same encryption key and access control policy. This may result in failure to provide the required power and performance degradation. For host-oriented key distribution issues, RFC 1825 allows (even recommended) user-oriented key distribution. Different connections obtain different encryption keys. However, user-oriented key distribution requires significant changes to the corresponding operating system kernel.

Although the IPSP specification has been basically completed, the situation of key management is ever-changing and there is still a lot of work to be done. An important issue that has not attracted enough attention is the key distribution problem in the multicasting environment, for example, in the Internet multicast Backbone Network (MBone) or an IPv6 key distribution problem.

In short, the Internet layer is very suitable for providing host-to-host security services. The security protocol can be used to establish secure IP channels and virtual private networks on the Internet. For example, you can simply strengthen the defense capability of the firewall system by using its IP packet encryption and decryption functions. In fact, many vendors have already done this. RSA Data Security has launched an initiative to promote the joint development of virtual private networks by Multiple Firewall and TCP/IP software vendors. This initiative is called the S-WAN (secure Wan) initiative. The goal is to develop and recommend Internet-layer security protocol standards.

Ii. Transport Layer Security

In Internet application programming, generally, interprocess communication (IPC) mechanisms are used to deal with different levels of security protocols. The two popular IPC programming interfaces are BSD Sockets and transport layer interface (TLI), which can be found in the Unix System V command.

The first idea of providing security services on the Internet is to strengthen its IPC interface, such as BSD Socke ts. Specific practices include the authentication of double-end entities and the exchange of data encryption keys. According to this idea, Netscape Communications Corporation developed a complete set of SSL protocols based on reliable transmission services (such as provided by TCP/IP ). SSL version 3 (SSL v3) was developed in December 1995. It mainly includes the following two Protocols:

The SSL record protocol involves the segmentation, compression, data authentication, and encryption of information provided by applications. SSL v3 provides data authentication