4.1 Introduction to ECC

Information security in any system is determined based on the basic CIA principles, which include confidentiality, integrity, and availability. In order to achieve these properties, a network needs three key functionalities such as data encryption, user authentication, and secure channel establishment [16]. These functionalities are interrelated and they use security keys with different perspectives. Typically, in encryption and decryption functions, the cryptographic operations are performed in two ways. In the first category, which is the symmetric key cryptography, the sender and the receiver share a common secret key (e.g. DES, AES). The second type is called as the asymmetric or Public Key Cryptography (PKC) where each user has a pair of keys (e.g. ECC, RSA). This pair consists of a public key, which can be widely disseminated and known by others, and a private key, which is known only by the owner. Both types can be used for user and device authentication. Moreover, secure channels are obtained based on successful user (or device) authentication, which is followed by establishing secret keys between the communication entities.

Unlike symmetric key algorithms, PKC does not need a secure channel for initial key exchange between two parties. However, since the security strength of PKC systems are mostly reliant on the complexity of mathematical problems, they are significantly more resource consuming than the symmetric key algorithms. Numerous PKC solutions are involved in key management schemes, applications, Internet standards and protocols. Among them, Elliptic Curve Cryptography (ECC) is an efficient PKC scheme with the most suitable adaptations for low‐performing resource‐constrained networking devices [6]. Compared to other expensive PKC schemes, like the well‐known Rivest Shamir Adleman (RSA) public‐key algorithm, ECC has faster computational time, smaller keys, and uses less memory and bandwidth. This is explained in the graph in Figure 4.1, where ECC can obtain the similar security level as RSA using much smaller keys.

4.1.1 Notations

While designing ECC algorithms, the Elliptic Curves (ECs) are defined over a finite field by an equation using two variables with coefficients, which are the elements of the finite field [11]. Consequently, all the variables, coefficients and curve points fall below the same finite abelian group, G. The resultant points of the curve operations are also restricted in the same abelian group. A special point 0, known as the zero element or point of infinity, is considered the identity element of the group. ECC is formulated with EC point addition, point scalar multiplication and, additive and multiplicative inverses on ECs over prime integer fields or binary polynomial fields. Modulo arithmetic is the foundation for all the EC point operations. The implementation of ECC on WSNs is performed over prime integer fields, since binary polynomial field operations are too costly for low‐power sensors.

We consider the ECs defined over prime fields , where is a large prime number. The variables and coefficients will have the values between 0 and and calculations are performed in . Let and . Then the EC is defined as;

(4.1)

Once , , and are selected, a group of EC points are defined so they satisfy Equation 4.1. Then a base point generator is chosen so that the order of is a very large value and . The key building block of ECC is the scalar point multiplication which is , where is a positive integer and and are points in the EC. The value is computed by adding point for times and the resulting point is obtained. However, the recovery of , knowing the points and is a hard or computationally infeasible problem which is known as the Elliptic Curve Discrete Logarithmic Problem (ECDLP). In real‐time applications is made large in order to overcome guessing and brute force attacks.

Nevertheless, ECC is still not a widely deployed cryptographic scheme and its theoretical foundation is not very popular in standardized protocols. On the other hand, many ECs are already patented which makes it far more challenging to define new ones. Weak random number generators may also lead to successful attacks and built‐in traps can be hidden behind bad‐curve designs.

4.2 ECC Based Implicit Certificates

Digital certificates advocate the establishment of identity in secure communications. Similar to the conventional or explicit certificates such as X.509, implicit certificates are made up of three parts [1]: identification data, a public key and a digital signature, which binds the public key to the user's identification data and verifies that the binding is accepted by a trusted third‐party. In an explicit certificate, the public key and digital signature are two distinct elements. In contrast, the public key and digital signature are included in implicit certificates and allow the recipient to extract and verify the public key of the other party from the signature segment. This will significantly reduce the required bandwidth since there is no need to transmit both the certificate and the verification key.

The most important advantages of using implicit certificates over the conventional certificates are the smaller size and faster processing. Table 4.1 specifies the comparable key sizes for symmetric and asymmetric cryptosystems based on equivalent security strengths (i.e., symmetric key size). Elliptic Curve Digital Signature Algorithm (ECDSA) is a variant of the Digital Signature Algorithm (DSA) that operates in elliptic curve groups. Elliptic Curve Qu‐Vanstone (ECQV) [3] is another type of implicit certificate scheme with smaller certificate sizes, lower computational power and very fast processing time for generating certified public keys. Accordingly, the sizes of ECQV and ECDSA‐signed certificates are substantially smaller than RSA due to the reduced public key size of ECC.

4.2.1 Authentication and Key Management Using ECC Implicit Certificates

ECC‐based implicit certificates have been used to design the lightweight and secure key establishment and authentication protocols for resource‐constrained sensor networks. As a starting point, in [13], the authors have proposed a two‐phase implicit certificate‐based key establishment protocol for resource‐constrained sensors deployed in generic WSNs. In the first phase, sensor nodes receive implicit certificates from the cluster head which acts as a certificate authority (CA). The certificate generation process is inspired by the design principles of the ECQV implicit certificate scheme. The second phase contains the key establishment component where sensors use implicit certificates to establish pair‐wise keys with neighbouring sensor nodes. The concepts behind this work are extended in [15] by using implicit certificates for authenticating devices and users under the umbrella of IoT.

Using the schemes presented in [13] and [15], a pervasive authentication and key establishment scheme is designed for IoT networks in [14]. The scheme is called as PAuthKey and uses ECQV implicit certificates. Figure 4.2 illustrates the considered network architecture to design the protocols while considering four types of communication links: Link A ‐ between two sensor nodes in the same cluster; Link B ‐ between two sensor nodes in distinctive clusters and in the same network; Link C ‐ between two sensor nodes located in distinctive clusters and different networks; Link D ‐ between a user and a sensor node.

4.2.1.1 Phase 1: Registration and Certificate Acquisition

During this phase, all sensors receive the security credentials from the respective cluster heads (CH) which is acting as a local CA. The message flow of the certificate acquisition is described below (Figure 4.3). The starting Requester Hello message includes node identity (U) and cipher suites which are supported by the requester and installed on the sensor nodes in off‐line mode (e.g., CERT_ECC_160_WITH_ AES_128_SHA1 requests for certificates in 160‐bit EC curves, 128‐bit AES for bulk encryption, and SHA1 for hashing). At a successful requester identity verification, CA agrees to one cipher suite from the received options, and sends CA Hello message with its public key as an unprotected message to approve the initiation of the handshake.

Upon receiving CA Hello message, the requester generates a random number and computes EC point , where the EC domain parameters support the negotiated cipher suites. The node produces a random cryptographic nonce , calculates Message Authentication Code (MAC) value (i.e., ) using the common authentication key K, and sends those two along with the Certificate Request message.

Then CA verifies the MAC value and nonce to identify the integrity and the message freshness. If both are successfully verified, CA generates a random number , computes the certificate and private key reconstruction value , where is CA's private key and . Certificate message includes the certificate , , a random nonce , and the MAC on [].

If MAC and are correct, U calculates using the same hash function. Then the node U can compute its own private key and public key .

Node U's Finished message contains an encrypted message digest of previous handshake messages using the requester public key . CA is also capable of computing U's public key ; . The following derivation proves that both equations give exactly the same as computed by node U.

(4.2)

CA uses public key for encrypting previous messages and answers with the Finished message to complete the handshake of the pre‐authentication phase. Finally, the sensor nodes possess the security credentials to start secure communication with the internal and the external network entities (i.e., end‐users and sensor nodes).

4.2.1.2 Phase 2: Authentication and Key Establishment

Phase 2 is described in terms of scenario 1 (Figure 4.4), which is the communication between two sensor nodes in the same cluster. It is assumed that all nodes in the same cluster are aware of the identities of the other nodes.

First, the client node U sends the Client Hello message accompanied with its identity to the server node V. The server replies with the Server Hello message along with the cipher suites it supports and CH's identity, which is the CA for both nodes. If the client does not have the security credentials from the given cipher suite, it has to retrieve them from the CA. Otherwise, the client can continue the handshake by sending its certificate . Similar to the registration phase handshake, random cryptographic nonce and MAC values are used to preserve the freshness and integrity of the message.

Upon receiving the client's certificate, the server first verifies the MAC value and then computes the client's public key using its certificate; e = H() and . This is proven according to Eq. 4.2. Then V generates a random nonce and sends it along with and . In the meantime, V computes the pairwise key from its private key and U's public key , where . Similar to V, upon receiving the message, U verifies the MAC and if the verification is successful it computes and .

Finally, the exchange of the Finished messages conclude the handshake, which are encrypted by the common key . At the end of six message transfers, the two edge nodes can authenticate each other, and establish a common secret key and a secure communication link that can be used for securing further data acquisitions between the client and the server. In the same manner, the rest of the scenarios will follow similar approaches with slight modifications as described in [14].

4.3 ECC‐Based Signcryption

A signcryption scheme simultaneously generates encryption of a message and a corresponding signature in one single phase. As a consequence, cryptographic properties like confidentiality, integrity, authentication and non‐repudiation are more efficiently obtained compared to the traditional approach of first encrypt and then sign the message. Recently, signcryption schemes with multiple receivers, able to establish anonymity of sender and receivers, have gained a lot of popularity. This follows on from the fact that nowadays, people pay more and more attention to personal privacy. Therefore, it is important to derive suitable solutions that allow hidden involvement of the user in certain communications. Several application domains exist for the multi‐receiver signcryption schemes with anonymity of the receivers, like e‐voting systems, network conference meetings, broadcast DVD, pay‐TV, etc. For example, a service provider can broadcast a ciphertext for a TV program or DVD. Each authorised device who has subscribed can then use his own private key to decrypt the ciphertext. In this situation, it is clear that the anonymity of the receiver is an essential requirement.

We now shortly describe the security features of the signcryption scheme ASEC, which is proposed in [5]. Next, the different steps of the scheme are described. We refer to [5] for a more detailed analysis on the security and performance.

4.3.2 Scheme

The signcryption scheme consists of three different phases. The first phase is the key generation of the private and public keys of the participants. The second part handles the signcryption, executed by the sender. In the third phase, receivers perform the operations individually, which are referred to as the unsigncryption process.

4.3.2.1 Key Generation

The key generation is performed by a trusted PKG and involves the user identities to construct the private key of the users. Let us denote the master private key of the scheme by and the master public key by . This pair is used to derive the key pairs of the entities in the scheme. The parameter is a random value in and is required to revoke the user's credentials and issue new credentials without changing the private master key or the identity of the user.

1. – The private key of the sender is determined as , and the corresponding public key as .
2. – The private key of the receiver is determined as , and the corresponding public key as . Let us consider that contains the intended receivers of the message.

The private keys are securely delivered to the different participants in off‐line mode. The master public key is stored in each node. For each user of the system, the values are made publicly available and are independently checked on changes by a third party.

4.3.2.2 Signcryption

The sender selects the group of receivers and looks up the corresponding identities and public keys for . A check on the hash value is made to guarantee the integrity and authenticity of the published data. Then the following steps are performed.

1. 1. A random is selected. The corresponding point is computed.
2. 2. A random is selected. The corresponding point is computed.
3. 3. , the EC point is computed.
4. 4. chooses a random key .
5. 5. constructs the polynomial of degree that passes through the points by means of Lagrange interpolation.
6. 6. derives other points on this polynomial.
7. 7. The encryption is performed.
8. 8. The hash is computed.
9. 9. The value is computed.
10. 10. The value is computed.
11. 11. This value will be encrypted,
12. 12. The message is broadcasted.

4.3.2.3 Unsigncryption

Let be a receiver of the message. performs the following steps.

1. 1. The EC point is calculated.
2. 2. Let .
3. 3. The hash operation is executed. If this value corresponds with of the transmitted message, the validity of the message is approved and the process can be continued.
4. 4. The EC point is calculated.
5. 5. constructs the polynomial of degree that passes through the points by means of Lagrange interpolation.
6. 6. The intersection of this polynomial with the ‐axis defines the key .
7. 7. The decryption is performed.
8. 8. If the last field corresponds with the transmitted value of , it means that the receiver belongs to the intended group of receivers.
9. 9. The decryption is executed.
10. 10. First, the same as the received one should be obtained. Next, the identity of the sender is now checked by first requesting the public key belonging to . Then the equality should be checked. If so, possesses the public key and its identity is verified.

The different steps of the signcryption and unsigncryption mode of ASEC are summarized in Table 4.2.

