[Feature Request]: Prepare for PKI & Config Updates

[Hunter275]

Description

TO DO for PKI

This is the bare minimum work needed for PKI
See: meshtastic/Meshtastic-Apple#869

Security Configuration

• Create new "Security" tab under "Config" - @KomelT
• Add PKI key input - @KomelT
• PKI key validation
• Load Security settings from device
• Save Security settings to device
• BONUS: Add PKI key generator (see PSK Generator #266)
  • Confirmation dialog when generating new Private Keys
• Ability to show/hide PKI keys with "eye" icon - @KomelT
• Move "Serial Output Enabled" toggle from Device tab to new Security tab
• Move "Enabled Debug Log" toggle from Device tab to new Security tab
• Add "Allow Bluetooth logging" toggle
• Add "Allow Legacy Admin" toggle (don't use PKI)
• Add "Admin key" input for managed nodes (use PKI)
  • Disable "Admin key" input when "Allow Legacy Admin" is toggled on
• Move "Managed" toggle from Device to new Security tab
  • Require either "Allow Legacy Admin" or "Admin key" when enabling "Managed" toggle

Nodes List

• Display green lock for nodes with a public key
• Display red lock with slash for nodes with public keys that do not match their recent messages (How do we track this persistently?)
• Display yellow open lock for existing DM messages sent before PKI
• Allow user to forget node, allowing it to rejoin with new key (is this the same as deleting a node?)

Messages

• Display a Green Lock when a DM is using PKI
• Display a Yellow Open Lock when a DM is not using PKI
• Display a lock when message sent with PKI
• Display a lock on the message when message received with PKI
• Display message when others in conversation change their key
• Display an error when a message is sent with the incorrect public key

[Hunter275]

This is a lot of work and ideally would be split among a few people.

If you're looking to help out just add a comment with whatever task(s) you're working on, big or small.

I plan on getting a branch ready tomorrow with the new "Security" tab added just as a jumping off point for everyone.

[Hunter275]

[Hunter275]

Text from Google Drive document "Meshtastic PKI doc" as of the time of this comment

---

One of the known limitationswith Meshtastic is that the keys are all PSK, and there’s no re-keying or forward secrecy for direct messages. Direct messages just re-use the shared channel key. I’ve jumped in to try to fix this.

I’m basing the effort on a drive-by pull request from a couple years back, that never went anywhere. The basic concept is to use a curve25519 diffie-hellman process, AKA x25519. Part 1 of the DH calculation gives us a public/private keypair, and the node sends the public key with its node announce packets.

Then the remote node takes that incoming public key, and its own private key, and does part two of the DH exchange, giving it a shared secret. We then use a SHA-256 hashing step to smear the bits of that key, as the raw DH result has “mathematical properties”. This hashed output will be used for AES CCM encryption between the two nodes.

This scheme is intended to guarantee that Direct Messages between two nodes is only decryptable by those nodes. Additionally, it is intended to guarantee that the sending node is in possession of the private key that corresponds to the advertised public key. And finally, It is intended to guarantee that the message received is the message that was sent by the key holder.

This PKI implementation is limited. It does not provide Perfect Forward Secrecy. By this we mean that if at any time the shared private key is known, the entire conversation between two nodes can be decrypted.

It does not verify the identify of the sender, and does not provide any verification of the public key that was sent over the mesh. It is up to the user to determine that the public key in their local NodeDB actually corresponds to who they think it does.

The Meshtastic firmware does not allow for re-keying, except by removal of a node from the NodeDB. This may happen organically, if there are more nodes than the MAX_NODEDB_SIZE. To prevent this, nodes can be marked “favorite” and will not be ejected from that list.

This Meshtastic PKI scheme is based on Curve25519, which is not considered quantum-resistant. The key sizes of the current quantum-resistant schemes are prohibitively large on Meshtastic hardware.

A PKI message does reveal the from, to, and message length.

This PKI implementation does not inherently include replay attack prevention. The firmware will keep a short list of seen PKI nonces, and reject a message on that list. In addition, the admin flow is gaining a session passkey that will very effectively eliminate replay attacks outside the session expiration window, currently set to 120 seconds.

Additionally, it is recommended that when possible, the clients keep a record of seen packet IDs, and reject packets that unexpectedly re-use an ID. As the nonce is part of the packet ID, this will also catch packet replays.

The adminModule will also generate a session key upon receiving a get_x request, and include that key with its get_x_response messages. This session key must be included in subsequent set_x messages, and it times out after 5 minutes. This prevents replay attacks against admin messages.

[KomelT]

I want to help.

For starters, I can add a new "Security" tab under "Config" and PKI key input.

[Hunter275]

iOS screenshots