[Cryptography] OpenPGP and trust

[ianG]

On 5/04/2014 08:28 am, Stuart Longland wrote:
> 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.


One question:  Over both or either can we sent OpenPGP messages?  For
example, this email, with an OpenPGP plaintext signature affixed?

(What I thought you were asking for was two hams to auth each other over
radio.  Which would have meant being able to send a short word, get one
back, and do that in both directions.  This is called a
challenge-response.  It is entirely possibly, but OpenPGP does not
specify such a technique, so it would have to be hacked in.  At least I
don't think it does...)


> 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.


Do you mean,

...
> 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.


Do you mean, someone might just copy the call-sign?

> 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

By this you mean, individuals can request client certificates?


> - 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!)


No, you should not implement digital signatures yourself.

(and I'm the guy that generally advises programmers to give it a go ;)


> Now I expand on the concept a little bit.
> 
> Suppose I wanted to allow any radio amateur operator to access the BBS.

*any* of them ... ok.

> 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.


OK, as a select group, you want to maintain a file that lists these keys.


> 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".

Well, not really.  It isn't written that way in OpenPGP.  In practice,
the tech does "the key X signed key Y" and the people imply stuff over
the top of that.

According to custom, there are two popular groups of signers.  There are
those who will sign a key on meeting a person.  These people will trade
fingerprints, look them up when back home, sign those keys and upload
the sigs or something.  In this former case, the names don't matter,
what matters is you met a person who says "this is my FP."  For example,
you might end up signing a key saying "Mad Max" or "Mickey Mouse."

Then there is another group of people that check the identity docs of
the person and see that it matches the name in the public key.  These
people will check that the name is held by that person, but they don't
do a thorough check.

Without knowing what the situation is, you can't rely either way.


> So supposing with my certificate, indicating me as holding the call-sign
> VK4MSL, I meet up with another amateur Bob with the call VK4BOB.

OK, so your key needs to name you as "Stuart Longland - VK4MSL" or
similar.  Or "Mad Max - VK4MSL" ... so far.

> 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.


So, the missing link here is that you sign Bob's key with an implied
"can access computer" statement.  Or, you take a record of that key and
install it manually into the file (so far I'm seeing this latter idea).

> 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.


Ah.  So, how far does the accepting go?  Do you accept Alice's sister
Malice, as Alice turns out to sign anyone's key any time she likes?

Assuming that we're only talking about two layers here, you then the Bob
layer then the Alice layer, what you have is this:

   your sig says "accept this key to grant access to others"

and

   access grantor's sig says "accept this key to access machine"

OR, completely different, the signature only makes this statement:

   "this key has a radio licence as per the name."


> 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.

Hmmm... viral 'trust'.  Nice in concept, but I don't know that you want
to go too far without a statement of some form.

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


lots :)

> 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?

Two problems - the group name and the statement of membership.

You can't really use any so-called trust signature for any purpose
without some form of written or agreed custom.

In PKI this is sometimes included in a CPS or Certification Practice
Statement.  This is potentially relevant if you're just able to survive
on the default CPS statement which is something like "CA checked some ID
docs of this person and decided they matched the client cert's name."
But this is rather unlikely because you're after something else:  some
mishmash of the following:

     has a radio licence,
     we know the radio licence number,
     has a call sign,
     we know the call sign,
     is a person,
     we know the name of the person,
     has been granted permission to use the machine,
     has met a certain person,
     is going to be a responsible member of the community,
     ...

(I'm only speculating here, but) the point is that you need to be
somewhat sure that you have this statement down, and you communicate it
to the grantors (Bob's?).

At this stage I'd suggest *you write down the statement you want*.

Then you need others to sign off on it -- that is, agree to it in
consensus, over beers, at your meeting.  Then, ideally you would need to
identify that statement with the name below.

Now, this gets tricky because OpenPGP doesn't let you WoT-sign a key
with a statement.  What you would need to do is add an additional UID (I
think) with distinct words in them.  For example, instead of your normal
name, you'd add something like an additional UID with words like
"AMATEUR RADIO KEY" in it.  (and fix your code to search for those words
in the sig checking.)

So all of that would end up with a UID like:

      "Stuart Longland - VK4MSL - ARK1.0"

Does that make any sense?  Now, ARK1.0 would then be by custom your
above Amateur Radio Key Statement, v 1.0, in which you would state what
your signature over the other person really signified.

Then, everyone who uses this document, and has been signed by someone
upstream, has agreed to the document and acts according to it.

In summary:

1.  Write the statement you want to have signers make.
2.  Add a UID into OpenPGP keys that signifies that statement.
3.  Teach everyone to follow the statement, when signing.
4.  Get your code to find those key/sigs.

(Some not unimportant details ommitted as we're still whiteboarding)



Also, you should probably have a look at CAcert, which does something
similar.  They run a PKI/x.509 style CA, with a web of trust, and with
(6000) assurers being those who are approved to check people's identity.
 These assurers could also be tasked to do various other tasks, such as
"check the radio licence" and then report back to others that "this
person has a radio licence", which statement can be affixed with CARS
meaning CAcert Assurer Reliable Statement, which you can then rely on as
a member of the community.  If it turns out to be false, you can
arbitrate against the Assurer.  The point being here they can do careful
checking, make the statements needed and send them on to you.  All in
theory.  They also do OpenPGP signing, which means you can get a general
sense of the person's name being correct, and also that you can find
them through the CAcert community.





iang