Security Protocol Series (v)----IKE and IPSEC (medium)

In the previous article, the experimental environment was built. The protocol analysis can be performed once the IKE/IPSEC protocol is fully run and the relevant output and capture packets are collected. During the analysis, we will use the output of the IKE process and the Wireshark grab packet, combined with the relevant RFC, using Python to verify the calculation. First look at the full operation of the Protocol (filtering out irrelevant messages, such as)

The following is a specification description of the IKEV2 protocol in RFC 5996

From the above, the IKEV2 protocol consists of two phases of the interactive process (two back and forth, a total of four messages). The first stage is called Ike_sa_init Exchange. The second stage is called Ike_auth Exchange. Concept viewing Mencius message format, preceded by the IKE header HDR, followed by various types of loads. HDR contains the Security Parameter Indexes (SPIs) of the Protocol initiator and responder, the protocol version number, the length of the message, and some fixed fields. The load is: different types, representing different meanings. Typical loads are described below (excerpt from RFC)

  Notation Payload ----------------------------------------- AUTH authentication CERT Certificate certreq Certificate Request CP Configuration D Delete EAP Extensible Authentication HDR IKE Header (not a payload) IDi Identific ation - initiator IDr identification - Responder KE Key Exchange Ni, Nr Nonce N Notify SA Security Association SK         Encrypted and authenticated TSi traffic Selector - initiator TSr Traffic Selector - Responder V Vendor ID  

To see the first phase of interaction (Ike_sa_init), the first message was sent by initiator (Windows 7), followed by the Responder (Linux) Response message. The load of two messages is basically the same, including Sai1/sar1,kei/ker and NI/NR. The number 1 in the SAI1/SAR1 notation represents the first stage.

Sai1/sar1 respectively represents the cipher algorithm suite that the initiator and responder can support, which acts like the Cipher Suites in the TLS message, as described in the description. Kei/ker and Ni/nr are also regulars in the cryptographic protocols, respectively, representing both the Diffie–hellman key exchange and the one-time random number. Visible in the IKE protocol, forcing the use of Diffie–hellman key exchange, so as to achieve Perfect Forward secrecy effect, at this point is slightly better than the TLS protocol. In addition, the second message contains a certificate request payload (CERTREQ). Because certificate authentication (AUTHBY=PUBKEY) is enabled in the ipsec.conf configuration file.

Look at the actual packet capture content (first ike_sa_init message)

We found that there were two Notify loads in addition to the Security association/key exchange/nonce load just mentioned.
Wireshark in the parse protocol tree, the original is NAT_DETECTION_SOURCE_IP and nat_detection_destination_ip load. They express support for NAT traversal, regardless of cryptographic core functionality, and are no longer discussed.

Now focus on the SAI1 load. SAI1 contains 6 proposal, specific proposal content (expanded after rearrangement) for

    Cryptographic algorithm      integrity algorithm        pseudo-random number generation function   Diffie-hellman Group
3DES_CBC     hmac_sha1_96       prf_hmac_sha1      modp_1024
[2] aes_cbc_256  hmac_sha1_96       prf_hmac_sha1      modp_1024
[3] 3DES_CBC     hmac_sha2_256_128  prf_hmac_sha2_256  modp_1024
[4] aes_cbc_256  hmac_sha2_256_128  prf_hmac_sha2_256  modp_1024
[5] 3DES_CBC     hmac_sha2_384_192  prf_hmac_sha2_384  modp_1024
[6] aes_cbc_256  hmac_sha2_384_192  prf_hmac_sha2_384  modp_1024

Each proposal is composed of four tuples related to cryptography, namely, cryptographic algorithm, integrity algorithm, pseudo-random number generation function, Diffie-hellman group. What does the four-tuple function?

For the moment, continue to look at the second ike_sa_init message, Strongswan response message content is: HDR, SAr1, KEr, Nr, N, N, CertReq, N. Among them, KEr, Nr and KEi, Ni, are a string of binary format content. Three Notify we don't care. Just look at SAr1 and certreq. The SAR1 includes only one proposal, 3des_cbc/hmac_sha1_96/prf_hmac_sha1/modp_1024, which is the cipher algorithm suite supported by Strongswan.
In contrast to the above SAi1, both parties agree that the cryptographic algorithm/integrity algorithm/pseudo-random number generation function/diffie-hellman Group is
3des_cbc/hmac_sha1_96/prf_hmac_sha1/modp_1024.

