IoT Goes to the Disco

What is one of the easiest roles in Cybersecurity? Ans: Making IoT security look bad.

Photo by Louis Reed on Unsplash

IoT Goes to the Disco

What is one of the easiest roles in Cybersecurity? Ans: Making IoT security look bad!

Introduction

For some reason, security is often an afterthought in creating IoT infrastructures, and the implementation of cryptography, especially, is often poorly defined. Here is my wi-fi kettle which uses Telnet — an insecure protocol — to connect to:

But it doesn’t have to be like this, as there are a whole lot of standards out there which can simply the life of a developer. With the STROBE protocol framework [specification] we implement a single cryptographic primitive for symmetric key encryption. Unlike Openssl — which tries to implement so many protocols and methods — the STROBE library is fairly small and can fit on most IoT devices. Along with this, it builds onto a TLS-like framework, and makes sure that all of the messages are linked to previous ones.

There’s a whole lot of libraries out there that developers can use for the STROBE protocol framework. libdisco, for example, is a Golang library and is based on the STROBE protocol framework. The symmetric cryptographic primitives rely on SHA-3 permutation (Keccak), and asymmetric cryptographic primitives on X25519 and ed25519. STROBE thus defines a range of cryptographic protocols to integrate with IoT devices. In order to reduce processing, energy and memory requirements, it only uses Keccak (SHA-3) to encrypt and authenticate messages [paper].

The underlying cryptography method is the sponge function and which provides us with permutation-based cryptography. With a permutation we take a given input and then permutate it to produce an output. We do this with AES, where a given input will always give a certain output. SHA-3 (or Keccak) uses a sponge function to its permutation. Where AES-128 has 10 rounds, Keccak-f[1600] has 24 rounds and has an input/output size of 1600 bits. The great thing about this sponge function is that we can store states within it, and where each new state is dependent on previous states.

So why use AES, when you can have SHA-3?

SHA-3 as stateful crypto

SHA-3 was known as Keccak and is a hash function designed by Guido Bertoni, Joan Daemen, Michaël Peeters, and Gilles Van Assche. MD5 and SHA-0 have been shown to be susceptible to attacks, along with theoretical attacks on SHA-1. NIST thus defined there was a need for a new hashing method which did not use the existing methods for hashing, and a competition for competing algorithms.

In October 2012, Keccak won the NIST hash function competition and is proposed as the SHA-3 standard. It should be noted that it is not replacement SHA-2, which is currently a secure method. Overall Keccak uses the sponge construction where the message blocks are XORed into the initial bits of the state, and then inevitably permuted.

The sponge function takes a simple function f and involves a number of stages, and where we create a fixed output (dependent on the bit length of the hash function). Simple operations of XOR, AND, and bit shifts are used, and which leads to a fast generation of the hash function:

The f permutation function takes a variable-length input and produces an arbitrary output length. A is the bit rate, and each f function operates on b bits, and where a capacity is defined as c = b — r.

The SHAKE method is useful as it can be used to create a hash method of a variable length. For the 128-bit version will produce a hash value is 32 hex characters.

The operation defines a number of functions and applies them into the SHA-3 function:

  • AD: Absorbs data to authenticate.
  • KEY: Absorbs a key.
  • PRF: Generates a random output (forward secure).
  • send_CLR: Sends non-encrypted data.
  • recv_CLR: Receives non-encrypted data.
  • send_ENC: Encrypts data.
  • recv_ENC: Decrypts data.
  • send_MAC: Produces an authentication tag.
  • recv_MAC: Verifies an authentication tag.
  • RATCHET: Introduce forward secrecy.
Ref: NCC Group [here]

Coding

The following is some sample Go code to test the core primitives used [link]:

A sample run is [link]:

Message: Hello
Password: qwerty

=== Digest ===
Digest (message): 1c38d06d9edd0e3271dd11cf39721630d48e9411c959b60e250c9a003629832e

=== Encryption ===
Cipher: fe04f8a8574c60506b30b84034d1742538e54d735140d8a9d3994c5d7ebd0c93e966cdb71f4777726f9e4d8618
Decrypted: Hello

=== Integrity Check ===
48656c6c6f2618278cf5d9c679620caf534b65eeef
Retrived: Hello
=== Key generation ===
Key1: 4815c5cbbd27c1589098b99983b4cfca6496b7235ef83fd34198b6302a4e03f6
Key2: c01863cfdc4a1a61c30735c62d9a366f1e518681dba7c7df1075a3941f25cb18
=== Key pair (X25519 key pair) ===
Bob Public Key: d43ef61b11c3d8b72e53483f1ca8d76cf803ebe35368db1b0b3c41b881e32845
Private Key: 11af0d74ad7e9c200138ec1a9b2ed2d3a6e55ff52b70663162b6ad6566287998
Alice Public Key: 18db6d38162a33443c56cffe4c1d100d949f0098dc234b4691668fd4b384075b
Private Key: 1e84885188e55366972da26d315f10e09de0c08d249b6b50b6d651a01a02735f
Shared key (Bob): ac0a6ab7a68358f92737fa631c179aeabe0ca082e8d7c0d4bda2809e9e1bf458
Shared key (Alice): ac0a6ab7a68358f92737fa631c179aeabe0ca082e8d7c0d4bda2809e9e1bf458

Conclusions

No excuses for insecure IoT devices!

https://asecuritysite.com/golang/godisco

Here is how you use libDisco and Keccak for symmetric key encryption: