E2E KEEP: End to End Key Exchange and Encryption Protocol for Accelerated Satellite Networks

Accelerating methods are used to enhance TCP performance over satellite links by employing Performance Enhancement Proxies (PEPs). However, providing a secure connection through the PEPs seems to be impossible. In this paper an appropriate method is proposed in order to provide an accelerated secure E2E connection. We show an efficient secure three-party protocol, based on public key infrastructure (PKI), which provides security against spiteful adversaries. Our construction is based on applying asymmetric cryptography techniques to the original IKE protocol. Security protocols use cryptography to set up private communication channels on an insecure network. Many protocols contain flaws, and because security goals are seldom specified in detail, we cannot be certain what constitute a flaw. Proofing security properties is essential for the development of secure protocol. We give a logic analysis of the proposed protocol with the BAN-logic and discuss the security of the protocol. The result indicates that the protocol is correct and satisfies the security requirements of Internet key exchange. Based on the results of this preliminary analysis, we have implemented a prototype of our security protocol and evaluated its performance and checked safety properties of security protocol, and the results show that the protocol is robust and safe against major security threats.


Introduction
Virtual Private Networks (VPNs) provide the user with secure duplex connection channels [1].As a privacy protecting measure, VPNs are employed to encapsulate TCP/IP stream and safeguard it against interference, snooping, hijack or attack.In essence, a VPN provides a secured "tunnel" between two end points across a public network.The protocols used over the Internet (TCP/IP) are designed for reliable end-to-end data delivery over unreliable and congested networks.In a satellite connection the circuit is not congested in the same way that a terrestrial connection might be; there is less retransmission and recovery.However, satellite bears a high latency (delay) medium and TCP response to such latency is not in a determined way.To begin a data transmission, TCP uses a slow-start mechanism to determine any present congestion on the network.A delay over satellite link is interpreted as congestion; therefore the slow start mechanism remains in force for the duration of the transmission.Combined with the need to make frequent acknowledgments for the receipt and transmission of each packet this leads to a very inefficient use of a me-dium that is inherently reliable and uncontested.As a remedy treatment for limitations of TCP over satellite, the equipment and service providers pass TCP and other application layer protocols through Performance Enhancing Proxies (PEP) which accelerate this traffic over the satellite connection.The PEP applies a number of methods such as window size reduction for packet transmission and selectively omitting some acknowledgment requirements in data stream.VPN tunnels encrypt user information at both ends to ensure secrecy and authentication.Therefore, sender and receiver sides, before any data transfer, need to exchange encryption keys.When an IPSec VPN is used, the TCP headers encapsulated within the VPN data stream cannot be accelerated.There are some techniques to set up an accelerated secure VPN over satellite links [2]:  Trusted PEPs (see Figure 1);  Application layer Security Protocols;  changing IPSec to make the header accessible;  Multilayer security (ML-IPSec).
Each packet will be divided into different sections by ML-IPsec and encrypted independently [3].In this method, PEPs have only header encry tion key, thereby they do p not have access to the payload.So, an end to end secure connection can be provided.Among previous studies, this method can met security requirements more than other methods.The proposed method i.e.ML-IPSec, replaces IPSec single layer model with a multilayer security model.This method is based on dividing IP packets into several zones, using a specific security pattern for each zone (see Figure 2).Thus, the PEPs can access limited parts of IP packet.Authentication and encryption will be done by different keys for each zone area and PEP can only decrypts its own part and after applying changes will encrypt it again.ML-IPSec has encrypted TCP header and application data header part in every IP packet separately and exhibits decrypting key only for final sender and receiver.TCP header decryption key will be accessible for some of trusted PEPs.Therefore, it will establish a secure end to end connection.

Inbound and Outbound Processing in ML-IPsec
The inbound and outbound processing of an IP datagram in an IPsec gateway is demonstrated through a 2-zone example in Figures 3 and 4.

