Forward Secrecy

[orbita2d]

Is there any interest in upgrading the security of private meshes?

Currently, by my understanding, the current strategy is AES with a PSK. This doesn't provide any level of forward secrecy, so an attacker could store the messages, and later get physical access to a node, and read the PSK off the device over serial (or even Bluetooth). This would allow them to decrypt any messages in the channel.

I understand that for meshtastic, any encryption scheme which relies on interactivity could be onerous. (Please tell me if that assumption is wrong).

One strategy might be to leverage the fact that many of these devices have an accurate track of time (using GNSS), to build a hash ratchet which rolls keys on a time interval a la TOTP.

Before I looked into this further I wanted to see if there was any hunger for something like this?

[github-actions[bot]]

@orbita2d, Welcome to Meshtastic! 👋

Thanks for opening your first issue. If it's helpful, an easy way
to get logs is the "Open Serial Monitor" button on the Web Flasher.

If you have ideas for features, note that we often debate big ideas
in the discussions tab
first. This tracker tends to be for ideas that have community
consensus and a clear implementation.

We're very active on discord,
especially the #firmware and #alphanauts-testing channels. If you'll
be around for a while, we'd love to see you there!

Welcome to the community! ❤️

[fifieldt]

Hi, and welcome!

I'll push this idea into discussions since we tend to keep the issues for things a bit closer to implementation.

Initial query would be - what impact do you envision for storage usage on nodes (we count bytes for some devices!) and how much additional traffic on the air would it need. They're the main considerations when adding to the firmware. As someone who doesn't understand as much as I should, some hand waving would be welcome :)

[fifieldt]

@jp-bennett is the resident expert for the current encryption code

[jp-bennett]

For regular channel messages, forward secrecy is probably not going to be feasible on these devices. DMs use a Diffie Helman scheme with X25519 keys. There's also a PR that adds PFS to the DM scheme you may be interested in taking a look at: #9116

[orbita2d]

So my proposal for forward secrecy here would

1. Require the devices to have a precise measure of the time (using a GNSS module)
2. Not add any messaging overhead
3. It would be a time-based window rather than a message counter

what impact do you envision for storage usage on nodes

We'd need a rewritable 40 bytes I think (32 for the key, 8 for a counter), I don't know what you need the failure modes to look like if e.g. it loses power mid-write.

How much wear can the flash memory in these devices take?

how much additional traffic on the air would it need

No interactivity or extra messages, maybe a few more bytes for a timestamp.

In rough terms, the core idea is use a KDF to derive key_{n+1} = KDF(key_n, n), overwrite key_n in persistent storage, incrementing n every X mins, and rely on synchronised clocks to keep nodes in lockstep. It would store only key_{n-1} persistently send using key_n, and keep key_{n-1} ... key_{n+1} in RAM for receiving messages. This would allow nodes to decrypt messages sent within the last X mins, and be able to tolerate small de-syncs between the clocks.

KDF chains and clock-synchronised key schedules are well understood, but I'm not sure anywhere else has combined them like this to meet these constraints. If it is interesting I'll write up the idea in more detail. To be clear it's not especially complicated and uses standard cryptographic primitives.

It's worth also mentioning that it would not provide any post-compromise security, if someone can read the key state and put the device back, they can read all future messages. This is unlike Signal and (I think) the proposal for the DM scheme you linked.

[fifieldt]

Thanks for writing up the idea in an understandable way :) May I ask how accurate the time needs to be? Is it within a minute, within a few seconds, or do milliseconds matter? We currently don't really use the PPS signal from the GPS chip and there are some interesting sleep patterns, so our time is a bit rough :) It can be improved, just want to know what our target is!

[orbita2d]

There's a trade-off here between tolerance and security, but if we rotate the key every X mins, we can tolerate a total of X mins between send time (according to sender) and message delivery (according to recipient), in either direction.

I'm not sure what the right value of X is here, but I believe we could tolerate a full minute of clock skew without issue.