Lightweight Cryptographic Audio end-to-end encryption for IoT devices
Introduction
Description
X3DH Key Agreement
BOM

Published August 30, 2022

Lightweight Cryptographic Audio encryption for IoT devices

This project aims to simulate walkie-talkie communication over Wi-Fi with an X3DH key agreement protocol and a lightweight algorithm.

374

Lightweight Cryptographic Audio encryption for IoT devices

Things used in this project

Hardware components

Sony Spresense boards (main & extension)

Sony Spresense LTE extension board

Raspberry Pi Pico

Espressif ESP8266 ESP-01

Adafruit i2s microphone module

Adafruit I2S stereo decoder

Software apps and online services

Microsoft VS Code

Hand tools and fabrication machines

Soldering iron (generic)

Solder Wire, Lead Free

Breadboard, 170 Pin

Servo Motor, Premium Male/Male Jumper Wires

Story

Lightweight Cryptographic Audio end-to-end encryption for IoT devices

Names: Lino Mercado-Esquivias, Muhammed Zahid Kamil, Russell Hua, Shahzman Saqib, Alexander Ea

Introduction

Walkie-talkies, also known as two-way radio communication first came to light in the latter stages of World War 2[1]. The first walkie-talkie was actually called a “handie-talkie” in 1940 known as SCR-536 [1]. The walkie-talkie has various uses such as in the military, construction, emergency services, security services, hospitality, and transportation industries.

Walkie-talkies are used to send audio through a specific radio frequency/channel that both end users have agreed upon. A walkie-talkie includes many different features but the features that are common include:

Antenna - to receive and transmit radio wave

Antenna - to receive and transmit radio waves
Speaker - to hear/play the received messages over the channel
Microphone - to send audio over the same channel
Push-to-talk button - Walkie-talkies are by default always in ‘receive’ mode, so pressing this button allows a user to send messages.
Use of radio waves

Walkie-talkies work with radio frequency and consist of a transmitter and receiver. The transmitter, with the aid of an antenna, sends messages through radio waves while the receiver receives the information. In busy areas, the channels/frequencies that are available for two-way radios become limited[1]. The range of the walkie-talkies is also affected by the weather, type of obstructions, and noise from other radio signals[2]. Radio waves can travel from one end to the other in a straight line or bounce off of objects (which drastically reduces their strength). It can also be absorbed by objects. Walkie-talkies in mountain terrains range from 5-25 miles while in cities they range from 2-5 miles from rooftop to rooftop and less than a mile from street to street [3].

However, walkie-talkies can be tracked, scanned, and hacked. A directional and portable antenna can be used to identify the location of the transmitter of a user [4]. Walkie-talkies can be used to scan channels for active communication and then obtain any messages that are sent over the channel. According to the Independent, walkie-talkie toys that are popular amongst kids can be hacked so that a stranger could communicate with the child instead from a distance of 200m [5]. Highly encrypted walkie-talkies use the industry standard AES (Advanced Encrypted Standard) for secure communication.

This project aims to simulate a walkie-talkie communication over Wi-Fi [15] with the Extended Triple-DiffieHelman Protocol X3DH i.e Signal Protocol for asymmetric key encryption to generate a shared key. TinyJambu is a lightweight authenticated symmetric key encryption that uses this key to encrypt the audio and is sent over Wi-Fi. The term lightweight indicates that it is an algorithm meant for microcontrollers. With Wi-Fi, the range of the walkie-talkies is extended drastically compared to using radio waves. The Sony Spresense board with the LTE extension board is acting as a server to relay information from one user to another user.

The Signal Protocol, also known as X3DH is used by the Signal Messaging app to provide end-to-end encrypted communication. However, we have decided to use only the X3DH Key Agreement protocol to only generate a shared key from both users and this key will use the TinyJambu algorithm to encrypt the audio. TinyJambu is one of the finalists in the NIST lightweight cryptography (LWC) standardization competition.

The project uses the Sony LTE extension board to act as the Wi-Fi server that not only relays information from one user to the other but also sends pre-keys according to the Signal Protocol [7].

Description