Partial In-Out Processing at PEP
In an intermediate node, a packet will go through partial inbound processing and then outbound processing (see Figure 5).
Internet key exchange (IKE) provides a way to agree on the common security protocols, algorithms and keys.Secondly, it guarantees both sides about the identity of the other side [4].The E2E KEEP protocol, derived from the standard IKE, is considered less vulnerable to attack.It will be easier to configure and deploy, making IPSec VPNs to insecure networks.We used public key technology to meet the key management requirements of insecure networks.More specifically, we choose to develop a PKI for managing X. 509 public key certificates and certificates Revocation lists (CRLs) issued to the network nodes.The IKE protocol contains two phases: in the first phase a secure channel between both sides can be established, while in the second IPSec Security Associations (SAs) can be directly negotiated.In RFC 2409 [5] four different authentication methods for Phase I protocols are defined: pre-shared key, public key signature, public key encryption, and revised public key encryption.The phase II is protected by Phase I SA; it does not need to provide its own authentication protection, allowing a fast negotiation.
A certificate defined in X. 509 contains the user's public key and other information and a signature of this information by CA (Certificate Authority) [6].Three certificate examples are given below:   In these expressions, CERT S represents the certificate of S, CERT P represents the certificate of P, and CERTR represents the certificate of R and CERT CA represents the certificate of CA, in Which ID X means the identity of entity X, PK X is the public key of entity X, X  is the private key of entity X, Date X is the issue date of the certificate to X, and LF X is the life time.
These data are signed by CA using its private key CA and the data in CERT CA are signed by the top level certification authority using its private key TLCA .E{Y} x indicates that "Y" is encrypted with the asymmetric key "X".The certificate hierarchy takes the form of a multiple tree structure (see Figure 6).Each tree has a top level certification authority (TLCA) at the root, zero or more layers of middle-level CAs (MLCAs), and a layer of low-level CAs.Each low-level CA owns one or more contiguous blocks of IP addresses, and is responsible for issuing certificates to the nodes with their IP addresses falling in the ranges.Different low level CAs may be dedicated to issue certificates to nodes.TLCAs and MLCAs in different trees may be linked by cross certificates.These cross certificates establish the verification paths between leave certificates in this case a certificate should contain CA's basic information and the public key of TLCA and MLCA in order to validate the certificate.Here, we do not discuss these details.

A Scheme of the Proposed Protocol
In this section, we present the scheme of our protocol [6].The proposed protocol includes two parts, first part, negotiation between Sender and PEP (see Figure 7), and second part, negotiation between Sender and Receiver (see Figure 8) [7].

First Part of E2E KEEP
Messages (1) and (2) carry out the parameter negotiation.In message (1), the sender generates a random number, cookie-S (C S ), and sends the C S in the first message to the PEP.The [SA] prop includes a list of proposals to the PEP that the sender sends, for example encrypt arithmetic (e.g., DES, 3DES) and authentication arithmetic (e.g., MD5, SHA-1).In message (2), the PEP generates, C P and Usually, C P is generated from some local secret,   some unique information about the PEP (e.g., C P = Hash (source & dest IP addrs, C S ports, P's local secret)), and possibly other local state information and sends it to the supposed sender.In [SA] cho , PEP either chooses one and only one proposal from the list and sends its choice to the sender or rejects the entire list and sends back an error in the second message.The sender includes <C S , C P > as the requested confirmation in the step 3-6.The PEP can compute a new C P from < sender, C S > and compare this new C P with the one in steps 3-6.If these two cookies match, then the PEP can have some assurance that it is the supposed sender, not an attacker, who sent the first message.The messages (3) to (6) carry out the key exchange.N S and N P are nonces, large and never-used before random numbers, used to defeat replay.Certificates contain data used for authentication.SIG (S) and SIG (P) are the sender's and the PEP's signatures [8].
Step 1: The sender generates a random number, cookie C S and proposes SA.Where: Step 2: The PEP generates cookie C p , chooses one and only one proposal from the list in [SA] prop .Then, he sends C S , C P , [SA] cho and CERT P to the supposed sender.

Sender
Step 3: After receiving the message, Sender should validate cookie C P and certificate CERT P using the public key of CA.If they are not valid, Sender terminates the execution.Sender generates a header key "K h " and uses the public key of PEP to encrypt the message CERT S ||K h , Otherwise, where "||" means concatenation.Then, Sender sends message (3) to PEP.Step 4: After receiving message (3) from Sender, PEP decrypts it to get CERT S and K h .Then, PEP verifies the validity of certificate CERT S using the public key of CA.If it is invalid, PEP terminates the execution.Otherwise, PEP generates a nonce N P and encrypts it with the public key of Sender.Finally, PEP sends these messages to Sender.
Step 5: After receiving message (4) from PEP, sender opens the message, decrypts it to get N P .Then, sender generates SIG (S) and a nonce N S .Sender encrypts N S with the public key of PEP then sender generates and sends those to PEP, where: Step 6: After receiving message (5) from sender, PEP validates SIG (S).If it is valid, PEP generates SIG (P) and send it to sender, where: Then sender validates SIG (P) if it is valid, sender will sure PEP is authenticated.If it is not invalid, sender terminates the execution (see Figure 9).

Second Part of E2E KEEP
Key exchange between sender and receiver is same as sender and PEP, but here sender generate header key as well as data key then send those to receiver (see Figure 10).

Proof of the Concept: Protocol Analysis
It is important to make sure there are no security flaws in the protocol.Thus, this protocol must be analyzed.The BAN-logic is one of the methods for the analysis of cryptographic protocols (see Table 1) [9].The analysis of the protocol involves applying a number of rules [10,11].Now we can apply the logical postulate rules to each message with assumptions.

Negotiation Analysis between Sender and PEP
We start with the assumptions in

П (S):
The entity S has a good private key.The value of this key is only known to S.

PK (K, S):
The entity S has the good public key K associated.

σ (X, S):
The formula X is signed with the private that belongs to S.  After receiving see hash of session key and secret nonce" N S " from P, S deduces: From the freshness distribution rule (FD), S deduces: Now P has been authenticated and S believes P. S | P Thus each participant is believes both that the key is valid.Our analysis achieves this result, since we have derived this goal: K h S | P| (S  P)

Negotiation Analysis between Sender and Receiver
Again we start with the assumptions in Thus each participant believes both that the key is valid.Our analysis achieves these results, since we have derived this goal (see Figure 12): K h S | R| (S  P) K d S | R| (S  R)

Investigate Some Kinds of Conventional Attacks
After discussion on the proposed protocol we investigate some kinds of conventional attacks to the network and study the security level of proposed protocol proving that it is a secure protocol against such attacks [7]. 1) Man-In-The-Middle The Man-In-The-Middle is an attack in which an intruder can read and modify the data transferred between two parties without letting none of them know that the link between them has been compromised.By far the attacker can observe and intercept the exchanged messages between the two victims.MITM attacks occur due to the lack of authentication or weak authentication being performed between the two legitimate parties involved in a transaction or communications session.To prevent the insertion of messages, the E2E KEEP protocol is designed.Any deletion will render the message invalid and consequently no partial SA will be created, Strong authentication of the parties prevents a SA from being established with parties other than the intended ones.
2) Denial of Service Denial of Service attack is one in which the system's resources become depleted and the system would not be useful for legitimate users anymore.In public networks, computers are vulnerable to denial of service attacks.A cookie pair at header is used to protect computing resources which with respect to efficiency of resource usage is comparable with dropping artificial messages before computing intensive public key operations.It is impossible to attain an absolute denial of service protection but the design of E2E KEEP makes situation easier to handle.
3) Replay/Reflection Replay or Reflection attack is a situation in which the network traffic is replayed by a third party after being recorded.E2E KEEP protocol requires the cookies to include a time variable material which facilitates the detection of replay.

4) Connection Hijacking
The connection hijacking is an attack in which a third party steals a link by jumping to the middle of transacttion.The E2E KEEP protocol is protected from the connection hijacking by linking the authentication, key exchange, and security association exchanges.The linking of exchanges renders the connection useless for a third party attacker after authentication is accomplished and the attacker cannot play the role of an authenticated party during key exchange or security association exchange.

Simulation
After designing E2E KEEP and providing guarantee for being secure implementation of protocol was done using C# for verifying accuracy of its function.In this section the schematics of Sender, PEP and Receiver agent before and after key exchange has been shown (see Figures 13  and 14).In the end, it was seen E2E KEEP works properly.
Part of C# code which has used in implementation has been shown in Figure 15.

Conclusion
Key exchange and distribution algorithm not only authenticate the actual identity of the sender and receiver, but also enhance the security criteria of the transfer.In this paper, we present a new authentication and key exchange protocol, it provides an end to end accelerated secure connection over satellite links.This protocol en

Figure 1 .
Figure 1.TCP acceleration on satellite links by trusted PEP.

Figure 2 .
Figure 2. VPN tunnel and multilayer IP security model.

Figure 8 .
Figure 8. Negotiation between sender and receiver.
After receiving message (3) from S and from the public key rule (PK)[12]: , Date , LF , E ID , PK , Date , LF   Now from the s raying rule (S): After receiving message (5) from S and from the public key rule (PK): see sender's signature P σ (H (K h ••• N P ), S)   From the Reading of Signature rule (RS), P can see hash of session key and secret nonce "N P ".P H((K h , •••, N P )) After receiving message (5) from S and from the public key cryptographic system rule (PKCS), P deduces: P | S |~ ((K h , •••, N P )) P | # N P From the nonce verification (NV) rule P | # N S , P | S| (K h , •••, N P ) From the freshness distribution rule (FD), P deduces: P | # K h P believes that the session key is valid.
PEP's signature S  σ (H (K h ••• N S ), P) From the Reading of Signature rule (RS), S can see hash of session key and secret nonce "N S ". S  H (K h ••• N S ) P | П (P)


After receiving message (3) from S and from the public key rule (PK): header and data keys: K h , K d Massage 4: RS: {N R } S PK After receiving message (4) from R and from the public key rule (PK)After receiving message (5) from S and from the public key rule (PK): see sender's signature R σ (H (K h , K d , •••, N R ), S) From the Reading of Signature rule (RS), S can see hash of session key and secret nonce "N R ". R H (K h , K d , •••, N R ) After receiving message (5) from S and from the public key cryptographic system rule (PKCS), R deduces: R | S |~ (K h , K d , •••, N R ) R | # N R From the freshness distribution rule (FD) and Nonce Verification (NV), R deduces: R | # (K h , K d ) R believes that the header and date keys are valid K Receiver's signature S  σ (H (K h , K d , •••, N S ), R) From the Reading of Signature rule (RS), S can see hash of session key and secret nonce" N S ".

Figure 13 .
Figure 13.Schematics of sender, PEP and receiver before key exchange.

Figure 14 .
Figure 14.Schematics of sender, PEP and receiver after key exchange.