Chatters Security
Chatters is designed to be reasonably secure, while still not requiring any centralized systems to facilitate any part of the security. Broadcast messages are encrypted so that only devices within the cluster are able to read the content, regardless of which channels / hops are used to get the message out. Device to device messages (DMs) are encrypted in such a way that only the sender and recipient are able to interpret the message…again, regardless of what hops (if any) are between the sender and recipient. Within Chatters, a message is composed of at least 3 packets:
Header: This packet contains an NBF (not before) timestamp, NAF (not after) timestamp, a recipient device ID, and 6 message flags that can be used in various ways. It is never encrypted, as it is useful for routing, validating, and other things.
Body: The body is composed of at least one packet, but can be more, as long as the full message doesn’t exceed my somewhat arbitrarily-chosen limit of 1024 bytes. This packet is encrypted by default, except in very special cases (public key exchange, etc). These body packets contain the actual message content. For broadcast messages, the body is encrypted using the cluster’s symmetric key. For direct messages (DMs), the body is encrypted using the sender’s private key and recipient’s public key. No devices besides the sender and receiver have the information required to decrypt it.
Footer: The content of the header and unencrypted message body are hashed (SHA256) and signed (ECDSA) using the sender’s public key. The footer contains both the hash and the base 64 encoded signature. This enables any cluster participant to determine if the message is authentic and fresh, without needing the ability to decrypt the payload.
Algorithms
For symmetric encryption and FRAM storage encryption, chatter uses the ‘ChaCha Poly32’ encryption algorithm, which is designed for limited-resource devices.
ECDSA is used for digitally signing messages and verifying message signatures. Elliptic curve is also used for temporarily generating a non-stored shared key, when sending a direct (non-broadcast) message.
SHA256 is used throughout chatter, wherever hashing is required.
Encryption Keys
The chatters messaging system is designed to be quite secure. Each device, when initialized, creates its own ECDSA keypair. The private key is stored encrypted in FRAM, and never leaves the device.
A chatters device can generate a new cluster at any time. When a new cluster is created, a symmetric key for the cluster is generated and stored (encrypted) in FRAM. The only time this symmetric key is shared is when onboarding a new device to the cluster. At that time, the cluster root and device to be onboarded switch to a dedicated “onboard” frequency, exchange public keys, and then use asymmetric encryption to complete the more sensitive exchanges.
Currently, only ChatterBox devices store the symmetric key. Bridge devices do not store the key, as they do not ever need to actually read or understand message content.
Negotiating Trust
When a device is onboarded to a cluster, in addition to cluster-related data (lora frequency, etc), the device receives a root-signed license. This license provides the ability for a device to prove to other devices that it was onboarded by the root (or other trusted devices in the future). Whenever a message is received by an unknown sender in the cluster, the recipient will automatically request the sender’s root-signed license. If everything looks good, the sender will automatically be added to the recipient’s truststore. This happens transparently to the recipient.
