Secret Sharing-based Authenticated Key Agreement Protocol

In this article, we present two novel authenticated key agreement (AKA) schemes that are easily implementable and efficient even on constrained devices. Both schemes are constructed over elliptic curves and extend Schonorr’s signature of knowledge protocol. To the best of our knowledge, we introduce a first AKA protocol based on the proof of knowledge concept. This concept allows a client to prove its identity to a server via secret information while the server can learn nothing about the secret. Furthermore, we extend our protocol via secret sharing to support client multi-device authentication and multi-factor authentication features. In particular, the secret of the client can be distributed among the client’s devices. The experimental analysis shows that our secret sharing AKA (SSAKA) can establish a secure communication channel in less than 600 ms for one secondary device and 128-bit security strength. The protocol is fast even on very constrained secondary devices, where in most of cases takes less than 500 ms. Note that the time consumption depends on the computational capabilities of the hardware.


INTRODUCTION
Key agreement protocols are currently one of the most used cryptographic primitives. These schemes permit to set-up a secure communication channel between two or more entities. The first modern key agreement protocol was the Diffie-Hellman (DH) protocol [8]. However, the basic DH protocol suffers from the man-in-the-middle attack since the involved parts do not authenticate themselves. The combination of a key agreement protocol with a digital signature scheme allows obtaining an AKA protocol. AKA protocols not only allow parties to compute the session key but also ensure the authenticity of the involved parties. AKA protocol is the process by which two (or more) authenticated entities establish a shared secret key.
The key is then used to achieve confidentiality or data integrity, for instance.
AKA protocols find applications mainly in Internet of Things (IoT) environment. There are many applications based on IoT such as home automation, smart city, healthcare, smart grid, and smart car [16]. These applications generate a large amount of data which leads to many security concerns, such as data leakages, eavesdropping, or unauthorized access. Unfortunately, IoT devices are constrained in their computational and memory capabilities. Therefore, we need a lightweight authentication protocol to cope with such an IoT environment.
This work presents an authenticated key agreement protocol that is provable secure, easily implementable, and efficient even on constrained devices in IoT. Furthermore, our protocol supports user multi-device authentication and it is based on zero-knowledge proofs and elliptic curve constructions.

Related work
Blake and Menezes [5] give a good overview of key agreement protocols that are based on the intractability of the DH problem. Law et al. [12] propose a two-pass protocol for authenticated DH key agreement which works on elliptic curves. This scheme combines static and ephemeral key pairs to obtain the session key.
Several identity-based key DH AKA are based on Weil and Tate pairing [7,14,24,26,27]. However, all these schemes are proved to be insecure [28]. To be noted that Smart [27] developed an identitybased key AKA which requires a trusted key generation center and uses a secret sharing scheme for the key generation. Wang [28] presents a pairing-based identity-based AKA which achieves all security AKA properties.
Pasini and Vaudenay [19] propose three protocols. The first scheme uses DH protocol in a secure channel. The second scheme combines the DH protocol and a short authenticated strings. The short string is used for authentication on an insecure channel. Finally, the third scheme uses an universal hash function. All schemes are based on commitment scheme. They focus on minimizing the number of message moves over the insecure channel and the length of authenticated messages.
Reddy et al. [22] extensively studied the existing mutual authentication protocols for a multi-server environment. Moreover, they propose a biometric-based 3-factor mutually AKA protocols for multi-server architecture based on elliptic curve cryptography and Burrows-Abadi-Needham logic. In 2019, the same authors [21] present an anonymous three-factor mutually AKA protocol for client-server architecture on elliptic curve cryptography. Yang et al. [29] present an AKA protocol with dynamic credential for wireless sensor networks. Dynamic credentials allow to clients to know if their authentication credentials have been compromised.
Melki et al. [15] propose a lightweight and multi-factor authentication protocol for IoT devices. The protocol is based on configurable Physical Unclonable Functions (PUF) and channel-based parameters. Hajny et. al. [9] present a multi-device authentication scheme using wearables and IoT devices. This scheme is provable secure and based on zero-knowledge proofs. However, the scheme does not support mutual authentication and key agreement mechanisms. In 2018, the same authors [10] present multi-device authentication scheme with strong privacy protection.
The scheme is provably secure and provides the full set of privacyenhancing features such as the anonymity, untraceability, and unlinkability of users. Even this scheme does not provide mutual authentication and key agreement mechanisms. The scheme is symmetric, therefore, it does not provide non-repudiation property so typical for digital signatures. Lopes et al. [13] propose a secretsharing-based AKA based on Shamir secret share scheme [25] for multi-device authentication. In their scheme, a trusted third party create and share the secret keys among the user's devices. Moreover, each partial secret key needs to be disclose to be authenticated.
To the best of our knowledge, we introduce a first AKA protocol based on the proof of knowledge concept. This concept allows the user to prove its identity to a server via secret information (such as a password or cryptographic key) while the server can learn nothing about this secret. Furthermore, our AKA is based on Schnorr signature [23] which produces fast and short signatures. Finally, the protocol construction easily integrates other security and privacy features such as multi-device and multi-factor authentication techniques.