The project aims to do the following with two users called Alice and Bob who want to talk to each other:

Bob wants to talk to Alice

Bob wants to talk to Alice
Bob requests Alice’s pre-key bundle from the server (Sony Spresense board)
Bob verifies Alice’s pre-key bundle and generates an ephemeral key.
Bob generates a shared key
Bob presses the button to talk and records his audio
Bob then encrypts the audio with TinyJambu and sends it to Alice through the Server
Alice receives the encrypted audio and starts generating her shared key.
Alice decrypts the audio with her generated shared key
Alice plays the decrypted audio.

Figure 1, below depicts a visual representation of the communication between Bob and Alice:

Figure 1: Overview

A more extensive flowchart for Bob, Alice, and the server (Sony Spresense board) is shown in Figures 2, 3, and 4 below.

Figure 2: Flowchart of Bob

Figure 3: Alice Flowchart

Figure 4: Server (Sony Spresence board) flowchart

X3DH Key Agreement

The X3DH Key Agreement protocol has three phases:

Alice publishes her pre-keys (IKA and SPKA) to a server
Bob fetches a “pre-key bundle” from the server, verifies it, and sends an initial message to Alice
Alice receives, verifies, and processes Bob’s initial message

Step 1:

Alice has a long-term identity key pair (IKA), creates a Signed Prekey (SPKA), and sends it to the server. Each key pair has a private key and a public key. The public keys are sent to the server as the pre-key bundle.

Step 2:

Bob receives the pre-key bundle, verifies the signature sent from Alice, and generates his ephemeral key pair (EKB). Bob then executes a Diffie-Helman (DH) calculation between keys as shown in Figure 5 below and passes through a key derivation function to generate the shared key. Bob uses his private keys in the DH key exchanges.

Figure 5: DH Calculations

Figure 5, shows the DH Curve25519 key exchanges, that can be represented in the following calculations below:

DH1 = DH(IKA, SPKB)
DH2 = DH(EKA, IKB)
DH3 = DH(EKA, SPKB)
SK = KDF(DH1 || DH2 || DH3)
DH - stands for Diffie-Helman key exchange [8]
KDF - stands for Key Derivation Function to generate a 128-bit key in this project [9]

The key generated from KDF is then used to encrypt the audio using TinyJambu [10]. This is an authenticated lightweight encryption algorithm. In current technology, most use the industry encrypted standard AES-256, but this project aims to use TinyJambu-128 instead.

Step 3:

Alice waits to receive the encrypted audio, Bob’s public Ephemeral Key (EKA), and Bob’s long-term public Identity key (IKB). Alice then computes the same DH calculations as Bob and generates a shared key. Alice uses her private keys in the Key exchange calculations. If both Alice and Bob have generated the same key, then Alice is able to decrypt bob’s audio.

BOM

The project simulates an audio encrypted form of communication over Wi-Fi. The parts used for this project are as follows:

X1 Adafruit I2S microphone module [11] (Figure 6)
X1 Adafruit I2S stereo decoder [12] (Figure 7)
Three X3 Espressif ESP-01 wifi modules [13] (Figure 8)
Two Raspberry Pi Picos [14] (Figure 9)
Sony Spresence with LTE extension board (Figure 10)

Figure 6: X1 Adafruit I2S microphone module

Figure 7: X1 Adafruit I2S stereo decoder

Figure 8: X3 Espressif ESP-01 wifi module

Figure 9: Raspberry Pi Pico

Figure 10: Sony Spresence with LTE extension board

Below is the final demo of our project.

Please note:

The attempt at using the Spresense board as a server didn't work because of issues getting circuitpython working. After flashing the bootloader and image, the board doesn't appear as a drive at all, across 2 computers (Linux and macOS), and at least 6 cables. As a result, uart is not available and it's not possible to communicate to the esp to setup the server. Using the sdk could work, but the drivers for uart are not easily accessible compared to circuitpython. As result, this project was not fully completed. There was more progress made with the other parts - the raspberry pi pico - but not with the Spresense board

References

Credits

Mohamed Aly

2 projects • 2 followers

Lightweight Cryptographic Audio encryption for IoT devices