[Feature Request]: Better security for admin channel

[jp-bennett]

Platform

NRF52, ESP32

Description

There's a potential issue with the way the admin channel is currently implemented, in that if a baddie gets physical access to a device, it exposes every device with that admin channel configured.

I can think of two ways to mitigate this risk, and there may be some benefit in combining the two. The first idea is to stop using the "admin" name as the admin channel, and instead store a setting on the device as to the admin channel name. So each device could have its own admin channel, like "admin_shortname" with a dedicated key. This has the added benefit that when you use your local radio to connect to the device, you're not vulnerable to rogue admin commands coming from a remote device.

The second way to approach this would be to add an admin_key as an optional device config setting. Incoming admin messages would be signed with that key, probably using HMAC. If an admin message comes in not containing a valid HMAC signature, it's just ignored. Again, this would be a unique key per device.

The ultimate goal is that you can put a repeater out in the wild, and not lose anything if it falls into evil hands. These are just early thoughts on how to possibly mitigate this risk, not fully thought out for every possible attack.

[jp-bennett]

One note is that an HMAC authentication by itself would not prevent someone listening to admin commands sent to other nodes, assuming a single admin channel key that is compromised. This would leak any information sent in those commands, though not the admin_key itself.

[jp-bennett]

If good per-device DM encryption lands, the ultimate solution might be to move config and info messages to DMs, still authenticated by an admin key, as detailed above.

[tim292stro]

I'd consider doing it considering with a layer of abstraction - separate the Admin channel controls from the link security. If the actual admin has a key for each node the admin channel just becomes a transport, Anyone who gets on it would only be able to send messages to other nodes on the chanel, but without the specific unit admin key, changes couldn't be made. This concept would also compartmentalize the risk of a network takeover - as each node's key would be unique, so physicially taking over one node would result in an attacker gaining no insight to the key for other nodes. If this is a real concern on comodity hardware, the user/owner could add a secure enclave part on I2C to hold the key and enable some level of assurance for the cryptographic algorithms/security.

Actual administration would require some consideration for migrating from one configuration to another as a network-synchronized action, and there would have to be a mechanism to propagate settings changes to out-of-contact nodes (this could involve relays and temporarily altering hops rules, etc). The UI would need some signifiicant work to enable this propagation resilliently.

I don't like the idea of admin control data going over the air-plaintext, so a transient session key should be agreed on for a short term tunnel that fits in mesh packes. Concepts like "perfect forward secrecy" used in web traffic would be a good guide. Maybe a OTP setup local key exchange from the installing-owner to generate a single use limited validity PIN for a given node would be beneficial too... that might work better for unique key management with limited TTL, especially if the nodes are GPS equipped for time receiving - lower traffic if the communication doesn't need a key agreement conversation.

[g1gabyt3]

If there was an easy way to store and select from a dropdown different keys for the admin channel, you could just have different keys for each device with an admin channel. That way you quickly change the PSK used in the admin channel depending on which device you wanted to send admin messages to. That way if one device is stolen, all the other devices have a completely different PSK so they're not compromised. This would be the most efficient way to handle it. It would be an application change though, not a firmware change as the firmware would just know it's singular PSK for the admin channel.

[cyberorg]

May be public key/authorized_key like ssh can be implemented? Or even a pin before admin session is initiated would be better than what we have now.

At the moment it seems any node in the mesh can administer any other node with admin channel with the same key configured.

[thebentern]

At the moment it seems any node in the mesh can administer any other node with admin channel with the same key configured.

Yes, channels are only secured by symmetric encryption. This is how all of the traffic in meshtastic is encrypted. If we make a special provision for admin channels, other private channels would still be "vulnerable".

[geeksville]

This issue has been mentioned on Meshtastic. There might be relevant details there:

https://meshtastic.discourse.group/t/question-about-router-nodes/12169/4

[g1gabyt3]

