Cryptographic Protocols for Confidentiality, Authenticity and Privacy on Constrained Devices

Cyber security and privacy protection play a crucial role in modern communication systems. While it is relatively easy to secure classical networks, it is a hard problem to provide even basic security properties, such as confidentiality, integrity, authenticity and privacy, in heterogeneous networks that involve devices with restricted resources. In these environments, such as industrial networks, sensor networks or IoT networks, the protection of user data is still very low. In this paper, we present the design of cryptographic protocols that provide the crucial security and privacy-protection features while they’re fully implementable on constrained devices. First, we present a computationally efficient scheme for the establishment of a secure channel on a device with almost no cryptographic support and very low computational and memory resources. Second, we present a privacy-enhancing scheme for achieving so-called anonymous authentication, that is the verification of user authorization without disclosing her identity. Also in this case we use only very limited support of cryptographic operations and computational resources. Besides the full cryptographic description, we also show the benchmarks based on our implementation of protocols and the way of integration into real-world applications.


I. INTRODUCTION
Security and privacy in communication networks is usually provided by cryptographic means. In case of security, we try to achieve confidentiality (a feature that guarantees that attackers cannot read data), integrity (a feature that guarantees that attackers cannot modify data during a transfer) and authenticity (a feature that guarantees that attackers cannot impersonate valid users). There are many proven ciphers that provide these CIA (Confidentiality, Integrity and Authenticity) features individually and even together in a single algorithm. The most popular standardized algorithms are Advanced Encryption Standard (AES) [1] for encryption (providing confidentiality), Secure Hash Function (SHA) [2], [3] for computing message digests (providing integrity) and (Elliptic Curve)Digital Signature Algorithm (EC)DSA [4] for digital signatures (providing authenticity).
The examples of algorithms mentioned above are integrated into cryptographic protocols that provide security features This paper is supported by the Czech Ministry of Industry and Trade grant #FV40340 and EU grant #813278 (A-WEAR).
to users in communication systems. Most of the algorithms may be used in standard communication systems that involve servers, computers, mobile phones, etc. However, in heterogeneous networks, such as IoT and SCADA, there are also different types of devices, usually with very restricted computational and memory resources. As examples, we name sensors, controllers, wearable devices, cyber-physical devices or medical aids. On such devices with only very limited computational power, it is very difficult to use advanced cryptographic algorithms without affecting the fundamental functions. In most cases, the use of asymmetric ciphers (such as RSA, DSA or DH algorithms) is not supported by the CPUs and micro controllers and is very difficult to implement in software due to lack of computational power.
The situation gets even worse in case we need to implement privacy-preserving features on constrained devices. Even the fundamental building block for privacy-enhanced authentication, the group signatures [5]- [7], is based on asymmetric cryptography and operations that are at least as complex as digital signatures. More advanced cryptographic schemes, such as Attribute-Based Credentials (ABCs) [8]- [10] or Homomorphic Encryption (HE) [11]- [13] are currently not implementable on constrained devices due to lack of computational resources and unsupported basic operations, such as the bilinear pairings and arithmetic operations on elliptic curves. However, with the increasing popularity of IoT and industrial networks, we cannot ignore security and privacy protection in real applications any more. Therefore, we propose practical cryptographic protocols for constrained devices that provide the basic security and privacy-protection features and are implementable on current hardware with reasonable running times.

A. State of the Art
The algorithms for regular hardware devices (i.e., computers, server, mobile devices) are well-known and standardized, usually by the National Institute of Standards and Technology (NIST): RSA or (EC)DSA for digital signatures, AES for encryption, SHA-2 or SHA-3 for message digests. These algorithms are used in cryptographic protocols for building secure channels, in most cases Transport Layer Security (TLS) [14] or IP Security (IPsec) [15] protocols are used. However, these protocols require asymmetric cryptography to authenticate users, which results in a very difficult or impossible implementation on constrained devices. Solutions based on symmetric cryptography exist, but are often proprietary (e.g., in case of smart-card based authentication systems [16]), too complex (e.g., Kerberos for enterprise networks [17]) or insecure (e.g., 2G mobile network authentication [18]). The performance of basic cryptographic pritmives has been evaluated on real-world constrained devices, e.g. in papers [19], [20].
In the area of privacy protection, we distinguish two major topics: anonymous routing and privacy-enhancing authentication systems. The anonymous routing protocols, such as TOR or Mixnets, are the prerequisite. Without anonymous routing, any higher-layer protection would be useless as users could be identified by IP addresses (or patterns in communication, content, etc.). Fortunately, there are already solutions [21], [22] that can be used even on constrained resources and achieve anonymous communication channels. However, the privacyenhancing technologies for managing user identity and/or personal attributes, are not yet available on platforms with limited resources. There are very promising results from the smart card area [10], [23], [24], but generally, full-fledged user-centric authentication schemes are not yet ready for the implementation on existing constrained devices, in particular devices with restricted cryptographic support and strong requirements on low verification times. This paper provides solutions for applications witch such specific requirements.

B. Our Contribution
We propose two novel cryptographic schemes that provide 1) confidentiality, integrity and authenticity in networks involving constrained devices and 2) privacy protection for users using constrained devices and authentication devices. We fully describe the communication patterns, specify the cryptographic design and show the implementation results including benchmarks on ARM-based micro controllers and smart cards.
We provide the cryptographic preliminaries in Section II, the design of cryptographic protocols in Section III and the results from our practical implementation in Section IV.

II. PRELIMINARIES
In this section, we describe the cryptographic preliminaries.

A. Notation
The symbol ":" means "such that" and |x| is the bitlength of x. The symbol H denotes a secure hash function. We write a ← $ A when a is sampled uniformly at random from A. Let GroupSetup(1 κ ) be an efficient algorithm that generates a group G = g of prime order q, such that |q| = κ. Let e denote a bilinear map.

C. Weak Boneh-Boyen Signature
We recall the weak Boneh-Boyen signature scheme [6], which is existentially unforgeable against a weak (nonadaptive) chosen message attack under the q-SDH assumption.
Setup: On input security parameter τ , generate a bilinear group (q, and output sk = x as private key and pk = (q, G 1 , G 2 , G T , g 1 , g 2 , e, w) as public key.
Sign: On input message m ∈ Z q and secret key sk, output σ = g 1 x+m

III. CRYPTOGRAPHIC DESIGN
In this section, we specify the cryptographic protocols for security and privacy protection.

A. Security Protocols
The main goal of the security scheme is creating a security channel that provides confidentiality, integrity and authenticity. Therefore, there must be an authentication phase where at least users prove their identity. Based on the authentication phase, a shared key must be established and used for authenticated encryption. All these features must be realized using only symmetric cryptography (preferably only using AES and a hash function) so that it is implementable on existing, low-price microcontrollers, such as the PIC24 family from Microchip.
The communication pattern of our scheme employs the following entities: • Issuer (I): is responsible for issuing personal identifiers ID U and private keys K V −U to users. • User (U): gets the identifier ID U and private key K V −U and proves their possession to the verifier. Establishes a shared session key K S for encryption. • Verifier (V): verifies the possession of a secret keys K V −U . Establishes a shared session key K S for encryption. Our scheme consists of the following algorithms: K ←Setup(1 κ ): the algorithm inputs the security parameter κ and generates the master key K ← $ Z 2 κ . The Setup algorithm is run by the issuer.
(K Vi , K Vi−Ui ) ←Issue(1 κ , K): the algorithm inputs the security parameter κ and the master key K. First, a randomly generated identifier ID Vi is assigned and a unique secret key is generated for all verifiers using a key-derivation function (i.e., a hash-based PBKDF) as K Vi = H(K, ID Vi ). Then, a secret key unique per each verifier is generated to all users as K Vi−Ui = H(K Vi , ID Ui ). The Issue algorithm is run by the issuer. Verifiers' and users' secret key are securely distributed to their owners.
: the protocol consists of the Show algorithm run by the user and the Verify algorithm run by the verifier. The Show algorithm inputs the user's identifier, secret key and a random nonce from the verifier and outputs the session key K S . The Verify algorithm inputs the verifier's identifier, secret key and the random nonce from the user and outputs the session key K S . The protocol is a simple challenge-response protocol based on hashing secret keys with random challenges (nonces). The protocol is depicted in Figure 1.

Security Analysis
The protocol is based on a single primitive, namely the proven block cipher AES. The protocol provides the following features: • Confidentiality: all communication data are sent inside the tunnel encrypted by AES. • Integrity: data integrity is protected by the GCM mode of AES. • Authenticity: both user and verifier are verified using secret keys. • Replay Attack Protection: all authentication sessions are unique, randomized by nonces. Encryption key is always randomly generated. • Key Diversification: all users and all verifiers have unique keys, so that the attacker breaking key of one user/verifier cannot get the keys of others.

B. Privacy Protocols
The design of security protocols is relatively easier than the construction of privacy-enhancing protocols, as only symmetric primitives are usually required. In this section, we design a protocol for so-called anonymous authentication. Using this protocol, the user can prove that she has the authorization to use a service without disclosing her identity. Therefore, all the transaction are anonymous, unlinkable and untraceable. In this scenario, we assume that issuer is also the verifier of the user authorisation (i.e., the private user's key ownership). Even in this settings, the verifier is unable to identify and/or trace a user to whom he already issued the keys. The protocol works with so-called epochs, therefore the keys must be re-issued periodically (e.g., each week or month).
The communication pattern employs the following entities: • Issuer (I): is responsible for issuing personal identifiers ID U i and private keys (K U i , K U i ) to users. • User (U): gets the identifier ID U i and private keys (K U i , K U i ) and proves their possession to the verifier. The proof is anonymous and always unique (randomized) so tracing and profiling of users is prevented. • Verifier (V): verifies the possession of a secret key K V .
Using K V , the verifier is able to check the user's proof of user key ownership without identifying the user or disclosing any keys. Verifier is also able to check that the key is valid for current time period (epoch).
Our scheme consists of the following algorithms: K ←Setup(1 κ ): the algorithm inputs the security parameter κ and generates the group G = g 1 of prime order q, such that |q| = κ. The algorithm also generates the master key The Setup algorithm is run by the issuer.
(K Ui , K Ui , K V ) ←Issue(1 κ , K): the algorithm inputs the security parameter κ and the master key K. First, a randomly generated identifier ID U i and a current epoch identifier E (e.g., a week or month identifier) are set. Then, a unique secret key K U i = g 1 K 0 +K 1 ID U i +K 2 E 1 and an auxiliary value U i is generated for all users. The Issue algorithm is run by the issuer. Verifiers' and users' secret key are securely distributed to their owners.
e, s, s ID ) → (0/1): the protocol consists of the Show algorithm run by the user and the Verify algorithm run by the verifier. The Show algorithm inputs the user's identifier, secret key and the random nonce from the verifier and outputs the cryptographic proof of key ownership consisting of (K U i , e, s, s ID ) values. The proof is based on the non-interactive proof of weak Boneh-Boyen signature knowledge (more details in [25]). The Verify algorithm inputs the verifier's secret key and the proof from the user and outputs 1 if the proof is correct and 0 otherwise. Note that neither user identifier not her keys are disclosed during the ownership proof. Furthermore, all communicated values are randomized in the sessions so that sessions of a single user cannot be linked together. The protocol is depicted in Figure 2.

Security Analysis
The protocol is using only a hash function and basic arithmetic in a standard prime-order group. The protocol provides the following features: • Anonymity: users remain anonymous during the protocol execution. • Unlinkability: all sessions of a single users cannot be linked together, so profiling is prevented.  • Untraceability: although issuer issues keys to users, he cannot link the issuance and verification sessions. This feature holds also in cases where issuer is also verifier. • Revocation: users' keys expire after the epoch period (e.g., a prepaid time) is over. Users have to ask for a key regeneration, but that can be rejected by issuers if users should be revoked from the system.

IV. IMPLEMENTATION RESULTS
We provide the proof-of-concept implementation of both designed schemes, see Figure 1 and Figure 2 for more details. Both schemes' implementations consist of the terminal side, i.e., entity representing the issuer/verifier, and the authentication token side, i.e., entity representing the user. All implementations are available on the GitHub public repository: https: //github.com/a-wear/crypto-cap.git. The terminal application is written in C programming language, and includes only publicly available libraries: OpenSSL [26] (performing encryption and hashing algorithms), MCL [27] (performing operations over elliptic curves, such as EC scalar point multiplication and EC point addition), GMP [28] (performing modular arithmetic operations) and PCSC [29] (providing communication with a smart card). The terminal application was always executed on a Raspberry Pi 4B device.
In case of the authentication token, we explore different devices such as smart cards and smartphones, which are widely used in physical access control systems. We used only publicly available software libraries, development tools and off-the-shelf devices. Namely, MultOS API, SmartDeck 3.0.1 and MUtil 2.8 are used for the development of a MultOS application, Oracle Java Card API version 3.0.4 is used to develop a Java Card application, and finally, Android API (Java programming language) version 4.4 (KitKat) with Boun-cyCastle [30] library (performing elliptic curve operations) is used to a develop mobile application. The technical and software specification of all deployed devices is provided in Table I.  [31] for more details. Therefore, MultOS platform seems to be the best option for a Protocol 2 implementation that is depicted in Figure 2. Unfortunately, the MultOS ML4 card implementation lacks T=1 transmission protocol, therefore, only data of maximum 255 bytelength can by transmitted in one APDU (Application Data Unit) message. These cards are also missing contactless communication interface and many of modern cryptographic algorithms, e.g., AES, block cipher modes, e.g., GCM, or secure hash functions, e.g., SHA-2. On the other hand, Java Card supports elliptic curve cryptography (EC scalar point multiplication and EC point addition from Java Card API version 3.0.5). However, those cards are missing modular arithmetic operations and modern block cipher modes. Indeed, Java Card 3.0.5 includes javacardx.framework.math.BigNumber, i.e., a support of big integer operations, beyond modular arithmetic operations, and javacardx.crypto.AEADCipher, i.e., a support of AES-GCM and AES-CCM algorithms. However, these classes are only optional and they are not usually supported by off-the-shelf smart cards. Therefore, due to the lack of cryptographic support, we were able to implement the Protocol 1 on Java Cards and the Protocol 2 on MultOS cards only. However, both protocols have been implemented on an Android device. By employing smart phones with OS Android and using the BouncyCastle library, we can achieve higher performance and use more secure cryptographic algorithms in accordance with the Protocol 1 and Protocol 2 design. Table II presents used security parameters, key sizes and cryptographic algorithms in our implementation. The user-side algorithm execution is the most crucial part of the authentication protocol, see Figure 3. In fact, the time needed to execute a verification algorithm on Raspberry Pi 4B takes only 0.2 ms for Protocol 1 and 5.3 ms for Protocol 2. In both cases, the Android phone shows better performance results comparing with the smart cards (Java Card and Mul-tOS card). However, it is at the expense of security, since smartphones are not considered as tamper-resistant devices in contrast to smart cards.

V. CONCLUSION
In this paper, we proposed two cryptographic protocols for constrained devices. The Security Protocol is designed for devices which have almost no cryptographic support and provide only random number generation and AES encryption. Using the Security Protocol, a secure communication channel with both confidentiality and integrity protection can be established. The Privacy Protocol requires only random number generation and standard arithmetic operations over EC. Using the Privacy Protocol, users' registration can be verified without disclosing her identity. Furthermore, standard privacy-enhancing features are provided: unlinkability and untraceability of transactions. Besides the theoretical design, we also present the performance measurement results using the implementation of both protocols on smart cards and mobile devices. The benchmarks indicate that both protocols can be run in less than 0,7 s on any constrained device, including smart cards. As the next steps, we plan to further optimize the protocols and implement on wearable devices, such as smart watch.
ACKNOWLEDGMENT This paper is supported by the Czech Ministry of Industry and Trade grant # FV40340. The authors gratefully acknowledge funding from European Union's Horizon 2020 Research and Innovation programme under the Marie Skłodowska Curie grant agreement No. 813278 (A-WEAR: A network for dynamic wearable applications with privacy constraints, http: //www.a-wear.eu/).