Praktisk IoT Cryptography på Espressif ESP8266

Espressif ESP8266 Chipset gör tre dollar “Internet” Development Boards en ekonomisk verklighet. Enligt den populära automatiska firmware-byggswebbplatsen NODEMCU-Builds, har under de senaste 60 dagarna varit 13 341 anpassade firmware bygger för den plattformen. Av de har endast 19% SSL-stöd och 10% inkluderar kryptografimodulen.

Vi är ofta kritiska mot bristen på säkerhet inom IOT-sektorn, och täcker ofta botnets och andra attacker, men kommer vi att hålla våra projekt till samma standarder vi kräver? Kommer vi sluta med att identifiera problemet, eller kan vi vara en del av lösningen?

Denna artikel kommer att fokusera på att tillämpa AES-krypterings- och hashtillståndsfunktioner till MQTT-protokollet med det populära ESP8266-chipet som kör Nodemcu-firmware. Vårt syfte är att inte tillhandahålla en kopia / pastapacea, men att gå igenom processen steg för steg, identifiera utmaningar och lösningar på vägen. Resultatet är ett system som är end-to-end krypterad och autentiserad, förhindrar avlyssning längs vägen och spoofing av giltiga data, utan att förlita sig på SSL.

Vi är medvetna om att det också finns mer kraftfulla plattformar som enkelt kan stödja SSL (t.ex. Raspberry Pi, Orange Pi, Friendalarm), men låt oss börja med den billigaste hårdvaran de flesta av oss har ljuger och ett protokoll som passar för många av våra projekt . AES är något du kan implementera på en AVR om du behövde.

Teori

MQTT är ett lättmeddelandeprotokoll som körs ovanpå TCP / IP och används ofta för IOT-projekt. Klientenheter prenumererar eller publicerar till ämnen (t ex sensorer / temperatur / kök), och dessa meddelanden vidarebefordras av en MQTT-mäklare. Mer information om MQTT är tillgänglig på sin webbsida eller i vår egen Kompegerade serie.

MQTT-protokollet har inga inbyggda säkerhetsfunktioner bortom användarnamn / lösenordsautentisering, så det är vanligt att kryptera och autentisera över ett nätverk med SSL. Men SSL kan vara ganska krävande för ESP8266 och när det är aktiverat, är du kvar med mycket mindre minne för din ansökan. Som ett lätt alternativ kan du bara kryptera data-nyttolasten som skickas och använd ett Session-ID och Hash-funktion för autentisering.

Ett enkelt sätt att göra detta använder LUA och NODEMCU Crypto-modulen, som innehåller stöd för AES-algoritmen i CBC-läge samt HMAC Hash-funktionen. Med hjälp av AES-kryptering kräver korrekt tre saker att producera cifertext: ett meddelande, en nyckel och en initialiseringsvektor (IV). Meddelanden och nycklar är enkla koncept, men initialiseringsvektorn är värt någon diskussion.

När du kodar ett meddelande i AES med en statisk nyckel, kommer det alltid att producera samma utgång. Till exempel kan meddelandet “usernamepassword” krypterat med nyckel “1234567890abcdef” ge ett resultat som “E40D86C04D723AFF”. Om du kör krypteringen igen med samma nyckel och meddelande får du samma resultat. Detta öppnar dig till flera vanliga typer av attack, speciellt mönsteranalys och återspelningsattacker.

I en mönsteranalysattack använder du kunskapen om att en viss bit av data alltid kommer att producera samma chiffertext för att gissa vad syftet eller innehållet i olika meddelanden är utan att faktiskt veta den hemliga nyckeln. Om till exempel meddelandet “E40D86C04D723Aff” skickas före all annan kommunikation, kan man snabbt gissa att det är en inloggning. Kort sagt, om inloggningssystemet är förenklat, kan det vara tillräckligt att skicka det paketet (en replayattack) för att identifiera dig som en auktoriserad användare, och kaos följer.

IVS gör mönsteranalys svårare. En IV är en del av data som skickas tillsammans med nyckeln som ändrar slutet cifertextresultatet. Som namnet antyder initierar det krypteringsalgoritmens tillstånd innan data går in. IV måste vara annorlunda för varje budskap som skickas så att upprepade data krypterar till olika chiffertext, och vissa cifrar (som AES-CBC) kräver att det är oförutsägbart – ett praktiskt sätt att uppnå detta är bara att randomisera det varje gång. IVs behöver inte hållas hemliga, men det är typiskt att obfuscate dem på något sätt.

