tim292stro
commented
2 years ago Would also be nice to have a way to programmatically/remotely wipe the key, and distribute a new key.
For example having a group key and a channel key, the group key is used for centralized automated operations like updating a channel key, the channel key is used to encrypt/decrypt COT traffic only. This would enable using SMS/Meshtastic to distribute new keys. Send a text with:
spcKpllQKBx8kYw381FBzXLJEHmV/XZUWBCLRwxVv0Y=TAK998Dgv2Pt31vmwWIxhfA4mVV7R+ZRZXO8tvuzNOznJQ=
Where "TAK" is your delineator, and it is preceded with the AES-256 group-key encryption of the first 256-bits of the Sha512 hash in Base64 of {channelname}, and followed by a new key AES-256 encrypted by the group-key in base64 for the key-value pair with the {channelname} as the key. Nothing in plaintext that way, and should fit inside a 160 character limit for SMS/Meshtastic.
EDIT: probably want to be able to sign this also... for validation/attribution.
Also, for centralized administration and user to user (non-group channels), it might be interesting to look at the way Signal was architected for user verification. Each device generates a unique one-time public/private key, then one device shares the public key and a one-time channel name/ID with a QR to the other user. The scanning user then sends their public key encrypted by the QR code user's public key to the temporary channel. The QR user then public key encrypts a chunk of data to use as a hash with the scanning user's public key back over that same temporary channel, and the scanning user sends back its own chunk of data to use as a hash to the QR user over that same temporary channel. Both users combine each portion of the data plus the temporary channel name/ID into a hash to generate a new channel name/ID and a first key. The QR user sends the "hello" to test the new link and if the scanning user meets successfully, they have a secure channel to start talking over. The highest risk to eavesdropping is the physical exposure of the QR code exchange (this can be mitigated with something extremely technical like a jacket over the phones on a table... :P)
The server (or in Meshtastic lexicon "the router") never has to know who each user is, and never needs to see the plaintext of each message. It would only know that a Meshtastic node name sent a message to a Meshtastic nodename, this is about as much information leakage as IP addresses, and they could be randomized, especially if the TAK instance is talking to Meshtastic directly over UART.
Tyler-2
In some cases, one or more ATAK user groups may need to communicate over a shared, or even public Meshtastic channel - for example, when using pre-existing network infrastructure to increase coverage. In these cases, the Meshtastic built-in channel encryption layer is insufficient to ensure the secrecy and integrity of the communications.
For these cases, it would be really useful to have a second in-app encryption layer controlled from the plugin settings - which encrypts all messages prior to sending to the Meshtastic channel using a separate pre-shared key that never leaves the EUD. Similar to the ATAK builtin function AES-256 Mesh Encryption, but for Meshtastic comms.
It would be really useful even in case of loss of a Meshtastic radio, which is currently a fatal attack vector as each radio contains the channel key in cleartext.