Then look at the CertReq (certificate request) payload, the contents are as follows

Certificate Authority Data, what is this thing? Need the other side to provide the certificate is just, how there is a string of binary content? View RFC 5996, which has such a text

Certification Authority value is a concatenated list of SHA-1 hashesof the public keys of trusted certification Authoritie S (CAs). Eachis encoded as the SHA-1 hash of the Subject public Key Info element (see sections 4.1.2.7 of [RFC3280]) from each Trust Anchorcertificate. The twenty-octet hashes is concatenated and Includedwith no other formatting.

The

Originally had a series of SHA-1 digest values, and the input to the digest was the public key information in the Strongswan trusted CA certificate. In more detail, the subjectpublickeyinfo section, see below

 tbscertificate:: = SEQUENCE {version [0] EXPLICIT version DEFAULT v1, serialnumber Certificateserialnumber, Signature algorithmidentifier, issuer Name, Val Idity validity, subject Name, subjectpublickeyinfo Subjectpublickeyinfo, Issueruniqueid [1] implicit uniqueidentifier OPTIONAL,--                             If present, version must be v2 or v3 Subjectuniqueid [2] implicit uniqueidentifier OPTIONAL,                             --If present, version must be v2 or V3 extensions [3] EXPLICIT extensions OPTIONAL            --If present, version must be V3} subjectpublickeyinfo:: = SEQUENCE {algorithm Algorithmidentifier, Subjectpublickey BIT STRING} 

Indicates the location of the public key information for the summary calculation in the CA file: The first byte is 0x30, followed by 0x81 0x9F ... until the last byte of the yellow background (note that the DER representation of SEQUENCE Subjectpublickeyinfo)

Here is the verification process
D:\>dd if=ca.der bs=1 count=162 skip=195 of=subjectpublickeyinfo iflag=binary oflag=binary
D:\>openssl DGST-SHA1 Subjectpublickeyinfo
SHA1 (subjectpublickeyinfo) = 4f9e47fe96b05611c4d7f66dca3f265b32dde04d

It seems that Strongswan is more rigorous: not only require the other party to provide certificates, but also required to provide a certificate is issued by Strongswan recognized CA.

At this point, the first phase of IKEV2 is completed. At this stage, the two sides agree on a series of cryptographic algorithms to be used later, and prepare their own Diffie-hellman key exchange values and random numbers. The result of the first phase of the negotiation is IKE SA. In addition, Strongswan requires certificate-based identity authentication. Of course, all of this is transmitted in plaintext.

Then into the second phase, this phase of the Ike_auth Exchange, also includes two packets back and forth. The first message is still Windows 7 initiated, and the second message is the Strongswan response.

Recalling the first stage, after Ike_sa_init exchange, the two sides have the basic protection ability to follow-up communication, including: Message encryption, message integrity protection. Why is this? Because after sai1/sar1 comparison, has negotiated out four tuples: The encryption algorithm, the integrity algorithm, the pseudo-random number generation function, and the Diffie-hellman group. Among them, the encryption algorithm (i.e. 3DES_CBC) is used for the encryption protection of the message. The hmac_sha1_96 algorithm is used to protect the integrity of the message. After the algorithm is agreed, the next question is, where does the key come from? We see that there are also diffie-hellman groups in the four-tuple, plus the KEi and KEr loads in the Ike_sa_init exchange. A friend familiar with the password protocol can guess that the key should come from the Kei/ker exchange result. In the actual protocol, the exchange result of Diffie-hellman key is more the function of "key seed", but not directly participate in the basic operation of cryptography such as addition and decryption. At this point, the IKEV2 agreement is no exception. It is important that once the key seed is available, all keys directly involved in the basic operation can be generated continuously. So how to produce? This will depend on the last element in the four-tuple: pseudo-random number generation function.

After the idea is clear, now look at how the RFC has put the theory into practice. First, we look at the generation of the key seed, and in the IKEv2, it generates a formula of

Skeyseed = PRF (Ni | Nr, G^ir)

