[Feature Request]: Generate node ID out of public key

[contra-bit]

Platform

Cross-Platform

Description

I'd like to propose creating the node ID (aka node number) out of the public key, similar to how software like Tor and SSH handle it.
This would allow users to choose whether a factory reset node should appear as new or retain its old identity.

Currently, the node ID is generated from the MAC address, which leads to issues when a node is reset and a new public and private key pair is generated without warning.
This causes PKI mismatches and prevents functions like updating the position or getting a new node name.

By generating the node ID from the public key, users can choose to back up their private and public keys and restore them after a factory reset, allowing the device to retain its identity on the network.
If the keys are not restored, the device will appear as a new node.

This approach also solves a a privacy concern, as it allows users to appear as a new device on the network if they choose to.

It's essential to inform users about the importance of backing up their keys, as mentioned in Feature Request #272.
This should be done in a secure and user-friendly way, such as prompting the user to download or print a copy of their private keys.

Regarding the open points in Feature Request #272 Prepare for PKI & Config Updates:

Display message when others in conversation change their key.

Tying the node ID the public key, will minimize the risk of a user resetting their node.
The chance of a user accidentally messing up their public key is minimized.

Allow user to forget node, allowing it to rejoin with new key

This can be implemented by adding an option to "forget" a node, which would remove the node's public key and any associated data such as the node id from the local device.
Rejoining the network, with a different public key and the same node id, will not be possible.
This will be the same as deleting a node. If the user wants to keep the node, he will restore his keys.

Here's a possible implementation:

• When generating a new node ID, use a hash of the public key instead of the MAC
  address.
• Provide an option for users to choose whether a factory reset node should retain its old identity or appear as new. (This would create a backup of the private and public keys and update the node, after the factory reset).
• Document the process of adding multiple remote management keys and the implications of adding only the key of a remote device.
• Implement notifications for key changes in conversations.
• Implement the "forget node" option.

This feature would improve the overall security, privacy, and user experience of the Meshtastic network. It addresses the issues mentioned in Feature Request #272 Prepare for PKI & Config Updates and #281 Prompt User to download PKI keys for backups, and provides a more robust and user-friendly PKI system.

Relevant issues

• #281 Prompt User to download PKI keys for backups
• #272 Prepare for PKI & Config Updates
• #315 Add ability to add all 3 PKI admin keys
• Key Exchange not mentioned yet
• Meta PKI Issue
• Dicussion on the meaning of Node ID
• Relevant for how to implement the Node ID generation

[garthvh]

Seems likely to cause more issues, we are pretty far down the path of using the BLE Mac, there is a way to reset this on all platforms if you really want to.

[randshell]

@GUVWAF As a side note on the Bluetooth privacy topic, there seems to be support for random MACs in the protocol itself: https://duo.com/decipher/understanding-bluetooth-security.

I'm note sure if it can be useful for Meshtastic 3.0, but I'll leave it here just in case.

[GUVWAF]

Yes, I also know that some phones do this for the WiFi MAC address as well. But I'd argue this is a nice-to-have (since there are other ways to fingerprint radios as well); not a necessity and it comes with downsides.

What makes it difficult for Meshtastic is that:

• Every time someone forgets to back up its keys it will generate a new entry in everyone's NodeDB and they have to somehow figure out that those are actually the same nodes and one should be deleted, because it cannot be addressed anymore with this ID.
• Even if you back up your keys, the nodes send out a NodeInfo packet almost immediately after booting, which thus also results in a stale entry in everyone's database every time you factory reset a node.

[randshell]

What makes it difficult for Meshtastic is that:

The random MAC I wrote about is specifically about the Bluetooth protocol and so the communication with, for example, the Android device.

[GUVWAF]

The random MAC here is specifically about the Bluetooth protocol and so the communication with, for example, the Android device.

Okay, I see what you mean. However, OP wanted to change the Bluetooth MAC since that is used to generate the Node ID, not for Bluetooth-specific privacy in general.

[randshell]

Oh, all right. I thought it was a request for an additional privacy feature, but I guess it was just a case of the "XY problem". 🙂

Btw. Thanks again for all the support.

[contra-bit]

Thanks (again :) ) @GUVWAF for giving me more details.

There's one important bit I think you're missing: one of the major advantages of my proposal is to allow a node to get a totally new identity, unrelated to the previous one.

Thus:

There are other human identifiers associated with the node, such as the long and short name (which you usually keep the same).

You wouldn't keep them the same. That's the point.

With a new ID, you have to find out which node that originally was, so you know who is sending to you and thus which node you need to contact from now on

