[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.

[contra-bit]

@garthvh Could you please detail what specific issues switching to a node ID generated out of the public key would create? I am wondering if they could be easily addressed.

I must stress that the node ID now got intertwined with the PKI infrastructure introduced by @jp-bennett (after @edinnen work). Keeping the node ID tied to the BLE MAC is already creating issues, such as the pub key mismatch after a factory reset that I mentioned (which makes all nodes that had the previous pub key unable to talk with it).

Forcing the user to change the devices' BLE MAC addres in order to solve this (to get a new node ID) seems quite bad UX.

In order to address issues such as this, switching to a pubkey derived node ID, should keep the code base more simple in the near-future. (That's why projects with PKIs opt for that.)

P.S. Could you please link me to how I may generate a new BLE MAC address for the supported Meshtastic devices?

[garthvh]

Those mismatches are intentional, telling you that the node you are communicating with may have been compromised. There are a lot of advantages to using a hardware bound number, using a generated id like the pki is going to substantially increase spoofing and reduce the effectiveness of blacklisting nodes.

[GUVWAF]

Why do you want to generate a new BLE MAC address? I don't even think that's possible, it's usually burned in by the vendor (and e.g. for the RP2040 that doesn't have BLE it's a unique identifier). Upon a public key mismatch, you can delete the node from your list (if you want, after verifying with the owner that he did a factory reset) and it will update to the new public key automatically.

Could you please detail what specific issues switching to a node ID generated out of the public key would create?

Generating a new NodeNum every time you factory reset causes your node to be duplicated in everyone's node list, and they wouldn't know who to send to. It also increases the chance of duplicate NodeNums.

[contra-bit]

Thanks @GUVWAF and @garthvh for all the details and for bearing with me. Please allow me to better elucidate some points.

First of all, let's keep in mind that Meshtastic is a permissionless network, anyone can join or leave at any time. There's no access control.

Generating a new NodeNum every time you factory reset causes your node to be duplicated in everyone's node list

It wouldn't be a duplicate. There would be no way to tell it's the very same device. It would be as if it was a new node entering the network. This is exactly what's lacking. It is a desirable privacy and anonymity feature.
If the user would like to prevent that (i.e. keep the same ID) it would be just a matter of restoring the keys from a backup.

they wouldn't know who to send to.

That's the point. There would be a new node in the mesh whom others may try to contact, and there would be a node that went offline (forever).

Indeed this would increase the network churn. Is the size of the nodes list such a big concern? If so, I think it should be easy to alleviate by removing old nodes (not seen in the last X days).

Upon a public key mismatch, you can delete the node from your list

You should look at the problem the other way around.
As is, whenever someone does a factory reset (and forgets to backup the keys), he ends up with a hardware device that is now useless for the local Meshtastic network. It can no longer send messages or transmit telemetry data (battery level, GPS coordinates, etc.). There's even the chance of creating a network partition.

Being forced to ask (out-of-band) all other node operators (sometimes dozens) to delete your node from their list, in order to fix this, does not align with the permissionless nature of Meshtastic.

Having the option to get into the network with a new ID would fix this.

However, if you wish to retain your previous ID, you could still do it, by just restoring your keys.

Why do you want to generate a new BLE MAC address?

To get a new ID attributed to a node, so it may appear as a new fresh node on the network.
This way I won't have to bother dozens of node operators for something that was just a test. (The alternatives right now are either to go buy new hardware or modify the ID generation code.)

Those mismatches are intentional, telling you that the node you are communicating with may have been compromised.

With a node ID corresponding to the pubkey (or a hash of it) you could still have similar warnings. You could check if the triplet (node ID, short name, long name) matches what is in the node DB, and warn the user in case there's a mismatch. This is akin to what SSH does: it checks whether hostname matches the recorded pubkey.

using a generated id like the pki is going to substantially increase spoofing

No. It's actually the opposite. If correctly implemented it will eradicate ID spoofing. A new node would be inserted into the local DB only after checking that it provides a valid signature of its node info. With this, an attacker could only spoof if he was able to crack someone's private key, which is supposed to be (nearly) impossible.

Whereas, with the current implementation, an attacker can just edit the source code and spoof any device ID at will. He can even go further and try some social engineering to request known node operators to forget the previous keys (sure this can be mitigated through secure communication and proper verification processes).

and reduce the effectiveness of blacklisting nodes

Perhaps. But I would argue it is quite ineffective already. A potential spammer can just change the source code and generate new IDs at will.
(The only real solution for this would be a 180 degrees change to the security model of Meshtastic: having a whitelist instead of a blacklist. A node would only communicate with what its operator allows. But this is undesirable on a mesh due to connectivity reasons.)

we are pretty far down the path of using the BLE Mac

This, i.e. retro-compatibility, seems to me as the major hindrance to my proposal. All existing nodes would change ID upon update.

IMHO the long-term usability, privacy and security advantages far outweigh the temporary disruption that it may cause (which can be alleviated by proper documentation and warnings accompanying the release). However, if the disruption caused is deemed too serious, a migration path may be devised. For instance: allowing nodes to keep the old MAC-based ID for a few releases and letting operators issue the migration themselves when ready.

I believe that the sooner this is done the better. Keeping a PKI infrastructure coexisting with a non-cryptographic ID will only create more usability, privacy and security issues as time goes on.

[GUVWAF]

First of all, let's keep in mind that Meshtastic is a permissionless network, anyone can join or leave at any time. There's no access control.

Only if you use the default channel key, you can also use only private channel keys.

It wouldn't be a duplicate. There would be no way to tell it's the very same device. 

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

Is the size of the nodes list such a big concern? If so, I think it should be easy to alleviate by removing old nodes (not seen in the last X days).

Yes it is, and removing after X days requires the node to have a notion of time, which is not always the case. Or, it requires it to be always online so it can use relative time over a long period.

As is, whenever someone does a factory reset (and forgets to backup the keys), he ends up with a hardware device that is now useless for the local Meshtastic network. It can no longer send messages or transmit telemetry data (battery level, GPS coordinates, etc.). 

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

Being forced to ask (out-of-band) all other node operators (sometimes dozens) to delete your node from their list, in order to fix this, does not align with the permissionless nature of Meshtastic.
Having the option to get into the network with a new ID would fix this.

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 (and then delete the old node to avoid confusion). In my opinion, that’s an even worse UX.

Whereas, with the current implementation, an attacker can just edit the source code and spoof any device ID at will. 

Yes, and that’s why you have to verify with the owner whether the public key change was really intended. With your approach, you can also generate new IDs and say “Hey I factory reset my node, contact me here now”.

A node would only communicate with what its operator allows. But this is undesirable on a mesh due to connectivity reasons.

You can just use only private channels, packets are still routed via other nodes as long as LoRa settings match (and the nodes didn't explicitly disable this feature).

 Keeping a PKI infrastructure coexisting with a non-cryptographic ID will only create more usability, privacy and security issues as time goes on.

I’m curious about the privacy and security issues. Also would like to hear what @jp-bennett thinks of this proposal in general.

[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.

[garthvh]

You can change the node id on every platform if you want to, this is a tiny edge case and there is a solution already that complexity does not need to be applied to every device and user.

[contra-bit]

You can change the node id on every platform if you want to,

Ohh, that's great. Could you please link me somewhere describing how to do it?

[GUVWAF]

Indeed, while there may be very niche use-cases where you'd like to change your NodeNum, when adding it as an option to everyone it would only lead to misuse (either intentional or not). Especially making it the default when doing a factory reset will lead to issues.

Could you please link me somewhere describing how to do it?

You can set one here:

firmware/src/mesh/NodeDB.cpp

Line 679 in 7fd1c33

myNodeInfo.my_node_num = nodeNum;

Then factory reset and it should pick this one.

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"

Re-purposing a node is really a niche use case, and in my view this is a good requirement, because it's a sign the old node in the list does not exist anymore, and is replaced by this specific one. If you change your phone number, you also have to tell everyone that.

Take a look at how it works for a smartphone.

You mention "That's how mobile phones are tracked accross the cell phone networks", but surely not every smartphone gets a new Wi-Fi/BLE MAC address and IMEI after a factory reset. And indeed even without unique identifier you can fingerprint devices by other means.

I.e. their resources (in this case power and connectivity) are offered to you with no barrier.

Right, they offer you resources, but if you set your rebroadcast mode to KNOWN_ONLY, you don't offer them any. You can capture and replay any wireless signal, but that doesn't give you "access" to the network.