[Bug]: DMing can be permanently impaired if a device resets its keys

[SudoRand]

Category

Other

Hardware

Rak4631

Is this bug report about any UI component firmware like InkHUD or Meshtatic UI (MUI)?

• Meshtastic UI aka MUI colorTFT
• InkHUD ePaper
• OLED slide UI on any display

Firmware Version

2.6.11.60ec05e

Description

It seems there is a gap in the current Meshtastic implementation of Trust On First Use for direct message encryption keys. If a node is operating in an area with a public mesh and its keys are ever reset, that device may be permanently unable to direct message with nodes that have seen it on the network before.

From this point forward, the device will be unable to send or receive DMs with nodes that previously wrote down the old key. Since the key is associated with the device's fixed Node ID based on the hardware MAC address, the problem is permanent.

The only solution is to get the owner of every node that you might want to DM (or that might want to DM you) to manually delete your device from their NodeDB. This is complicated by the fact that you can't DM them to ask them to do this, and the apps don't make it clear when this may be needed.

Restoring the old key isn't a solution because the problem will exist for any nodes that first saw this node when it was using the new key (and the old key may have been reset for a good reason).

A common solution in other Trust On First Use systems is to have a UI that informs the sender or recipient that the peer they are communicating with has changed keys and confirms whether they want to trust the new key.

Another option is to let nodes reset the Node ID along with its keys. That way, if you find yourself in this situation you could at least "start fresh" by resetting both your ID and your keys. This seems helpful for other reasons, like when selling or giving away used hardware the new owner wouldn't have to use your identity on the mesh and then the old and new owners wouldn't be able to (theoretically) decrypt each other's communications.

There are various common reasons why keys may need to be reset, including when addressing the "low entropy key" issue, when factory resetting, when buying or being given used hardware, or when a private key has been leaked/compromised.

It would be great if there was a means for devices in this situation to become fully viable on the network again.

This topic was previously discussed here.

Relevant log output

[Ryu945]

A common solution in other Trust On First Use systems is to have a UI that informs the sender or recipient that the peer they are communicating with has changed keys and confirms whether they want to trust the new key.

Isn't this already done now? I remember seeing a picture of someone with this notification in Discord.

Another option is to let nodes reset the Node ID along with its keys. That way, if you find yourself in this situation you could at least "start fresh" by resetting both your ID and your keys.

When you say Node ID, your referring to what exactly?

[ford-jones]

A common solution in other Trust On First Use systems is to have a UI that informs the sender or recipient that the peer they are communicating with has changed keys and confirms whether they want to trust the new key.

Ryu is correct, we do have this already. On the apps you can select the padlock and an alert will popup which says "Request new keys from %s"

I agree that this doesn't completely solve the issue, as you mentioned each of your local nodes would have to go through and do this on their end and there is no way to tell them to do so. Just pointing out that this part of the issue is resolved 🙂

[SudoRand]

Ryu is correct, we do have this already.

Thanks for pointing this feature out. That is indeed helpful because it makes it easier to see which nodes might need refreshed keys.

As you mention, I will still not be able to send a message to anyone unless they spend their time actively looking for open padlocks and clicking some buttons, or I am able to contact them from a different node or outside of Meshtastic.

A more ideal experience would be when I send someone a DM, the recipient would see a UI that says "FOO sent you a message but it had an untrusted key. Would you like to trust this new key?"

When you say Node ID, your referring to what exactly?

I believe the Node ID is also know as the "Node Number" in the app's UI. According to this documentation, it is derived from the MAC address, which is a unique number permanently burned into each device's hardware chip.

[GUVWAF]

when I send someone a DM, the recipient would see a UI that says "FOO sent you a message but it had an untrusted key. Would you like to trust this new key?

The problem is that the new key is not sent with the DM, it's only in the NodeInfo packet. We could indeed, however, at the moment you receive a NodeInfo with a new key ask to accept this new key via a client notification.

There's some caveats here; for example when someone factory reset its node, it will generate new keys. After booting, the node sends out its NodeInfo almost immediately, so other nodes get the new key before it has a chance to restore the original keys.