Contributions
In this article, we present two novel schemes, namely AKA and SSAKA. The basic AKA scheme is based on zero-knowledge-proof protocols and it is efficient even on constrained devices that are very often used in current IoT ecosystems. To the best of our knowledge, we introduce a first AKA protocol based on the proof of knowledge concept. The AKA zero-knowledge core allows to increase the security strength of the algorithm by sharing the client's secret among more user devices such as wearable, embedded microcontrollers, or smartcards. Moreover, the client can actively be part of the authentication by using passwords or PIN codes. Thanks to this, our AKA can be easily extended to support multi-device and multi-factor authentication features. This is achieved in SSAKA scheme where our AKA scheme is combined with a slightly modified multi-device authentication technique presented in [9]. The SSAKA strengthens security by sharing the client secret between more parties. In particular, the secret of the client can be distributed among the client devices. Finally, an evaluation of our schemes is presented. We show that our SSAKA can establish a secure communication channel in less than 600 ms for one secondary device and 128-bit security strength.
This paper is organized as follows: Section 2 defines used notation and gives the necessary background on underlying cryptographic primitives used in our AKA schemes. Section 3 presents our basic AKA scheme based on zero-knowledge proofs and Section 4 introduces our secret sharing-based AKA which allows deployment of more additional devices and user password to the authentication and key agreement processes. Section 5 discusses security analysis of our schemes and Section 6 shows our implementation results. In the last section, we conclude this work.

PRELIMINARIES
In this section, we introduce the notation used throughout the paper. Moreover, we recall proof of knowledge concept and secret sharing scheme which are the cryptographic core of our AKA protocol. In particular, we will focus on signature of knowledge concepts which are non-interactive proof of knowledge protocols.
From now on, the symbol ":" means "such that", "|x |" is the bitlength of x, and "||" denotes the concatenation of two binary strings. We write a ← $ A when a is sampled uniformly at random from A. A secure hash function is denoted as H : {0, 1} * → {0, 1} κ , where κ is a security parameter. Moreover, G = ⟨д⟩ denotes a cyclic group of order q, and α is an element of Z * q . We describe the Proof of Knowledge (PK) and the Signature of Knowledge (SK) protocols using the notation introduced by Camenisch and Stadler. In particular, the protocol for proving the knowledge of discrete logarithm of c with respect to д is denoted as PK{α : c = д α } and the protocol for proving the knowledge of discrete logarithm of c with respect to д and message m is denoted as SK{α : c = д α }(m).

Proof of Knowledge
The concept of proof of knowledge is frequently used in many modern cryptosystems such as group signatures, ring signatures, and attribute-based credentials. In proof of knowledge, one entity, namely prover, proves to another entity, namely verifier, the veracity of a given statement. Statements regarding discrete logarithm problems can be easily proven by using Σ-protocols [6].
A Σ-protocol is a simple 3-way protocol where the prover commits a random number r , receives a challenge e, and finally responds by the proof z to the challenge. One of the most used Σ-protocol is the Schnorr protocol [6]. We recall its properties below:
• Completeness: if the statement is true, the verifier will always accept the proof.
• Special Soundness: if the statement is false, no cheating prover can convince the verifier of the validity of the proof, and the prover will be always rejected.
• Special Honest Verifier Zero-Knowledge: if the statement is true, no verifier learns anything other than the fact that the statement is true.
Okamoto Σ-protocol [18] is an extension of Schnorr protocol which allows the usage of two private keys and provides witness indistinguishability. The Okamoto protocol is defined as follow: Let G be a group of prime order q and д 1 , д 2 ∈ ⟨д⟩ are generators such that the loд д 1 д 2 is known to nobody. Let w 1 , w 2 ∈ Z * q be the prover's private keys, and let h = д w 1 1 д w 2 2 be the prover's public key. The Okamoto protocol is proof of knowledge of discrete logarithm of c with respect to д 1 , д 2 donated as PK{w 1 , w 2 : h = д w 1 1 д w 2 2 }. In our protocol, we adopt the Okamoto protocol into one single group generator in order to design secret sharing of knowledge protocols, see Figure 1.
Interactive proof of knowledge protocols are frequently used in authentication schemes, where a challenge e is generated by a verifier. On the other hand, non-interactive proof of knowledge protocols are widely used in particular for signature scheme constructions. In this case, the challenge e is generated by the prover with the use of a secure hash function H . The non-interactive variant is more often called signature of knowledge, due to the inclusion of the message in the proof as shown in Figure 2.