This would not happen too. For other node operators it would be just as if a new node appeared on the mesh. They don't know whom it belongs to. And that's what is intended.

There a plenty of reasons for a user wishing to get a new ID for his node. Examples:

• You're selling/giving it to someone else.
• You want to repurpose the node for another role (e.g. turn it from your mobile client to a remote sensor).
• You want to avoid tracking (e.g. you reset the ID when you travel to a different place).

With the introduction of PKI, this need became even more pressing, as now the node ID gets associated with a specific pubkey on everyone's node DB.

With the current MAC-based forever fixed node ID, stuff like repurposing a node or giving it to a friend, which before the PKI could be just a matter of doing a factory reset and setting a new node name, now involves coordination with all the peers of your mesh. That's lots of effort for no gain, as you do not wish (in all these scenarios) the ever again "be the same".

On the other hand, if you do wish the keep the previous ID, it will be just a matter of backing up your keys. Easy.

Now, on the finer details:

[Permissionless] Only if you use the default channel key

Not only that. A new node is immediately recorded to the node DB and used for relaying messages. No barriers to join the mesh.

Yes it is, and removing after X days requires the node to have a notion of time, which is not always the case.

Ohhh… So there's no automatic way to prune the node DB? What happens when it becomes full? The node just stops accepting new peers?

If so, that's quite an attack vector. It should be addressed anyway.

No, sending messages to a channel and transmitting telemetry just works, because that uses the channel key.

Indeed, it works for channels, as those use a PSK. But it stops working for direct communication.

I tested it. I was giving a node (that I just used for tests) to a friend. I did a factory reset (without saving the PKI keys of course), and now all peers are no longer able to read the node's battery level and GPS coordinates (due to the ID-to-key mismatch).

We are now forced to contact everyone in the mesh whom already runs the PKI-enabled version. It could have been much simpler if the factory reset also gave it a need ID: my friend would now have a fresh device that had no correlation with my previous usage.

With your approach, you can also generate new IDs and say “Hey I factory reset my node, contact me here now”.

Sure, but that attack will become harder to pull off.

With a cryptographically bound ID, the attacker won't be able to spoof the ID, only the node name. The victim receiving that message will thus see 2 nodes online with the same name, but with different IDs.

Right now, things are worse: the attacker can spoof the ID too! The victim will only see 1 node on his list.

---

I’m curious about the privacy and security issues

To sum it up simply, the advantages of using an ID bound to the pubkey, instead of a fixed one based on the MAC address, are:

• Privacy/anonymity: the same hardware can now get a different ID, and thus be repurposed/sold/offered/wtv without tying it to the previous usage.
• Security: spoofing IDs becomes impossible (or rather, super computationally hard).

[GUVWAF]

I’m sorry, but what has getting a new identity for re-purposing a node to do with any of this? To re-purpose a node, just give it a new long and short name. The old node doesn’t exist anymore, so it doesn’t make sense to leave multiple nodes in someone’s NodeDB. There are position precision settings to avoid tracking, or just disable it on the public channel.

The point was that you get a public key mismatch if you don’t back-up your keys when doing a factory reset, and nodes on the receiving end need to delete that node before being able to send DMs again. You proposed to generate a new Node ID in that case and then:

They don't know whom it belongs to. And that's what is intended.