[SudoRand]

On the apps you can select the padlock and an alert will popup which says "Request new keys from %s"

I am using the iOS app, and it doesn't appear to have this feature. When I see an open padlock icon and click it, it just takes me to the node's info page. A that point I would just have to know to go down and click Delete Node.

The problem is that the new key is not sent with the DM, it's only in the NodeInfo packet. We could indeed, however, at the moment you receive a NodeInfo with a new key ask to accept this new key via a client notification.

I don't think we'd want to spam everyone every time a node changes keys because that could be pretty noisy on a big mesh. It seems that it would be better to initiate this experience when a DM is received or sent. At that point, their node most likely already knows about the mismatch situation and is using that knowledge to display an open padlock for my node that changed keys.

From a technical standpoint the simplest action would probably be to for their node to simply invalidate my currently trusted key when the user confirms a dialog. They could resume communication once the padlock displays as closed again after a new NodeInfo is recieved.

However, this user experience could be significantly optimized if there's a willingness to write down an additional piece of info in the NodeDB. The NodeDB could actually record a "most recently seen key" in addition to the "currently trusted key". This could give them the ability to instantly accept and trust my new key whenever they are about to DM me or they get alert that their node received a DM from me that it can't decode.

Edited: To make it clearer who is who in my examples above.

[GUVWAF]

From a technical standpoint the simplest action would probably be to for their node to simply invalidate my currently trusted key when the user confirms a dialog.

I think that's a fair request, but it's one for the apps. They can import a "shared contact" with no key after the user accepts it.

However, this user experience could be significantly optimized if there's a willingness to write down an additional piece of info in the NodeDB.

32 additional bytes of RAM for each node entry is a lot for this in my opinion. Again this could be implemented on the app as well.

[SudoRand]

Yes, thanks for talking this over. I think you're right that for one direction of communication this could be easily solved by the apps. When sending a DM to a node, the UI could check if the destination has an "unlocked padlock" and it could easily prompt the user for a resolution first.

I haven't studied the serial/bluetooth API spec yet, but I'm suspecting new firmware support would be needed to alert the app about the situation where someone has sent you a DM but you are still trusting their old key.

[GUVWAF]

I'm suspecting new firmware support would be needed to alert the app about the situation where someone has sent you a DM but you are still trusting their old key.

That's correct. It wouldn't know that it's an "old key", but at least we can notify that we tried to decrypt, but failed.

[bazfp]

I've become a victim of this, got a pop up saying my public key was being advertised and I may have a low entropy key.

After googling it seemed like the best thing to do was regenerate my keys. Now I can't talk to any device on the network and I have a useless device!

[andres-a-git]

What about generating the Node ID in combination while generating new keys before selecting the frequency after factory reset?
If Meshtastic wants to grow and such cases (you mess up keys or sell your node) will appear in the future then it should not be wise to play with padlocks in the apps by lots of people

[ford-jones]

When we do a full erase and install, could we cache the current keys on the device (phone or computer) until reflash has completed, then set the key to what it was previously?

There could then be an additional option to explicitly reset the keys too, but not have it be default behaviour.

[SudoRand]

What about generating the Node ID in combination while generating new keys before selecting the frequency after factory reset?

Yes, I agree that this seems like the cleanest solution for a lot of use cases. It could be a single firmware change, which is probably simpler than the more elaborate user experience flows discussed above that would require coordinated app and firmware changes.

When we do a full erase and install, could we cache the current keys on the device

This would help some situations, but there are other times that you're resetting the keys on purpose for a reason. (Like giving/receiving used hardware, fixing low entropy keys, changing a compromised key, etc).

[ford-jones]

This would help some situations, but there are other times that you're resetting the keys on purpose for a reason.

Certainly! I mentioned we could introduce an additional option to explicitly specify that you would like to reset the keys, which would be useful in those cases you listed.

The overall result would be a reduction in the number of occurrences of this happening to users wanting to fully reset their devices for any other reason.