It would still beat the way it is now. I have a lot of repeater nodes. I put the default primary channel on them (because they have to have a primary) and then an admin channel. If someone steals one of my repeaters they would then have the admin channel key and if use the same admin channel key on all of them they could then do anything they want to any of my repeater nodes. To mitigate this I give them separate admin channel keys and have that saved in a spreadsheet. I then have Meshtastic device that I change the admin channel password to that of the node I want to administrate and then send the commands with the Python command line. This isn't very user friendly. Quite frankly it's a huge pain in the ass. I'm currently writing shell scripts to make this process easier for me, but there ought to be a better solution. Having the admin channel use symmetric encryption if you have physical control over all the devices is fine, but not when you have repeater nodes placed all over your county or across multiple counties where they could possibly be stolen. If someone stole one, I would have to climb a lot of different towers and reprogram nodes. That could take me weeks or even months to get done because one node gets stolen.

There either needs to be asymmetric encryption for the admin channel or a way to easily use different keys for the admin channel message to each node.

-----BEGIN GEEK CODE BLOCK-----

Version: 3.1

GIT d--- s+: a C++++ UBLAV++++

P++ L++++ !E W+++ N+ w--- M++ V

PS+ PE+ Y++ PGP++ t+ 5 X++ R++

tv-- b+ DI+++ D++ G++ e* h----

r++ z++++ ------END GEEK CODE BLOCK------

Please Note: Any following text is automatically appended to all my communications by the system, without my permission, consent, or approval. I have no control over its appearance or content.

---

Disclaimer Do not remove this disclaimer under penalty of law.

For optimum performance and safety, please read these instructions carefully.

Void where prohibited. No representation or warranty, express or implied, with respect to the completeness, accuracy, fitness for a particular purpose, or utility of these materials or any information or opinion contained herein. Actual mileage may vary. Prices slightly higher west of the Mississippi. All models over 18 years of age. No animals were harmed during the production of this product. Any resemblance to actual people, living or dead, or events, past, present or future, is purely coincidental. This product not to be construed as an endorsement of any product or company, nor as the adoption or promulgation of any guidelines, standards or recommendations. Some names have been changed to protect the innocent. This product is meant for educational purposes only. Some assembly required. Batteries not included. Package sold by weight, not volume. Contents may settle during shipment. No user-serviceable parts inside. Use only as directed.

Do not eat. Not a toy.

Postage will be paid by addressee. If condition persists, consult your physician. Subject to change without notice. Times approximate. One size fits all. Colors may, in time, fade. For office use only. Edited for television. List was current at time of printing. At participating locations only. Keep away from fire or flame. Avoid contact with skin. Sanitised for your protection. Employees and their families are not eligible. Beware of the dog. Limited time offer. No purchase necessary. Not recommended for children under 12. Prerecorded for this time zone. Some of the trademarks mentioned in this product appear for identification purposes only. Freshest if eaten before date on carton. Subject to change without notice. Please allow 4 to 6 weeks for delivery. Not responsible for direct, indirect, incidental or consequential damages resulting from any defect, error or failure to perform. Slippery when wet. Substantial penalty for early withdrawal. For recreational use only. No Canadian coins. List each check separately by bank number. This is not an offer to sell securities.

Read at your own risk. Ask your doctor or pharmacist. Parental guidance advised. Always read the label. Do not use while operating a motor vehicle or heavy equipment. Do not stamp. Breaking seal constitutes acceptance of agreement. Contains non-milk fat. Date as postmark. Lost ticket pays maximum rate. Use only in well-ventilated area. Price does not include taxes. Not for resale. Hand wash only. Keep away from sunlight. For a limited time only. No preservatives or additives. Keep away from pets and small children. Safety goggles required during use. If rash, irritation, redness, or swelling develops, discontinue use. Do not fold, spindle or mutilate. Please remain seated until the web page has come to a complete stop. Refrigerate after opening. Flammable. Must be 18 years or older. Seat backs and tray tables must be in the upright position. Repeat as necessary. Do not look directly into light. Avoid extreme temperatures and store in a cool dry place. No salt, MSG, artificial colouring or flavoring added. Reproduction strictly prohibited. Pregnant women, the elderly, and children should avoid prolonged exposure to this product. If ingested, do not induce vomiting. May contain nuts. Objects in mirror may be closer than they appear. Do not use if safety seal is broken.

Warranty does not cover normal wear and tear, misuse, accident, lightning, flood, hail storm, tornado, tsunami, volcanic eruption, avalanche, earthquake or tremor, hurricane, solar activity, meteorite strike, nearby supernova and other Acts of God, neglect, damage from improper or unauthorised use, incorrect line voltage, unauthorised use, unauthorised repair, improper installation, typographical errors, broken antenna or marred cabinet, missing or altered serial numbers, electromagnetic radiation from nuclear blasts, microwave ovens or mobile phones, sonic boom vibrations, ionising radiation, customer adjustments that are not covered in this list, and incidents owing to an airplane crash, ship sinking or taking on water, motor vehicle crashing, dropping the item, falling rocks, leaky roof, broken glass, disk failure, accidental file deletions, mud slides, forest fire, riots or other civil unrest, acts of terrorism or war, whether declared or not, explosive devices or projectiles (which can include, but may not be limited to, arrows, crossbow bolts, air gun pellets, bullets, shot, cannon balls, BBs, shrapnel, lasers, napalm, torpedoes, ICBMs, or emissions of electromagnetic radiation such as radio waves, microwaves, infra-red radiation, visible light, UV, X-rays, alpha, beta and gamma rays, neutrons, neutrinos, positrons, N-rays, knives, stones, bricks, spit-wads, spears, javelins etc.).

Other restrictions may apply. Breach of these conditions is likely to cause unquantifiable loss that may not be capable of remedy by the payment of damages. This supersedes all previous disclaimers

On Fri, Apr 19, 2024 at 10:17 AM Ben Meadors @.***> wrote:

At the moment it seems any node in the mesh can administer any other node with admin channel with the same key configured.

Yes, channels are only secured by symmetric encryption. This is how all of the traffic in meshtastic is encrypted. If we make a special provision for admin channels, other private channels would still be "vulnerable".

— Reply to this email directly, view it on GitHub https://github.com/meshtastic/firmware/issues/2610#issuecomment-2066790757, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABIHQQAOVWBN2W3FE3UGGWDY6EYQPAVCNFSM6AAAAAA2JU4I7WVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANRWG44TANZVG4 . You are receiving this because you commented.Message ID: @.***>

[jhollowe]

I know this wouldn't work for devices without GPS (or a network time source), but something like a per-node TOTP token (likely in addition to a nonce) would provide an easy-to-use method of different authentication per node and would use the authenticator apps people already use.

But ideally, we could just have public/private keys. The nodes have a (or list of) trusted keys which are allowed to edit admin settings. I do think separating the "physical" layer encryption of the channel and the encryption/authorization of the admin commands is a good idea.

[EternityForest]

Allowing different "config presets" stored on the app, not the device, that you could select without rewriting and wearing out flash, could have a lot of other uses.

Admin channels really need authentication, but ideally a lot of other things would be authenticated as well.

Seems like it would be easy to add a variable length optional MAC field to the packets, to give 8/16/32/64 bit encryption depending on the security level required, and prevent replays with some basic time sync. I started a thread here:https://meshtastic.discourse.group/t/is-the-encryption-authenticated-and-replay-resistant-are-there-any-plans-to-make-it-so/9126 but it didn't get much interest.

The core idea is basically to keyed hash the message plus the current time(rounded to 5 minutes) to produce a MAC, and accept the current or the next closest MAC to handle the transitions.

To actually set the time, you mark certain channels as trusted time sources, and then just listen for sync messages, which must themselves be authenticated.

If you haven't got a time sync in a few days, you fall back to allowing unauthenticated messages to re-sync, or you just wait for someone to manually fix it.

If you need replay protection even within the 5-10 minutes window, you add a counter field. Once you get a message with a counter field, you don't listen to any more authenticated messages unless they have an incremented counter, until the next 5 minute MAC window.

The counter only needs to be 1 byte, and the MAC itself only needs to be 24 to 32 bits, especially if there's a timeout on invalid MACs.

If you stuff the counter and mac together in one uint32, you only need one extra protobuf field.

This would also give the possibility of authenticated chat and command messages, which I think is a super big deal for relay controls and the like.

[cyberorg]

For now I am using this workaround:

• Set different keys on each remote nodes
• Maintain a file with those keys and node names(it would be convenient if this was builtin meshtastic app.)
• Change the key needed on any node from which we need to administer them and revert when done.

[EternityForest]

@cyberorg That seems like it would be a perfectly good long term solution if the UI supported it with a switcher menu in the app