A project log for digital-walkie-talkie

long range, low power, modular

Christoph TackChristoph Tack 07/25/2021 at 09:490 Comments

The advantage of using digital communication over analog is that it's much easier to implement decent security measures.  Security deals with the following properties of the information:

We won't reinvent the warm water here.  We'll see what TLS1.3 and SSH have to offer us. 

Key exchange

TLS leaves many options here, some of which are interesting to us: PSK and ECDHE and a combination of the two.  In pre-shared key (PSK) mode, a pre-shared secret is established prior to key-exchange.  This can be done using an out-of-band secure channel : serial cable, NFC, ...  The problem with this approach is that it doesn't scale well.  The pre-shared secret should be unique for each combination of two devices.  If you have 20 devices, you'll end up generating and distributing 20!/(2!*18!) = 190 unique pre-shared secrets.

ECDHE (Elliptic Curve Diffie Hellman with Ephemeral keys) is easier to manage.  Each device in the group could be uploaded with a list of "certificates".  This list could be store on an SD-card in the device.  The list would be the same for all devices in the pool and it doesn't even need to be secret.  WiFi could be used to upload the list to the devices.

Message 1 : Client to server

TLS1.3 as well as SSH start with the client that creates an ephemeral key pair.  It then sends a random number (to prevent replay-attacks) and the ephemeral public key to the server. 

The ephemeral key pair is only used for key exchange.  Its lifetime is very short. 


In SSH this actually takes two different messages.


ClientHello message

Message 2 : Server to Client

The server creates an ephemeral key pair  as well.  For both protocols, the server's first message contains about the same arguments as the client's first message.  The server then adds additional data.


Additional data:


ServerHello message:

  1. Random : server_nonce = 32 bytes
  2. Extension: key_share : server's ephemeral public key

Additional data: EncryptedExtension, encrypted with keys derived from handshake secret.

Mutual authentication

As shown above, the key exchange only provides server authentication.  The server has no way of telling who the client really is.  Implementation of mutual authentication in TLS1.3, simply requires an extra message, with the client sending similar EncryptedExtension data.

Mutual authentication in SSH requires the SSH authentication protocol (RFC4252), which is a different message flow.  In short, the client sends its public key and attaches a signature to prove possession of the private key.


As the Arduino tool chain for ESP32 already includes libsodium, we'll use that.  Monocypher can't be used with ESP32 because of linker conflicts with the libsodium library.