5G-Compliant Authentication Protocol for RFID
Abstract
:1. Introduction
2. Security Architecture and Procedures for 5G and Threat Model
2.1. 5G Architecture
2.2. The 5G Authentication and Key Agreement Protocol, 5G-AKA
- A.
- Shared cryptographic material. HN and UE (USIM) share a long-term symmetric key K. All the UEs belonging to that HN also store the public key of HN, while HN stores the corresponding secret key .
- B.
- Sequence numbers. UE and HN share a loosely-synchronized sequence number : UE stores , while HN stores . These are checked during the authentication procedure to prevent replay attacks.
- C.
- Cryptographic functions. The 3GPP architecture defines a key derivation function , and seven cryptographic functions, , , , , , and [4]: the first three are message authentication functions, while the last four are key derivation functions. These are one-way keyed functions that should be practically indistinguishable from independent random functions. In particular: (i) knowledge of the values of one function on a fairly large number of given inputs should not enable its values to be predicted on other inputs; (ii) outputs from any one function should not be predictable from those of the other functions (on the same or other inputs); (iii) it should be infeasible to determine any part of the secret key, by manipulation of the inputs and examination of the outputs of the algorithm. These requirements are broadly captured by pseudo-random functions (PRF) and pairwise independence (Section 19.3.2.2, p. 19 [5]), and in particular jointly PRFs [6]. Informally, the PRFs , , are jointly PRFs if for any key , the output of is practically indistinguishable from the output of , on the same input, where , , are functions drawn uniformly from the set of all functions from to . Finally, the KDF is used to derive the keys for secure communication. It is specified in [7], as a keyed hash function based on SHA256 [8].
- D.
- The MILENAGE algorithms [5]. Although the implementation of – and is proprietary and not standardized, the 3GPP security working group has developed an example algorithm set for these authentication and key generation functions. This uses a 128-bit blockcipher (AES-128) as a kernel function. The seven functions – and , are constructed by invoking the kernel function and using circular shifts and xor-ing constants , selected appropriately to ensure separation (independence). Furthermore, and use a CBC MAC structure, while the others use double encryption in counter mode.
- E.
- Identifiers. The is, as explained, the encryption of the with the public key of HN using a random number : . The is used to identify the UE, while the is never sent clearly. This prevents a security flaw in 4G that allows an attacker to get the permanent identifier of an UE () by impersonating a serving network ( catcher attack [9]). After a successful execution of 5G-AKA, the SN can issue a pseudonym called (globally unique temporary UE identity) that the UE can be used to identify itself for a certain period of time [10]. This avoids computing the that requires generating a random number and computing an assymmetric encryption. The is updated by AMF upon receiving a registration request message from a UE of type “initial registration”, “mobility registration update”, “periodic registration update” or in response to a paging message, but it is left to the operator to re-assign it more frequently.
- F.
- Assumptions on Channels. The channel between UE and SN, on the radio physical layer, is subject to attacks by passive and active adversaries (Section 2.3). By contrast, the channel between the SN and HN is supposed to be secure (Clause 5.9.3 [2]).
- The first phase is the initiation of the authentication procedure and the selection of the authentication method. The SEAF of SN may initiate an authentication with the UE during any procedure establishing a signalling connection with the UE. If UE does not have a valid , then it computes and sends the to SN, who relays it to HN. Otherwise, UE sends the to SN. If the SN (AMF) is able to obtain the corresponding , by looking it up in its database, then SN forwards it to HN. If not, it requests (“Identifier Request Message”) the to UE and relays it to HN. SN includes its identifier () in the message to HN. The HN (AUSF) then checks whether the SN is authorized and if so, obtains the : directly if it was sent or, otherwise, deconcealing it from the (at SIDF). Based on , the HN (UDM/ARPF) shall choose the authentication method.
- The second phase is the actual authentication procedure, which is based on a typical challenge–response mechanism. Thus, upon receiving a request for authentication, HN generates a random number R, which is used as a challenge, and an authentication value , which consists of a message authentication code (using ) and a value, (using ), which masks the sequence number , required to compute the and included to prevent replay attacks. It additionally computes the response to this challenge () and sends its hashed value () to SN, so that this can detect incorrect responses, even when it is not able to compute the correct ones. The use of reduces the vulnerability to denial of service (DoS) attacks, since junk messages can be detected earlier. The response involves the long-term key K, the challenge R and the identifier of SN, to guarantee that both parties are communicating with the same SN. UE receives the challenge and the authentication value: . Then, USIM retrieves , computes the and makes a twofold check: (i.) that the is correct and therefore the authenticity of the message, and (ii.) that has not been replayed () and that it is within a certain range (), to prevent de-synchronization attacks by forcing the counter to wrap around. If (i.) fails, then a “MAC failure message” is sent. If (i.) is correct but (ii.) fails, then a “Synchronization failure message” is replied along with a re-sync token to inform to HN of the value in a hidden way; using for authentication and to mask and protect it from eavesdroppers. Otherwise, if (i.) and (ii.) are correct, USIM computes (using ), (using ) and (using ) and forwards it to ME, who computes and sends and derives the anchor key . SN verifies that the hashed values of this response is correct and if so, forwards it to HN. Finally, HN verifies the response and if correct, sends to SN.
- Final phase. A successful 5G-AKA ends up with the derivation of the anchor key by both HN and UE, from which further keys can be obtained. The authentication is implicit [11], since the authentication confirmation occurs only when the parties succeed in exchange messages correctly using the derived keys. The standard does not specify any additional key confirmation query for . If the exchanged messages are not correct, then the parties assume that either the derived keys or are not correct, and as a result, that the authentication process was not successful.
2.3. Threat Model
3. Proposed Protocol
3.1. 5G-Compliant RFID Initialization Protocol
3.2. 5G-Compliant RFID Authentication Protocol
4. Analysis
4.1. Passive Adversaries
4.2. Active Adversaries
- (a)
- is not changed and some or all of the other values are changed. This is not possible because it implies that the adversary is able to compute a collision (same output, different input) for the MAC .
- (b)
- is changed but some or all of the other values remain unchanged. Again, this is not possible because it implies that the adversary is able to compute a valid for a different input that will get accepted with non-negligible probability, without knowing .
- (c)
- and the input is changed. Again the adversary cannot compute with non-negligible probability a valid for a given input without knowing .
- (a)
- The adversary intercepts the first flow: , , , , , and later replays it, impersonating the tag to the reader. The reader then computes a valid that is stored by the adversary.
- (b)
- In the second flow, the adversary intercepts the valid computed by the Reader.
- (c)
- The adversary does not intercept any flow, just eavesdrops and stores during a legitimate communication.
- (a)
- After a new first flow from a legitimate tag , , and the corresponding challenge , , the adversary impersonates the tag and replays the stored flow , , , . This will not be accepted by the reader because is different from the unique value , that corresponds to the new set of values singularized by .
- (b)
- The adversary, impersonating the tag, replays the first flow , receives a new challenge , from the Reader, and replays the second flow , . In this case, the reader will check that is correct, according to the received flows, and then compute and send . However, because is different from , that corresponds to the challenge , the hashed value will not be accepted by SN.
4.3. Readers
5. Conclusions
Author Contributions
Funding
Conflicts of Interest
References
- Ashton, K. That ’Internet of Things’ Thing. RFID J. 2009, 22, 97–114. [Google Scholar]
- 3GPP. Security Architecture and Procedures for 5G System, (3GPP), TS 33.501. Available online: https://www.3gpp.org/ftp/Specs/archive/33_series/33.501/ (accessed on 21 September 2020).
- Arkko, J.; Lehtovirta, V.; Eronen, P. RFC 5448:Improved Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA). RFC Editor. 2009. Available online: https://www.rfc-editor.org/info/rfc5448 (accessed on 17 November 2020).
- 3GPP. 3G Security; Security Architecture, (3GPP), TS 33.102. Available online: https://www.3gpp.org/ftp/Specs/archive/33_series/33.102/ (accessed on 21 September 2020).
- 3GPP. 3G Security; Specification of the MILENAGE Algorithm Set: An Example Algorithm Set for the 3GPP Authentication and Key Generation Functions f1, f1*, f2, f3, f4, f5 and f5*; Document 5: Summary and Results of Design and Evaluation, (3GPP), TR 35.909. Available online: https://www.3gpp.org/ftp/Specs/archive/35_series/35.909/ (accessed on 23 September 2020).
- Koutsos, A. The 5G-AKA Authentication Protocol Privacy. arXiv 2018, arXiv:1811.06922. [Google Scholar]
- 3GPP. Generic Authentication Architecture (GAA); Generic Bootstrapping Architecture (GBA), (3GPP), TS 33.220. Available online: https://www.3gpp.org/ftp/Specs/archive/33_series/33.220/ (accessed on 19 September 2020).
- Krawczyk, H.; Bellare, M.; Canetti, R. RFC 2104: “HMAC: Keyed-Hashing for Message Authentication”. Available online: https://tools.ietf.org/html/rfc2104 (accessed on 17 November 2020).
- Shaik, A.; Borgaonkar, R.; Seifert, J.P.; Asokan, N.; Niemi, V. Practical Attacks Against Privacy and Availability in 4G/LTE. In Proceedings of the 23nd Annual Network and Distributed System Security Symposium, NDSS 2016, San Diego, CA, USA, 21–24 February 2016. [Google Scholar]
- 3GPP. Numbering, Addressing and Identification, (3GPP), TS 23.003. Available online: https://www.3gpp.org/ftp/Specs/archive/23_series/23.003/ (accessed on 21 September 2020).
- Basin, D.; Radomirovic, S.; Dreier, J.; Sasse, R.; Hirschi, L.; Stettler, V. A formal analysis of 5g authentication. In Proceedings of the 2018 ACM SIGSAC Conference on Computer and Communications Security, Toronto, ON, Canada, 15–19 October 2018; pp. 1383–1396. [Google Scholar] [CrossRef] [Green Version]
- Dolev, D.; Yao, A. On the security of public key protocols. IEEE Trans. Inf. Theory 1983, 29, 198–208. [Google Scholar]
- Khan, H.; Martin, K.M. A Survey of Subscription Privacy on the 5G Radio Interface—The Past, Present and Future. IACR Cryptol. ePrint Arch. 2020, 2020, 101. [Google Scholar]
- Paret, D. RFID and Contactless Smart Card Applications; John Wiley & Sons: Hoboken, NJ, USA, 2005. [Google Scholar]
- ISO/IEC 29192-1:2012. In Information Technology—Security Techniques—Lightweight Cryptography—Part 1: General; International Organization for Standardization: Geneva, Switzerland, 2012.
- Feldhofer, M.; Wolkerstorfer, J.; Rijmen, V. AES implementation on a grain of sand. IEEE Proc. Inf. Secur. 2005, 152, 13–20. [Google Scholar]
- Dao, V.L.; Hoang, V.P.; Nguyen, A.T.; Le, Q.M. A compact, low power AES core on 180 nm CMOS process. In Proceedings of the 2016 International Conference on IC Design and Technology (ICICDT), Ho Chi Minh, Vietnam, 27–29 June 2016; IEEE: Piscataway, NJ, USA, 2016; pp. 1–5. [Google Scholar]
Publisher’s Note: MDPI stays neutral with regard to jurisdictional claims in published maps and institutional affiliations. |
© 2020 by the authors. Licensee MDPI, Basel, Switzerland. This article is an open access article distributed under the terms and conditions of the Creative Commons Attribution (CC BY) license (http://creativecommons.org/licenses/by/4.0/).
Share and Cite
Munilla, J.; Hassan, A.; Burmester, M. 5G-Compliant Authentication Protocol for RFID. Electronics 2020, 9, 1951. https://doi.org/10.3390/electronics9111951
Munilla J, Hassan A, Burmester M. 5G-Compliant Authentication Protocol for RFID. Electronics. 2020; 9(11):1951. https://doi.org/10.3390/electronics9111951
Chicago/Turabian StyleMunilla, Jorge, Adel Hassan, and Mike Burmester. 2020. "5G-Compliant Authentication Protocol for RFID" Electronics 9, no. 11: 1951. https://doi.org/10.3390/electronics9111951
APA StyleMunilla, J., Hassan, A., & Burmester, M. (2020). 5G-Compliant Authentication Protocol for RFID. Electronics, 9(11), 1951. https://doi.org/10.3390/electronics9111951