1 Introduction
- A proposal for a new security protocol for 5G wireless P2MP backhaul
- A formal security analysis of the proposed protocol using BAN-logic and Scyther tool, and
- A detailed comparative analysis between the proposed and existing protocols in terms of security property, computation overhead, and communication overhead.
2 Related work
2.1 Security policy update
2.2 Key update
2.3 Balancing between security and efficiency
3 5G wireless P2MP backhaul security protocol
3.1 Preliminary
Notation | Meaning |
---|---|
TM | Terminal |
HUB | HUB |
ASF | Authentication Server Function |
IDX | X’s identifier |
Capability | List of the possible cryptographic algorithms, authentication and key exchange methods, etc. |
Policy | The adaptively selected cryptographic algorithms, authentication and key exchange method, key size, key lifetime, etc. to secure the 5G backhaul system |
PMK | Pre-master key |
MK | Master key |
AK | Authentication Key |
CK | Cipher key |
CM | AES128-CMAC |
nx | xth nonce |
ts | Time stamp |
Kold | Secret key generated in previous session |
|| | Concatenation |
[] | Optional parameter |
p, g | p is a pre-configured public modulus (prime) and g is a pre-configured public base for Diffie-Hellman key exchange |
PFS | Perfect Forward Secrecy |
KX-Y | Shared secret key between X and Y. |
3.2 Threat model
3.3 Initial authentication phase
- The TM starts this phase by sending the Auth_Req message to the HUB, which is then transmitted to the ASF. For this goal, the TM obtains the current time information ts, generates an arbitrary random number n1, and prepares for the capability attribute with its possible cryptographic algorithms and so forth.Once these values are initialized, the TM adds IDTM and IDHUB to them and calculates the message authentication code CM1 (by means of CMAC) with the long-term key KTM-ASF. The TM then sends the Auth_Req message to the HUB where the included CM1 is used primarily for the integrity and authenticity of the message to be sent to the ASF via the HUB. When the HUB receives the message, it checks if the IDHUB is correct and ts is within the allowed time window. Only if valid, it transfers the Auth_Req message to the ASF. In this way, the HUB can defend against the resource exhaustion attack, a kind of DoS attack, caused by excessive message flooding. Upon a receipt of the Auth_Req message, the ASF verifies that IDHUB is the HUB’s identifier and ts is valid. In turn, it verifies the CM1 through the shared secret key KTM−ASF. If the above verification is positive, the ASF can trust the TM, and based on the trust it proceeds the next step. In other words, the TM is now authenticated to the ASF.×
- In order to prepare for the ASF_Auth_Res message, the ASF evaluates the TM’s capability and profile, the application data traffic’s security requirements, and the current situation and authorization rule of its backhaul system and environments, thereby deciding the security level. Then, based on the decided security level, it creates the policy by not only deciding cryptographic algorithms, key size, key lifetime, etc., but also choosing whether the Diffie-Hellman key exchange is used or not. Note that the security of the authentication and key exchange can be enhanced if the Diffie-Hellman key exchange is adopted. At the same time, it generates the pre-master key PMK by computing CM(KTM−ASF, ts ||“pre-master key”). Afterwards, the ASF returns the policy and the PMK in the form of the ASF_Auth_Res message to the HUB over the secure channel.
- Upon receiving the ASF_Auth_Res message, the HUB first checks the included policy, from which it adopts the selected cryptographic algorithms, key size, key lifetime, etc. to protect the data communication after this phase. At this point, if recommended, it prepares for the Diffie-Hellman key exchange by choosing its private key y and computing the corresponding public key gy. In addition, the HUB generates a random number n2 and uses the included PMK to calculate the master session key MK = CM(PMK,n1||n2||“master key”). Then, with the session key, it computes the CMAC value CM2 = CM(MK, IDHUB||IDTM||n1||n2||policy[||gy]), followed by sending the Auth_Res message to the TM.
- When the TM receives the Auth_Res message, it checks if the included n1 matches with the initial random number sent by itself, and then computes the PMK and the MK as done by the ASF and the HUB, respectively. Afterwards, the accompanied CM2 is validated with the MK to verify if the Auth_Res message is fresh and authentic. Aside from trusting the message, the TM, if the above validation is positive, can successfully authenticate the HUB because it cannot generate the CM2 without receiving the PMK from the ASF. As the next step, the TM computes the authentication and cipher session keys (AK and CK, respectively) with the MK and the two nonces n1 and n2. At this point, if the given policy recommends the Diffie-Hellman key exchange, the TM should randomly generate its private key x and the corresponding public key gx, and then involve gxy for generating the two session keys AK and CK. Note that in this case, the mutual authentication and key exchange between the HUB and the TM can be enhanced with the Diffie-Hellman key exchange. Moreover, the TM achieves the perfect forward secrecy by removing the private key x from its memory immediately after computing the two keys. On the other hand, only if the CM2 is valid, the TM performs the expensive Diffie-Hellman public key operations, which can prevent the resource exhaustion attacks, a kind of DoS attack. Finally, the TM sends the HUB the Auth_Cfrm message as a session key confirm message. This message, unlike other ones, includes the two CMAC values CM3 and CM4 to confirm that the TM owns the two keys MK and AK, respectively. In particular, if the Diffie-Hellman key exchange is used, the HUB can counter the resource exhaustion attacks by first validating the CM3 prior to the expensive public key operations.
- Once the Auth_Cfrm message arrives, the HUB first uses the MK to test if its CM3 is correct. If the test is successful, the HUB can authenticate the TM and trust its ownership for the MK. Then, the two session keys AK and CK are derived in the same way as done by the TM. The HUB in turn validates the involved CM4 to confirm that the TM owns the AK, which indicates also the TM’s ownership for the CK. Here, if the Diffie-Hellman key exchange is requested, the HUB should compute gxy and reflect it on the session keys AK and CK. In this case, the authentication and key exchange can be strengthened. If the CM4 is valid, the HUB concludes this phase by sending the Auth_Fin message as a key confirmation message. On arrival of this message, the TM validates its CM5 to confirm that both the AK and the CK are agreed well between the HUB and itself. At this point, the message cannot be replayed because the CM5, which is computed with the new session key AK, is fresh.
3.4 Key update phase
- The TM starts this phase by sending the KU_Req message. For this, it prepares for a random number n1 and timestamp ts while optionally generating its Diffie-Hellman public key pair (x, gx) according to the policy set in the initial authentication phase or the policy update phase. Then, the current session key AKold is used to compute the CMAC value CM1 on the above information and the IDs of the TM and the HUB. On receiving the KU_Req message, the HUB validates the CM1 to gain the belief that the TM really wants to update the session keys. Therefore, if the CM1 is valid, it computes the new master session key MK and the new two session keys AK and CK. Even though the Diffie-Hellman key exchange is requested, such session key generation is not vulnerable to the resource exhaustion attacks by performing the public key operations after validating the CM1. Once the new session keys are successfully generated, the HUB computes the two CMAC values CM2 and CM3 where the CM2 shows the HUB owns the new MK and the CM3 shows the HUB owns both the new AK and CK. Finally, it sends the KU_Res message to the TM.×
- Upon receiving the KU_Res message, the TM first checks if the included n1 is correct. In positive case, it generates the new master session key MK, and then uses that new key to verify that the CM2 is valid. If this verification is true, the TM can trust that it shares the new MK with the HUB. Based on such trust, the TM derives the new authentication and cipher session keys AK and CK where the Diffie-Hellman key exchange can be applied if recommended. Here, note that the KU_Res message is not vulnerable to the resource exhaustion attack because the TM generates the new session keys only if the CM2 is correct. Once obtaining the new session keys AK and CK, the TM utilizes the new AK to validate the CM3. If this validation is true, it can obtain the belief that the HUB agrees both the new AK and CK with itself.
- The TM concludes this phase by sending the KU_Cfrm message whose CMAC value CM4 is computed with the new AK. When receiving the message, the HUB first verifies the included n2, then testing if the CM4 is correct. If positive, the HUB can confirm that the TM owns both the new session keys AK and CK as well as the key update process is successfully executed.
3.5 Policy update phase
- If the ASF detects, after communicating with the HUB, the TM’s current security context or the security status of the backhaul system and environments are remarkably changed, it decides the new security level by re-evaluating the TM’s capability and profile, the current application data traffic’s security requirements, the current situation and authorization rule of its backhaul system and environments, and so on. Then, the new policy, policynew, is made according to the determined security level, and transferred to the HUB over the pre-established secure channel. The policy agreement indicates the above procedure. More details on this procedure is beyond this research.×
- When the HUB receives the policynew from the ASF, it starts this phase by transmitting the PU_Req message, which is protected by the CM1. Moreover, this message recommends the TM to accept the policynew. On arrival of this message, the TM validates the timestamp ts and the CM1. If successful, it authenticates the HUB and gains trust enough to adopt the policynew and compute the new session keys MK, CK, and AK. Once this key generation is completed, the new keys MK and AK are used to calculate the two CMAC values CM2 and CM3, respectively. It means that the CM2 indicates that the TM possesses the MK as well as the CM3 indicates that the TM possesses the AK and the CK. Moreover, if the Diffie-Hellman key exchange is applied, the HUB can prevent the resource exhaustion attacks by validating the CM2 prior to the needed public key operations. Finally, the TM sends the PU_Res message to the HUB.
- Upon a receipt of the PU_Res message, the HUB tests if the included n1 matches with what it originally sent. Once this test holds, the HUB first generates the new master session key MK, which is then used to validate the CM2. The CM2, if it is shown to be valid, ensures the HUB that the MK is shared well between the TM and itself. That makes the HUB generate two more new session keys AK and CK, then computing the CM3 with the AK. Here, if the Diffie-Hellan key exchange is applied, the CM2 enables the HUB to defend against the resource exhaustion attacks as mentioned above. Once conforming that the CM3 is valid, the HUB can conclude that both the AK and the CK are agreed between the TM and itself. As a result, based on the CM2 and CM3, the HUB can authenticate the TM and gain the trust on the new session keys. Moreover, it can confirm that the TM adopts the policynew. As the next step, the HUB transmits the PU_Cfrm message to ensure the TM that it has the new authentication session key AK. At this point, the meaning that the HUB has the AK indicates that the HUB has also the MK and the CK.
- On receiving the PU_Cfrm message, the TM first checks if the included n2 and CM4 are valid. If this validation is successful, the authentication of the HUB to the TM, which is first performed based on AKold in (2), is enhanced through the CM4 computed with the AK. More importantly, the TM can confirm that the new session keys are not only agreed between the HUB and itself, but also the HUB is going to reflect the policynewfrom now on.
4 Security analysis
4.1 Security analysis based on BAN-logic
Notation | Meaning |
---|---|
P believes X | P believes the message X and acts as if it is true |
P sees X | P receives the message X |
P said X | P previously sent the message X |
P controls X | P has authority on X |
#(X) | X is fresh |
\(P \overset {K}{\leftrightarrow } Q\) | K is a secret key shared between P and Q |
\(\overset {K}{\rightarrow } P\) | K is the P’s public key |
\(P \overset {K}{\leftrightarrow } Q\) | K is a shared secret between P and Q. |
{X}K | X is encrypted with K |
〈X〉K | X is combined with a secret K |
Rule | Formula |
---|---|
MM: Message Meaning Rule | \(\frac {P\ {\text {believes}}\ P \overset {K}{\leftrightarrow } Q,\ P\ {\text {sees}}\ \{X\}_{K}}{P\ {\text {believes}}\ Q\ {\text {said}}\ X}\) |
\(\frac {P\ {\text {believes}}\ P \overset {K}{\Leftrightarrow } Q,\ P\ {\text {sees}}\ \langle X \rangle _{K}}{P\ {\text {believes}}\ Q\ {\text {said}}\ X}\) | |
\(\frac {P\ {\text {believes}} \overset {K}{\rightarrow } Q,\ P\ {\text {sees}}\ \{X\}_{Q^{-1}}}{P\ {\text {believes}}\ Q\ {\text {said}}\ X}\) | |
NV: Nonce Verification Rule | \(\frac {P\ {\text {believes}}\ \#(X),\ P\ {\text {believes}}\ Q\ {\text {said}}\ X}{P\ {\text {believes}}\ Q\ {\text {said}}\ X}\) |
JR: Jurisdiction Rule | \(\frac {P\ {\text {believes}}\ Q\ {\text {controls}}\ X,\ P\ {\text {believes}}\ Q\ {\text {believes}}\ X}{P\ {\text {believes}}\ X}\) |
FR: Freshness Rule | \(\frac {P\ {\text {believes}}\ \#(X)}{P\ {\text {believes}}\ \#(X,Y)}\) |
DR: Decomposition Rule | \(\frac {P\ {\text {sees}}\ (X,Y)}{P\ {\text {sees}}\ X}\) |
BC: Belief Conjunction Rule | \(\frac {P\ {\text {believes}}\ X,\ P\ {\text {believes}}\ Y}{P\ {\text {believes}}\ (X,Y)} \frac {P\ {\text {believes}}\ Q,\ P\ {\text {believes}}\ (X,Y)}{P\ {\text {believes}}\ Q\ {\text {believes}}\ X}\) |
\(\frac {P\ {\text {believes}}\ Q\ {\text {said}}\ (X,Y)}{P\ {\text {believes}}\ Q\ {\text {said}} X}\) | |
DH: Diffie-Hellman Rule | \(\frac {P\ {\text {believes}}\ Q\ {\text {said}} \overset {g^{Y}}{\rightarrow }Q,\ P\ {\text {believes}}\ \overset {g^{X}}{\rightarrow }P}{P\ {\text {believes}}\ P\ \overset {g^{XY}}{\leftrightarrow } Q}\) |
\(\frac {P\ {\text {believes}}\ Q\ {\text {said}} \overset {g^{Y}}{\rightarrow }Q,\ P\ {\text {believes}}\ \overset {g^{X}}{\rightarrow }P}{P\ {\text {believes}}\ P\ \overset {g^{XY}}{\leftrightarrow } Q}\) |
4.1.1 Initial authentication phase
4.1.2 Key update phase
4.2 Security analysis based on Scyther
Event | Security property |
---|---|
Alive | Authentication |
Nisynch | Authentication |
Niagree | Authentication |
Weakagree | Authentication |
Running / commit | Authentication |
Secret | Secrey |
SKR | Secrey |
5 Performance analysis
Security property | EAP-AKA | EAP-TLS | EAP-IKEv2 | HIP | P2MP |
---|---|---|---|---|---|
SP1 | O | O | O | O | O |
SP2 | O | O | O | O | O |
SP3 | O | O | O | O | O |
SP4 | O | O | O | O | O |
SP5 | X | X | O | O | O |
SP6 | X | O | O | X | O |
SP7 | X | X | X | X | O |
SP8 | O | X | X | X | O |
Document | RFC 4187 | RFC 5216 | RFC 5106 | RFC 5201 | - |
Protocols | Computation overhead | |||
---|---|---|---|---|
TM | HUB | ASF | Total | |
EAP-AKA | 9CHM | – | 9CHM | 18CHM |
EAP-TLS | 1CAS+1CCV+4CHM+2CSYM | – | 1CAS+1CHM+1CSYM+1CSV+1CDS | 1CAS+1CCV+1CSV+1CDS+8CHM+4CSYM |
EAP-IKEv2 | 3CSYM+1CDH+1CCV+1CDS+1CSV+1CHM | – | 3CSYM+1CDH+1CCV+1CDS+1CSV+1CHM | |
HIP | 1Cpuzzle+1CSV+1CDH+1CDS+1CSYM+1CHM | 1CSV+1CDH+1CDS+1CSYM+1CHM | - | 1Cpuzzle+2CSV+2CDH+2CDS+2CSYM+2CHM |
P2MP | 8CHM+1CDH | 6CHM+1CDH | 2CHM | 16CHM+2CDH |
Protocols | Communication overhead | |||
---|---|---|---|---|
TM | HUB | |||
T1 | T2 | T3 | T4 | |
EAP-AKA | 4.5RTT | 4.5RTT | 4RTT | 4TT |
EAP-TLS | 8.5RTT | 8.5RTT | 8RTT | 8RTT |
EAP-IKEv2 | 6.5RTT | 6.5RTT | 6RTT | 6RTT |
HIP | 3.5RTT | 3.5RTT | 3RTT | 3RTT |
P2MP | 3.5RTT | 3.5RTT | 4RTT | 4RTT |