While this protects against pattern analysis, it doesn’t help with replay attacks. For example, retransmitting a given set of encrypted data will still duplicate the result. To prevent that, we need to authenticate the sender. We will use a public, pseudorandomly generated session ID for each message. This session ID can be generated by the receiving device by posting to an MQTT topic.

Preventing these types of attacks is important in a couple of common use cases. Internet controlled stoves exist, and questionable utility aside, it would be nice if they didn’t use insecure commands. Secondly, if I’m datalogging from a hundred sensors, I don’t want anyone filling my database with garbage.

Practical Encryption

Implementing the above on the NodeMCU requires some effort. You will need firmware compiled to include the ‘crypto’ module in addition to any others you require for your application. SSL support is not required.

First, let’s assume you’re connected to an MQTT broker with something like the following. You can implement this as a separate function from the cryptography to keep things clean. The client subscribes to a sessionID channel, which publishes suitably long, pseudorandom session IDs. You could encrypt them, but it’s not necessary.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
m = mqtt.Client("clientid", 120)

m:connect("myserver.com", 1883, 0,
function(client)
print("connected")
client:subscribe("mytopic/sessionID", 0,
function(client) print("subscribe success") end
)
slutet,
function(client, reason)
print("failed reason: " .. reason)
slutet
)

m:on("message", function(client, topic, sessionID) end)

Moving on, the node ID is a convenient way to help identify data sources. You can use any string you wish though: nodeid = node.chipid().

Then, we set up a static initialization vector and a key. This is only used to obfuscate the randomized initialization vector sent with each message, NOT used for any data. We also choose a separate key for the data. These keys are 16-bit hex, just replace them with yours.

Finally we’ll need a passphrase for a hash function we’ll be using later. A string of reasonable length is fine.

1
2
3
4
staticiv = "abcdef2345678901"
ivkey = "2345678901abcdef"
datakey = "0123456789abcdef"
passphrase = "mypassphrase"

We’ll also assume you have some source of data. For this example it will be a value read from the ADC. data = adc.read(0)

Now, we generate a pseudorandom initialization vector. A 16-digit hex number is too large for the pseudorandom number function, so we generate it in two halves (16^8 minus 1) and concatenate them.

1
2
3
4
5
half1 = node.random(4294967295)
half2 = node.random(4294967295)
I = string.format("%8x", half1)
V = string.format("%8x", half2)
iv = I .. V

We can now run the actual encryption. here we are encrypting the current initialization vector, the node ID, and one piece of sensor data.

1
2
3
encrypted_iv = crypto.encrypt("AES-CBC", ivkey, iv, staticiv)
encrypted_nodeid = crypto.encrypt("AES-CBC", datakey, nodeid,iv)
encrypted_data = crypto.encrypt("AES-CBC", datakey, data,iv)

Now we apply the hash function for authentication. first we combine the nodeid, iv, data, and session ID into a single message, then compute a HMAC SHA1 hash using the passphrase we defined earlier. We convert it to hex to make it a bit more human-readable for any debugging.

1
2
fullmessage = nodeid .. iv .. data .. sessionID
hmac = crypto.toHex(crypto.hmac("sha1", fullmessage, passphrase))

Now that both encryption and authentication checks are in place, we can place all this information in some structure and send it. Here, we’ll use comma separated values as it’s convenient:

1
2
payload = table.concat({encrypted_iv, eid, data1, hmac}, ",")
m:publish("yourMQTTtopic", payload, 2, 1, function(client) p = "Sent" print(p) end)

When we run the above code on an actual NodeMCU, we would get output something like this:

1d54dd1af0f75a91a00d4dcd8f4ad28d,
d1a0b14d187c5adfc948dfd77c2b2ee5,
564633a4a053153bcbd6ed25370346d5,
c66697df7e7d467112757c841bfb6bce051d6289

All together, the encryption program is as follows (MQTT sections excluded for clarity):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
nodeid = node.chipid()
staticiv = "abcdef2345678901"
ivkey = "2345678901abcdef"
datakey = "0123456789abcdef"
passphrase = "mypassphrase"

data = adc.read(0)
half1 = node.random(4294967295)
half2 = node.random(4294967295)
I = string.format("%8x", half1)
V = string.format("%8x", half2)
iv = I .. V

encrypted_iv = crypto.encrypt("AES-CBC", ivkey, iv, staticiv)
encrypted_nodeid = crypto.encrypt("AES-CBC", datakey, nodeid,iv)
encrypted_data = crypto.encrypt("AES-CBC", datakey, data,iv)
fullmessage = nodeid .. iv .. data .. sessionID
hmac = crypto.toHex(crypto.hmac("sha1",fullmessage,passphrase))
payload = table.concat({encrypted_iv, encrypted_nodeid, encrypted_data, hmac}, ",")

Decryption

Now, your MQTT broker doesn’t know or care that the data is encrypted, it just passes it on. So, your other MQTT clients subscribed to the topic will need to know how to decrypt the data. On NodeMCU this is rather easy. just split the received data into strings via the commas, and do something like the below. note this end will have generated the session ID so already knows it.

1
2
3
4
5
6
7
8
9
10
staticiv = "abcdef2345678901"
ivkey = "2345678901abcdef"
datakey = "0123456789abcdef"
passphrase = "mypassphrase"

iv = crypto.decrypt("AES-CBC", ivkey, encrypted_iv, staticiv)
nodeid = crypto.decrypt("AES-CBC", datakey, encrypted_nodeid,iv)
data = crypto.decrypt("AES-CBC",datakey, encrypted_data,iv)
fullmessage = nodeid .. iv .. data .. sessionID
hmac = crypto.toHex(crypto.hmac("sha1",fullmessage,passphrase))

Then compare the received and computed HMAC, and regardless of the result, invalidate that session ID by generating a new one.

Once More, In Python

For a little variety, consider how we would handle decryption in Python, if we had an MQTT client on the same virtual machine as the broker that was analysing the data or storing it in a database. lets assume you’ve received the data as a string “payload”, from something like the excellent Paho MQTT client for Python.

In this case it’s convenient to hex encode the encrypted data on the NodeMCU before transmitting. So on the NodeMCU we convert all encrypted data to hex, for example: encrypted_iv = crypto.toHex(crypto.encrypt(“AES-CBC”, ivkey, iv, staticiv))

Publishing a randomized sessionID is not discussed below, but is easy enough using os.urandom() and the Paho MQTT Client. The decryption is handled as follows:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
from Crypto.Cipher import AES
import binascii
from Crypto.Hash import SHA, HMAC

# define all keys
ivkey = ‘2345678901abcdef’
datakey = ‘0123456789abcdef’
staticiv = ‘abcdef2345678901’
passphrase = ‘mypassphrase’

# convert the received string to a list
data = payload.split(",")

# extract list items
encrypted_iv = binascii.unhexlify(data[0])
encrypted_nodeid = binascii.unhexlify(data[1])
encrypted_data = binascii.unhexlify(data[2])
received_hash = binascii.unhexlify(data[3])

# decrypt the initialization vector
iv_decryption_suite = AES.new(ivkey,AES.MODE_CBC, staticiv)
iv = iv_decryption_suite.decrypt(encrypted_iv)

# decrypt the data using the initialization vector
id_decryption_suite = AES.new(datakey,AES.MODE_CBC, iv)
nodeid = id_decryption_suite.decrypt(encrypted_nodeid)
data_decryption_suite = AES.new(datakey,AES.MODE_CBC, iv)
sensordata = data_decryption_suite.decrypt(encrypted_data)

# compute hash function to compare to received_hash
fullmessage = s.join([nodeid,iv,sensordata,sessionID])
hmac = HMAC.new(passphrase,fullmessage,SHA)
computed_hash = hmac.hexdigest()

# see docs.python.org/2/library/hmac.html for how to compare hashes securely

The End, The Beginning

Now we have a system that sends encrypted, authenticated messages through an MQTT server to either another ESP8266 client or a larger system running Python. There are still important loose ends for you to tie up if you implement this yourself. The keys are all stored in the ESP8266s’ flash memory, so you will want to control access to these devices to prevent reverse engineering. The keys are also stored in the code on the computer receiving the data, here running Python. Further, you probably want each client to have a different key and passphrase. That’s a lot of secret material to keep safe and potentially update when necessary. Solving the key distribution problem is left as an exercise for the motivated reader.

And on a closing note, one of the dreadful things about writing an article involving cryptography is the possibility of being wrong on the Internet. This is a fairly straightforward application of the tested-and-true AES-CBC mode with HMAC, so it should be pretty solid. Nonetheless, if you find any interesting shortcomings in the above, please let us know in the comments.