You are here

Using private key signing and nonce/csrf tokens for administrative transmissions

2 posts / 0 new
Last post
km6kou
km6kou's picture
Using private key signing and nonce/csrf tokens for administrative transmissions

The FCC gets upset when you use encryption to secure or obscure broadcasts sent over ham bands.
This is a problem for remote administration of mesh nodes because it forces you to transmit messages in plain text over the air.
Plain text passwords are very bad because anyone with some decent infosec knowledge is able to setup rouge nodes that listen and record all login attempts.
This critically cripples the reliability of any mesh network that is working on ham bands.

After giving this considerable thought, I have a proposal that may allow some level of secure administrative control while also remaining compliant with the regulations set by the FCC.

This involves only accepting administrative requests that:
1. Are signed with a private key
2. The signed request can be verified
3. The public key for the message is trusted (saved as a verified admin key)
4. Use a csrf/nonce that is randomly generated and assigned by the node for each elevated request

It is important to note that this will not make the messages private!
People will still be able to see what you are doing.
This is intended to prevent people from modifying or replaying requests.

This will allow the node to verify if requests are coming from verified admins.
This will also allow the admin to verify that responses are coming from the node.
This is intended to replace all passwords used on ham bands.

What this will fix:
1. Replay attacks
2. Csrf attacks
3. Request modification attacks

*****************************
The Problem:
*****************************
Right now authentication is handled with basic auth. If I wanted to change an important setting, the simplified transmission may look something like this:

[
message,
Authorization: Basic cm9vdDpyb290
]

You can base64 decode "cm9vdDpyb290" to reveal the username and password. In this case, it was root:root.

Anyone listening to the transmissions going on at the time would now have your login credentials.
They now own your node. Not cool bro.

*****************************
The Potential Solution:
*****************************

Identify request modification attacks:
You generate a private key and give the associated public key to the node.
Tell the node to ignore any administrative request that cannot be verified using the public key you uploaded.

Generate a private key for the node.
Make a copy of the node's public key.
You should ignore any response that cannot be verified using the node's public key.

Congrats, you and your node have exchanged public keys and can now verify each other's identity!
This should all be done when you are first setting up your mesh node.
This is important because it'll tip you off if someone tries to mess with your communications (such as cheeky mitm attack).

Prevent replay attacks and csrf:
Every time an administrative settings page is requested, have the node attach a csrf token in the reply
(only allow the csrf token to be accepted once to prevent replay attacks)
(make the csrf token random to prevent csrf attacks)

Here's how you would now change an administrative setting (this would replace the use of passwords and basic auth):

USER'S GET REQUEST:
[
message,
user sign(hash(message)),
user public key
]

NODE'S RESPONSE:
[
csrf token,
message,
node sign(hash(csrf token + message)),
node public key
]

​USER'S POST REQUEST:
[
csrf token,
message,
node sign(hash(csrf token + message)),
node public key
]

If everything checks out, the node does what you asked.

What do you think? Feel free to reach out!
mike@lemonshell.com

AE6XE
AE6XE's picture
This is a great option.  We
This is a great option.  We'll connect up separately. 

Joe AE6XE

Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer