A communication device for communication with a network device during EAP-AKA′. The communication device is operative to receive a first Perfect Forward Secrecy, PFS, parameter value and at least one attribute value indicating a choice of a Diffie-Hellman group from the network device. The communication device is also operative to receive a cipher key, CK, and an integrity key, IK. Generate a modified cipher key, CK′, and a modified integrity key, IK′ based on CK, IK and an access network identity. Operations include calculating a second PFS parameter value. Send the second PFS parameter value to the network device. Calculate a third PFS parameter value. Derive, using a pseudo-random function, a key based on the third PFS parameter value, CK′, IK′ and an identity associated with the communication device. A network device, methods, further communication devices, a server, computer programs and a computer program product are also disclosed.
|
12. A method performed by a server during an extensible authentication Protocol—Authentication and key agreement prime, EAP-AKA′ procedure with a communication device, the method comprising:
obtaining a modified ciphering key, CK′, and a modified integrity key, IK′, based on a ciphering key, CK, and an integrity key, IK, and an access network identity;
generating a public-private key pair for the server;
sending, to a communication device, a public key of the public-private key pair for the server and an attribute indicating
a used or desired key generation function associated with the public key for the server, and
a used or desired elliptic curve Diffie-Hellman ephemeral group related to the public key for the server;
receiving from the communication device a public key of a public-private key pair for the communication device;
generating a shared secret based on a private key of the public-private key pair for the server and the received public key for the communication device; and
deriving a key using a pseudo-random function for communication between the communication device and the server, based on the shared secret, the CK′, the IK′, an identity associated with the communication device and a value representing a choice of a key derivation function.
11. A server comprising a processor and a memory, said memory comprising instructions executable by said processor, whereby said server is operative during an extensible authentication Protocol—Authentication and key agreement prime, EAP-AKA′, procedure to:
obtain a modified ciphering key, CK′, and a modified integrity key, IK′, based on a ciphering key, CK, and an integrity key, IK, and an access network identity;
generate a public-private key pair for the server;
send a public key of the public-private key pair for the server to a communication device and an attribute indicating
a used or desired key generation function associated with the public key for the server, and
a used or desired elliptic curve Diffie-Hellman ephemeral group related to the public key for the server;
receive from the communication device a public key of a public-private key pair for the communication device;
generate a shared secret based on a private key of the public-private key pair for the server and the received public key for the communication device;
derive a key using a pseudo-random function for communication between the communication device and the server, based on the shared secret, the CK′, the IK′, an identity associated with the communication device and a value representing a choice of a key derivation function.
1. A method performed by a communication device during an extensible authentication protocol-authentication and key agreement prime, EAP-AKA′, procedure with a server, the method comprising:
receiving, from the server, a message comprising a public key of a public-private key pair for the server, and an attribute indicating
a used or desired key generation function associated with the public key for the server, and
a used or desired elliptic curve Diffie-Hellman ephemeral group related to the public key for the server;
receiving a ciphering key, CK, and an integrity key, IK, from a universal subscriber identity module;
generating a modified ciphering key, CK′, and a modified integrity key, IK′, based on the CK, IK and an access network identity;
generating a public-private key pair for the communication device;
generating a shared secret based on a private key of the public-private key pair for the communication device and the public key for the server;
sending the public key for the communication device to the server in order to enable the server to generate the shared secret through generation of the shared secret based on the public key for the communication device and a private key of the public-private key pair for the server; and
deriving a key using a pseudo-random function for communication between the communication device and the server, based on the shared secret, the CK′, the IK′, an identity associated with the communication device and a value representing a choice of a key derivation function.
10. A communication device, wherein the communication device comprises a processor and a memory, said memory comprising instructions executable by the processor, whereby said communication device is operative, during an extensible authentication protocol-authentication and key agreement prime, EAP-AKA′, procedure with a server, to:
receive, from a server, a first message comprising a public key of a public-private key pair for the server, and an attribute indicating
a used or desired key generation function associated with the public key for the server and
a used or desired elliptic curve Diffie-Hellman ephemeral group related to the public key for the server;
receive a ciphering key, CK, and an integrity key, IK, from a universal subscriber identity module;
generating a modified ciphering key, CK′, and a modified integrity key, IK′, based on the CK, IK and an access network identity;
generate a public-private key pair for the communication device;
generate a shared secret based on a private key of the public-private key pair for the communication device and the public key for the server;
send the public key for the communication device to the server in order to enable the server to generate the shared secret through generation of the shared secret based on the public key for the communication device and a private key of the public-private key pair for the server; and
derive a key using a pseudo-random function for communication between the communication device and the server, based on the shared secret, the CK′, the IK′, an identity associated with the communication device and a value representing a choice of a key derivation function.
3. A method according to
4. A method according to
5. A method according to
6. A method according to
7. A method according to
8. A method according to
receiving an EAP-Request/identity message from the server, and
sending the identity to the server in an EAP-Response/identity message.
9. A method according to
13. A method according to
14. A method according to
15. A method according to
16. A method according to
17. A method according to
sending an EAP-Request/identity message to the communication device, and
receiving the identity associated with the communication device in an EAP-Response/identity message from the communication device.
18. A method according to
|
|||||||||||||||||||||||||||||||
This application is a 35 U.S.C. § 371 national stage application of PCT International Application No. PCT/EP2018/079689, filed on Oct. 30, 2018, which claims the benefit of U.S. Provisional Patent Application Ser. No. 62/578,710, filed on Oct. 30, 2017, the disclosures and content of which are incorporated by reference herein in their entireties.
The disclosure herein relates to communication devices, a network device and a server which are operative during EAP-AKA′ (Extensible Authentication Protocol-Authentication and Key Agreement prime). The disclosure also relates to methods, computer programs and computer program product therefore.
Data transferred over communication networks is becoming increasingly sensitive. Communication networks, such as mobile, wireless and fixed communication networks, are nowadays more and more frequently used for e.g. various economical and business-related transactions, control of cyber-physical systems, etc. In for instance mobile communications it is important that the communication network and user equipment (UE) mutually authenticate each other and are able to encrypt exchanged traffic data, where both of these security services are critically dependent on secure key management.
AKA (Authentication and Key Agreement)
Current 3GPP systems use (U)SIM pre-shared key based protocols to authenticate subscribers. AKA is based on challenge-response mechanisms and symmetric cryptography. AKA typically runs in a UMTS Subscriber Identity Module (USIM) or a CDMA2000 (Removable) User Identity Module ((R)UIM). In contrast to its earlier GSM counterparts, 3rd generation AKA in 3GPP (Third Generation Partnership Project) provides long key lengths and mutual authentication.
AKA, e.g. in 3rd and 4th generation 3GPP networks, works in the following manner:
Since the addition of replay protection and mutual authentication in the third generation 3GPP systems, there have been no published attacks that violate the security properties defined for the AKA, at least not within the assumed trust model. However, there have been attacks using a different trust model [CB2014] [MT2012]; the protocol was not designed to counter those situations. There have also been attacks against systems where AKA is used in a different setting than initially intended, e.g. [BT2013].
Many different attacks have been reported as part of revelations associated with pervasive surveillance. Some of the reported attacks involved compromising smart cards, such as attacking SIM card manufacturers and operators in an effort to compromise shared secrets stored on these cards. Such attacks are conceivable, for instance, during the manufacturing process of cards, or the transfer of cards and associated information to the operator. Since the publication of reports about such attacks, manufacturing and provisioning processes have gained much scrutiny and have improved.
However, the danger of resourceful attackers attempting to gain information about SIM cards is still a concern. They are a high-value target and concern a large number of people. Note that the attacks are largely independent of the used authentication technology. The issue is not vulnerabilities in algorithms or protocols, but rather the possibility of someone gaining unlawful access to key material. While the better protection of manufacturing and other processes is essential in protecting against this, it would be desirable to further limit the consequences of attacks when they occur.
Recent reports of compromised long term pre-shared keys used in AKA are not specific to AKA or EAP-AKA′, as all security systems fail at least to some extent if key material is stolen. However, the reports [Heist2015] indicate a need to look into solutions that allow a weaker trust model, in particular for future 5G systems. It is also noted in [Heist2015] that, even if the current trust model is kept, some security can be retained in this situation by providing Perfect Forward Security (PFS) [DOW1992] for the session key. If AKA would have provided PFS, compromising the pre-shared key would not be sufficient to perform passive attacks; the attacker is, in addition, forced to be a Man-In-The-Middle (MITM) during the AKA run. Introducing PFS for authentication in 3GPP systems can be achieved by adding a Diffie-Hellman (DH) exchange. WO-20161137374-A1 and [TrustCom2015] discuss these problems and provide a solution associated with the underlying AKA method.
There are however even more things that could be done to mitigate consequences of attacks, e.g. in case of a compromised share key stored on e.g. a tamper resistant smart card such as a UICC, eSIM, eUICC and iUICC etc. Such a key is for example the shared key K in 4th generation 3GPP systems, which key is used for derivation of a cipher key, CK, and an integrity key, IK. An object of the invention is therefore to enable increased security in communications network in case a key shared between two parties becomes known to a third party.
A first aspect of the invention relates to a communication device for communication with a network device. The communication device is operative, during an Extensible Authentication Protocol-Authentication and Key Agreement Prime, EAP-AKA′, procedure, to:
receive a first Perfect Forward Secrecy, PFS, parameter value and at least one attribute value indicating a choice of a Diffie-Hellman group from the network device;
receive a ciphering key, CK, and an integrity key, IK, from a Universal Subscriber Identity Module, USIM;
generate a modified ciphering key, CK′, based on the CK, the IK and an access network identity;
generate a modified integrity key, IK′, based on the CK, the IK and the access network identity;
calculate a second PFS parameter value;
send the second PFS parameter value to the network device;
calculate a third PFS parameter value based on the first PFS parameter value and the second PFS parameter value; and
derive, using a Pseudo-random function, a key for communication between the communication device and the network device or any other network device associated with the network device, based on the third PFS parameter value, the CK′, the IK′ and an identity associated with the communication device.
A second aspect of the invention relates to a network device which comprises a processor and a memory, said memory comprising instructions executable by said processor,
whereby said network device is operative during an EAP-AKA′ procedure to:
obtain a modified ciphering key, CK′, based on a ciphering key, CK, an integrity key, IK, and an access network identity;
obtain a modified integrity key, IK′, based on the CK, the IK, and the access network identity;
calculate a first PFS, PFS parameter value;
send the first PFS parameter value and at least one attribute value indicating a choice of a Diffie-Hellman group to a communication device;
receive a second PFS parameter value from the communication device;
calculate a third PFS value based on the first PFS parameter value and the second PFS parameter value; and
derive, using a Pseudo-random function, a key for communication between the communication device and the network device or any other network device associated with the network device, based on the third PFS parameter value, the CK′, the IK′ and an identity associated with the communication device.
A third aspect of the invention relates to a communication device for communication with a network device. The communication device comprises a PFS Extensible Authentication Protocol-Authentication and Key agreement prime, PFS EAP-AKA′, module for, during an EAP-AKA′ procedure:
receiving a ciphering key, CK, and an integrity key, IK, from a USIM;
generating a modified ciphering key, CK′, based on the CK, the IK and an access network identity;
generating a modified integrity key, IK′, based on the CK, the IK and the access network identity;
receiving a first PFS parameter value and at least one attribute value indicating a choice of a Diffie-Hellman group from the network device from the network device;
calculating a second PFS parameter value;
sending the second PFS parameter value to the network device;
calculating a third PFS parameter value based on the first PFS parameter value and the second PFS parameter value; and
deriving, using a Pseudo-random function, a key for communication between the communication device and the network device or any other network device associated with the network device, based on the third PFS parameter value, the CK′, the IK′, and an identity associated with the communication device.
A fourth aspect of the invention relates to a method performed by a communication device for communication with a network device during EAP-AKA′ procedure. The method comprises:
receiving a first PFS parameter value and at least one attribute value indicating a choice of a Diffie-Hellman group from the network device;
receiving a ciphering key, CK, and an integrity key, IK;
generating a modified ciphering key, CK′, based on the CK, the IK and an access network identity;
generating a modified integrity key, IK′, based on the CK, the IK and the access network identity;
calculating a second PFS parameter value;
sending the second PFS parameter value to the network device;
calculating a third PFS parameter value based on the first PFS parameter value and the second PFS parameter value; and
deriving, using a Pseudo-random function, a key for communication between the communication device and the network device or any other network device associated with the network device, based on the third PFS parameter value, the CK′, the IK′ and an identity associated with the communication device.
A fifth aspect of the invention relates to a method performed by a network device during EPA-AKA′ procedure. The method comprises:
obtaining a modified ciphering key, CK′, based on a ciphering key, CK, an integrity key, IK, and an access network identity;
obtaining a modified integrity key, IK′, based on the CK, the IK, and the access network identity;
calculating a first PFS parameter value;
sending the first PFS parameter value and at least one attribute value indicating a choice of a Diffie-Hellman group to a communication device;
receiving a second PFS parameter value from the communication device;
calculating a third PFS value based on the first PFS parameter value and the second PFS parameter value; and
deriving, using a Pseudo-random function, a key for communication between the communication device and the network device or any other network device associated with the network device, based on the third PFS parameter value, the CK′, the IK′, and an identity associated with the communication device.
A sixth aspect of the invention relates to a computer program for a communication device in communication with a network device of a communication network. The computer program comprising computer program code which when run in the communication device, causes the communication device, during an EAP-AKA′ process to:
receive a first PFS parameter value and at least one attribute value indicating a choice of a Diffie-Hellman group from the network device;
receive a ciphering key, CK, and an integrity key, IK, from a USIM;
generate a modified ciphering key, CK′, based on the CK, the IK and an access network identity;
generate a modified integrity key, IK′, based on the CK, the IK and the access network identity;
calculate a second PFS parameter value;
send the second PFS parameter value to the network device;
calculate a third PFS parameter value based on the first PFS parameter value and the second PFS parameter value; and
derive, using a Pseudo-random function, a key for communication between the communication device and the network device or any other network device associated with the network device, based on the third PFS parameter value, the CK′, the IK′, and an identity associated with the communication device.
A seventh aspect of the invention relates to a computer program for a network device of a first or second communication network. The computer program comprises computer program code which when run in the network device, causes the network device, during an Extensible Authentication Protocol-Authentication and Key agreement prime, EAP-AKA′, procedure to:
obtain a modified ciphering key, CK′, based on a ciphering key, CK, an identity key, IK, and an access network identity;
obtain a modified integrity key, IK′, based on the CK, the IK, and the access network identity;
calculate a first PFS parameter value;
send the first PFS parameter value and at least one attribute value indicating a choice of a Diffie-Hellman group to a communication device;
receive a second PFS parameter value from the communication device;
calculate a third PFS value based on the first PFS parameter value and the second PFS parameter value; and
derive, using a Pseudo-random function, a key for communication between the communication device and the network device or any other network device associated with the network device, based on the third PFS parameter value, the CK′, the IK′, and an identity associated with the communication device.
An eighth aspect of the invention relates to a computer program product for enhancing the communication security of a communication device in communication with a network device of a communication network, the computer program product comprising a computer readable storage medium with computer program code according to the sixth or seventh aspects above.
A ninth aspect of the invention relates to a method performed by a communication device during an EAP-AKA′ procedure with a server. The method comprises:
A tenth aspect of the invention relates to a communication device, wherein the communication device comprises a processor and a memory. The memory comprises instructions executable by the processor, whereby said communication device is operative, during an EAP-AKA′ procedure with a server, to:
An eleventh aspect of the invention relates to a server comprising a processor and a memory. The memory comprises instructions executable by said processor, whereby said server is operative during an EAP-AKA′ procedure to:
A twelfth aspect of the invention relates to a method performed by a server during an EAP-AKA′ procedure with a communication device: The method comprises:
The communication device is in an embodiment of the first and third aspects a user equipment or an embedded telematics unit in a vehicle or an embedded telematics unit in a robot.
The third PFS parameter value is in an embodiment of the first to fifth aspects a Diffie-Hellman value.
The first PFS parameter value is in an embodiment of the first to fifth aspects a public key of a public-private key pair for the network device and the second PFS parameter value is in that embodiment a public key of a public-private key pair for the communication device. In such an embodiment, the communication device may be operative to generate the third PFS parameter value based (also) on a private key of the public-private key pair for the communication device.
In an embodiment of the first to fifth and ninth and twelfth aspects, the identity associated with the communication device is a Network Access Identifier, NAI, or a part of the NAI. In an alternative embodiment to the preceding embodiment of the first to fifth aspects, the identity associated with the communication device is an International Mobile Subscriber Identity, IMSI.
In an embodiment of the first and third and fifth aspects, the communication device is operative to derive the key also based on an ASCII string representing an EAP-AKA′ value. The ASCII string may in such an embodiment be eight or twelve characters long. In an embodiment of the ninth and twelfth aspects, the ASCII string is twelve characters long and indicates a choice of a KDF.
The key is in an embodiment of the first and second aspects derived with an input value to the pseudo-random function, which may be PRF′, said input value being a concatenation of the modified integrity key, the modified ciphering key, the third PFS parameter value, the EAP-AKA′ value and the identity associated with the communication device.
The at least one attribute value also indicates in an embodiment of the first to fifth aspects a key derivation function, KDF.
The Diffie-Hellman group is in an embodiment of the first to fifth aspects a 1024-bit MODP group specified in Appendix B.2 of IETF RFC 7296.
The Diffie-Hellman group is in another embodiment of the first to fifth aspects an Elliptic Curve Diffie-Hellman Ephemeral group. In such an embodiment, the Diffie-Hellman group may be a Curve25519 group as specified in IETF RFC 8031.
In an embodiment of the first and third and fourth aspects, the communication device is operative to calculate the second PFS parameter value and send the second PFS parameter value to the network device each time the communication device performs the EAP-AKA′ procedure.
In an embodiment of the first and fourth aspects, the communication device is operative to receive from the network device an attribute value indicating use of a Message Authentication Code applicable for PFS parameter negotiation in EAP-AKA′ and wherein the attribute value indicates that the Message Authentication Code has been calculated over a whole Extensible Authentication Protocol, EAP, packet containing an EAP header, an EAP-AKA′ header and attribute values including the first PFS parameter value.
In an embodiment of the first aspect, the communication device is operative to:
receive an EAP-Request/Identity message from the network device, and
send the identity associated with the communication device to the network device in an EAP-Response/Identity message.
The at least two attributes are in an embodiment of the first aspect received from the network device, wherein each one of the attributes indicates both a choice of a Diffie-Hellman group and key derivation function for the derivation of the key.
The identity associated with the communication device is in an embodiment of the first aspect sent in an AT_IDENTITY attribute in an EAP-Response/AKA-Identity message.
A communication device comprises in an embodiment of the first aspect a processor and a memory, said memory comprising instructions executable by the processor, whereby said communication device is operative to:
receive the first PFS parameter value from the network device;
receive the CK and the IK from the USIM;
generate the CK′ based on the CK, the IK and the access network identity;
generate the IK′ based on the CK, the IK and the access network identity;
calculate the second PFS parameter value;
send the second PFS parameter value to the network device;
calculate the third PFS parameter value based on the first PFS parameter value and the second PFS parameter value; and
derive, using a Pseudo-random function, the key for communication between the communication device and the network device or any other network device associated with the network device, based on the third PFS parameter value, the CK′, the IK′ and the identity associated with the communication device. The communication device according to this embodiment may also perform the other actions mentioned above in relation to the first aspect.
The network device is in an embodiment of the second aspect a Mobility Management Entity.
The network device is in an embodiment of the second aspect operative to send an EAP-Request/Identity message to the communication device, and receive the identity associated with the communication device in an EAP-Response/Identity message.
The network device is in an embodiment of the second aspect operative to send the identity associated with the communication device to a Home Subscriber Server.
The network device is in an embodiment of the second aspect operative to receive CK′ and IK′ from the Home Subscriber Server.
In an embodiment of the second aspect, at least two attributes are generated and sent to the communication device, which attributes indicate both a choice of a Diffie-Hellman group and key derivation function for the derivation of the key for each one of the attributes.
The network device according an embodiment of the second and fifth aspects, is operative to, before the second PFS parameter value has been received from the communication device, derive a second key based on only the CK′, the IK′, the EAP-AKA′ attribute value and the identity associated with the communication device. In such an embodiment, the network device may be operative to derive an authentication key from the second key, and generate an attribute value indicating the use of the message authentication code applicable for PFS parameter negotiation in EAP-AKA′, and including that attribute value in a first EAP-Request/AKA′-Challenge message sent from the network device to the communication device.
The PFS EAP-AKA′, module is in an embodiment of the third aspect operative to generate the third PFS parameter value based on a private key of the public-private key pair for the communication device.
The PFS EAP-AKA′ module is in an embodiment of the third aspect configured to: receive from the network device an attribute value indicating use of the message authentication code applicable for PFS parameter negotiation in EAP-AKA′ and wherein the attribute value indicates that a Message Authentication Code has been calculated over a whole Extensible Authentication Protocol, EAP, packet containing an EAP header, an EAP-AKA′ header and attribute values including the first PFS parameter value.
The CK and IK are received from a USIM in an embodiment of the method according to the fourth aspect.
The network device is in an embodiment of the second and fifth aspects operative to calculate a Message Authentication Code over a whole EAP packet containing an EAP header, an EAP-AKA′ header and attribute values including the first PFS parameter value; and
send, to the communication device, an attribute value indicating use of the message authentication code applicable for PFS parameter negotiation in EAP-AKA′.
The message is in an embodiment of the ninth aspect an EAP-Request/AKA′-Challenge.
The Elliptic Curve Diffie-Hellman Ephemeral group is in an embodiment of the ninth and twelfth aspects a Curve25519 group as specified in IEIF RFC 8031.
In an embodiment of the ninth aspect, the method comprises generating and sending the public key for the communication device to the server each time the communication device performs the EAP-AKA′ procedure.
In an embodiment of the ninth aspect, the method comprises receiving a Message Authentication Code attribute from the server, where the Message Authentication Code attribute protects the public key for the server and the attribute that indicates a used or desired key generation function associated with the public key and a used or desired Elliptic Curve Diffie-Hellman Ephemeral group related to the public key for the server.
In an embodiment of the ninth aspect, the method comprises receiving an EAP-Request/Identity message from the server, and sending the identity to the server in an EAP-Response/Identity message.
In an embodiment of the ninth aspect, at least two attributes are received from the server, wherein each one of the attributes indicates both a choice of an Elliptic Curve Diffie-Hellman Ephemeral group and key derivation function for the derivation of the key.
In an embodiment of the twelfth aspect, the method comprises sending a Message Authentication Code attribute to the communication device, where the Message Authentication Code attribute protects the public key for the server and the attribute that indicates a used or desired key generation function associated with the public key and a used or desired Elliptic Curve Diffie-Hellman Ephemeral group related to the public key for the server.
In an embodiment of the twelfth aspect, the method comprises sending an EAP-Request/Identity message to the communication device, and receiving the identity associated with the communication device in an EAP-Response/Identity message from the communication device.
In an embodiment of the twelfth aspect, at least two attributes are sent by the server to the communication device, wherein each one of the at least two attributes indicates both a choice of an Elliptic Curve Diffie-Hellman Ephemeral group and key derivation function for the derivation of the key.
Hereby is achieved through at least some of the aspects and their embodiments that a large portion of the current structure of 3GPP (Third Generation Partnership Project) interfaces may be re-used while still increasing security, with the rationale that this will make the construction more easily adopted. For example, no changes to the interface between a Universal Subscriber Identification Module (USIM) and the mobile terminal is needed, i.e. with 3GPP terminology the interface between the Mobile Equipment (ME) and the USIM is needed (the ME is a part of the UE). As a consequence, there is no need, or at least a decreased need, to roll out new credentials to existing subscribers associated with “leaked” shared keys.
An effect of at least some embodiments enables mutual securer authentication between a server and peer which utilizes EAP-AKA′, and establishes keying material for secure communication between the two. New properties are achieved for the key material, that are not present in EAP-AKA′ in its original form. An extension of EAP-AKA′ for PFS is therefore enabled, rather than a completely new authentication method. A solution according to at least some of the aspects of the invention and embodiments thereof may be implemented as one or a set of new, optional attributes, that are provided alongside the base attributes in EAP-AKA′. Old implementations can ignore these attributes, but their presence will nevertheless be verified as part of base EAP-AKA′ integrity verification process, helping protect against bidding down attacks. Such an extension enables a maintained number of rounds necessary to complete the EAP-AKA′ protocol.
An improved defence against pervasive surveillance. It should be noted that PFS and defences against passive attacks are by no means a panacea, but they can provide a partial defence that increases the cost and risk associated with pervasive surveillance.
It should also be noted that the planned 5G network architecture includes the use of the EAP framework for authentication. The default authentication method within that context will be EAP-AKA′, but other methods can certainly also be run according to at least some of the embodiments disclosed herein.
The embodiments will now be described in more detail in relation to the enclosed drawings, in which:
EAP-AKA′ Protocol
The disclosure in this text enables an extension, which may be optional, to the EAP-AKA′ authentication method. Such an extension provides Perfect Forward Secrecy (PFS) for a session key generated as a part of the authentication run in EAP-AKA′. This prevents an attacker who has gained access to the long-term pre-shared secret (normally called the key K in 3rd and 4th generation 3GPP systems) in a SIM card/UICC from merely passively eavesdropping the EAP-AKA′ exchanges and deriving associated session keys. Attackers would thus be forced to use active attacks instead.
PFS means that even if a long term key (such as the shared key K (usually 128-bits) stored in a UICC/USIM in a communication device and in an associated home network such as in a HSS (Home Subscriber Server)/AuC (Authentication Centre)) used to establish session keys is exposed, it still does not imply that past session keys are also exposed. That is, the session key is secure in a future where the long-term key has been compromised.
The enhancements in the protocol (EAP-AKA′ PFS) specified here are compatible with the signalling flow and other basic structures of both AKA and EAP-AKA′. An effect of at least some embodiments is that the enhancement as optional attributes may be implemented in such a way that legacy implementations can ignore them.
A purpose of the EAP-AKA′ protocol is to achieve mutual authentication between the EAP server and peer, and to establish keying material for secure communication between the two. The enhancements brought with the embodiments of in this disclosure specifies the calculation of key material, providing new properties that are not present in key material provided by EAP-AKA′ in its original form.
As is seen in
PFS parameter values in the form of a Diffie-Hellman value G{circumflex over ( )}xy can be obtained as G{circumflex over ( )}(xy) or G{circumflex over ( )}(yx) (which will produce the same value for G{circumflex over ( )}xy). The key may more particularly be obtained as a base value G raised to a random number x raised to a random number y, or, G raised to y raised to x, i.e.
(G{circumflex over ( )}x){circumflex over ( )}y or (G{circumflex over ( )}y){circumflex over ( )}x.
The term “random” should here be understood as including both statistically random as well as pseudo-random.
As can be seen in
pub_communication device=X(d,G)
The communication device and the server exchange their public keys and compute a shared secret, which by the communication device is computed as:
Shared_Secret=X(d,pub_server).
The correspondence at the server side is:
Public key pub_server=X(d,G)
Shared secret=X(d,pub_communication device)
A modified cipher/ciphering key CK′ and a modified integrity key IK′ are in both embodiments associated with
When deriving CK′, IK′ from CK, IK and the access network identity, the following parameters shall be used to form the input S to the KDF.
If AK is not used, then AK shall be treated in accordance with 3GPP TS 33.102, i.e. as 000 . . . 0.
The access network identity is defined separately for each access network type. For each access network type, the access network identity is documented in TS 24.302 to ensure that UE and HSS use the same access network identities as input for key derivation. The SQN is a sequence number and AK is an anonymity key.
The input key shall be the concatenation CK∥IK of CK and IK.
The KDF returns a 256-bit output, where the 128 most significant bits are identified with CK′ and the 128 least significant bits are identified with IK′.
Alternatively, such as in New Radio/5G, the network identity may be the serving network name which is input to the above KDF of TS 33.402 as the value P0 of access network identity. The serving network name is in this alternative case a concatenation of a service code set to ‘5G’ and a Serving Network (SN) Id, e.g. using a character “:”.
The term Identity refers to at least a part, but in some embodiments the whole identity string, that is used to identify the peer/communication device and/or the user of the peer/communication device. The user of the peer device may for example be identified by an IMSI stored on the USIM of a UICC. The identity may include a realm portion and a user name portion. The user name may be e.g. a permanent user name, a pseudonym username or a fast re-authentication username. The term peer refers to either a UE/communication device for end users, but it can also be a server end.
NAI: Network Access Identifier according to IETF RFC 4282.
AT_RAND, AT_AUTN, AT_RES, AT_MAC, AT_KDF_INPUT and AT_KDF are for the skilled person previously known attributes as such within EAP-AKA′, but are described herein to make them more readily available to the reader.
AT_RAND
The format of the AT_RAND attribute is shown below in
AT_AUTN
The format of the AT_AUTN attribute is shown in
The value field of the AT_AUTN attribute contains two reserved bytes followed by the AKA AUTN parameter, 16 bytes (128 bits). The reserved bytes are set to zero when sending and ignored on reception.
AT_RES
The format of the AT_RES attribute is shown in
The value field of the AT_RES attribute begins with the 2-byte RES Length, which identifies the exact length of the RES in bits. The RES length is followed by the AKA RES parameter. The length of the AKA RES can vary between 32 and 128 bits. Because the length of the AT_RES attribute must be a multiple of 4 bytes, the sender pads the RES with zero bits where necessary.
AT_MAC
The AT_MAC attribute is used for EAP-AKA message authentication. The value field of the AT_MAC attribute contains two reserved bytes followed by a keyed message authentication code (MAC). The MAC is calculated over the whole EAP packet and concatenated with optional message-specific data, with the exception that the value field of the MAC attribute is set to zero when calculating the MAC. The EAP packet includes the EAP header that begins with the Code field, the EAP-AKA header that begins with the Subtype field, and all the Attributes. The reserved bytes in AT_MAC are set to zero when sending and ignored on reception.
The format of the AT_MAC attribute is shown in
The MAC algorithm is HMAC-SHA1-128 keyed hash value. (The HMAC-SHA1-128 value is obtained from the 20-byte HMAC-SHA1 value by truncating the output to 16 bytes. Hence, the length of the MAC is 16 bytes.)
When the AT_MAC attribute is included in an EAP-AKA message, the recipient processes the AT_MAC attribute before looking at any other attributes, except when processing EAP-Request/AKA-Challenge.
However, when used within EAP-AKA′, the AT_MAC attribute is changed as follows. The MAC algorithm is HMAC-SHA-256-128, a keyed hash value. The HMAC-SHA-256-128 value is obtained from the 32-byte HMAC-SHA-256 value by truncating the output to the first 16 bytes. Hence, the length of the MAC is 16 bytes.
Otherwise, the use of AT_MAC in EAP-AKA′ follows Section 10.15 of [RFC4187].
AT_KDF_INPUT
The format of the AT_KDF_INPUT attribute is shown in
AT_KDF_INPUT field: This is set to 23.
Length field: The length of the attribute, calculated as defined in [RFC4187].
AT_KDF
AT_KDF is an attribute that the server/network device uses to reference a specific key derivation function. It offers a negotiation capability that can be useful for future evolution of the key derivation functions. The format of the AT_KDF attribute is shown in
The fields in the AT_KDF attribute are as follows:
AT_KDF: This is set to 24.
Length: Set to 1.
Now turning to new attributes according to embodiments associated with
AT_GX
The AT_GX carries a Diffie-Hellman value. The format of the AT_GX attribute according to an embodiment is shown in
AT_GX: This field is set to TBA1 BY IANA.
Length: The length of the attribute, set as other attributes in EAP-AKA [RFC4187].
Value: This value is the server's Diffie-Hellman public value. The length of the Diffie-Hellman public value for e.g. MODP groups may be, and in some embodiments is, equal to the length of the prime modulus over which the exponentiation was performed, prepending zero bits to the value if necessary.
AT_GY
The AT_GY carries a Diffie-Hellman value. The format of the AT_GX attribute according to the same embodiment for AT_GX above is shown in
AT_GY: Set to TBA2 BY IANA.
Length: The length of the attribute, set as other attributes in EAP-AKA [RFC4187].
Value: This value is the peer's/communication device's Diffie-Hellman public value. The length of the Diffie-Hellman public value for MODP groups is equal to the length of the prime modulus over which the exponentiation was performed, prepending zero bits to the value if necessary.
AT_PUB_ECDHE
In an embodiment where the AT_GX and AT_GY values are public keys in the form of an ECDHE (Elliptic Curve Diffie-Hellman Ephemeral) public value, such as in the embodiment illustrated in
The fields of the AT_PUB_ECDHE attribute are as follows:
AT_PUB_ECDHE: This is set to TBA1 BY IANA.
Length: The length of the attribute, set as other attributes in EAP-AKA [RFC4187].
Value: The value is then the sender's (i.e. the communication device/peer or the network node/server) ECDHE public value. For Curve25519, the length of this value is 32 bytes, encoded in binary as specified [RFC7748] Section 6.1. To retain the security of the keys, the sender shall in an embodiment of the invention generate a fresh value for each run of the protocol.
AT_KDF_DH
The AT_KDF_DH indicates the used or desired key generation function, if the PFS extension according to the embodiment of
The format of the AT_KDF_DH attribute is shown in
The fields of AT_KDF_DH are as follows:
AT_KDF_DH: This field is set to TBA3 BY IANA.
Length: The length of the attribute is set to 1.
Key Derivation Function: An enumerated value representing the key derivation function that the server (or peer) wishes to use. This field takes on different values as the AT_KDF attribute Key Derivation Function.
A server/servers may, and in some embodiments must, send one or more AT_KDF_DH attributes in the EAP-Request/AKA′-Challenge message. These attributes represent the desired functions ordered by preference, the most preferred function being the first attribute.
AT_KDF_PFS
In an embodiment, e.g. in the case where ECDHE is used, the AT_KDF_DH may be called AT_KDF_PFS as in the embodiment of
The format of the AT_KDF_PFS attribute is shown in
The fields for the AT_KDF_PFS attribute are as follows:
AT_KDF_PFS: This is set to TBA2 BY IANA.
Length: The length of the attribute is set to 1.
Key Derivation Function: An enumerated value representing the key derivation function that the server (or peer) wishes to use. This field has a different name space than the similar field in the AT_KDF attribute Key Derivation Function.
AT_MAC_DH
Some embodiments, such as the one illustrated in
The value field of the AT_MAC_DH attribute contains two reserved bytes followed by a keyed message authentication code. The MAC is in such embodiments calculated over the whole EAP packet and concatenated with optional message-specific data, with the exception that the value field of the AT_MAC and AT_MAC_DH attributes are set to zero when calculating the MAC. This is done in this manner to ensure that AT_MAC_DH can be calculated first, and then AT_MAC calculated as normal (with AT_MAC_DH value already filled in). This enables a receiver unaware of this extension to check the value of AT_MAC without having to understand the procedures in setting various fields to zero when calculating AT_MAC_DH.
In these calculations, the EAP packet includes the EAP header that begins with the Code field, the EAP-AKA′ header that begins with the Subtype field, and all the attributes. The reserved bytes in AT_MAC_DH are set to zero when sending and ignored on reception. The contents of the message-specific data that may be included in the MAC calculation are the same as those for AT_MAC (see [RFC4187]).
The format of the AT_MAC_DH attribute is shown in
The fields of this attributes are:
AT_MAC_DH: This is set to TBA4 BY LANA.
Length: The length of the attribute, MUST be set to 5.
Reserved: This field is set to zero when sent and ignored on receipt.
The MAC algorithm is HMAC-SHA1-128 [RFC2104] keyed hash value. (The HMAC-SHA1-128 value is obtained from the 20-byte HMAC-SHA1 value by truncating the output to 16 bytes. Hence, the length of the MAC is 16 bytes.) The key K_aut_pre is used for in the EAP-Request/AKA′-Challenge message and K_aut in corresponding EAP-Response message.
When the AT_MAC_DH attribute is included in an EAP-AKA′ message, the recipient must process the AT_MAC_DH attribute before looking at any other attributes, except when processing EAP-Request/AKA′-Challenge. If the message authentication code is invalid, then the recipient ignores all other attributes in the message and operate as specified in [RFC4187] Section 6.3.
New Key Derivation Function
A new Key Derivation Function type is defined for “EAP-AKA′ with DH and 1024-bit MODP”, represented by value 1. It represents a particular choice of key derivation function and at the same time selects a Diffie-Hellman group to be used.
The Key Derivation Function type value is only used in the AT_KDF_DH attribute in the embodiment of
The new KDF or another new KDF may in the embodiment of ECDHE in
Upon receiving a set of the above attributes, if the peer supports and is willing to use the key derivation function indicated by the first AT_KDF_DH/AT_KDF_PFS attribute, and is willing and able to use the extension according to any one of the embodiments of
Upon receiving an EAP-Response/AKA′-Challenge with AT_KDF_DH/AT_KDF_PFS from the peer, the server checks that the suggested AT_KDF_DH/AT_KDF_PFS value was one of the alternatives in its offer. The first AT_KDF_DH/AT_KDF_PFS value in the message from the server is not a valid alternative. If the peer has replied with the first AT_KDF_DH/AT_KDF_PFS value, the server behaves as if AT_MAC_DH (if used, otherwise AT_MAC) of the response had been incorrect and fails the authentication. For an overview of the failed authentication process in the server side, see
When the peer receives the new EAP-Request/AKA′-Challenge message, it may, and in some embodiments must, check that the requested change, and only the requested change occurred in the list of AT_KDF_DH/AT_KDF_PFS attributes. If yes, it continues. If not, it behaves as if AT_MAC/AT_MAC_DH had been incorrect and fails the authentication. If the peer receives multiple EAP-Request/AKA′-Challenge messages with differing AT_KDF_DH/AT_KDF_PFS attributes without having requested negotiation, the peer may, and in some embodiments behaves as if AT_MAC/AT_MAC_DH had been incorrect and fail the authentication.
When AT_KDF_DH is set to 1 by IANA, the Master Key (MK) is derived and as follows:
MK=PRF′(IK′|CK′|G{circumflex over ( )}xy,“EAP-AKA′”|Identity)
K_encr=MK[0 . . . 127]
K_aut=MK[128 . . . 383]
K_re=MK[384 . . . 639]
MSK=MK[640 . . . 1151]
EMSK=MK[1152 . . . 1663]
and the rest of computation proceeds as defined in Section 3.3 of [RFC5448]. The above values are sufficient for all messages and all behaviour in the protocol, starting from (and included) the EAP-Response/AKA′-Challenge message that the peer sends to the server to successfully complete authentication.
K_encr (encryption key) is thus 128 bits, K_aut (authentication key) is 256 bits, and K-re (re-authentication key) is 256 bits.
The Pseudo-Random Function PRF′ construction is the same as the IKEv2 uses and is referred to in section 3.4.1 of [RFC5448]. The value “EAP-AKA′” is typically an eight-character-long ASCII (American Standard Code for Information Interchange) string. It is used as is, without any trailing NUL characters. The PRF′ takes two arguments. K is a 256-bit value and S is an octet string of arbitrary length. The alternative PRF′ is defined as follows:
PRF′(K,S)=T1|T2|T3|T4| . . . .
T1=HMAC-SHA-256 (K, S|0x01)
T2=HMAC-SHA-256 (K, T1|S|0x02)
T3=HMAC-SHA-256 (K, T2|S|0x03)
T4=HMAC-SHA-256 (K, T3|S|0x04) . . . .
The PRF′ produces as many bits of output as is needed. HMAC-SHA-256 is the application of HMAC [RFC2104] to SHA-256.
The MSK (Master Session Key) is keying material that is derived between the EAP peer and server and exported by the EAP method. The MSK is at least 64 octets in Length and in the embodiments disclosed here 512 bits. In existing implementations, a AAA server acting as an EAP server transports the MSK to the authenticator.
The EMSK (Extended Master Session Key) is additional keying material derived between the EAP client/communication device/peer and server that is exported by the EAP method. The EMSK is at least 64 octets in length and in EAP-AKA′ 512 bits. The EMSK is not shared with the authenticator or any other third party. The value “EAP-AKA′” may in another embodiment, especially for use when generating a session key such as EMSK, be a twelve-characters-long ASCII string. An alternative name for the twelve-characters-long ASCII string version, especially for directly or indirectly generating EMSK with the help of a Diffie-Hellman value, is “EAP-AKA′ PFS” to distinguish it from an eight-character value for use in EAP-AKA′ key derivation without the use of PFS parameters sent between the communication device and the network node/server. This twelve-character ASCII string for EAP-AKA′ PFS can thus be used as input for example when “EAP-AKA′ with DH and 1024-bit MODP” is used/selected and for an “EAP-AKA′ with ECDHE and Curve25519” selection (see below).
K_aut that is used in AT_MAC is still exactly as it was in EAP-AKA′. The only change to key derivation is in re-authentication keys and keys exported out of the EAP method, MSK and EMSK. As a result, EAP-AKA′ attributes such as AT_MAC continue to be usable even when this extension is in use and with or without the use of AT_MAC_DH.
K_aut_pre and K_encr_pre are to be used before the first successful EAP-Response/AKA′-Challenge message. This includes the EAP-Request/AKA′-Challenge message sent by the server, where the AT_MAC_DH value will use K_aut_pre. However, since now MK depends on G{circumflex over ( )}xy that is only available once both sides have both G{circumflex over ( )}x and G{circumflex over ( )}y, messages and behaviour before the successful EAP-Response/AKA′-Challenge message need to use values that do not depend on G{circumflex over ( )}xy:
MK_pre=PRF′(IK′|CK′,“EAP-AKA′”|Identity)
K_encr_pre=MK[0 . . . 127]
K_aut_pre=MK[128 . . . 383]
Introducing PFS for EAP-AKA′ can as mentioned above in an alternative embodiment be achieved by using an Elliptic
Curve Diffie-Hellman (ECDH) exchange [RFC7748]. In EAP-AKA′ PFS this exchange is run in an ephemeral manner, i.e., using temporary keys as specified in [RFC8031] Section 2.
In the embodiment illustrated in
MK=PRF′(IK′|CK′,“EAP-AKA′”|Identity)
MK_ECDHE=PRF′(IK′|CK′|SHARED_SECRET,“EAP-AKA′PFS”|Identity)
K_encr=MK[0 . . . 127]
K_aut=MK[128 . . . 383]
K_re=MK_ECDHE[0 . . . 255]
MSK=MK_ECDHE[256 . . . 767]
EMSK=MK_ECDHE[768 . . . 1279]
Where SHARED_SECRET (corresponding to the third PFS parameter of the claims of this specification) is the shared secret computed via ECDHE, as specified in Section 2 of [RFC8031] and Section 6.1 of [RFC7748]. Both the peer and the server may check for zero-value shared secret as specified in Section 6.1 of [RFC7748]. If such checking is performed and the SHARED_SECRET has a zero value, both parties behaves as if the current EAP-AKA′ authentication process starts again from the beginning. Note that the way that shared secret is tested for zero can, if performed inappropriately, provide an ability for attackers to listen to CPU power usage side channels. Refer to [RFC7748] for a description of how to perform this check in a way that it does not become a problem.
Diffie-Hellman Groups
The selection of suitable groups for the Diffie-Hellman computation is necessary. The choice of a group is made at the same time as deciding to use of particular key derivation function in AT_KDF_DH. For “EAP-AKA′ with DH and 1024-bit MODP” the Diffie-Hellman group is the 1024-bit MODP group specified in Appendix B.2 of [RFC7296] as follows.
Group 2—1024-bit MODP
This group is assigned ID 2 (two).
The prime is 2{circumflex over ( )}1024−2{circumflex over ( )}960−1+2{circumflex over ( )}64*{[2{circumflex over ( )}894 pi]+129093}.
Its hexadecimal value is:
FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE65381
FFFFFFFF FFFFFFFF
The generator is 2.
In an embodiment where ECDHE is used for the enhancement of EAP-AKA′, selection of suitable groups for the elliptic curve computation is necessary. The choice of a group is made at substantially the same time as when deciding to use a particular key derivation function in AT_KDF_PFS. For “EAP-AKA′ with ECDHE and Curve25519” the group is the Curve25519 group specified in [RFC8031].
Message Processing
Changes related to message processing when the extension according to the above embodiments is used in EAP-AKA′ are now described. It is specified when a message may be transmitted or accepted, which attributes are allowed in a message, which attributes are required in a message, and other message-specific details, where those details are different for this extension than the base EAP-AKA′ or EAP-AKA protocol. Unless otherwise specified here, the rules from [RFC5448] or [RFC4187] apply.
EAP-Request/AKA′-Identity
In at least some of the embodiments, no changes, except that the AT_KDF_DH, AT_GX, AT_GY, and AT_MAC_DH attributes shall not be added to this message. The same with the AT_KDF_PFS or AT_PUB_ECDHE in case of ECDHE. The appearance of these messages in a received message MUST be ignored. In an embodiment where ECDHE is used, no changes except that the AT_KDF_PFS or AT_PUB_ECDHE attributes must not be added to this message.
EAP-Response/AKA′-Identity
In at least some of the embodiments, no changes, except that the AT_KDF_DH, AT_GX, AT_GY, and AT_MAC_DH attributes shall not be added to this message. The same with the AT_KDF_PFS or AT_PUB_ECDHE in case of ECDHE. The appearance of these messages in a received message must be ignored.
EAP-Request/AKA′-Challenge
The server sends the EAP-Request/AKA′-Challenge on full authentication as specified by [RFC4187] and [RFC5448]. The attributes AT_RAND and AT_MAC are included as specified in in Section 9.3 of [RFC4187], and are also necessary for backwards compatibility.
In EAP-Request/AKA′-Challenge, there is no message-specific data covered by the MAC for the AT_MAC attribute. The AT_KDF_PFS and AT_PUB_ECDHE attributes MUST be included. The AT_PUB_ECDHE attribute carries the server's public Diffie-Hellman key. If either AT_KDF_PFS or AT_PUB_ECDHE is missing on reception, the peer MUST treat them as if neither one was sent, and the assume that the extension defined in this specification is not in use.
The AT_RESULT_IND, AT_CHECKCODE, AT_IV, AT_ENCR_DATA, AT_PADDING, AT_NEXT_PSEUDONYM, AT_NEXT_REAUTH_ID and other attributes may be include as specified in Section 9.3 of [RFC4187].
AT_MAC_DH should be included in at least some embodiments of the one in
When processing the EAP-Request/AKA′-Challenge, the peer must process AT_RAND, AT_AUTN, AT_KDF_DH/AT_KDF_PFS, AT_GX/AT_PUB_ECDHE before processing other attributes. Only if these attributes are verified to be valid, the peer derives keys and verifies AT_MAC_DH (if used). If the peer is unable or unwilling to perform the extension specified in this document, it proceeds as defined in [RFC5448]. Finally, the operation in case an error occurs is specified in Section 6.3.1. of [RFC4187].
EAP-Response/AKA′-Challenge
The peer/communication device sends EAP-Response/AKA′-Challenge in response to a valid EAP-Request/AKA′-Challenge message, as specified by [RFC4187] and [RFC5448]. If the peer supports and is willing to perform the extension according to any one of the embodiments in
The AT_MAC_DH attribute is in an embodiment included. In EAP-Response/AKA′-Challenge, there is no message-specific data covered by the MAC. The AT_GY/AT_PUB_ECDHE attribute is also be included and carries the peer's public Diffie-Hellman key.
The AT_RES attribute is in an embodiment included and checked as specified in IETF RFC4187. When processing this message, the Server processes AT_RES before processing other attributes. Only if this attribute is verified to be valid, the Server derives keys and verifies AT_MAC.
If the Server has proposed the use of the extension specified in this protocol, but the peer ignores and continues the basic EAP-AKA′ authentication, the Server makes policy decision of whether this is allowed. If this is allowed, it continues the EAP-AKA′ authentication to completion. If it is not allowed, the Server
behaves as if authentication failed.
The AT_CHECKCODE, AT_RESULT_IND, AT_IV, AT_ENCR_DATA and other attributes may be included as specified in Section 9.4 of [RFC4187].
EAP-Request/AKA′-Reauthentication
No changes, but note that the re-authentication process uses the keys generated in the original EAP-AKA′ authentication, which, if the extension of the embodiments illustrated in
EAP-Response/AKA′-Reauthentication
No changes, but as discussed in conjunction with the EAP-Request/AKA′-Reauthentication above, re-authentication is based on the key material generated by EAP-AKA′ and the extension of the embodiments illustrated in
EAP-Response/AKA′-Synchronization-Failure
No changes, except that the AT_KDF_DH, AT_GX, AT_GY (or AT_KDF_DH or AT_PUB_ECDHE), and AT_MAC_DH attributes is in the embodiments of
EAP-Response/AKA′-Authentication-Reject
In the embodiments illustrated in
EAP-Response/AKA′-Client-Error
In the embodiments illustrated in
EAP-Request/AKA′-Notification
No changes.
EAP-Response/AKA′-Notification
No changes.
Security Considerations
This section deals only with the changes to security considerations as they differ from EAP-AKA′, or as new information has been gathered since the publication of [RFC5448].
The possibility of attacks against key storage offered in SIM or other smart cards has been a known threat. But as the discussion above shows, the likelihood of practically feasible attacks has increased. Many of these attacks can be best dealt with improved processes, e.g., limiting the access to the key material within the factory or personnel, etc. But not all attacks can be entirely ruled out for well-resourced adversaries, irrespective of what the technical algorithms and protection measures are.
This extension according to the embodiments illustrated in
This extension generates keying material using the ECDHE exchange in order to gain the PFS property. This means that once an EAP-AKA′ authentication run ends, the session that it was used to protect is closed, and the corresponding keys are forgotten, even someone who has recorded all of the data from the authentication run and session and gets access to all of the AKA long-term keys cannot reconstruct the keys used to protect the session or any previous session, without doing a brute force search of the session key space. Even if a compromise of the long-term keys has occurred, PFS is still provided for all future sessions, as long as the attacker does not become an active attacker. Of course, as with other protocols, if the attacker has learned the keys and does become an active attacker, there is no protection that that can be provided for future sessions. Among other things, such an active attacker can impersonate any legitimate endpoint in EAP-AKA′, become a MITM in EAP-AKA′ or the extension defined in this document, retrieve all keys, or turn off PFS. Still, past sessions where PFS was in use remain protected. Achieving PFS requires that when a connection is closed, each endpoint MUST forget not only the ephemeral keys used by the connection but also any information that could be used to recompute those keys.
The following security properties of EAP-AKA′ may be impacted by embodiments of this extension:
Protected Ciphersuite Negotiation
EAP-AKA′ has a negotiation mechanism for selecting the key derivation functions, and this mechanism has been extended by the extension. The resulting mechanism continues to be secure against bidding down attacks.
There are two specific needs in the negotiation mechanism:
Negotiating Key Derivation Function within the Extension
The negotiation mechanism allows changing the offered key derivation function, but the change is visible in the final EAP-Request/AKA′-Challenge message that the server sends to the peer. This message is authenticated via the AT_MAC_DH attribute (when used) or the AT_MAC, and carries both the chosen alternative and the initially offered list. The peer refuses to accept a change it did not initiate. As a result, both parties are aware that a change is being made and what the original offer was.
Negotiating the Use of this Extension
This extension is offered by the server through presenting the AT_KDF_DH/AT_KDF_PFS, AT_GX/AT_PUB_ECDHE, and AT_MAC_DH attributes in the EAP Request/AKA′-Challenge message. These attributes are protected by AT_MAC or both AT_MAC and AT_MAC_DH when AT_MAC_DH is used, so attempts to change or omit them by an adversary will be detected. Except of course, if the adversary holds the long-term shared secret and is willing to engage in an active attack.
Such an attack can, for instance, forge the negotiation process so that no PFS will be provided. However, as noted above, an attacker
with these capabilities will in any case be able to impersonate
any party in the protocol and perform MITM attacks. That is not a situation that can be improved by a technical solution. However, as discussed above, even an attacker with access to the long-term keys is required to be a MITM on each AKA run, which makes mass surveillance more laborious.
The security properties of the extension also depend on a policy choice. Both the peer and the server make a policy decision of what to do when it was willing to perform the extension specified in this protocol, but the other side does not wish to use the extension. Allowing this has the benefit of allowing backwards compatibility to equipment that did not yet support the extension. When the extension is not supported or negotiated by the parties, no PFS can obviously provided.
If turning off the extension specified in this protocol is not allowed by policy, the use of legacy equipment that does not support this protocol is no longer possible. This may be appropriate when, for instance, support for the extension is sufficiently widespread, or required in a particular version of a mobile network.
Key Derivation
This extension provides key material that is based on the Diffie-Hellman keys, yet bound to the authentication through the (U)SIM card. This means that subsequent payload communications between the parties are protected with keys that are not solely based on information in the clear (such as the RAND) and information derivable from the long-term shared secrets on the (U)SIM card. As a result, if anyone successfully recovers shared secret information, they are unable to decrypt communications protected by the keys generated through this extension. Note that the recovery of shared secret information could occur either before or after the time that the protected communications are used. When this extension is used, communications at time t0 can be protected if at some later time t1 an adversary learns of long-term shared secret and has access to a recording of the encrypted communications.
Obviously, this extension is still vulnerable to attacker that are willing to perform an active attack and who at the time of the attack have access to the long-term shared secret.
This extension does not change the properties of related to re-authentication. No new Diffie-Hellman run is performed during the re-authentication allowed by EAP-AKA′. However, if this extension was in use when the original EAP-AKA′ authentication was performed, the keys used for re-authentication (K_re) are based on the Diffie-Hellman keys, and hence continue to be equally safe against expose of the long-term secrets as the original authentication.
In addition, it is worthwhile to discuss Denial-of-Service attacks and their impact on this protocol. The calculations involved in public key cryptography require computing power, which could be used in an attack to overpower either the peer or the server. While some forms of Denial-of-Service attacks are always possible, the following factors help mitigate the concerns relating to public key cryptography and EAP-AKA′ PFS.
In 5G context, other parts of the connection setup involve public key cryptography, so while performing additional operations in EAP-AKA′ is an additional concern, it does not change the overall situation. As a result, the relevant system components need to be dimensioned appropriately, and detection and management mechanisms to reduce the effect of attacks need to be in place.
This specification is constructed so that a separation between the USIM and Peer on client side and the Server and HSS on network side is possible. This ensures that the most sensitive (or legacy) system components cannot be the target of the attack. For instance, EAP-AKA′ and public key cryptography takes place in the phone and not the low-power SIM card.
EAP-AKA′ has been designed so that the first actual message in the authentication process comes from the Server, and that this message will not be sent unless the user has been identified as an active subscriber of the operator in question. While the initial identity can be spoofed before authentication has succeeded, this reduces the efficiency of an attack.
This text specifies an order in which computations and checks must occur. When processing the EAP-Request/AKA′-Challenge message, for instance, the AKA authentication must be checked and succeed before the peer proceeds to calculating or processing the PFS related parameters. The same is true of EAP-Response/AKA′-Challenge. This ensures that the parties need to show possession of the long-term secret in some way, and only then will the PFS calculations become active. This limits the Denial-of-Service to specific, identified subscribers. While botnets and other forms of malicious parties could take advantage of actual subscribers and their key material, at least such attacks are (a) limited in terms of subscribers they control, and (b) identifiable for the purposes of blocking the affected subscribers.
It should be emphasized that the term “comprises/comprising” when used in this specification is taken to specify the presence of stated features, integers, steps or components, but does not preclude the presence or addition of one or more other features, integers, steps, components or groups thereof. The words ‘parameter’ and “attribute” should be interpreted as covering values of the parameter and attribute respectively, e.g. that the calculation of a parameter comprises the calculation of a value for that parameter, and that a calculation or derivation of a result or response based on one or more parameters comprises a calculation of the result or the response based on one or more values of the one or more parameters. In the same manner, receiving a parameter and/or attribute and sending/forwarding a parameter and/or attribute comprise the receiving and sending of a value of that parameter. The same goes for generation of a parameter or attribute, which means that a parameter value or an attribute value is generated. The same is also true for the identity of e.g. the communication device/peer, i.e. the identity and the identity value is used interchangeably without any problems for the skilled person to understand the realisation of the embodiments herein.
It should be realized that the communication device is not limited to being a User Equipment (UE). It may be any type of wireless endpoint, mobile station, mobile phone, wireless local loop phone, smartphone, desktop computer, PDA, cell phone, tablet, laptop, VoIP phone or handset, which is able to wirelessly send and receive data and/or signals to and from a network node. It may also be a communication device providing e.g. 3G, 4G and/or 5G connectivity for e.g. a sensor. The communication device may be a digital camera, a vehicle (or embedded telematics unit or Electronic Control Unit therein), a home gateway, home/residential WiFi/4G access point, an electricity meter, a domestic appliance device like a refrigerator, thermostat, burglary alarm, vacuum cleaner, lawn mower robot or the like. It may also be a stationary terminal connected to a fixed communication network.
In the following description, for purposes of explanation and not limitation, specific details are set forth such as particular architectures, interfaces, techniques, etc. in order to provide a thorough understanding of the embodiments. However, it will be apparent to those skilled in the art that features of the embodiments may be practiced in other embodiments that depart from these specific details. In other instances, detailed descriptions of well-known devices, circuits, and methods are omitted so as not to obscure the description of novel features with unnecessary detail.
The disclosure concerns improved communication security in a communication network using pre-shared keys as basis for the communication security. A communication network may here be a mobile communication network, such as a second Generation (2G) mobile communication network like Global System for Mobile communication (GSM), a third generation (3G) network like Universal Mobile Telecommunications System (UMTS) or a fourth generation (4G) network such as Long-Term Evolution (LTE) or any future, evolved system like the 3GPP 5th Generation (5G) currently being developed and including the EAP-AKA′ protocol for session key generation. These are just a few examples of networks where the embodiments may be implemented. Other types of networks that may be used are for instance Wireless Local Area Networks (WLAN). A communication device, such as a user equipment (UE), a Mobile Station (MS), sometimes denoted a cellular phone, may communicate using these communication networks. Furthermore, a communication device here is connected to an identity module, where the identity module may be a smart card such as a universal integrated circuit card (UICC) holding a subscriber identity module (SIM) and/or a Universal Subscriber Identity Module (USIM) or an IP Multimedia Subsystem SIM (ISIM), an embedded SIM (eSIM) module, a software module, an integrated UICC (iUICC), a Global Platform Trusted Execution module or the like. The identity module may thus also be implemented in software running in a trusted execution environment, or software running on a general purpose processor, although the latter is not preferred. Generally the term USIM is used as an example in the descriptions, but the person skilled in the art will appreciate that any type of identity module associated with the peer/communication device will serve the same purpose. It should be realized that the identity module may be a part of the communication device, e.g. in the form of an eUICC/eSIM and an iUICC. It may also be a separate or removable entity (such as a standard nano SIM card) that is connected to the communication device, when the communication device is to be used.
As a basis for communication security a key is used, e.g. for authentication and key agreement. The key may advantageously be pre-shared and stored in an identity module as just described. In the following only the example of the communication device/peer in the form of a UE will be discussed. However, it should be realized that the communication device is not limited to being a UE.
The AUTN (Authentication Token) is a parameter composed of different fields: AMF (Authentication Management Field), MAC and a sequence number indication (SQN, possibly encrypted/modified by an anonymity key AK). The MAC is a Message Authentication Code that protects the challenge RAND (RANDom number), as well as SQN and AMF from being forged by a 3rd party through the cryptographic functions implemented by the USIM. The keys CK and IK are used directly for ciphering/integrity protection in 3G and are used indirectly for these purposes in 4G/LTE and 5G/New Radio by deriving ciphering/integrity keys from CK and IK (specifically: from a key Kasme, formed by CK and IK and for forming CK′ and IK′ used in EAP-AKA′ as previously discussed).
As a simplifying notational convention used in the remainder of the description of cryptographic and other forms of computations, parameters other than those explicitly mentioned may be input to functions such as Key Derivation Functions (KDF), Message Authentication Codes (MAC) and all other functions in all instances described herein. The parameters may be put in a different order than explicitly mentioned. The parameters may be transformed before being input to the function. For example, a set of parameters P1, P2, . . . , Pn, for some non negative integer n, could be transformed by first being run through a second function f and the result of that, i.e., f(P1, P2, . . . , Pn), being input to the function.
An example of a key derivation when a parameter P1 is first transformed before being input to a KDF to calculate a key called “output_key” could be a derivation of form output_key=KDF(f(P1), some other parameter), where f is some arbitrary function or chain of functions. The input “some other parameter” could be 0, 1 or more other parameters, e.g., used to bind the key to a certain context. Sometimes, the notation “ . . . ” may be used as a synonym for “some other parameter”. Parameters may be input as separate parameters or may be concatenated together and then input in one single input to the KDF. Thus, one of skill in the art will understand that additional parameters may be used, parameters may be transformed or re-arranged etc. and even in the presence of variations like these, the core of the idea remains the same.
The first communication network 36 is thus in this example a network that is visited by the UE, while the second communication network 38 is a home network of the UE.
In different embodiments, each wireless network may comprise any number of wired or wireless networks, network nodes, base stations, controllers, wireless devices, relay stations, and/or any other components that may facilitate or participate in the communication of data and/or signals whether via wired or wireless connections.
Each wireless network may comprise one or more IP networks, public switched telephone networks (PSTNs), packet data networks, optical networks, wide area networks (WANs), local area networks (LANs), wireless local area networks (WLANs), wired networks, wireless networks, metropolitan area networks, and other networks to enable communication between devices.
As was mentioned earlier embodiments are directed towards introducing PFS in a system such as that in the embodiments illustrated in
One way of realizing the ME 51 is schematically shown in
Processor 54 may be a combination of one or more of a microprocessor, controller, microcontroller, central processing unit, digital signal processor, application specific integrated circuit, field programmable gate array, or any other suitable computing device, resource, or combination of hardware, software and/or encoded logic operative to provide, either alone or in combination with other ME components, such as storage 56, ME functionality. Such functionality may include providing various wireless features discussed herein, including any of the features or benefits disclosed herein. In one embodiment the USIM is stored in a iUICC, which in turn is tamper resistant part of the processor 54.
Storage 56 may be any form of volatile or non-volatile memory including, without limitation, persistent storage, solid state memory, remotely mounted memory, magnetic media, optical media, random access memory (RAM), read-only memory (ROM), removable media, or any other suitable local or remote memory component. Storage 56 may store any suitable data, instructions, or information, including software and encoded logic, utilized by ME 51. Storage 56 may be used to store any calculations made by processor 54 and/or any data received via interface 50B.
Interface 50B may be used in the wireless communication of signalling and/or data between UE and a network device, such as the base station 42. For example, interface 50B may perform any formatting, coding, or translating that may be needed to allow UE to send and receive data from base station 42 over a wireless connection. Interface 50B may also include a radio transmitter and/or receiver that may be coupled to or a part of antenna 50a. The radio may receive digital data that is to be sent out to base station 42 via a wireless connection. The radio may convert the digital data into a radio signal having the appropriate channel and bandwidth parameters. The radio signal may then be transmitted via antenna 50a to base station 42.
Antenna 50a may be any type of antenna capable of transmitting and receiving data and/or signals wirelessly.
The storage 56 may also comprise instructions for handling PFS in relation to communication of the ME to the first wireless network. The storage 56 may more particularly comprise computer instructions causing the processor 54 to implement the EAP-AKA′ module 52. The storage 56 may also comprise UICC drivers for communication allowing the ME to detect and power the UICC for the calculation of e.g. the CK and IK and output these to the EAP-AKA′ module of the ME. The communication module 50 may in turn in essence be implemented through the combination of the interface 50B and antenna 50A.
Processor 60 may be a combination of one or more of a microprocessor, controller, microcontroller, central processing unit, digital signal processor, application specific integrated circuit, field programmable gate array, or any other suitable computing device, resource, or combination of hardware, software and/or encoded logic operative to provide, either alone or in conjunction with other network device components, such as storage 62, network device functionality. For example, processor 60 may execute instructions stored in storage 62.
Storage 62 may comprise any form of volatile or non-volatile computer readable memory including, without limitation, persistent storage, solid state memory, remotely mounted memory, magnetic media, optical media, random access memory (RAM), read-only memory (ROM), removable media, or any other suitable local or remote memory component. Storage 62 may store any suitable instructions, data or information, including software and encoded logic, utilized by network device 64. Storage 62 may be used to store any calculations made by processor 60 and/or any data received via interface 58.
Network device 64 also comprises interface 58 which may be used in the wired communication of signalling and/or data between network device 64, network WN1 or WN2, and/or UE. For example, interface 58 may perform any formatting, coding, or translating that may be needed to allow network device 64 to send and receive data from network WN1 or WN2 over a wired connection.
The embodiments described herein are concerned with adding PFS to EAP-AKA′. An aim is therefore, at least according to some embodiments, to raise the security level of communication between a communication device and a communication network in relation to the use of long-term shared keys. It may also be of interest to avoid sending additional EAP-AKA′ messages, which is achieved by the embodiments disclosed in conjunction with
In the examples given here the communication network 36 is the first wireless network WN1 and the first network device 44 is the MME of the first wireless network.
The operation may start with the UE attaching to the first communication network 36. As a part of this, an identifier e.g. international mobile subscriber identity IMSI may be provided from the UE as at least a part of the NAI or rather from the USIM 48 of the UE to the first network device 44, which in turn sends a request for an authentication vector AV to the second network device 46 in the second communication network 38. The second network device 46 generates the authentication vector, which may comprise the authentication token AUTN, the random value RAND, the expected result of the verification computation XRES. It may also comprise other keys such as the keys CK/IK or even the modified ciphering key and integrity key CK′/IK′. Thus, in so far, the second network node 46 may operate according to existing EAP-AKA′ specifications. In this way the first network device 44 obtains the authentication vector, which may at least comprise a random value RAND and an expected verification result XRES. Here it can be mentioned that RAND is provided for use as a challenge to the UE and AUTN comprises a challenge verification code for this challenge.
As indicated earlier, the USIM 48 comprises a key K, with advantage a key K that is pre-shared with the second network device 46. It also comprises cryptographic processing means. This module 48 may then provide at least one result parameter (CK/IK) as a response to the challenge (RAND and AUTN). One result parameter may be one or more cryptographic keys such as the ciphering key CK and the integrity key IK, which may be used by the EAP-AKA′ module 52 to obtain, such as receiving or deriving CK′/IK′. Another result parameter may be a response parameter RES to the challenge, which response parameter has a response value. Such a response parameter thus has a cryptographic value computed based on the pre-shared key and said cryptographic processing means.
The computer program code of a mobile equipment may be stored in the form of computer program product for instance in the form of a computer readable storage medium, such as a CD ROM disc or a memory stick. In this case the computer readable storage medium carries a computer program with the computer program code, which will implement the functionality of the above-described communication device and/or the network device. One such computer readable storage medium 110 with computer program code 112 is schematically shown in
Alternatively, instead of being enabled through a computer program, the respective method may be fully or partially enabled through a hardware processor, such as an ASIC or PFGA or baseband module comprised in the communication device, network device, network system, peer, and server respectively.
In a second action C2 it receives the CK and IK. The CK and IK are output from e.g. the USIM/identity module of the communication device to the ME or the EAP-AKA′ module 52 of the communication unit. The UICC is generally physically connected to the ME, i.e. is generally a part of the communication device.
In a third action C3, the communication device/ME/EAP-AKA′ module generates the CK′ and IK′ based on CK, IK and the access network identity as mentioned above.
In a fourth action C4, the communication device calculates a second PFS parameter value. The second PFS parameter value is in the embodiment of
In a fifth action C5, the communication device sends the second PFS parameter to the network device.
In a sixth action C6, the communication device calculates a third PFS parameter value, which in an embodiment is a Diffie-Hellman parameter. The third PFS parameter value is in the embodiment of
In a seventh action C7, the communication device derives, using a Pseudo-random function, a key for communication between the communication device and the network device or any other network device associated with the network device, based on the third PFS parameter value, the CK′, the IK′ and an identity associated with the communication device. The identity associated with the communication device is in one embodiment a NAI associated with the communication device and in another the IMSI associated with the communication device. The key may also be based on an eight or twelve-character long ASCII string representing an EAP-AKA′ value. The key may be EMSK in some embodiments, e.g. when the EAP-AKA′ value is a twelve-character long ASCII string.
It should be understood that all the actions C1-C7 above may not be done in exactly the same order as presented above. For example, the CK and IK can be received and CK′, IK′ can be generated before the reception of the parameter values in action C1. The calculation of the second PFS parameter is action C4 can also be done before action C1. Another example is that the calculation of the third PFS parameter and the derivation of the key in actions C6 and C7 may take place before the sending of the second PFS parameter in action C5.
In a second action N2, the first PFS parameter value is calculated by the network device. The first PFS parameter value is in one embodiment a public key of a public-private key pair for the network device.
In an optional third action N3, a MAC is calculated.
In an optional fourth action N4, a second key is generated by the network device before the second PFS parameter value has been received from the communication device. The second key, which in one embodiment is the MK_pre, may be derived based on only the CK′, the IK′, the EAP-AKA′ attribute value and the identity associated with the communication device.
In an optional fifth action N5, the network device derives an authentication key. The authentication key is derived from the from the second key.
In a sixth, optional action N6, the network device generates AT_MAC_DH and include it in a first EAP-Request/AKA′-Challenge message sent in a seventh action N7. The MAC_DH in the attribute AT_MAC_DH may be calculated over a whole EAP packet containing an EAP header, an EAP-AKA′ header and attribute values including the first PFS parameter value.
In the seventh action N7, the network device sends the first PFS parameter value and at least one attribute value indicating a choice of a Diffie-Hellman group to a communication device. The at least one attribute value may also indicate a key derivation function and the attribute value is in the embodiment of
It may optionally also send the attributes AT_MAC and AT_MAC_DH to the communication device.
In an eighth action N8, the network node receives the second PFS parameter value from the communication device. The second PFS parameter value may be a public key of a public-private key pair for the communication device.
In a ninth action N9, the network device calculates the third PFS parameter value based on the first PFS parameter value, which may be a Diffie-Hellman value, and the second PFS parameter value. The third PFS parameter value may also be based on a private key of the public-private key pair for the communication device in an embodiment where public keys are exchanged between the communication device and network device.
In a tenth action N10, the network device derives, using a Pseudo-random function, a key for communication between the communication device and the network device or any other network device associated with the network device, based on the third PFS parameter value, the CK′, the IK′, and the identity associated with the communication device. The identity associated with the communication device is in one embodiment its Network Access Identifier, NAI, or a part of the NAI, but may in another embodiment be the IMSI associated with the communication device. In an embodiment, the key is derived also based on an ASCII string representing an EAP-AKA′ value, which ASCII string in one embodiment is eight characters long and in another embodiment twelve characters long.
Again, it should be understood that all the actions N1-N10 above may not be done in exactly the same order as presented above.
In a second optional action C12, the communication device sends the identity to the network device in an EAP-Response/Identity message.
In a third action C13, the communication device receives from the server, a message comprising a public key of a public-private key pair for the server, and an attribute indicating (1) a used or desired key generation function associated with the public key for the server, and (2) a used or desired Elliptic Curve Diffie-Hellman Ephemeral group related to the public key for the server. The message may with advantage be an EAP-Request/AKA′-Challenge. The public key of the server may be contained in the attribute AT_PUB_ECDHE. The Elliptic Curve Diffie-Hellman Ephemeral group is in one embodiment a Curve25519 group as specified in IETF RFC 8031. The communication device may also receive a MAC attribute (AT_MAC) from the server, where the MAC attribute protects the public key for the server and the attribute that indicates a used or desired key generation function associated with the public key and a used or desired Elliptic Curve Diffie-Hellman Ephemeral group related to the public key for the server. The communication device may receive two or more attributes from the server, wherein each one of the attributes indicates both a choice of an Elliptic Curve Diffie-Hellman Ephemeral group and key derivation function for the derivation of the key.
In a fourth action C14, the communication device receives the CK, IK from a USIM.
In a fifth action C15, the communication device generates CK′ and IK′ based on the CK, IK and an access network identity.
In a sixth action C16, the communication device generates a public-private key pair for the communication device.
In a seventh action C17, the communication device generates a shared secret based on a private key of the public-private key pair for the communication device and the public key for the server.
In an eighth action C18, the communication device sends the public key for the communication device to the server in order to enable the server to generate the shared secret through generation of the shared secret based on the public key for the communication device and a private key of the public-private key pair for the server.
In a ninth action C19, the communication device derives a key using a pseudo-random function for communication between the communication device and the server based on the shared secret, the CK′, the IK′, the identity associated with the communication device and a value representing a choice of a key derivation function. The identity associated with the communication device is in an embodiment a NAI or a part of a NAI. The value representing a choice of a KDF may be a twelve-character long ASCII string representing an EAP-AKA′ value.
It should be understood that all the actions C11-C19 may not be done in exactly the same order as presented above. For example, the CK and IK can be received and CK′, IK′ can be generated before the reception of the parameter values in action C13. The generation of the public-private key pair for the communication device in action C16 can also be done before action C11-C15. Another example is that the sending of the public key for the communication device to the server may take place before the generation of the shared secret. Yet another example is that the derivation of the key in C19 may take place before the action C18.
In a second action S2, the server generates a public-private key pair for itself.
In a third, optional action S3, the server sends an EAP-Request/Identity message to the communication device 40.
In a fourth, optional action S4, the server receives the identity of the communication device in an EAP-Response/Identity message. The identity associated with the communication device is in one embodiment a NAI, or a part of the NAI.
In a fifth action S5, the server sends to the communication device, a public key of the public-private key pair for the server and an attribute indicating (1) a used or desired key generation function associated with the public key for the server, and (2) a used or desired ECDHE group related to the public key for the server. The ECDHE group may be a Curve25519 group as specified in IETF RFC 8031. The server may in this action S5 also send a MAC attribute to the communication device, where the MAC attribute protects the public key for the server and the attribute that indicates a used or desired key generation function associated with the public key and a used or desired Elliptic Curve Diffie-Hellman Ephemeral group related to the public key for the server. The server may send at least two attributes, wherein each of the attribute indicates both a choice of an Elliptic Curve Diffie-Hellman Ephemeral group and key derivation function for the derivation of the key.
In a sixth action S6, the server receives from the communication device a public key of a public-private key pair for the communication device.
In a seventh action S7, the server generates a shared secret based on a private key of the public-private key pair for the server and the received public key for the communication device.
In an eighth action S8, the server derives a key, e.g. EMSK, using a pseudo-random function for communication between the communication device and the server. The key is derived based on the shared secret, the CK′, the IK′, an identity associated with the communication device and a value representing a choice of a key derivation function. The value representing a choice of a key derivation function is in one embodiment, such as in the case the EMSK shall be derived, a twelve-character long ASCII string representing an EAP-AKA′ value.
The embodiments should now have been sufficiently described and some of the changes in relation to prior art and/or extensions to EAP-AKA′ are:
1. Application of the idea to EAP-AKA′ (and EAP-AKA) rather than AKA directly.
2. Inclusion of the entire packet and all attributes in a protocol. Instead of “MAC over gx”, embodiments herein uses an EAP version with “MAC over all”, the attributes AT_GX/AT_PUB_ECDHE included.
3. The use of this new extension is backwards compatible by including both legacy MAC and other attributes and the DH attributes from the server/network, and letting the peer/UE decide which one it wants to execute. This saves a roundtrip that would otherwise be needed for negotiation.
4. Providing bidding-down protection by including new things in a way that integrity protection in an older version algorithm protects the new things, even if the older version doesn't understand the new things.
5. In embodiments utilizing AT_MAC_DH, the algorithm to calculate and use two separate MAC values when one doesn't know which ones the peer wants or can use. A problem is, that to take a MAC value of a message that ultimately includes the MAC value itself, one has to revert to special tricks to ensure that MAC can be calculated. Normally protocols do this in one of two ways, either taking the MAC of the message that does not include the MAC value or attribute carrying it at all. Or, zeroing out the actual MAC value when calculating the MAC value.
However, some embodiments only carry one MAC value. A key obstacle is that we cannot change the behaviour of the receiver who only understands the legacy version of a MAC attribute. This is what is done in at least one of the embodiments for two MAC values:
Norrman, Karl, Arkko, Jari, Torvinen, Vesa
| Patent | Priority | Assignee | Title |
| Patent | Priority | Assignee | Title |
| 5199070, | Dec 18 1990 | MATSUSHITA ELECTRIC INDUSTRIAL CO , LTD | Method for generating a public key |
| 20060153370, | |||
| 20060280300, | |||
| 20150180653, | |||
| 20160255070, | |||
| 20190268335, | |||
| 20210058776, | |||
| 20210226781, | |||
| WO2016137374, |
| Executed on | Assignor | Assignee | Conveyance | Frame | Reel | Doc |
| Oct 30 2018 | Telefonaktiebolaget LM Ericsson (publ) | (assignment on the face of the patent) | / | |||
| Nov 06 2018 | NORRMAN, KARL | TELEFONAKTIEBOLAGET LM ERICSSON PUBL | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 048930 | /0378 | |
| Jan 17 2019 | TORVINEN, VESA | OY L M ERICSSON AB | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 048945 | /0351 | |
| Jan 23 2019 | ARKKO, JARI | OY L M ERICSSON AB | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 048945 | /0351 | |
| Feb 06 2019 | OY L M ERICSSON AB | TELEFONAKTIEBOLAGET LM ERICSSON PUBL | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 048930 | /0490 |
| Date | Maintenance Fee Events |
| Nov 20 2018 | BIG: Entity status set to Undiscounted (note the period is included in the code). |
| Date | Maintenance Schedule |
| Jan 18 2025 | 4 years fee payment window open |
| Jul 18 2025 | 6 months grace period start (w surcharge) |
| Jan 18 2026 | patent expiry (for year 4) |
| Jan 18 2028 | 2 years to revive unintentionally abandoned end. (for year 4) |
| Jan 18 2029 | 8 years fee payment window open |
| Jul 18 2029 | 6 months grace period start (w surcharge) |
| Jan 18 2030 | patent expiry (for year 8) |
| Jan 18 2032 | 2 years to revive unintentionally abandoned end. (for year 8) |
| Jan 18 2033 | 12 years fee payment window open |
| Jul 18 2033 | 6 months grace period start (w surcharge) |
| Jan 18 2034 | patent expiry (for year 12) |
| Jan 18 2036 | 2 years to revive unintentionally abandoned end. (for year 12) |