Signcryption	Unsigncryption
1.  Choose ,	1.
2.  Choose ,	2.
3.  ,	3.
4.  Choose	4.
5.  Construct pol through , 's	5.  Construct pol with
6.  Derive other points	6.  Find as
7.	7.
8.	8.  Check
9.	9.
10.	9.  Check
11.
12.  Send

4.4 ECC‐Based Group Communication

Rather than device‐to‐device communications, group communications in the form of broadcasting and multicasting incur efficient message deliveries among resource‐constrained sensor nodes in IoT‐enabled WSNs. Secure and efficient key management is significant to protect the authenticity, integrity, and confidentiality of multicast messages. In [12], two group key establishment protocols are developed for secure multicast communications among resource‐constrained devices in IoT. We limit the explanation in this chapter to the second and most efficient protocol. We start with a short discussion on background and some assumptions considered in the system and then explain the different steps in the scheme. We refer to [12] for a more detailed analysis on the security and performance.

4.4.2 Scheme

The message flow of multicast key establishment of the scheme is shown in Figure 4.5. We note that the scheme exploits the concepts of ECIES to establish a shared secret key among the multicast group.

Step 1: First, the size  and the composition of the multicast group are determined by the initiator. Then a random value is generated, where . EC points s are computed using and the public keys of the group members: , where to . Next, the EC point is encoded into the point as follows: ; . For each node , the value is computed. The group key is then defined by . Denote and let . The new multicast message for group is generated and transmitted by the initiator with the calculated values . Additionally, the digital signature is appended to preserve message authentication and integrity. Note that the same value can also be reused as the parameter in the signature scheme (see e.g. Schnorr Signature scheme).

Step 2: When the sensor node receives the broadcast message, initially, it checks whether it is included in the multicast group . Then the digital signature and the counter are checked. If both are correctly verified, is computed using the received random value and the node's private key : . The EC point is converted to the point using the same encoding as in step 1. After that can compute and verify the integrity by checking if corresponds with the received Auth value.

Step 3: Each sensor node should send an acknowledgement message to finish the handshake. Later, by verifying the acknowledgement message, the initiator can ensure the authenticity of that particular group member and the accurate derivation of group key .

After three steps the shared secret key is known by the initiator and the other members in the multicast group.

4.5 Implementation Aspects

For the implementation of the security protocol, one needs to choose a particular elliptic curve. Several standards exist where curves are presented, e.g. ANSI X9.62 (1999), IEEE P1363 (2000), SEC 2 (2000), NIST FIPS 186‐2 (2000), ANSI X9.63 (2001), Brainpool (2005), NSA Suite B (2005), ANSSI FRP256V1 (2011). The curves in each of these standards are selected in such a way that the ECDLP is difficult. However, as pointed out in [2,4], protection against the ECDLP does not guarantee that the resulting scheme is secure. Also, the implementation of the curve plays a very important role. It might be possible that the implementation produces incorrect results for some rare curve points, leaks secret data when the input isn't a curve point or leaks secret data through branch timing and/or cache timing. Resistance against this type of attack is called ECC security. Most of these attacks can be ruled out by a good choice of parameters and definition of the curve. It has been demonstrated in [2] that all of the curves proposed in the standards are vulnerable with regards to ECC security. A list of secure curves is also provided.

In particular, the elliptic curve, Curve25519, offering ECC security with 128 bits security level is worth mentioning. It is one of the fastest ECC curves and is not covered by any known patents. The reference implementation is public domain software. Besides its speed, it has some other very interesting features.

1. – The public keys are very short as they can be represented by only 32 bytes. In most of the schemes, the keys are represented by 64 bytes, although able to be compressed by half as suggested by Miller [9]. However, the time for compression is also quite noticeable and usually not reported.
2. – There is no need to add additional protection against any timing attacks. The standard implementation is already avoiding all input‐dependent branches, all input‐dependent array indices, and other instructions with input‐dependent timings.
3. – There is no need for time‐consuming key validation as every 32‐byte string can act as a valid public key. If this is not the case and no key validation is first performed, there are attacks which are able to break the key agreement scheme.
4. – The software code is very small. In particular, the compiled code, including all necessary tables, is around 16 kilobytes.

4.6 Discussion

