On The Fly Diffie Hellman for IoT

TL;DR

This paper proposes an on-the-fly Diffie-Hellman key exchange protocol using OTP for IoT devices with limited capabilities, enhancing security in unsecured wireless environments without relying on external trusted servers.

Contribution

It introduces a novel Diffie-Hellman based protocol tailored for low-capability IoT devices, enabling secure key exchange within smart environments without external trusted servers.

Findings

Protocol is secure against replay and DoS attacks

Enables secure communication with minimal computational requirements

Reduces reliance on external trusted third parties

Abstract

The Internet of Things (IoT) is a fast growing field of devices being added to an interconnected environment in an abstract heterogeneous array of servers and other devices, called smart environments, ranging from private local (home) environments to nation-wide infrastructures, often accessible via unsecured wireless communications and information technologies, hence, massively open to attacks. In this paper we address some of issues that arise when connecting smart devices endowed with low computational capabilities to a home gateway via unsecured wireless communication channels, by using a One Time Pad (OTP) protocol based upon an On-the-fly Diffie-Hellman Key Exchange. Our assumptions are that only a user and the gateway have enough processing power to perform - say - secured RSA encrypted communication, hence relaxing the need for a trusted secure server outside the domain and that the protocol should at least be secure for a range of known attacks, as replay or DoS attacks.

Tables

Table 1. Table 1:

Symbols	Description
$c=E_K\left(m\right)$	Message $m$ is encrypted using secret key ($K$),
	producing the ciphertext $c$.
$m=D_K\left(c\right)$	Message $m$ is decrypted using secret key ($K$)
	from the ciphertext $c$.
$\left|\right|$	String concatenation

Equations

$$K_{priv}^{HG},K_{pub}^{HG}$$

Full text

Keywords: Diffie Hellman Key Exchange, IoT, One Time Pad Cryptography, Trusted Server.

1 Introduction

Following [1] and [2], the connection of an IoT device, endowed normally with limited processing power, to a central server using wireless networks requires following suitable authentication protocols and encryption, in order to avoid the well known Man in the Middle (MiM) attack, which we assume is a malicious third party having partial or complete access to the wireless communications between device and server. We base our considerations mostly upon [1] and the references cited therein.

For the system setup we propose establishing a secure connection between a smart device (SD) and the home gateway (HG) without referring to an external secure trusted server. Our protocol uses instead the End User as a One Time Trusted Server (OTTS) (wich is used only once at configuration time) for securely creating a Diffie-Hellman One Time Pad (OTP) for on-the-fly encryption between the device and the gateway. Once the setup protocol has been executed, all communications between the selected device and the server runs encrypted and can be hence considered secure. Communications between the server and the user are supposed to be secure enough as to be protected by RSA encryption and authentication.

A potential drawback of this procedure could lie in an eventual loss, interruption or tampering of communications, which would require again user interaction for restarting the protocol, an issue which we address in section 4.

This article proceeds as follows: Section 2 provides a brief description of the basics of Diffie-Hellman key exchange and RSA authentication. Both RSA and DH require previous agreement between parties (Alice and Bob) upon the modular arithmetic to be used, which normally happens without concern about secrecy of those said parameters. If both parties have enough computational power as to possess, each, valid RSA public and private keys, both algorithms can be combined to securely agree upon key generation (KeyGen) for DH, which, nonetheless, still doesn’t avoid an active adversary to assume the role of one of the parties. Section 3 presents our protocol which takes care of this possibility by adding a third party at setup time, the user, with which the assumption of secure connection to a trusted external server can also be relaxed. Section 4 deals with the issue of restarting the protocol. We close the article with some comments upon the security analysis of the proposed protocol as well as a discussion of its applicability to high throughput smart devices.

2 Background

2.1 Diffie-Hellmann Key Exchange

The well known Diffie-Hellman Key Exchange [3] protocol proceeds as follows:

• •

Alice and Bob share knowledge of two primes $g$ and $p$, in which $g$ is a primitive root111Recall that a primitive root $g$ of $p$ is a generator of the cyclic group $\mathcal{G}_{p}=\mathbb{Z}/(p\mathbb{Z})=\{e,g^{1},g^{2},\dots,g^{p}\}$ and hence such that any invertible element has an inverse which is a power of $g$. of $p$.

• •

Alice generates or has a secret $a\in\{2,\dots p-2\}$ [4].

• •

Alice computes the quantity $x=g^{a}\mod p$ and sends $x$ to Bob (over the insecure channel).