Why is this intended after only a factory reset? Edit: I may be able to see a use-case for generating a completely new ID (although I would not be in favor of it because it just leads to stale entries in people's NodeDBs), but that shouldn't be the default for when you factory reset.

Not only that. A new node is immediately recorded to the node DB and used for relaying messages. No barriers to join the mesh.

You can’t send or receive messages to/from those nodes if you don’t share a channel key - that’s not really joining the mesh. Also, nodes without NodeInfo will be removed from the DB when rebooting.

What happens when it becomes full? The node just stops accepting new peers?

It does try its best to remove the oldest not favorite node.

I tested it. I was giving a node (that I just used for tests) to a friend. I did a factory reset (without saving the PKI keys of course), and now all peers are no longer able to read the node's battery level and GPS coordinates (due to the ID-to-key mismatch).

Then something else must have gone wrong. Battery level and GPS coordinates are not using PKI, because they are broadcast to a channel.

Right now, things are worse: the attacker can spoof the ID too! The victim will only see 1 node on his list.

Yeah, but it can’t decrypt packets encrypted with the public key of the old node, and you only update the public key after you delete the node. With your proposal, if you accidentally choose the node with wrong NodeID, you may send private information to it.

[contra-bit]

what has getting a new identity for re-purposing a node to do with any of this?

Because with the new PKI infrastructure the node ID now got tied to the node's pubkey.

To re-purpose a node, just give it a new long and short name. The old node doesn’t exist anymore

That no longer suffices. The old node still exists in everyones' node DB and is associated with the previous pubkey. Since, with the current code base, the new node re-uses the previous node ID you will get a key mismatch.

Thus, if for instance, a new person wants to use this new node, he will have to reach all peers that he has in common with the previous owner and say "hey, please delete the node, it's now owned by a different person".

Why is this intended after only a factory reset?

That's what factory resets do everywhere else, they delete the previous owner state. IMHO the node ID should be part of that state. Take a look at how it works for a smartphone.

Anyway, the default can be to keep the node ID and cryptograhic keys.

There are position precision settings to avoid tracking

Tracking comes in many different forms. Not only listening to the node's position updates.
Even if a node sends no position information, it's still possible to know its rough position, just by knowing whom it is connecting to, the radio signal power, etc. That's how mobile phones are tracked accross the cell phone networks.

Since, as of now, the node ID can never change, it's easy to track a device accross the network. An attacker can know that you went from one region to another, or from one country to another. (With messages being relayed over MQTT the attacker may not even need to have physical nodes in all places).

For some reason or another you may wish to not reveal you're using Meshtastic on another place. The easy solution would be to get a new node ID, but that's impossible now (without change the source code).

Battery level and GPS coordinates are not using PKI, because they are broadcast to a channel.

Indeed. I just re-tested it again and I was able to get the battery level and GPS coordinates. The only thing that did not work were direct messages (as expected). Sorry for the wrong info on this one, and thanks for poiting it out.

You can’t send or receive messages to/from those nodes if you don’t share a channel key - that’s not really joining the mesh.

Even without sharing a channel key other nodes will nevertheless retransmit your messages, right? I.e. their resources (in this case power and connectivity) are offered to you with no barrier. That's permissionless in my view.

[esev]

I've modified the firmware on my EDC device as mentioned in a previous comment to set a custom node id. I do this so I can upgrade devices without changing IDs. And so that I can gift a non-used device without transferring the node id.

If there was an option to generate the node id from the public key, that would be useful to me as I wouldn't need to maintain a separate firmware branch for this purpose.

Edit: There may be complications with HAM/licenced mode here, as they might not have public keys.

[thebentern]

For 3.0 where we have an opportunity to re-work the protocol, I'd almost argue the public key could be considered the new identifier for a node in some sense.

[randshell]

Also note that PKI is only used for direct messages, you can send a message to a channel saying you factory reset your node.

Thank you very much @GUVWAF, that's actually a nice idea without going into rebuilding. 🙂

Hmm, I was under the impression that it did. At least the "Full Erase and Install" option in the flasher does.

I'd be open to test it if this turns out to be an issue, just ping me.

---

Hi there @esev, @thebentern!

I've modified the firmware on my EDC device as mentioned in a previous comment to set a custom node id. I do this so I can upgrade devices without changing IDs. And so that I can gift a non-used device without transferring the node id.

I think configuring Github CI, starting from the already existing yaml configs, should be pretty straightforward actually. Perhaps I could try this approach as well. 🤔

For 3.0 where we have an opportunity to re-work the protocol, I'd almost argue the public key could be considered the new identifier for a node in some sense.

That's great to know, thanks!

[randshell]

@esev https://github.com/randshell/meshtastic-firmware/blob/191ca8ce124d9adbc9843ec5de0a3edf3f2c0af9/src/mesh/NodeDB.cpp#L891

Interesting. So if there's someone willing to help out or if there's a spare device, it's possible to use the custom build just for the initial spoofing. This, in turn, will force the device to generate a new nodeId. From what I've read briefly this should happen only at the beginning, so it should be safe as it would persist across upgrades.

[esev]

It should persist across upgrades, yes. And my experience is that it needs a factory reset (edit: maybe just a node db reset, I can't remember) to pickup the new ID. If there is ever an issue that requires a factory reset though it'll revert back to the original Mac address node id unless the custom build is in place.

I found the line that @GUVWAF mentioned to be the simplest place to do the firmware modification. Change nodeNum to the value you want to use:

firmware/src/mesh/NodeDB.cpp

Line 902 in 191ca8c

myNodeInfo.my_node_num = nodeNum;

You need to be careful to not generate a node ID that is common as well. It is tempting to use hex words, but that'll eventually result in conflicts.