Secret Sharing Scheme
Secret Sharing [4] is a cryptographic tool that is used as a building block in many protocols such as multiparty computation, generalized oblivious transfer, and attribute-based encryption. The scheme involves a dealer who owns a secret and a set of n parties. The dealer distributes a secret value k in shares in a way that only qualified subsets of parties can recover the secret.
A secret sharing scheme has two requirements [4]: • Correctness: the secret k can be reconstructed by any authorized set of parties.
• Perfect Privacy: every unauthorized set cannot learn anything about the secret (in the information theoretic sense) from their shares.
The minimum number of shares needed to reconstruct the secret is called threshold. There are constructions with and without threshold [11,25].

BASIC AKA PROTOCOL
In this section, we define the algorithms and entities of our AKA protocol. The AKA communication pattern is depicted in Figure 3 and employs two parties: • Client: is typically a user which is accessing specific online services. To get an access to these services, the client must pass the authentication phase by proving possession of the access key. The key is stored on a user device which can be any computing device represented by simple microcontrollers, wearables, smartphones, or even by powerful personal computers. • Server: is very often a powerful computer providing different user services. However, the rise of IoT environments causes that servers are represented more often by computationally less powerful devices such as Raspberry Pi singleboard computers.

Protocol description
The goal of the AKA protocol is not only to allow parties to compute the session key but also to ensure the authenticity of both involved parties. To do so, the client holds the servers' signature public key pk S and the server holds the client's signature public key pk S . On both sides, we use a variant of Schnorr's signature scheme to generate the signatures and, therefore, to authenticate both communication parties. We assume, that both these signature public keys are securely transferred between parties before AKA protocol starts. In the case of the server, it can be easily achieved by using a Public Key Infrastructure (PKI), which involves trusted certification authorities, or by pre-installing the server's signature public keys directly to the client application. The client usually provides his/her signature key during the registration phase. Then the AKA protocol works in three following steps: (1) Step 1: The client sends ClientHello message with 1) his unique Client IDentifier (CID), 2) the cipher suites specifying preferred cryptographic algorithms (e.g., elliptic curve type such as SECP256), symmetric cipher (eg., AES-GCM-256), and hash function (e.g., SHA2-256), and 3) the client challenge RNDc. The RNDc challenge protects the system against authentication replay attacks. (2) Step 2: The server creates a message Y which includes CID, used cipher suites, RNDc, and a confirmation of common cipher suites. The message can have for example the following format: Y = {CID || SECP256 || SHA2-256 || AES128GCM || RNDc || ACCEPT}. The server then executes AKA-SERVER-SIGNVERIFY algorithm to generate the Schnorr' signature σ on the message Y and, therefore, to generate authentication proof. Both values Y and σ are sent back to the client in the ServerHello message. It is important to notice that the signature includes also the server's DH public key for the key agreement protocol. This DH key serves also as an authentication challenge of the server since the key is randomly generated for each communication session. The client then performs AKA-CLIENT-PROOFVERIFY algorithm to check the validity of the signature σ , computes a common session key κ, and client's proof of knowledge π of the secret key sk C . (3) Step 3: The server performs second part of the AKA-SERVER-SIGNVERIFY algorithm to compute the common session key κ and verify client's authentication proof.
Thanks to the deployment of the Schnorr's signature, we can 1) sign messages of both parties and, therefore, authenticate one against other, 2) generate randomness, i.e. an authentication challenge which allows avoiding replay attacks, and 3) perform DH key agreement protocol over cryptographic commitments to establish a common session key.