• •

Bob knows $(g,p)$ and chooses his own secret $b$ for computing $y=g^{b}\mod p$, which is then sent over to Alice.

• •

Both Alice and Bob now compute $y^{a}\mod p$ and $x^{b}\mod p$ respectively.

• •

The computed result $K=y^{a}\mod p=x^{b}\mod p$ is identical for both, Alice and Bob, while all the transmitted data is indistinguishable from random, hence the insecure channel causes no trouble. $K$ can now be used for OTP Xor-encrypting exchanges between Alice and Bob.

2.2 RSA Signature

We consider now the standard RSA signature [4] as follows: Let Alice and Bob wish to share sensible information, which we denote by $Z$ (for example $Z$ could be the pair ($g,p$) from the DH-Key Exchange described before). They proceed as follows:

• •

Alice and Bob have each their private and public Key, which we denote by $K^{A}_{pub}$, $K^{A}_{priv}$, respectively $K^{B}_{pub}$, $K^{B}_{priv}$

• •

Alice sends Bob the triple ($Z,E_{K^{A}_{priv}}(Z)$)

• •

Bob decrypts Alice’s message using her public Key and checks that $Z=D_{K^{A}_{pub}}(E_{K^{A}_{priv}}(Z))$. If not, the message has been intercepted and tampered with, else they are recognized as signed by Alice.

2.3 Certificated agreement upon structural data

Assume now that the structural data for establishing RSA authentication and DH should be agreed upon by preserving privacy between parties Alice and Bob. A standard signature procedure allows for this as follows:

• •

Assume Alice and Bob have each their own RSA public and private keys.

• •

Alice choose two primes $g$ and $p$ with $g$ a primitive root of $\mathcal{G}_{p}$, which will be her secret.

• •

She encrypts the pair ($g,p$) with her own private Key $K^{A}_{priv}$: $E_{K^{A}_{priv}}(g,p)$.

• •

She encrypts now the signed message $\mathcal{M}=(g,p,E_{K^{A}_{priv}}(g,p))$ with Bob’s public key: $E^{B}_{pub}(\mathcal{M})$ and sends it to Bob, which decodes it, check the signature using Alice’s public key and - since the check will succeed - obtains as a result a valid shared ($g,p$) with which now a valid DH-Key Exchange can be safely performed between Alice and Bob.

Notice that the RSA authentication as described above is one-sided, in the following sense: The structural space $\mathcal{G}_{p}$ is proposed by Alice and she keeps it secret. After completion of the protocol, Bob thinks he knows for sure that Alice shared her secret $Z$ with him. But a careful analysis shows that if Alice has been hacked, then a malicious Man-in-the-Middle (MiM), which we call Daniel (Dan), may have intercepted Alice’s message and replaced it with his own signed triple ($\tilde{Z},E_{K^{D}_{priv}}(\tilde{Z})$) after replacing Alice’s public key with his own $K^{D}_{pub}$. So now Bob will address Dan each time he thinks he is talking Alice to. This is a standard issue in two-party authentication and is the reason why a handshaking protocol between Alice and Bob has to happen as in the Station-to-Station (STS) protocol, see [5], but also explains variants of the kind authenticated key agreement with key confirmation (AKC) [6], [3], [7].

3 Protocol

By introducing the End User as a third party with enough processing power, we can relax the assumption made upon Alice and establish a secure connection as follows:

Assume a given IoT device (which we denote by SD, or smart device) with low or limited computational capability, which will take the role of Alice (like a temperature sensor, a door actuator or similar), just powerful enough as to autonomously produce (pseudo) random numbers and perform exponentiation in modular arithmetic. SD will be connected via an open unsecured channel (a wireless connection, for example) to a home gateway (HG), which will be our Bob, which we assume is a server (or computer) with higher computational power, at least enough as to be able to have its own public and private key for RSA purposes.

The scenario will be now the following: The End User, which we call U, proceeds to connect the SD (Alice) to the HG (Bob) as in [8], using for example a HAN protocol like ZigBee, known as SD-To-HG communication pattern. We assume that the user can write parameters onto the SD and aim to securely connect Alice to Bob by XOR-encrypting their communications via a One - Time - Pad established on-the-fly, as follows:

3.1 System Setup

In the following we use standard notation for encryption, decryption and concatenation as:

Assuming RSA asymmetric key cryptography is available for the user U and the home gateway HG, as well as an offline interface for the User enabling him to write into the smart device SD parameters as needed, our system setup protocol proceeds as follows:

• •

U generates a one-time (configuration session) RSA pair $K^{SD}_{pub}$, $K^{SD}_{priv}$ for Alice, as well as a pair $(g,p)$ with $p$ a prime number and $g$ a primitive root which defines the structural space $\mathcal{G}_{p}$.

• •

U writes into the SD the private key $K^{SD}_{priv}$.

• •

U sends to Bob (the gateway) the RSA encrypted message $E_{K^{HG}_{pub}}((g,p)||K^{SD}_{pub})$. 222Strictly speaking, U should send the signed message encrypted with HG’s publick key $E_{K^{HG}_{pub}}\left(((g,p)\;||\;K^{SD}_{pub})\;||\;E_{K^{U}_{priv}}((g,p)\;||\;K^{SD}_{pub})\right)$ allowing HG to verify U’s identity, but this can be avoided if communication between HG and U is RSA protected or happens offline..

• •

Bob decrypts the message (if necessary authenticates Bob) and hence learns $(g,p)$ as well as $K^{SD}_{pub}$.

• •

Now Bob encrypts the pair $(g,p)$ together with his signature by using the RSA key he just learned: $E_{K^{SD}_{pub}}((g,p)||E_{K^{HG}_{priv}}(g,p))$, and sends it over (the still insecure channel) to Alice.

• •

Alice requests Bob’s public key and checks for message integrity (authentication) by verifying that $D_{K^{HG}_{pub}}(E_{K^{HG}_{priv}}(g,p))=(g,p)$.

As a result, Alice and Bob now share knowledge of $(g,p)$, provided securely by U and can hence Diffie-Hellman ad libitum between them, which they will use for jointly creating the Key for the OTP.

Observe that we deviate from the system design used in [1] in that we do not assume the Service Provider (SP) as being secure (trusted) in the sense that, in our setting, generation and assignment of keys for securely handshaking between Alice and Bob is entrusted to the end user (U) by means of a one-time RSA authentication, using U and the SD on one side, and assuming secure communications between the HG and the User on the other. Also, requirements upon the SD are only in terms of performing basic modular arithmetic needed just for Diffie-Hellman.

3.2 On the fly OTP

Once Alice and Bob have securely identified themselves at system setup via the above procedure and shared the (now secret) values of $(g,p)$, they proceed to encrypt their communication via XOR-ing on the fly: Each time a packet of length $\sigma$ will be transmitted a DH procedure is performed in order to generate a new key with which the packet is XOR encoded. Hence the name ’on-the-fly’. Via suitable padding and delay agreement, the protocol can be adapted to include the new (encoded) value of the key for the next data transfer, as well as the use of time stamps as Nonces in order to avoid replay attacks, see below.

Observe that unless Alice and/or Bob are compromised in the sense that, if after an attack either $K^{SD}_{priv}$ or $(g,p)$ have been changed or made public (see for example firmware attack [9]), the OTP generated by sharing the key with DH is secure to replay attacks (by adequately using Nonces) and by itself, granting perfect security, since each time a packet is transmitted a new key is agreed upon between Alice and Bob.

4 Re-initialization

Should communication between Alice and Bob be interrupted or fail the authentication, rebooting the system is easy if the private key of SD has not been compromised, it suffices to Bob to reestablish communication by creating a new pair $(g,p)$ and authenticate himself with Alice to share $(g,p)$ to her, provided - of course - that Bob has not been hacked into. If, on the contrary, $K^{SD}_{priv}$ has been exposed, user U has to manually re-initiate the system by furnishing a new system setup.

5 Security analysis

In this section we argue about the protocol’s security properties (Authentication, message freshness, data integrity, etc) and its resistance to various attacks (Replay attack, Man in the Middle, etc).

5.1 Authentication

At the beginning of the protocol, as described by Section 3-A, the User must have physical access to the SD device he is setting up, therefore, authentication between SD and U can be assumed as granted de facto. On the other hand, authentication between U and HG proceeds through the RSA private and public key process, so that this part of the communication channel can be assumed secure: Any eavesdropper watching the traffic between U and HG will see, for example the sensible data $((g,p)||K^{SD}_{pub})$ encrypted with HG’s public key $K^{HG}_{pub}$, so that only HG can decode it with his own private key $K^{HG}_{priv}$.