In the above formula, G^ir is the Diffie-hellman key exchange value, and the PRF is the pseudo-random number generation function in the four-tuple (that is, PRF_HMAC_SHA1, see RFC 2104). And Skeyseed did not directly bring G^ir to use, but also add Ni, Nr influence. The thinking of the Protocol designer is thoughtful. Note, of course, that G^ir is a secret value, except that the third party is not aware of the real communication. (If a third party initiates a man-in-the-middle attack and knows the key exchange value, it cannot be signed by the latter, so the man-in-the-middle attack is ignored).

The following is a Python script that calculates Skeyseed (G^ir from Strongswan's on-screen debug output)

#skeyseed = PRF (Ni | Nr, G_ir)ImportBinascii fromCrypto.hashImportHMAC, SHANi= Binascii.a2b_hex ('305243E21BB674F3EBDA3A370C7688C446F5C189391F55F7C26A91F82D03F2689114AE822042ECD8E6CEDCB6128F09FB') Nr= Binascii.a2b_hex ('d7e075db89009f3788b30d2fe6dc77f7cb527d8e2ce091b496a0253767c75188')#Ni, Nr length is not the sameG_ir = Binascii.a2b_hex ([Diffie-hellman key exchange results])#[] Replace with actual contentKey = Ni +Nrdata=G_irskeyseed=Binascii.a2b_hex (hmac.new (key, data, SHA). Hexdigest ())PrintHmac.new (key, data, SHA). Hexdigest ()

After the key seed skeyseed is obtained, the pseudo-random number generation function can generate the key that actually participates in the encryption and decryption operation. This is consistent with the idea in the TLS protocol. However, a single pseudo-random number generation function, the output length is limited, and the actual need to use the key, the number is more, the length will not be enough. So often using the concept of counting cycle increment, do: with a pseudo-random number generation function, constantly generate the required key. How did you get that? Just look at the key generation formula in the RFC and you'll understand

   {Sk_d | Sk_ai | Sk_ar | Sk_ei | Sk_er | Sk_pi | SK_PR}                   = prf+ (skeyseed, Ni | Nr | Spii | SPIR)   prf+ (k,s) = T1 | T2 | T3 | T4 | ...   Where:   T1 = PRF (k, S | 0x01)   T2 = PRF (k, T1 | S | 0x02)   T3 = PRF (K, T2 | S | 0x03)   T4 = PRF (K, T3 | S | 0x04)   ... Where Sk_d: Generate key seed for IPSec keying material Sk_ai: Authentication key for subsequent IKEV2 message-for protocol initiator Sk_ar: Authentication key for subsequent IKEV2 message-for protocol responder Sk_ei: encryption key for subsequent IKEV2 message-for protocol Initiator Sk_er: Encryption key for subsequent IKEV2 messages-used for protocol responder SK_PI: Generate Identity (AUTH) payload-Used for protocol initiator SK_PR: Generate identity authentication (AUTH) payload-Used for protocol responder

According to the above formula, the function prf+ () generates a series of key streams, and then Sk_d, Sk_ai, Sk_ar, Sk_ei, Sk_er, SK_PI, SK_PR sequentially take the respective length of the key from the key stream.

The following is a Python script that generates these keys

Spii = Binascii.a2b_hex ('75dd3961203ca3b1') SPIr= Binascii.a2b_hex ('3cc3328025824d2d') K=skeyseeds= Ni + Nr + spii +Spirt="'Totalkey="' forIinchRange (1, 10):#10 cycles enough to generate the required keysCount_byte = Binascii.a2b_hex ('%02d'I#0x01 0x02 0x03 ...data = T + S +Count_byte T=hmac.new (K, data, SHA). Hexdigest () T=Binascii.a2b_hex (T) Totalkey+=Tsk_d= Totalkey[0:20]sk_ai= totalkey[20:20+20]sk_ar= totalkey[40:40+20]sk_ei= totalkey[60:60+24]sk_er= totalkey[84:84+24]sk_pi= totalkey[108:108+20]SK_PR= totalkey[128:128+20]Print 'sk_d ='+binascii.hexlify (sk_d)Print 'Sk_ai ='+binascii.hexlify (Sk_ai)Print 'Sk_ar ='+binascii.hexlify (Sk_ar)Print 'Sk_ei ='+binascii.hexlify (Sk_ei)Print 'sk_er ='+binascii.hexlify (sk_er)Print 'SK_PI ='+binascii.hexlify (SK_PI)Print 'SK_PR ='+ binascii.hexlify (SK_PR)

Until now, various algorithms and keys have been calculated. Note that this is what happens after the first phase of ike_sa_init exchange. Then enter the second stage (Ike_auth Exchange). Naturally, the second-stage message can be protected using the various cryptographic elements negotiated above. How exactly is it protected? See first Ike_auth message of interaction first

Ike_auth the message header is removed, all the remaining loads are protected and are specifically represented by a load of type Encrypted and authenticated. The internal format of the load is described in

Sure enough, all the keys discussed above (Sk_ai/sk_ar, Sk_ei/sk_er, SK_PI/SK_PR) will come in handy in addition to Sk_d (discussed later). The content in the yellow background represents the plaintext before encryption. Of course, only encryption is not enough, but also to protect the integrity of the message (the more popular is the encryption authentication integration processing, such as the use of Aead in block encryption). Ciphertext is followed by a field called Integrity Checksum Data (ICD), which acts as an integrity protection. It is important to note that the ICD is computed using the previously negotiated hmac_sha1_96 algorithm, and its protection content is the entire IKEV2 message that removes the last ICD field. Now follow this logic to unlock the veil of the encryption message, the corresponding Python script is as follows (take the first Ike_auth message for example)

 from Import DES, DES3 Import  #  [] Replace cipher =#  [] with actual content instead of plaintext = Cipher.decrypt ( Ciphertext

Compare the output of the Strongswan below, exactly the same

13[ENC] data after decryption with padding = 1872 bytes @ 0xaf0036a013[enc] 0:25 xx xx (    3D) 0B Geneva (%).  G.... 0=1.0...13[ENC] 16:55, Geneva, 4E to 0B, Geneva,  U .... CN1.0 ... S.h 13[enc]   32:0c 5A to 0C 0A., 0A 0C.  HZ1.0 ... U .... V13[enc]   48:50 4E, 0C 0A, 4E PN1.0 .....  U .... Vpn13[enc]   64:20 6C (6E): Geneva, the client& of the 6E.   w.0. N

Once the plaintext is obtained, the Integrity Checksum Data can be calculated directly and the script is as follows

# Verifying the Ike_auth Integrity Checksum Data # calculation range: from Ike_auth message header to end of message (except Integrity Checksum Data field)  from Import HMAC, SHA Import  #  [] replace integritychecksumdata with actual content = hmac.new (sk_ai, data, SHA). Hexdigest () Print Integritychecksumdata

After we get the Ike_auth plaintext, let's see what it is. This can turn to the powerful Wireshark, which comes with the ability to decrypt the IKE payload, provided that you tell it the key. Is the interface that unlocks the decryption function (Wireshark Version 1.8.5)

The decrypted message is as follows

So the actual message structure is: HDR, Sk{idi, CERT, CertReq, AUTH, N, CP, SAi2, TSi, TSr}, we see what these loads represent?

IDi-Represents the identity of the initiator, expands the Wireshark protocol tree, whose content is the subject field in the initiator certificate (SUBJECT:C=CN, St=hz, O=vpn, Cn=vpn Client), and is encoded with the DER_ASN1_DN type

CERT-it goes without saying that the bearer content is the initiator's certificate.

CertReq--The initiator asks the responder to provide a certificate (to verify the other's digital signature), which has been discussed in detail earlier.

AUTH--Certification load, which is the focus

Recall that the Ike_auth message is currently only encrypted and integrity-protected, which achieves C (confidentiality) and I (Integrity) in the CIA. There is also a (authentication, identity authentication) that I personally think is more important. Another explanation is availability, which is explained here by the former). Identity authentication, or IFF, should be the primary issue to consider in an insecure environment. As a classic security protocol, IKEV2 naturally also considers this, it contains the identity authentication information in the AUTH payload, only AUTH load passes the verification, can think is the real opposite party in and oneself communication. So what exactly does the AUTH load contain? Easy to guess, it should be a digital signature. The signature key is the private key corresponding to the certificate, and the signature algorithm and signature contents need to be determined. For RSA keys, the signature algorithm uses the Rsassa-pkcs1-v1_5 standard in RFC 3447. While the signature content, it is more complex, still with the Ike_auth message sent by initiator as an example, the calculation process is as follows

RealMessage1 = Initiator's ike_sa_init message # Complete Ike_sa_init message, from IKE header to end of message Initidpayload = Idtype | RESERVED | Identificationdataofinitiator # See, it's the initiator. The actual content part of the identification payload Macedidfori = PRF (Sk_pi, initidpayload) # Generate initiator identity letter using PRF The HMAC value of initiatorsignedoctets = RealMessage1 | Noncerdata | Macedidfori # Signature Content

From the above, the signature content includes: The initiator's ike_sa_init message, the responder's Nonce, and the checksum of the initiator identity information. The last item also deals with SK_PI keys derived from the g_ir of the Diffie–hellman key exchange results from both parties. All of these messages are combined if they are signed correctly enough to convince the other party of the identity of the initiator. The following is the final calculation script.

 fromCrypto.hashImportHMAC, SHA fromCrypto.signatureImportpkcs1_v1_5 fromCrypto.publickeyImportRSA#initidpayload = idtype + RESERVED + identificationdataofinitiatorInitidpayload = Binascii.a2b_hex ([actual contents of IDi load])#[] Replace with actual contentMacedidfori =Binascii.a2b_hex (Hmac.new (Sk_pi, Initidpayload, SHA). Hexdigest ()) RealMessage1= Binascii.a2b_hex ([initiator's ike_sa_init message])#[] Replace with actual contentInitiatorsignedoctets = RealMessage1 + Nr +Macedidforikey= Rsa.importkey (Open ('Clientkey.pem'). Read (),'123456') Hash=sha.new (initiatorsignedoctets) signer=pkcs1_v1_5.new (key) Authenticationpayloadofinitiator= Signer.sign (hash)#pkcs1_v1_5 SignaturePrintBinascii.hexlify (Authenticationpayloadofinitiator

Compared with the certified load, the remaining loads are much simpler.

N--Notification payload: mobike_supported

CP--Configure load: Windows 7 assigns Ip/dns addresses to peer requests

SAi2-This is the Security association in the second phase interaction (Ike_auth), expressed in SAi2. At this point, the parties have not agreed how to protect the subsequent traffic, so they send SAi2 and SAr2 in their respective Ike_auth exchange messages, and then negotiate again. The result of this negotiation is called the IPSec SA. As you can imagine, the contents of the IPSec SA are also elements of the associated password, including key information such as algorithms, keys, and so on. In the capture package file, the main contents of SAI2/SAR2 are as follows

                Cryptographic algorithm       integrity algorithm sai1/proposal-1 ENCR_AES_CBC  auth_hmac_sha1_96sai1/proposal-2 encr_3des     auth_hmac_sha1_ 96sar2/proposal-1 encr_3des     auth_hmac_sha1_96

Finally, both sides agreed to use 3DES and hmac_sha1_96 as encryption and integrity algorithms. Since both identities have been confirmed, the protection of subsequent messages requires only the two. If you are more careful, you will ask where the key comes from? Without the key, the IPSec SA is incomplete. The answer is that the key comes from Sk_d, which is discussed later.

TSi and TSr-flow select loads that are irrelevant to this topic and do not unfold.

Based on the same idea, the Ike_auth message sent by the responder can be analyzed. Don't dwell on it here.

Finally, the protocol process of IKEV2 is summed up: the Ike_sa_init exchange between the two parties in the first stage, the result of the negotiation is IKE SA. The second phase of the Ike_auth Exchange is protected by cryptographic features defined in the IKE SA, both of which authenticate and negotiate out the IPSec SA. The IPSec SA protects subsequent traffic traffic.

At this point, the IKEV2 protocol analysis is complete.

Reference

RFC 2104--hmac:keyed-hashing for Message authentication
RFC 3280--Internet +/-Public Key Infrastructure Certificate and Certificate revocation List (CRL) profiles
RFC 3447--Public-key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1
RFC 5996--Internet Key Exchange Protocol Version 2 (IKEV2)
RFC 4718--IKEV2 clarifications and implementation guidelines

Security Protocol Series (v)----IKE and IPSEC (medium)