Although ECC schemes guarantee a high level of security, they could still contain an easily‐exploitable vulnerability if they are applied without an additional level of protection. Therefore, an additional layer of protection needs to be added to assure complete security towards clogging attacks. Moreover, there are other limitations of ECC schemes due to the low degree of maturity of the techniques and less adaptability. These will also create difficulties and challenges in practical deployments of ECC solutions. Security of the ECC scheme is entirely dependant on the curve. As a result, poor curve designs might hugely affect the security in entire systems. Despite the above discussed limitations, as discussed in the previous sections, ECC is used in many security protocols for numerous resource‐constrained networking devices that require lightweight solutions. Although, in this book chapter, we discussed some selected areas of ECC use cases, there can be many other areas where it is applicable.

References

1. 1 Explaining Implicit Certificates. Certicom cooperation. https://www.certicom.com/content/certicom/en/code-and-cipher/explaining-implicit-certificate.html (accessed 25 June 2019).
2. 2 SafeCurves: choosing safe curves for elliptic‐curve cryptography. https://safecurves.cr.yp.to (accessed 25 June 2019).
3. 3 SEC4: Elliptic Curve Qu‐Vanstone Implicit Certificate Scheme (ECQV). (2013). Version 0.97. http://secg.org/sec4-1.0.pdf (accessed 25 June 2019).
4. 4 Bernstein, D.J. (2018). Curve25519: New Diffie‐Hellman speed records. International Workshop on Public Key Cryptography. https://rd.springer.com/chapter/10.1007/11745853_14 (accessed 25 June 2019).
5. 5 Braeken, A. and Porambage, P. (2015). Asec: Anonym signcryption scheme based on ecoperations. International Journal of Computer Applications 5 (7):90–96.
6. 6 Hankerson, D., Menezes, A.J. and Vanstone, S. (2003). Guide to Elliptic Curve Cryptography. Berlin, Heidelberg: Springer‐Verlag.
7. 7 Kothmayr, T., Schmitt, C., Hu, W. et al. (2013). Dtls based security and two‐way authentication for the internet of things. Ad Hoc Networks 11 (8): 2710–2723.
8. 8 Liu, J., Xiao, Y. and Chen, C.P. (2012). Authentication and access control in the internet of things. Distributed Computing Systems Workshops (ICDCSW), 2012 32^nd International Conference, Macau, China (18–21 June 2012). IEEE.
9. 9 Miller, V.S. (1985). Use of elliptic curves in cryptography. Conference on the theory and application of cryptographic techniques, Linz, Austria (April 1985). Springer.
10. 10 Pang, L. and Li, H. (2013). nmibas: a novel multi‐receiver id‐based anonymous signcryption with decryption fairness. Computing and Informatics 32 (3): 441–460.
11. 11 Porambage, P. (2018). Lightweight Authentication and Key management of Wireless Sensor Networks for Internet of Things. http://jultika.oulu.fi/files/isbn9789526219950.pdf (accessed 17 July 2019).
12. 12 Porambage, P., Braeken, A., Schmitt, C. et al. (2015). Group key establishment for secure multicasting in iot‐enabled wireless sensor networks. 2015 IEEE 40th Conference on Local Computer Networks (LCN), Washington, USA (26–29 October 2015). IEEE.
13. 13 Porambage, P., Kumar, P., Schmitt, C. et al. (2013). Certificate based pairwise key establishment protocol for wireless sensor networks. 2013 IEEE 16th International Conference on Computational Science and Engineering (CSE), Sydney, Australia (3–5 Decmber 2013). IEEE.
14. 14 Porambage, P., Schmitt, C., Kumar, P. et al. (2014). Pauthkey: A pervasive authentication protocol and key establishment scheme for wireless sensor networks in distributed iot applications. International Journal of Distributed Sensor Networks 10 (7): 357430.
15. 15 Porambage, P., Shmitt, C., Kumar, P. et al. (2014). Two‐phase authentication protocol for wireless sensor networks in distributed iot applications. Wireless Communications and Networking Conference (WCNC), Istanbul, Turkey (6–9 April 2014). IEEE.
16. 16 Stallings, W. (2010). Cryptography and Network Security: Principles and Practice, 5e. Upper Saddle River, NJ: Prentice Hall Press.