Similarly, once the User U has written the private key $K^{SD}_{priv}$ for SD onto the device, communication between SD and HG can be assumed authenticated via the same procedure as above.

5.2 Key Establishment

After authenticating each other, parties in the protocol will establish a DH-shared key each time a message has to be transmitted, which is then used to XOR-encrypt the said message, which is why we call it on-the-fly OTP instead of session key. In order for this to happen while preserving security, the size of the message should not exceed the size of the shared key, which is why, in principle, our approach would not be sufficient for, say, continuous data streaming as in video devices. Nonetheless, buffering via latency of the computations depending on technology could be brought in for inserting reestablishment of the DH-key session at fixed intervals, an issue which we do not pursue here and will be the subject of a forthcoming article.

Besides, as long as the structure data $(g,p)$ remains known only to the legitimate parties, communication between them via XOR-encrypted messages require only the generation of new private DH parameters for each message sent. This precludes a malicious party from gaining access to the next messages based upon knowledge of the previous ones, unless, of course, the SD device and its firmware can be completely simulated, together with the software being used to generate the keys.

A procedure for dealing with this possibility can be easily derived along the lines of [1], section IV, authentication and key establishment.

5.3 Secrecy

Before sending a message, the sending party (SD or HG) encrypts it using the shared key that must be at least of the same length as the message in order to use it as a OTP to generate the ciphertext. By using the DH procedure, the parameters performing the DH-OTP will look random to any observer, which will be unable to determine the key, thus the transmitted XOR’d result will appear to be random to any eavesdropper or malicious party.

5.4 Freshness

This scheme generates a new (seemingly random) key every time a message should be sent. Even if the message is replayed, the ciphered text will not be recognized by the receiving party because of the different key they agreed upon before sending it. Hence replay attacks are naturally avoided with this procedure diminishing also the workload implicit in handshaking protocols including timestamps and the like.

5.5 Masquerade or Forgery attack

If a malicious attacker wanted to masquerade himself as the HG in order to read the sensitive data he would necessarily need to obtain first the private key $K^{HG}_{priv}$. Our protocol does certainly not exclude this from happening.

On the other hand, in order for an attacker to forge a valid message and send it to HG (in order to confuse or obfuscate the system by presenting intentionally wrong data, for example), the attacker should gain access to the structural data $(g,p)$, known in encrypted form by SD and HG only, in order to successfully simulate an authenticated SD message. For this, the intruder would need to physically gain access to the SD in the home network and thus extract this sensitive information, unless proper hardware security, (for example encrypting the device’s flash memory) is applied, a resource that would have side effects in performance.

We do not address this issue here, but instead point out that it has been addressed elsewhere, see for example [9] and the references therein.

6 Conclusion

Smart home environments are an essential part of the Internet of Things IoT, in which devices with low computational capabilities or power are connected to a communications net, accessible from ’the outside’ through a Gateway HG, most of the cases in straight unsecured schemes or with unmodified or built-in or factory-default security parameters.

Approaches for dealing with these kind of weakness involve often the assumption of a trusted external server. Yet more often than not, it is precisely inside the domains of the home environment that attackers can be successfully gain access to otherwise secured facilities. There are plenty of reports on security breaches that illustrates the importance of secure authentication and secure session keys even for the simplest smart devices and local home networks333See for example https://www.iotforall.com/infamous-iot-hacks/ last retrieved july 2019.

In this paper, we follow closely the protocol presented in [1] and [2] for Smart-Home-Environments but change some assumptions in both, the environment and the protocol itself, most notably in that the need for a trusted server outside the home network is no longer required. Instead, we replace the Trusted Server furnishing Keys and security by the (home) End User at system setup or configuration time, hence shifting the paradigm from a session-oriented protocol to an on-the-fly one.

Furthermore, by changing the assumptions upon the network architecture, we restrict ourselves strictly to the locality of the environment uncoupled or detached from any external communication services. For this to succeed, we require a central device in the smart home environment with whom the user communicates, independently of the outside connections, that acts as Home Gateway. Equivalently, we require a HG with computational capabilities powerful enough as to provide full RSA encryption between the user and the HG.

For the time being, we do believe that our proposed on-the-fly protocol is a feasible option, at least for devices with very low bandwidth and low frequency of communications, granting privacy, authentication and security as described above, but also that via careful packet padding and/or buffering, the on-the-fly technique can also be applied for data streaming devices also.

How this performs and is actually implemented is a subject whose discussion will be pursued in another work, with emphasis in performance.