You are here

Login/Authentication over Ham Data Network (USA)

1 post / 0 new
KN6AXN
Login/Authentication over Ham Data Network (USA)

Because FCC Regulation 97.113 (a) 4 states that:
"messages encoded for the purpose of obscuring their meaning" are "Prohibited transmissions".

It is not possible to use encryption across any radio links.
So if you have a computer running at a remote location that provides any kind of service, for example:

  1. Web/HTTP
  2. Telnet/SSH
  3. FTP

What options are currently available for authentication, so that only authorized users are allow to log into the service?

Existing Solutions
This is really a two part question, the first part is asking if anyone has already developed any software/solutions to do this?
If so, could you point me in the right direction...




Future Design
If not, the second part of the question is more of a software design question, specifically what approaches to solve the problem would be viable.

Off of the top of my head, three approaches seem viable:

1.> Public/Private Key Signing
If both the server and client had known private and public keys, it would be possible to sign (not encrypt) all traffic moving in both directions.
This would mean that both sides (and anyone else with the public keys) could verify each packet sent was authentic (i.e.: from the person/server with the private key). As a result, it would not be necessary to log into the service, because the identity of the sender has already been proved.

2.> Pre-shared Secret
If both sides of the conversation have a "shared secret" in common, each packet could be transmitted which a checksum (say SHA256) that combines both the plain text data and the secret, as a result the authenticity can again be verified by both sides.

3.> DH Session Key
Similar to the previous suggestion, except that instead of using a pre-shared secret both sides can generate a session key using something like Diffie-Hellman, this key would again be used as a salt to the SHA-256 hash rather than for encryption. I realize that this final solution doesn't provide authentication by itself, but it might provide a more efficient solution, if combined with a public/private key solution to provide the original authentication.


Given that any software developed to do this would be placed into the public domain (so as not to obscure any transmissions generated by it) would there be any legal issues resulting from any of these strategies?

Is there a better approach than the ones I have suggested ?


Thanks,
David KN6AXN
 

Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer