mudhorn/meshtastic
1
0
Fork 0
mirror of https://github.com/meshtastic/meshtastic.git synced 2024-12-26 22:19:46 -08:00
Code Issues Actions Packages Projects Releases Wiki Activity

Merge pull request #862 from pdxlocations/encryption-speculation

Browse source 
Remove Speculation from Encryption Documentation
This commit is contained in:
rcarteraz 2023-11-02 10:43:16 -07:00 committed by GitHub
parent 1635a7158e 2d6127d5cb
commit 08e25f2c53
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
1 changed files with 20 additions and 73 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

93
docs/about/overview/encryption.mdx
View file

@ -6,33 +6,37 @@ slug: /overview/encryption
sidebar_position: 3
---
Cryptography is tricky, so we've tried to 'simply' apply standard crypto solutions to our implementation. However, the project developers are not cryptography experts. Therefore we ask two things:
- If you are a cryptography expert, please review these notes and our questions below. Can you help us by reviewing our notes below and offering advice? We will happily give as much or as little credit as you wish ;-).
- Consider our existing solution 'alpha' and probably fairly secure against a not particularly aggressive adversary (but we can't yet make a more confident statement).
Cryptography is tricky, so we've tried to 'simply' apply standard crypto solutions to our implementation. However, the project developers are not cryptography experts.
Always keep in mind [xkcd's note on encryption](https://xkcd.com/538).
## Summary of strengths/weaknesses of our current implementation
Based on comments from reviewers (see below), here's some tips for usage of these radios. So you can know the level of protection offered:
Based on comments from reviewers (see below), here are some tips for usage of these radios, so that you may know the level of protection offered:
- It is pretty likely that the AES256 security is implemented 'correctly' and an observer will not be able to decode your messages.
- Warning: If an attacker is able to get one of the radios in their possession, they could either a) extract the channel key from that device or b) use that radio to listen to new communications.
- Warning: If an attacker is able to get the "Channel QR code/URL" that you share with others - that attacker could then be able to read any messages sent on the channel (either tomorrow or in the past - if they kept a raw copy of those broadcast packets)
Possible future areas of work (if there is enough interest - post in our [forum](https://meshtastic.discourse.group) if you want this):
The current implementation provides optional confidentiality to members of a configured network:
1. Optionally requiring users to provide a PIN to regain access to the mesh. This could be based on: intentionally locking the device, time since last use, or any member could force all members to re-authenticate,
2. Until a device re-authenticates, any other access via BLE or USB would be blocked (this would protect against attackers who are not prepared to write custom software to extract and reverse engineer meshtastic flash memory)
3. Turning on read-back protection in the device fuse-bits (this would extend protection in #2 to block all but **extremely** advanced attacks involving chip disassembly)
4. Time limiting keys used for message transmission and automatically cycling them on a schedule. This would protect past messages from being decoded even if an attacker learns the current key.
- Encryption is implemented in devices/nodes with network-wide encryption keys.
- Encryption is optional and is turned off when devices are in 'Ham mode'.
- There is no encryption supported in the clients (iOS, Android) to facilitate distribution as mass market software.
- Pairing from client-to-device is by:
- direct USB cable
- BT pairing
- Devices are 'promiscuous' and will pair with any near-by client. Network confidentiality requires physical protection of all nodes.
### Notes for reviewers
Always keep in mind [xkcd's note on encryption](https://xkcd.com/538).
- If you are a cryptography expert, please review these notes and our questions below. Can you help us by reviewing our notes below and offering advice? We will happily give as much or as little credit as you wish ;-).
- Consider our existing solution 'alpha' and probably fairly secure against a not particularly aggressive adversary (but we can't yet make a more confident statement).
## Notes for reviewers
If you are reviewing our implementation, this is a brief statement of our method.
- We do all crypto at the SubPacket (payload) level only, so that all meshtastic nodes will route for others - even those channels which are encrypted with a different key.
- We do all crypto at the SubPacket (payload) level only, so that all Meshtastic nodes will route for others - even those channels which are encrypted with a different key.
- Mostly based on reading [Wikipedia](<https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation#Counter_(CTR)>) and using the modes the ESP32 provides support for in hardware.
- We use AES256-CTR as a stream cypher (with zero padding on the last BLOCK) because it is well supported with hardware acceleration.
- Our AES key is 128 or 256 bits, shared as part of the 'Channel' specification.
@ -53,61 +57,4 @@ I'm assuming that meshtastic is being used to hike in places where someone capab
- I think the bigger encryption question is "what does the encryption need to do"? As it stands, an attacker who has yet to capture any of the devices cannot reasonably capture text or location data. An attacker who captures any device in the channel/mesh can read everything going to that device, everything stored on that device, and any other communication within the channel that they captured in encrypted form. If that capability basically matches your expectations, it is suitable for whatever adventures this was intended for, then, based on information publicly available or widely disclosed, the encryption is good. If those properties are distressing (like, device history is deliberately limited and you don't want a device captured today to endanger the information sent over the channel yesterday) we could talk about ways to achieve that (most likely synchronizing time and replacing the key with its own SHA256 every X hours, and ensuring the old key is not retained unnecessarily).
- Two other things to keep in mind are that AES-CTR does not itself provide authenticity (e.g. an attacker can flip bits in replaying data and scramble the resulting plaintext), and that the current scheme gives some hints about transmission in the size. So, if you worry about an adversary deliberately messing-up messages or knowing the length of a text message, it looks like those might be possible.
I'm guessing that the network behaves somewhat like a store-and-forward network - or, at least, that the goal is to avoid establishing a two-way connection to transmit data. I'm afraid I haven't worked with mesh networks much, but remember studying them briefly in school about ten years ago.
## Phased Proposal for the Meshtastic Security Framework
### Phase 1 - Fixed network encryption with AES-CTR
The current implementation provides optional confidentiality to members of a configured network:
- Encryption is implemented in devices/nodes with network-wide encryption keys.
- Encryption is optional and is turned off when devices are in 'Ham mode'.
- There is no encryption supported in the clients (iOS, Android) to facilitate distribution as mass market software.
- Pairing from client-to-device is by:
- direct USB cable
- BT pairing
- Devices are 'promiscuous' and will pair with any near-by client. Network confidentiality requires physical protection of all nodes.
### Phase 2 - Strong device and client identity
**Phase 2 security goals:**
- Know who sent a message (strong binding of messages to a particular node and/or terminal device)
- This would be an optional feature for a message
- Optionally enforce identity based restrictions on some actions performed at nodes and/or clients
- Optional support of strong pairing of a client to a device/node and restrict ability to manage and receive messages based on the pairing.
- The BT paring and the cryptographic paring are separate (to simplify phase 1 deployment and testing)
- Above features should be architected to be ‘cryptographically strong’ and algorithm agile.
**Phase 2 Proposed mechanisms:**
- Proposed initial algorithms
- Ed25519 for signatures based on NaCl libraries and iOS support for Ed25519
- Clients and nodes to generate local identity Ed25519 keys
- Devices maintain knowledge of owner public key
- Devices maintain knowledge of some peers public keys and associated information (name, etc.)
- Experimental protobuf message type with
- cipher suite indicator (csi)
- wrapped data using a cipher suite identifier to indicate use of Ed25519 wrapping identified algorithms.
Wrapped data to contain any of the existing message types.
- initial ‘cipher suite’ **only** signs a message
- new signed/authenticated messages to:
- device->client: provide ownership status of device (owner is identified by a public key)
- client->device: set owner key (must be existing device owner or owner null)
- any->all. Broadcast public key and associated info (crude initial key distribution)
### Phase 3 and 3+:
- Device/node e2e message confidentiality (1-to-1)
- NO client side encryption
- All encryption turned off for a network in 'Ham mode'
- Protect messages sent over LoRa from eavesdroppers outside of a well identified group
- multicast group key distribution / discovery (1-to-n)
- Privacy
- BT MAC layer address privatization
- Node address privatization (Use use if based on device public key and schedule based aliasing)
- Private peer discovery
- Private service announcement and discovery
- Device/node security (hardening key storage, tamper resistance, side channel protection, etc.)
- Public key pairing process for client-to-device also sets up BT (no BT pin)
I'm guessing that the network behaves somewhat like a store-and-forward network - or, at least, that the goal is to avoid establishing a two-way connection to transmit data. I'm afraid I haven't worked with mesh networks much, but remember studying them briefly in school about ten years ago.