[Cryptography] OpenPGP and trust

Stuart Longland stuartl at longlandclan.yi.org
Sat Apr 5 03:28:12 EDT 2014


Hi all,

I've been a bit busy over the last week so I haven't posted back until
now.  That said I've been giving this further thought.  I hope this
is a lot clearer than my last attempt at explaining this. :-)

A couple of you, reasonably ask: what is it that I'm trying to do
*exactly*.  What is this "system" and who are the "users" of this
system?  What are these users doing?

A reason why I haven't been specific on this, is because while I have a
use-case in mind, I note there are possibly several scenarios that I'd
like to be able to cater for.

So without further ado, let's consider a simple case.

I have a messaging system, wherein people can post and retrieve mail.
Some of this is going to be group messages (i.e. like this mailing list,
which I'm accessing via Gmane/NNTP), some will be private messages.

I'm considering two interfaces for this system: one on AX.25 packet
radio operating at a speed of 1200 baud, the other over the Internet.
I'd like the system to remain operable without an Internet connection:
that is, the Internet interface is merely an access point, it does not
rely on this for authentication of any kind.

There's software already out there for implementing such systems.
Bulletin board systems are still around, although I'm finding they don't
play so nice with modern OSes -- however I digress.  The system I build
this on is likely going to be UUCP based: if it helps, consider the BBS
as being UUCP with slightly specialised 'rnews'/'rmail' commands.

A lot of these either prompt for a user name, or in the case of packet
radio, it can derive a user name from your station ID sent in the
packets.  They either take this username at face value, or some will
prompt for a password, in clear text.  The user "registers" with the BBS
on their first log-in, which creates the account.

For Amateur Radio BBSes, this usually must be done over the radio.  This
has the useful side-effect that (ignoring impersonation) you then know
that person has a radio license.  For Internet access to the BBS, one
must then contact the operator and have a password/privileges assigned.

There are two problems with this:

(1) the person concerned must either have the equipment to connect to
    the BBS via radio, and a suitable RF path.

(2) it doesn't actually identify that the person who connected actually
    holds the call-sign they used to connect.

The latter is a problem if for whatever reason, someone who might have
reason to access the BBS, cannot do (1), or if that person has a need to
do privileged tasks.

It's also a problem even without special privileges: nothing stops a
miscreant from impersonating you logging into the BBS (even via RF) and
deleting messages before you get a chance to read them, or posting
messages that stir up trouble.

If the BBS is connected to the Internet (and I intend to do this), for
legal reasons, I've got to be able to prove that the person on the
Internet is actually licensed to use amateur radio bands.  On radio, I
can take the call-sign from the packet header at face-value, but would
rather not.

There are ways people have tried to solve this:
- ARRL LogBook Of The World:
  https://lotw.arrl.org/cgi-bin/lotw_page_auth/default uses CA
  certificates, which are issued after proving to the ARRL you hold that
  callsign
- QRZ.com, HamQTH.com call-sign databases
- The DIY approach

EchoLink (an example I posted earlier) does the DIY approach: you scan
in the license and email that to them.  That piece of paper has amongst
other things, your home address.  Some might be uncomfortable with this.

The first two require that the system doing the authentication has
access to the Internet.  The ARRL system being probably the best system
out of the two, but requires TLS.  I'm not sure how effective the
database look-up is at QRZ.com at authentication.

I know of one site that uses HamQTH.com and merely checks that the
call-sign exists: it does no actual *authentication* of the user (and
HamQTH do no actual checking, anyone can sign up).

For the BBS I'm proposing to set up, the primary user group is going to
be people in our emergency comms group.  Most of us meet face-to-face on
a monthly basis, and so verifying that we're all licensed and hold the
call-signs that we use over the air isn't a problem.

In fact, I set up an OwnCloud instance for this group, and issued
passwords to the group by email.  The service optionally accepts
connections via TLS, and I encourage its use, but also allow clear-text
as it uses a self-signed certificate and some of the users aren't
terribly technical.

The OwnCloud system has a messaging interface, and I'm considering ways
I can make some of that content on OwnCloud accessible via a packet BBS,
particularly the messaging system.

I could have the users supply the password they use to log into OwnCloud
over packet radio, but then they've just given away their log-in
credentials over a clear-text link.

I'm considering asymmetric cryptography using digital signatures as it
provides another way.  They can generate a private key themselves, and
share a public key via the OwnCloud site, then use their private key to
sign responses to challenge messages sent by the BBS when they try to
log in over packet.

>From this perspective, there are a number of ways I can go about this.
Seeing as there's at least 2 ways to implement digital signatures using
standard off-the-shelf software, it seems ridiculous to try and attempt
it myself.  (Especially after my XOR-wish-it-were-Diffie-Hellman
attempt!)

Now I expand on the concept a little bit.

Suppose I wanted to allow any radio amateur operator to access the BBS.
Those who are in my emergency comms group authenticate with digital
signatures, and thus get the ability to see and post messages to our
group's specific message board, everyone else just sees the public
boards.

A select group authenticating with digital signatures can send arbitrary
commands and files the BBS computer, telling it to install some software
package or perform a reboot, etc.

Since I want the system to be as widely available as possible, I open an
interface on the Internet.  For argument's sake, say it's a Telnet port.

I want to be able to prove that the person registering over the Internet
is a licensed radio amateur.  Spam bots will just enter any old junk
until the system lets them in (or bans the IP), so just prompting for a
call-sign and doing a search for it on QRZ won't do: I actually want
some assurance that they are who they say they are.

Thus, I'm looking at the web-of-trust model, rather than the CA type
model as a means of identifying people who are in this wider "group".  I
brought up OpenPGP as I knew it had a web-of-trust model, and fits with
the ethos of re-using existing solutions rather than trying to forge
ahead with a completely new system.

The thought is that: supposing myself and those around me all set up
certificates, we can verify each-others certificates and produce
signatures that basically say "I <whoever>, trust that this certificate
belongs to <name>".

As I understand it, in OpenPGP that's what signing a key signifies: "I
trust that key X belongs to person Y".

So supposing with my certificate, indicating me as holding the call-sign
VK4MSL, I meet up with another amateur Bob with the call VK4BOB.  We
check each-other's details and then sign each-others keys.  I tell the
computer running the BBS to trust any key I sign.

We part ways, and suppose Bob goes overseas, meets up with Alice over in
the US with the call KC0ALI, they check each-other's licenses and sign
each-others keys.

Alice should *then* be able to log into the BBS I have here: because I
trust Bob is who he says he is and that he does his checking properly;
and Bob trusts Alice is who she says she is.

If Alice were to connect, she'd have the option of either obtaining a
key from a key server, or supplying a public key.  The system could then
look for a chain of trust; if it finds one, guest-level access is
granted.  If Bob trusts Alice's checking of other keys, then anyone
Alice trusts, would similarly get access.

Are there any holes in my understanding on the web-of-trust, or issues
in the above scheme that I should be wary of?

Is it safe to use the presence of someone's trust signature in a key to
indicate the person's membership in a group or is this better stored
out-of-band?

Thanks in advance.
Regards,
Stuart Longland



More information about the cryptography mailing list