Definition of algorithms
In this section, we present the concrete instantiations of cryptographic algorithms of our AKA.
(spar ) ← AKA-SETUP(κ): The protocol is run by a server in order to generate initial system parameters. The algorithm inputs the security parameter κ and outputs the system parameters spar . On the input of the security parameter κ the server generates a cyclic group G = ⟨д⟩ of prime order q : |q| = κ, where the Discrete Logarithm (DL) assumption holds and outputs spar = (G, д, q) as public system parameters. The systems parameters are securely distributed between all system parties and they are used as an implicit input for all following algorithms.
The protocol is run between a server and a client. At first, the client establishes a secure communication channel with the server. At second, the algorithm inputs the security parameter κ and outputs user key pairs sk C ← $ Z * q , pk C = д sk C . The secret key sk C is securely stored on the client's device, while the public key pk C together with the user login name are sent to the server. The server assigns the unique CID to the client. CID, login name, and the public key pk C are securely stored in the server database.
The algorithm takes as input a message Y, the server's secret key sk S , and the client's signature public key pk C . It outputs the result of client authentication τ S = 0/1, and the shared session key κ as shown in Algorithm 1. At first, the server computes a cryptographic commitment t S = д r S as a part of the Schnorr's signature. Furthermore, the commitment serves also as an authentication challenge of the server and DH public key of the server, while the value r S represents DH secret key. Both Y and σ are sent to the client, while the client answers with his/her authentication proof π . The server verifies the reconstruct of the client's cryptographic commitment t ′ = д s C · pk e C C . The commitment t ′ also represents the client's DH public key, and therefore, the client computes a common session key such as κ = t ′r S . Finally the server very the client's proof The algorithm takes as input a message Y, the server's signature public key pk S , and the client's secret key sk C . It outputs the result of the server authentication τ C = 0/1, the client authentication proof π , and the common shared session key κ as shown in Algorithm 2. At first, the client reconstructs the server's commitment t ′ S = д s S · pk e S S , which also represents the server's DH public key and checks it's correctness by comparing e S ? = H (Y , t ′ S ). At second, if the signature is valid, the client computes the authentication 10: return τ S = 0/1, κ proof π and a common DH session key κ = t ′r C S . Otherwise, the client ends the protocol.

