Oliver, DL7TNY
Peter, OE1LFB
Thomas, DL9SAU
Jann, DG8NGN
44Net List
-------- Forwarded Message --------
Subject: Re: [44net] 33rd DCC 2014 Proceedings Papers online
Date: Thu, 11 Sep 2014 12:40:53 +0200
From: Jeroen Massar <jeroen@massar.ch>
Reply-To: AMPRNet working group <44net@hamradio.ucsd.edu>
To: AMPRNet working group <44net@hamradio.ucsd.edu>
Thanks for the preso and more importantly the work done on Hamnet!
Are there more details about the "Authentication platform"? I might have
some input on that based on a variety of projects... ;)
-------- Forwarded Message --------
Subject: Authenticating hams on the internet
Date: Tue, 30 Aug 2016 23:14:43 +1200
From: Ross Whenmouth <ross@topwire.co.nz>
To: dg8ngn@darc.de
Hi Jann,
In response to your paper presented at TAPR DCC2014 on the European HAMNET:
https://www.tapr.org/pdf/DCC2014-TheEuropeanHAMNET-DG8NGN.pdf
On the last page, you asked "How can I authenticate radio amateur operators?". I would like to suggest that X.509 certificates could be used for authentication - see:
http://blog.algoram.com/blog/2015/06/19/using-the-arrl-logbook-of-the-world-certificate-to-validate-yourself-to-web-services-as-a-licensed-radio-amateur/
As mentioned on the above site, the ARRL is already issuing X.509 certificates to hams as part of their "Trusted QSL" program (part of LoTW - "Logbook of The World". To gain a certificate, I had to install and run the TSQL software to request a new certificate, then send a snail-mail letter to the ARRL containing a photocopy of my passport and amateur radio licence. The ARRL has also stated that they would like to see other (amateur) organisations around the world become certifying authorities.
Thus, for a "hams only" service facing the internet (packet BBS?, VPN/IP tunnel?, remote radio control?, etc), access should be able to be controlled on the basis of whether the client has a valid certificate signed by a recognised CA (DARC?, ARRL, RSGB?, NZART? etc)
Certificates could even be used for authentication of data sent over the radio (the meaning of the message is sent in the clear != encryption) eg something like
[START][MYCALL][Cleartext_message][NONCE][SIGNATURE][END]
[MYCALL] is used as the database key to find my certificate/public key.
The [NONCE] is a changing number, used to prevent replay attacks (if I send the same message more than once, it has a different [NONCE] each time so a receiver can be sure that I intended to send it more than once).
The [SIGNATURE] is a cryptographic hash (eg SHA) of [MYCALL][Cleartext_message][NONCE] which is encrypted with the private key for my certificate (please note that this does not obscure the "meaning of the message" - ITU rules etc).
Anyone who receives the message can calculate the hash themselves SHA([MYCALL][Cleartext_message][NONCE]). Anyone who has my public key can "decrypt" the [SIGNATURE] and check that it matches the SHA hash that they calculated themselves (match means that message is authentic).
If you do not have my certificate, but you do have the CA's public key, then I (or anyone else) can send my certificate to you and you can check that it is valid:
[MYCALL][my_publickey][CA_ID][Expiry_date][Signature]
Again [Signature] is a hash of the message which is encrypted with the CA's private key.
If you have the CA's public key, you can decrypt the signature and check that it matches the locally generated hash eg
if (decrypt(signature, publickey[CA_ID]) == sha([MYCALL][my_publickey][CA_ID][Expiry_date]))
then you know that my certificate was signed by the CA and thus [my_publickey] is valid and can be used to authenticate my messages.
73 ZL2WRW
Ross Whenmouth <ross@topwire.co.nz>