textfiles/programming/CRYPTOGRAPHY/arrl.txt

Original Message Date: 05 Jun 91  08:21:13
From: Uucp
To: Tom Jennings
Subj: BBS mail and encryption...
^AINTL 1:125/111 1:125/111
From  kumr!pozar
From: pozar@kumr.LNS.COM (Tim Pozar)
To:   fidosw!Tom.Jennings
Date: 5 Jun 91 00:21:09 PDT (Wed)
Cc:   hoptoad!gnu

   Found this on the net...  Funny how we were just talking about this...

                      Tim
---
Article: 381 of rec.radio.amateur.packet
From: karn@epic.bellcore.com
Newsgroups: rec.radio.amateur.packet
Subject: Thoughts on BBS authentication
Message-ID: <1991Jun4.174323.1084@bellcore.bellcore.com>
Date: 4 Jun 91 17:43:23 GMT
Sender: usenet@bellcore.bellcore.com (Poster of News)
Reply-To: karn@epic.bellcore.com ()
Organization: Bell Communications Research, Inc
Lines: 304

I've had several requests for the "white paper" on cryptographic
authentication of BBS messages that I wrote recently in response to a query
by Paul Rinaldo, W4RI, of the ARRL. Paul is the chairman of the ARRL <20>
Digital
Committee, of which I am a member.

In case anybody can't tell, the opinions expressed here are my own.
--Phil

Paul,

This is in response to your request to the Digital Committee for
comments on authentication schemes that might be used to verify the
source and integrity of a message posted to an amateur BBS network.
This letter consists of a quick tutorial on the various forms of
cryptographic authentication, some personal judgements about their
practicality and suitability for the problem at hand, and some personal
opinions on the present regulatory situation.

The scheme that I talked about at the 1987 ARRL Networking Conference
was for authenticating IP datagrams using DES, but the same principles
apply to using any conventional secret key cipher to authenticate any
kind of message. (By "authenticate a message", I mean verifyng that the
message was in fact sent by the claimed sender, and that the message
contents have not be modified along the way.) Such schemes require all
the stations involved to share a single secret key.  Without the key
you cannot compute the proper authenticator for the messages you send,
nor can you verify an authenticator received with an incoming message.

The difficulty of key management with a conventional cipher can range
from "trivial" to "intractible" depending on the application. Key
management is simple as long as there are only a few stations that need
to generate or authenticate messages, and all trust each other. For
example, a DES-based scheme could be applied to a repeater to limit
remote control to a few trusted stations. A single key known to the
repeater would be shared by the control stations and kept secret from
everyone else. An in-person meeting or the telephone would suffice for
distributing the DES keys.

Now consider cases where the operators do not necessarily trust each
other, e.g., autopatch operation. Since many more stations use an
autopatch than control the basic operation of the repeater, its owners
may want individual accountability. A DES-based authentication system
could still work if each user has his or her own key. The same system
could be used to control access to a BBS. In either case, the "server"
(the repeater or BBS) keeps a complete list of keys for all authorized
users and logs each access. This is more work than the previous case,
but it is still entirely practical.

Common to the all these schemes so far is the assumption that only the
server needs to authenticate a request, e.g., the repeater controller
or the BBS. It must protect its users' keys against unauthorized
disclosure, but since the resource being protected by the authentication
system is the server itself, the owner of the server has an incentive
to do this.

But in the more general case where individual pairs of stations must be
able to authenticate each other, things get much more complicated. Each
pair has to have a key that is known only to that pair; if you have N
stations, you need a total of N^2 keys. All these keys must be
exchanged by some secure means before authentication can occur, and
they must be kept secret. To do this for every pair of amateurs in the
world is clearly impractical. And if you want *any* amateur to be able
to verify the authenticity of, say, a broadcast BBS message (to carry
on the amateur "self-policing" tradition, of course), there is *no*
solution using conventional cryptography - the same key needed to
verify a message could be used to forge one.

Some form of secret key authentication might still be practical between
neighbors in a packet backbone or a BBS autoforwarding network. But
this would only authenticate your immediate neighbors; it would not
authenticate the origins of the traffic they pass from other nodes. For
example, one BBS sysop could create illegal traffic and then pass it to
a neighbor claiming that it originated somewhere else, and there would
be no way to disprove this. So you really do want the authentication to
be "end to end", not "hop by hop", and we're left with an unsolved key
management problem.

One way to reduce the N^2 key problem is to establish a "key
distribution center" that maintains a list of all the users' private
keys. Users wishing to authenticate themselves to each other do so by
first authenticating themselves to the KDC. The KDC then generates a
"session key" (a random number) and sends it to the two parties
encrypted in their own keys. The parties then decrypt the session key,
yielding a shared secret that can be used for authentication. Still,
only the parties involved can authenticate each other; someone
listening in could not. (In most environments, this is an advantage;
somebody else's conversations are none of your business.)

MIT has developed a system based on this model called "Kerberos"; it is
in operation at MIT and elsewhere (the code is free). Nevertheless, it
has the drawback that authentication depends on the availability and
reachability of the KDC. But the fact that the KDC must have a complete
list of the users' private keys works against deploying multiple KDCs
with copies of the database for redundancy; the more KDCs there are,
the more opportunities for the database to be compromised. The scheme
also assumes that all of the parties (the two users and the KDC) have
the ability to communicate with each other in real time, a bad
assumption for amateur packet radio.

So the inescapable conclusion is that authentication schemes based
solely on private key cryptography are of limited utility in amateur
packet radio; they cannot solve the general problem. Fortunately, there
is a new alternative: public key cryptography (PKC). In PKC, the keys
used for encryption and decryption are different. Furthermore,
knowledge of the encryption key, Ke, does not imply knowledge of the
decryption key, Kd; in fact, the algorithms ensure that it is extremely
difficult to determine Kd from Ke. The combination of Ke and its
corresponding Kd is called a "key pair"; for this reason, public key
cryptosystems are sometimes called "dual key" ciphers, as opposed to
"single key" ciphers like DES.

The leading public key scheme, RSA, was invented by Ron Rivest, Adi
Shamir and Len Adelman while at MIT. They hold a US patent on it that
is being exploited by RSA Data Security, Inc. (There is no patent
protection on RSA outside the USA).

The original idea behind RSA was to allow you to publish Ke (hence the
name, "public key" cryptography) so anyone could send you a secret
message without prior arrangement.  As long as you keep Kd secret, only
you can decrypt it. But when used "backwards", RSA can also do
authentication. If you encrypt a message using Kd (your DECRYPTION key,
known only to you), then anyone can decrypt it using your Ke (your
public ENCRYPTION key). Anyone who decrypts such a message then knows
that whoever generated it must have known your Kd. This procedure of
using RSA in reverse is called "signing".

In practice, it is not desirable to run an entire message through RSA
to authenticate it because it is very slow, much slower than secret key
ciphers like DES.

There is a better way. Functions exist to quickly "hash" a message of
arbitrary length into a relatively small, fixed size "message digest".
They are much like cyclic redundancy codes (CRCs) except that they are
much more complex because they are designed to detect intentional
"transmission errors" as well as natural ones.  With a good function,
it is computationally infeasible even for someone who knows it to
produce two messages that hash to the same value, or to determine the
input that produces a given value. They are not ciphers, because they
have no key and their outputs cannot be "decrypted".

One message digest algorithm is MD4 ("message digest #4") by
Ron Rivest, who has placed it in the public domain. MD4 takes a message
of any length and produces a 128-bit (16 byte) result. Rivest
conjectures that it would take on the order of 2^64 operations to find
two inputs that hash to the same value, and 2^128 operations to find an
input that hashes to a given value. These are impressive numbers, so if
the algorithm holds up under analysis it should be quite secure in
practice.

Given RSA and MD4, one authenticates a message by first computing its
hash code with MD4. Then RSA is used to "sign" the hash code (by
encryption with the sender's private key, Kd) and the result is appended
to the message. The party wishing to authenticate the message also
computes the message digest. It then decrypts the encrypted message
digest received with the message (using the published key of the
sender, Ke) and compares it to the value it has just computed. If they
match, the message is genuine.

There still remains the problem of distributing the public keys.
Although they may be freely read by anyone, they must still be
protected against modification. Otherwise someone might forge a
signature of a message under someone else's name using a public key/
private key pair of his own creation; if the receiver can be duped into
accepting this bogus public key, then he will believe that the
signature is genuine.

One way is to publish the public keys as widely as possible, in so many
places that no one could possibly modify all of the copies of a
particular key that reach the intended target of a deception. For
example, the keys could be published on CD-ROM, or they could be listed
in the back pages of QST. But these schemes have two drawbacks: cost
and time.

Another refinement, "certification", addresses this problem. If a
"certifying authority" can be set up to sign the public keys of
individual users with its private key, then only the public key of the
certifying authority needs to be widely published. For example, the
ARRL might select and publish its own public key in QST. It could then
accept public keys from individual amateurs (accompanied with some
non-cryptographic form of authentication, such as a notarized
statement). The ARRL would sign the individual public keys with its
private key and return the results. Note that the ARRL need NOT know
the individual's private keys.

The signed public keys are known as "certificates". They can be
distributed by the users themselves (e.g., in a mail header) because
anyone can readily verify their authenticity with the published ARRL
public key. This eliminates the need for an online KDC. The ARRL's
workload might be a problem, but a solution exists for this too: a
hierarchy of certifying authorities. For example, each League Division
might act as the certifying authority for the amateurs in its area,
using a Division public key that has been certified by ARRL HQ.
Divisions might further delegate the workload to their constituent
Sections. The verification of an individual user's certificate would
therefore require the certificates of all of the certifying authorities
in the hierarchy as well as the published key of the ARRL.

So in theory, anyway, authentication based on public key cryptography
solves many of the problems associated with the earlier secret key
schemes. However, many practical obstacles would still remain:

1. The RSA algorithm is patented in the USA, and the owners of the
patent are holding it fairly close to their chest. Negotiations between
RSA and the Internet Activities Board (IAB) have been dragging on for
several years now over an agreement for the use of RSA in the Internet.
It is not at all clear how much the patent royalties will be, or how
they will be charged. (The leading theory is that the royalties will be
tied only to the issuance of certificates, not to the actual
implementation or use of RSA, but this is not yet final.) Would the use
of RSA in amateur packet radio (resulting in the payment of royalties
to RSA DSI) be considered as furthering the "regular business affairs"
of RSA DSI? (Hopefully not, but considering some of the FCC rules
interpretations we've been seeing lately...)

2. The algorithms are, by amateur standards, quite complex. At a
minimum, they would probably require every amateur to have a PC-class
computer to hash and sign messages. Given that a major reason TCP/IP is
still a relatively esoteric mode in amateur packet radio is the
reluctance of many amateurs to upgrade from C-64s and "dumb terminals",
it seems unlikely that universal user authentication could happen any
time soon. And I won't even *begin* to discuss the user education
issues.

3. Even if a full-blown RSA-based authentication system as described
earlier could be deployed, it is not clear that it would solve the
specific problem that originally prompted your query. Someone accused
of posting an illegal message to an amateur BBS could still claim that
his secret key had been stolen and used by someone else. Or he could
accuse the local "Section Certification Manager" of signing a bogus
public key with his callsign on it and using it to "frame" him by
sending verboten traffic. Even if a key really has been stolen and the
owner notifies the certification authorities, how do they spread the
word that the previously distributed public key is no longer valid?
These issues are still the subject of much discussion in the research
community. Furthermore, this technology has yet to have its first test
in a court of law.

In sum, although I find cryptographic authentication to be a
fascinating topic that has some potential for use in amateur radio, I
do not feel that it is "ready for prime time". Mandating its use at
this time would be an enormous overreaction to the "problem" of
controlling inappropriate BBS traffic.

Quite frankly, the FCC's heavy-handed behavior in this case has me
greatly concerned. I think they're going after a fly with a battleship.
I do not know whether they sincerely believe that they're "protecting"
amateur radio or if they have some more sinister motive. I can only
hope for the former, so we can reason with them.  Every new development
carries with it some risk of abuse; the more powerful the technology,
the greater the risk. Amateur packet radio is no exception; even in its
presently primitive state, it is useful enough to tempt some commercial
entities to abuse it. We should be able to convince the FCC that
requiring unrealistically stringent mechanisms to prevent even the
occasional commercial abuse of amateur packet radio runs the far
greater risk of destroying all of the good that it can do.

Lately, several of us (WA8DZP, K3MC, N6RCE, NG6Q and I) have been
taking a close look at the low power spread spectrum modems that are
rapidly becoming available for use under Part 15 rules on 902-928 MHz
and other shared ISM/amateur bands. In my own opinion, building high
speed (say, 100-500kb/s) metropolitan area networks under Part 15 rules
seems entirely feasible, even with the 1W power limit - given proper
design and engineering (good sites, directional antennas, power
control, efficient channel access methods, etc). True, the performance
of the existing generation of equipment is disappointing, mainly due to
the lack of receiver processing gain in most models. But with the new
FCC rules mandating the use of "true" spread spectrum receivers, plus
the commercial drive behind this industry, it seems likely that the
cost/performance ratio of this equipment will rapidly improve.
Unfortunately, the same probably cannot be said for amateur packet
radio gear, where the large scale production of inexpensive, high speed
radio modems seems as far away as ever. Hence our initial interest in
this technology.

But this latest blow from the FCC is making Part 15's complete absence
of licensing requirements, content and/or usage restrictions look
mighty attractive indeed - even though my primary intent is to use the
network for the kind of personal experimentation that has traditionally
been done in the amateur service. Are the FCC's rules really
"protecting" the amateur service if they scare off those who are most
interested in making technical contributions to the service?

I think it's time that the FCC not only remove the burden of
responsibility for content from automatic relay stations, but that it
loosen up its draconian definition of "business communications" as
well. A lot has happened to the telecommunications industry since the
Eyebank Docket; in particular, it is certainly no longer the job of the
FCC to protect a telephone company from "lost business". The amateur
rules should be pragmatic, with the realization that absolute
prohibitions do far more harm than good.

A simple "hams shalt not sell communications services" rule should
suffice to make any abuses self-limiting, as few hams I know would be
willing to use their time and their stations to help make money for
others if they didn't get a cut of it. Such a rule would be far clearer
than the present "no business interest" rule. The current rule has
spawned an entire generation of armchair amateur lawyers who revel in
interpreting the rules in the most restrictive fashion possible. One
only need look at how the field of computer networking is pretty much
passing amateur radio by to see the chilling effect of the present rules.

73,

Phil Karn





X-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-X
 Another file downloaded from:                     The NIRVANAnet(tm) Seven

 & the Temple of the Screaming Electron   Taipan Enigma        510/935-5845
 Burn This Flag                           Zardoz               408/363-9766
 realitycheck                             Poindexter Fortran   510/527-1662
 Lies Unlimited                           Mick Freen           801/278-2699
 The New Dork Sublime                     Biffnix              415/864-DORK
 The Shrine                               Rif Raf              206/794-6674
 Planet Mirth                             Simon Jester         510/786-6560

                          "Raw Data for Raw Nerves"
X-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-X