A Lightweight Many-to-Many Authentication Protocol for Near Field Communications Vitaly Petrov∗ , Maria Komar†, Yevgeni Koucheryavy∗ ∗ Department
of Electronic and Communication Engineering Tampere University of Technology, Tampere, Finland
[email protected],
[email protected] † Department
of Computer Science Yaroslavl State University, Yaroslavl, Russia
[email protected]
Abstract—In this paper the lightweight many-to-many authentication protocol, that uses Near Field Communications as a carrier technology is proposed. The solution works without any user interaction and can be applied for almost any data storage device: NFC or RFID tag, USB-flash drive, etc. The major novelty of the system is real-time encryption key generation algorithm. This approach doesn’t require any computation power on the tag, trusted third parties or secure link between tag and information system. So far, the mentioned features transforms to significant advantages of the proposed solution, while compared to existing analogues: OAuth, Opacity and LMAP. At the same time, the integrity of key sequences is not guarantied, that brings motivation for future research in the field.
I. BACKGROUND
AND
M OTIVATION
During the last decade the amount of Information Systems (IS), users have to communicate with in their daily life, grew dramatically. As the result, personal computers, mobile devices, web- and cloud-based systems now store a huge amount of confidential data. With respect to this trend, there was a re-arrangement of key parameters, user focus on, when choosing a particular application. Currently, besides performance characteristics, people pay much more attention to usability and security level of the app. While conventional user authentication methods, such as passwords, PINs, fingerprints, etc., have serious drawbacks (e. g. user has to memorise lots of passwords for different ISs or store the same ”key sequence” — fingerprint, etc. — in diverse systems), the new technology, called ”wireless authentication” can help with satisfying the usability/security trade-off. The basic idea behind is to apply the small tag, that supports NFC [1], RFID [2] or similar technology, as a ”key sequence” storage for multiple IS. However, this approach requires scalable and low-complex network protocol for user authentication in different IS, which is an open research problem. One of the possible solutions is described below. c 978-1-4799-1270-4/13/$31.00 2013 IEEE
Fig. 1.
Considered network topology.
II. L IGHTWEIGHT M ANY- TO -M ANY AUTHENTICATION P ROTOCOL Let us consider the network topology with N users, representing user’s home PCs or mobile devices, N cards with all the identificators and key sequences stored (one card per user), M departments, representing ISs: terminals in shops, banks, public transport, etc., and Certification Center (CC), responsible for private keys generation (see Figure 1). Several data chunks are stored on the card. Besides userID, given by CC, there is a set of pairs: depID : EN CdepID , where depID is a department identificator, given to particular department by CC (global for all the cards), and EN CdepID is an encrypted key sequence for IS with depID (different for different users). Described approach has several advantages: all the confidential data are stored on the card, rather than on trusted third parties; card itself is not battery-powered and doesn’t need any computation capability. So even cheap tags could be used. On the other hand, there are several requirements, solution has to satisfy, in order to be both secure and easy-to-use: • Usability: 1) Users can access all the key sequences from their cards at any time. 2) Departments can access the key sequence attached
.........INIT..........
U SER/DEP −−−−−−−−→ CARD
KEYuserID,depID = U KeyjdepIDi
.List of depID’s.
U SER/DEP ←−−−−−−−− CARD U SER/DEP −−−−−−−−−→ CARD
userIDj
KEYuserID,depID = DKeyi
...EN CdepID ...
U SER/DEP ←−−−−−−−−− CARD
userIDj
U KeyjdepIDi modc ≡ DKeyi
to their depID with no additional actions (User doesn’t have to explicitly allow the particular key sequence to be read). • Security: 1) User can not access the key sequences from other user’s cards, even if he/she has a physical access to the memory chip. 2) Department can not access the key sequences attached to other department’s IDs, even if it has a physical access to the memory chip. With respect to requirements 3 and 4, all the key sequences have to be encrypted with different encryption key (e. g. AES256 [3]). In order to satisfy requirements 1 and 2 the following key sequence access protocol is proposed for both user and department side (see Figure 2), where INIT is an initial signal that swithes the tag, and EN CdepID = E(KEYuserID,depID , KSuserID,depID ) is a key sequence for userID and depID encrypted with KEYuserID,depID . The major issue now is need to store M different encryption keys on the user side (one per depID) and N different encryption keys on the department side (one per userID). We minimize this amount to 1 by the following method. At first, let us constuct two set of functions: FdepIDi (userIDj ) and GuserIDj (depIDi ) satisfying the following criteria:
(1)
Then, let c — large prime number – be a system Public Key, while a < c — large integer — be a system Master Secret Key (MSK), stored in CC. Then, user’s and department’s secret keys could be generated as follows: U Keyj = auserIDj
mod c; DKeyi = adepIDi
mod c.
(4)
So, in order to satisfy formula 1, we need to prove
Key sequence access protocol.
FdepIDi (userIDj ) = GuserIDj (depIDi ) = = KEYuserIDj ,depIDi
(3)
The department can generate the decryption key similarly:
.........depID.........
Fig. 2.
mod c.
mod c (2) According to discrete logarithm problem [4], neither user, nor department can efficiently derive MSK from their secret keys. As such, only CC is able to generate a secret key for given userID or depID. Then, in order to decrypt the key sequence EN CdepID , user has to generate the decryption key KEYuserID,depID , performing the following operation:
mod c.
(5)
Theorem 1: Equation 5 is true for any i ∈ 1,¯M , j ∈ 1,¯N , where M is a number of departments and N is a number of users. Proof: Using equation 2, it is easy to show, that both sides of the formula 5 are equal to adepIDi ·userIDj mod c. Concluding, in this section the secure authentication protocol, that requires only a single encryption key on both user and IS sides is proposed. So far, there is no need to store a matrix of encryption keys on any device, including CC. III. C ONCLUSION A huge grow of number of ISs, user has to operate with, raises new challenges for user authentication protocols design. One of the possible solutions is to store identificators and key sequences on a single wireless node (e. g. NFC-device or RFID-tag). However, this approach requires a special mechanism that prevents Attacker from reading the key, even when a physical acces to the memory card is granted. In this paper the lightweight many-to-many authentication protocol for NFC, that solves the mentioned problem, is proposed. Our solution doesn’t require any battery power or computation capability on the key side. As such, it could be also used with other memory devices, such as USB flash drives. Despite the fact, the advantages of the proposed solution looks promising, the formal comparison with other existing approaches for user authentication, such as OAuth [5], Opacity [6] and LMAP [7] has to be presented. Also, the current version of the protocol allows user to modify the key sequence for any IS in an uncontrolled manner. So far, the solution in present form could be applied for user authentication, but should not be used for file storage (e. g. electronic copies of passport, driving licence, etc). R EFERENCES [1] NFC Forum, ”About NFC”, http://www.nfc-forum.org/aboutnfc/, 2013. [2] SO/IEC 14443 ”Identification cards — Contactless integrated circuit cards — Proximity cards”, 2008. [3] NIST, ”Advanced Encryption Standard”, Federal Information Processing Standards Publications (FIPS PUB 197), 2001. [4] Menezes A., Van Oorschot P.C., Vanstone S.A. Handbook of applied cryptography. CRC Press, 1997. [5] D. Hardt, ”The OAuth 2.0 Authorization Framework”, IETF RFC 6749, 2012. [6] ActiveIDentity, ”The Open Protocol for Access Control Identification and Ticketing with PrivacY”, ftp://ftp.heanet.ie/disk1/sourceforge/.. ./OPACITY\%20Overview-v3-7.pdf, 2010. [7] P. Peris-Lopez et al., ”LMAP: A Real Lightweight Mutual Authentication Protocol for Low-cost RFID tags”, WORKSHOP ON RFID SECURITY (RFIDSEC’06), 2006.