SECRET SHARING-BASED AKA PROTOCOL
Our Secret Sharing-based Authenticated Key Agreement (SSAKA) protocol is built upon our AKA protocol which was presented in Section 3. The SSAKA extends AKA scheme by secret sharing property. The secret is reconstructed only if all the involved parties (devices) collaborate. The client decides the number of involved devices and if being actively part of the protocol by using a password or a PIN code, for instance.
In this section, we define the algorithms and protocols of our SSAKA scheme in more details. The communication pattern is depicted in Figure 4 and employs four types of entities: • Server: is usually a service provider that needs to verify the identity of their users. The server can be represented by a powerful computer or a less powerful single board computer.
• Client: is represented by the user's Master Device (MD) which can be a PC, laptop, smartphone, or tablet. The client needs to prove his/her identity and to establish a secure communication channel with the server.
• Device: is an additional Secondary Device (SD) with usually less computational power. Examples of SD devices are smartcards, smartwatches, sensors, and embedded microcontrollers. SDs are involved in the authentication process to strengthen security.
• Party (P): specifies a device, a password or a PIN code used in the protocol.
SSAKA protocol requires the addition of three new algorithms which allow extending our AKA protocol to work in a multi-device environment. In particular, SSAKA-CLIENT-ADDSHARE algorithm generates a new client's secret key, where each involved device knows only its share of the key. SSAKA-CLIENT-REVSHARE algorithm allows revoking a device secret key from the client key. At last, SSAKA-DEVICE-PROOF algorithm computes the proof of knowledge of each device's secret. Moreover, Algorithm 2 is slightly modified to Algorithm 3. These changes permit the protocol to run in a multi-device environment. The sub-protocols are specified below in details.
(pk C , pk C , sk C ) ← SSAKA-CLIENT-ADDSHARE(⟨sk i ⟩ ∈N EW , sk C , pk C ): The protocol is run between a client MD, several SDs and the server. The task of this algorithm is to spread the client secret sk C among all involved parties. The algorithm inputs system parameters spar , client secret key sk C = sk 0 + DEV i=1 sk i , where sk 0 is the MD share and sk 1 , . . . sk DEV are shares of DEV already registered SDs, and ⟨sk i ⟩ ∈N EW represents the set of new shares (i.e., newly registered SDs). In this case, each SD generates its own keypair sk i ← $ Z * q , pk i = д sk i . The secret keys are kept secret while the public keys are securely sent to MD. The piece of secret can be also shared with the client him/herself. In this case, the client share sk pw is computed by hashing his/her password, or PIN code. Finally, the client MD computes the extension of the client public key, i.e it computespk C = N EW i=1 pk i for all N EW available devices or for the eventually client's passwords or PIN codes. The client runs the SSAKA protocol and sends the extension of the public keypk C to the server through established secure channel. The server updates the main client's public key pk C = pk C ·pk C . After this update, the new devices, passwords, or PIN codes must be always used in the SSAKA protocol. Let note that the MD private key sk 0 , and SDs keys ⟨sk i ⟩ ∈DEV never leave the devices, only the public keys pk C ⟨pk i , ⟩ ∈DEV are revealed. Each party (i.e., client's device) knows only a share of the client secret sk C and only together they are able to forge it, that is sk C = sk 0 + DEV i=1 sk i , where DEV is the number of all registered SDs.
(pk C , pk C , sk C ) ← SSAKA-CLIENT-REVSHARE(⟨sk i ⟩ ∈REV , sk C , pk C ): The protocol is run between a client MD, several SDs and the server. The task of the algorithm is to revoke the client secret among the parties. The algorithm inputs system parameters spar , client secret key sk C = sk 0 + DEV i=1 sk i , where sk 0 is the MD share and sk 1 , . . . sk DEV are shares of DEV already registered SDs, and ⟨sk i ⟩ ∈REV represents the set of revoked shares (i.e., newly revoked SDs). The client selects the shares to be revoked from the client secret sk C . To do so, the clients picks all corresponding SDs public keys or eventually public key of the user password pk pw = д sk pw , where sk pw = H (password). Finally, the client's MD computes the subtraction of client's public key, i.e it computespk C = REV i=1 pk i for all REV devices or eventually clients passwords or PIN codes. The MD runs SSAKA protocol and sends to server the subtraction of the public keyspk C through established secure channel. The server then updates the main client's public key pk C = pk C ·pk C this update, the revoked Ps are no more used in the SSAKA protocol.
(τ C , π , κ) ← SSAKA-CLIENT-PROOFVERIFY(Y , σ , pk S , sk C ): The algorithm runs as Algorithm 2 with small modifications that are marked in red in Algorithm 3. In this case, the algorithm requires to call Algorithm 4 for each SD, which has a share of the secret, and therefore is involved in the protocol. Moreover, t and κ values need the commitments t i and κ i of each SD. Values s i represent proofs of knowledge of the secret shares of all SDs.
The algorithm takes as input server's DH public key t ′ S and the P's secret key sk i and outputs the P's authentication proof s i and P's DH public key fragment κ i , see Algorithm 4 for more details. At first, the device commits to random value t i = д r i and computes DH public key fragment as κ i = t ′r i S . Both values sends to MD. The MD responses with authentication challenge e C on which the device computes the proof of knowledge s i its share of client secret sk i .

SECURITY ANALYSES
We prove the security of our AKA and SSAKA protocols in this section. The AKA protocol is based on provable secure cryptographic primitives, namely Schnorr signature and DH protocol.
Lemma 5.1. The Schnorr signature is existentially unforgeable under chosen-message attacks in the random oracle model assuming that the DL problem is hard.
Proof. The Lemma 5.1 is proven in [20]. = H (Y , t ′ , κ), where the κ = t ′r S and t ′ is the client's commitment. Therefore, the protocol pass if the commitment is correctly reconstructed.
where DEV is the number of all registered SDs. □ Lemma 5.3. The AKA and SSAKA authentication protocols are both sound.
Proof. Suppose that a client does not know the private key and is ready to correctly respond to at least two challenges (denoted as e C , e ′ C ) by sending s C and s ′ C . Then, the following equations must hold for the client to be accepted.
By dividing we get: And finally we get: And we reached the contradiction because the user knows the private key sk C = SSAKA soundness proof directly follows from AKA one. In fact, the only difference is in the values sk C and pk C which do not change the proof as shown in Lemma 5.2 □ Lemma 5.4. The AKA and SSAKA authentication protocols are both zero-knowledge.
Proof. We prove the zero-knowledge property by constructing the zero-knowledge simulator S. The simulator works in the following steps.
The simulator's output is computationally indistinguishable from the real protocol transcript, i.e. (t,ê C ,ŝ C , ) c (t, e C , s C ), because all pairs are selected randomly and uniformly from the same sets.
SSAKA zero-knowledge proof directly follows from AKA one as in Lemmas 5.2 and 5.3. □ Lemma 5.5. AKA and SSAKA key agreement protocol are secure against eavesdroppers.
Proof. The AKA key agreement protocol is based on DH protocol, where both entities reconstruct the DH public key of the counterparty from the authentication phase. In particular, the entities reconstruct cryptographic commitments t ′ S and t ′ , and compute a common secret κ.
In case of SSAKA, the situation is equivalent, since we can write where DEV is the number of all registered SDs. □ Lemma 5.6. SSAKA protocol provides both secret sharing properties, i.e. correctness and perfect privacy.
Proof. The proof is straightforward.
• Correctness: since each party P i owns a different part of the secret key sk i , the user secret key sk C = i sk i can be reconstructed only knowing all the sk i . • Perfect privacy: unauthorized set cannot learn anything about the secret since sk C = i sk i mod q. The modulus prevent to have information on sk C . □ Furthermore, our AKA and SSAKA protocols meet all security attributes of authenticated key agreement protocol defined in [16]: • Mutual authentication: both entities, i.e. a client and a server, authenticate each other during the run of the protocol. Our AKA uses the authentication model challenge-response based on the Schnorr's digital signature. • Key compromise impersonation: if an adversary compromises the long-term secret key of one entity, then the adversary can impersonate only this entity no others system entities. Our AKA uses asymmetric cryptography, where each involved entity uses its own secret Schnorr key. • Parallel session attack: the knowledge of some previous session keys does not allow the adversary to compromise other session keys. In both protocols session keys values are randomized, therefore knowing previous session keys does not leak any information on user's secret key (proofof-knowledge property). • Denial of service attack: an adversary can try to consume resources of the server by sending fake login messages. If that happens, the user's CID or IP address can be easily putted on the blacklist and the login request will be denied. • Replay attack: our AKA and SSAKA use authentication model challenge-response which prevents against replay attacks.
• Man-in-the-middle attack: our AKA uses mutual authentication based on Schnorr signatures which prevents against man-in-the-middle attacks.

EXPERIMENTAL RESULTS
In this section, we show the evaluation of our AKA and SSAKA protocols. AKA protocol is efficient and easy to implement even on very constrained devices. Moreover, we implement the whole SSAKA protocol on a set of various modern programmable devices, namely smartwatches, smartcards, smartphones, microcontrollers, and microcomputers. The hardware (HW) and software (SW) specification of deployed devices is shown in Table 1.
We suggest using only the cryptographic algorithms recommended by international cybersecurity authorities such as the National Institute of Standards and Technology (NIST) and the European Union Agency for Cybersecurity (ENISA), see Table 2 for more details.
The implementation is based on RIOT [1] operating system, RIOT compatible devices, and libraries. It allows us to make the applications easily portable across various types of devices based on different architectures and developed by different manufactures. In particular, we build up the applications on Crypto and micro-ecc libraries written in C programming language: • Crypto [1]: is the native cryptographic library of RIOT. It provides block ciphers, operation modes, and cryptographic hash algorithms. We consider it mainly for performing Advanced Encryption Standard (AES) encryption in the CCM operation mode and hashing with Secure Hash Algorithm (SHA) between a user device and the server.
The micro-ecc library implements ECDH and ECDSA algorithms and provides Application Programming Interface (API) to use them. The library provides also an access to AKA required underlayer mathematical operations such as Elliptic Curve (EC) point scalar multiplication, modular reduction, multiplication, and addition. To make them available to developers, only the flag -DuECC _ENABLE_VLI_API needs to be added to the compiler. The only missing AKA required operation is EC points addition. We extended the micro-ecc library by the EC points addition operation (the function uECC_point_add). To do so, we slightly modify the uECC_verify function in the uECC.c file. This function is originally used in ECDSA verification protocol to compute sum = G +Q, where G, Q are two EC points.
The RIOT supports two main elliptic curve cryptographic libraries, namely micro-ecc and Relic [3]. Relic supports among others calculation on NIST E(F 2 m ) and E(F p ) curves, pairing-friendly curves, pairings and related extension fields F p k . Furthermore, the Relic shows significantly better performance results as shown in Figure 5. However, the Relic memory requirements are significantly higher than micro-ecc ones, and therefore, we avoid the Relic from the AKA protocol implementations. We consider the Crypto library to implement ciphers algorithms since it is part of the RIOT and due to its efficiency. We compared the Crypto with TinyCrypt library, where the TinyCrypt was ca. 6 times slower. The Figure 5 shows the time needed to encrypt 16 KB data with AES256-CCM for Crypto library and to multiply the EC point with the scalar (ecMUL) with Relic and micro-ecc libraries. We use micro-ecc library also for Android implementations in smartphones and smartwatches. The Android Native Development Kit (NDK) allows us to execute a program in C/C++ on Android devices instead of using Java libraries. In fact, we compare the efficiency of Spongy Castle [17] (Android version of Java Bouncy Castle library) and micro-ecc as depicted in Figure 6. The difference is even more significant on less powerful devices such as wearables. The implementation results of Algorithms 1, 3, 4 on different IoT devices are shown in Table 3. The performance is measured in milliseconds, since the measurement of clock cycles is unavailable on the smart card platform and on wearables. Furthermore, the clock cycles are not meaningful for practical demonstration. We use the standard personal computer to simulate the server side. We let the smartphone act as MD while SDs where represented by smartwatches, microcontrollers, single board computers, and smartcards. The micro-ecc library was used in all implementations except the smartcard implementations. We used RIOT to run the same code on all microcontrollers. However, in the case of Arduino Nano we were not able to run the protocol using RIOT  due to the limited resources, so we reimplemented it using pure Arduino. The code for MultOS ML4 smartcard was written in Mul-tOS assembly code and C language while the JavaCard J3H145 application was written in JavaCard programming language using Java Card Development Kit (JCDK) 3.0.4. Since the JavaCard does not support modular arithmetic operations nor EC operations, we had to implement them. In case of modular arithmetic operations, we implement them from scratch as software solution. In case of EC operations, we used hardware solution, i.e. we used smartcard coprocessor through class javacard.security.KeyAgreement and ALG_EC_SVDP_DH_PLAIN_XY, ALG_EC_PACE_GM algorithms. Finally, we benchmark whole SSAKA implementation including a communication overhead. The implementation consists of one smartphone (Xiaomi Redmi note 8 Pro) which is used by client as a master device. The smartphone uses Near Field Communication (NFC) wireless technology to communicate with the server. We use smartwatch (HUAWEI Watch 2) as one secondary device needed to gain an access to the server and establish a secure communication channel. The smartwatch communicates with the smartphone through Bluetooth Low Energy (BLE) wireless communication channel. The Figure 7 shows our experimental results for different security strengths. The whole SSAKA protocol with deployed devices takes less than 600 ms for the 128-bit security strength (SECP256).
The Server time (marked in red) shows time needed by server to generate its signature and very the user's proof. The Smartphone time (marked in green) shows time needed by smartphone to verify the server and generate user's proof including the NFC communication overhead. The Smartwatch time shows the time complexity of secondary device including BLE communication overhead.

CONCLUSION
In this paper, we proposed two novel AKA schemes, namely AKA and SSAKA. The basic AKA scheme is based on zero-knowledgeproof protocols and it is efficient even on constrained devices that are very often used in current IoT ecosystems. The SSAKA scheme extends our AKA to support multi-device and multi-factor authentication. Sharing the client's secret among more user devices increases the security strength of the algorithm. Examples of sharing parties are wearables, embedded microcontrollers, smartcards, or even the client him/herself using passwords or PIN codes. Both protocols' full security analysis is provided and implementation aspects are described in this paper. Our SSAKA can establish a secure communication channel in less than 600 ms for one secondary device and the 128-bit security strength. The protocol complexity is given by the computational capability of the most contained secondary device. This is due to the fact that the communication between the master device and secondary devices is run in parallel. As a next step, we will focus on adding privacy-enhancing features to this scheme.