Protection of the Amateur Radio Packet Network
by the use of Digital Signatures
by
G8DHE
9 September, 1995
This paper sets out a solution to the problems of message alteration and user identification that has plagued the amateur radio networks since there inception. It describes, what needs to be achieved in order to accomplish this, and that a substantial part of the work has already been achieved. It explains why the use of encryption is not an issue in the proposed use of the system, despite the association of digital signatures and public key systems with encryption. Finally assistance is sought in customising existing software.
For many years now the Amateur Radio Packet Network has operated under the problem of being unable to prove satisfactorily that a given User is the legitimate owner of the callsign that is being used. This problem has meant that the licensing authorities in all countries have required that the Bulletin Board System (BBS), System Operator (Sysop) take on the responsibility of checking and verifying the content of traffic passed through the system does not contravene the licensing regulations. This is seen by Sysops as an added burden to their work of maintaining a BBS, but at the same time a severe risk to their own licence if not carried out to the best of their abilities.
In order to overcome some of these problems a series of solutions have been put forward in the past attempting to ensure that the identity of a User is not in question, this would then enable the regulations to be applied to the originator of the message and not on the Sysop at the point of entry to the system. With the increasing number of Users and volume of data being passed this is becoming increasingly difficult - if not an impossibility to control!
The main method of protection to date has been the use of password systems, either of the simple challenge type or of the one-time pad system. The former system is not sufficiently secure and the latter pose's problems in supporting and using the system. The only improvement on these schemes would be to use a full challenge system with individual algorithms allocated to each user. However, given the type of connection used, it is possible that an attack on the link can be mounted after a successful password or challenge exchange has taken place, thus rendering any password system ineffective.
The new weapon in the Sysops armoury is the use of Digital Signatures. These are capable of proving both the originator of a message and also the messages integrity as it passes around the network. Obviously to be accepted by the authorities the system must be shown to be accurate and to be usable by all the stations and BBS. Only then will it be possible for the regulations to be modified so that the originator of a signed message, and not the Sysop of the BBS, can be held responsible.
In order to understand the proposed system it will be necessary to describe and explain the use of several new concepts (to the majority of readers). In addition this understanding must be conveyed to the Users, the licensing authorities and the legal authorities in order that the desired regulatory changes can be brought about. This paper sets out to achieve the first two aims by first describing the elements of the system in simple terms for the possible users of the system and for the licensing authorities. A more detailed description of the individual elements of the pr
oposed system will be generated in response to discussion on the network and to the needs of the those involved in creating the neccessary software.
There are several elements to the system:-
1. Message Digests.
2. Public key encryption systems ,
(please don't all shout
at once read on first!).
3. Digital Signatures.
3. Key security and management.
4. Key Servers.
5. Digital Signature servers.
Each of these elements will now be described and then finally the entire mechanism can be put together to explain how the system works. At this stage it should also be stated that the elements of the system already exist and are in extensive use throughout the world. The most popular implementation being called Pretty Good Privacy (PGP). This implementation of the necessary code has been released into the public domain and can be used legally throughout the world. The additional coding required is merely that of integrating the code with existing BBS and Terminal software so that its use is automated.
Finally, what about the dreaded word encryption? Whilst Public key encryption systems such as PGP can be used to encrypt messages so that they become secret codes, this is NOT the facility that is being used. The facilities of Message Digests and the use of public keys systems is being used not to hide the meaning of a message but in this case to aid its successful transmission across a network - the PGP system is extensively used in this way already, its association with encryption is problematical in our desired use not because encryption is used but merely by its association with, and origins in, cryptographic techniques! In the proposed use of PGP the message contents remain in plain text, and a small amount of extra data is added in a section of its own (the signature) that ensures that the message cannot be altered without being detected and that its originator can be uniquely identified. If either section, message or signature, is altered then this can be identified and the message trapped.
A message digest, is a mathematical representation of a message that can be used to identify changes in the message text. This is a very similar concept to both "parity bits" and "checksums" that are used to identify errors in small amounts of binary data and which are used in each and every packet that is sent. A message digest has the ability however to identify ANY change in the original message, unlike parity and checksum systems that can only provide protection to a limited degree and may not identify all errors. There is of course a penalty to pay for this added protection and that is the size of the message digest, in the case of PGP a 128 BIT digest is used (16 Bytes), this is a very small price to pay for the added protection! The digest itself is merely a binary number which protects the message content, it cannot, on its own, identify who sent the message.
These are normally associated with encryption techniques used to hide the meaning of messages. However, encryption is not their only use. They can also be used to code or protect a Message Digest in such a way that anybody holding the public half of the key can decode the Message Digest and thus prove beyond doubt who the originator was and then that the message has not been tampered with.
Public key systems, are a method of creating a pair of numbers that are used as keys, one half of the pair is held securely by the person who wishes to be identified - this key is known as the private key. The second key is distributed widely so that anybody who wishes can obtain a copy of it - this key is known as the public key. In addition a Key ID is created, this is just a part of the public key (last 64 bits) this is used to identify the full public key on reception of a message so that the message can be checked.
Once a pair of keys have been generated, the public key needs to be disseminated widely along with the Key ID, and the identity of its "owner" needs to be assured. This is the role of Key Servers. These are systems which hold a copy of public keys.
A Digital Signature consists of a Message Digest, a Key ID and the Time and Date stamp of the actual message signature. The Message Digest element is first coded using the senders Private Key. This ensures that nobody can later forge a new Message Digest, but that everybody is able to decode it as the Public Key is available to all who need it. The result is then concatenated with the Key ID and Time & Date stamp of the key. This allows you to identify who sent the message and also to ensure that the key used to sign the message is a valid one.
As with all keys their effective use for security purposes relies totally on who has access to them and also on knowing the right key to use. The major difference between mechanical keys and electronic keys of the type being discussed here, is that a pair of keys is needed, to first lock a message and then unlock a message. It is not possible to use the same key to both lock and unlock a message. They must be used in sequence - it is this fact that ensures that nobody can use a Public Key to encode a Message Digest and thus claim the message came from the User, the Message Digest would not be able to be unlocked by applying the Public Key a second time and thus the forgery can be detected. It is thus vital that the Private Key is kept secure by the User after it has been generated - should a key’s security be questioned however there is a method built into the Key Management system to repudiate a key and establish a new key in its place.
The second aspect of key management is who’s key is it and how do we know it is the Users key? The first part is answered by the fact that when a key is circulated, both its Key ID and the name and description is circulated with it. The second part, assuring that the key is genuine, is a matter of "trust", it is carried out by getting another User (or several) to "Sign" the Public Key with their own keys. In this case the BBS Sysops could receive a copy of a Users Public Key, preferably in a face-to-face meeting, and only after being assured that the person is who he says is he is would he create what is known as a Key Certificate this is a copy of the Users key signed as being a genuine key with the Sysops Private Key. However, how do you know that the Sysops key is genuine? The only final way is for all Sysops keys, or anybody who wishes to Sign a key, to have their keys signed by someone you personally know and trust. Such a Signing can be arranged at say a Sysops National meeting, where several independent people can vouch for each key from a Sysop, these keys can then in turn be trusted. The risks and security that is required are fully explained in the PGP documentation that is available from the sources mentioned at the end of this article.
These are systems, in our case BBS, that hold a copy of the Public Keys available, their operation is very similar to the White Page servers already being used - in fact there is no reason why exactly the same mechanism cannot be used to transfer the keys around between servers. And in the same way that a User can request a WP server to give the address of a User, then the Public Key could also be requested. This mechanism ensures that all the Public Keys are available to everyone who needs to use them.
This final element of the system, is required for two reasons. The first is that not everyone will have the capability of signing their own messages, thus it will be necessary to ensure that at least a facility is available to all, provided the BBS that signs the message is certain (and takes responsibility for) ensuring the identity of a User (for instance by a one-time pad password). The second reason is that BBS, themselves may not have every Users (world-wide) Public Key immediately available. Thus if a BBS signs a message itself, after receipt, that signature itself can be validated as it is quite practical for the Public Key of each BBS World-wide to be held. This will add to the overall message length, but given that the signatures themselves are quite small, this is not an undue burden.
In order for such a system to come into use on the Amateur Radio Packet networks the following requirments will need to be met.
1. Easy availability of the PGP software for all the main
computer types and operating systems.
2. A significant number of Key servers to be operational.
3. BBS software capable of verifying that both received and
forwarded mail, using signatures, are valid.
Once the above has been achieved, and the system can be shown to be reliable and in frequent use, then will come the time to make a request of the authorites to re-consider the obligations within the UK’s NoV on the BBS Sysops responsibilities. However in the mean time we can still enjoy the benifits of knowing that messges are secure and from whom they originated.
The PGP software is already available for most computer types and operating systems. Althought not often found on Amateur radio BBS, the software is freely available from plenty of land line systems and of course via the Internet. Copies for a variety of systems are available for local users from G7VRB. A list of known sources is listed in the appendices. Source code for PGP is also freely available thus making the porting of the software to other systems reasonably easy for programmers.
The modifications necessary to allow easy access within common AX25 PMS/Terminal software should not form to many problems. I have already instigated a simple semi-automatic system using TPK running under Windows or DesqView.
At the present time there are no standard keyservers within the Amateur networks. However it is hoped that this situation will change shortly at GB7VRB and at the same time the code will be made available to other BBS on the networks. An announcment via the system will be made as soon as the software is available.
Some work has already begun with G7IUB, Leigh, starting to develop some code suitable for use with both FBB and the TCP/IP systems. However any other volunteers would be warmly welcomed to assist, likewise other authors of BBS code.
In practice a user of the system will find little outward difference in sending or receiveng messages. A user would prepare his message in the reccomended way using any standard text editor (or in built editor of exisiting software). The resulting file would then be used as input to the PGP program with a "request" to generate an ASCII armoured signature, this results in an output file which contains the original text, top’ed and tailed with PGP headers and the resuting signature. To accomplish this process the user will also be requested for his password to his private key. The resulting file is then sent to the BBS in the normal way.
On receipt at the first BBS, the message will be scanned for the PGP headers. If present then the message will be verified by passing the entire message to PGP for verification. This means that the users Key ID will be looked up and the resulting public key will be used to verify that the signature has not been tampered with, the message digest element will then be used to ensure that the text itself has not been altered. If these tests are successfully passed then the message will be allowed onto the BBS and forward’ed as required. If the BBS also acts as signature server then the entire message, including any original users signature will be signed automatically by the BBS. At subesquent BBS’s in the forwarding path the last signature will also be verified thus ensuring that the message has remained unaltered. If any BBS is unable to verify a signature then the message would be placed on hold awaiting the attention of its Sysop’s.
Any users choosing to read a message at a BBS, would then be assured that the message has traversed the system without being altered. In addition he could perform a validation check at his own computer to ensure that the originators signature is indeed that of the senders provided that he has a copy of the senders key. If the public key of the sender is not immiedately available, then it can be requested from a local key server. If required BBS software could also list the identity of the sender and the originating BBS if it has acted as a signature server thus minimising the work of a user on receipt.
It has already been shown that use of the PGP system of message digests and public keys is workable over any of the amateur Radio networks. If the system is to become viable and accepted by the authorities then this work needs to be expanded and made available for a majority of users of the networks. Once it can be shown that the system is in widespread use then the time will have arrived for the authorities to be approached with a request to consider varying the terms of the NoV’s. In the meantime however we should be able to show that the system has acheived its basic aim of eliminating the alteration of messages and identifing the senders of messages.
It is hoped that this paper will prompt some discussion and interest in using PGP in this manner on the Amateur data networks, and will encourage other software writers to offer assistance in customising PGP to the software available for use by amateur radio. To this end I am willing to co-ordinate software development and provide a List server to those who express an interest in assisting development. I can be contacted at the address’s shown below.
G8DHE @ GB7VRB.#38.GBR.EU
72 Cranleigh Rd., Worthing, Sussex. BN14 7QW
Phone: 01903 232161
APPENDIX 1
A typical message signed by PGP looks like this:-
-----BEGIN PGP SIGNED MESSAGE-----
Hi Lionel,
Yup your right, I did have you set to come in at the root before!
Just checked and it switched directory to FBB Ok, can you try again and
I'll keep an eye open to see what happens.
73 Geoff G8DHE @ GB7VRB - Sysop Worthing Video Repeater Group BBS
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2i
iQBVAgUBMFGJk6IEoyZMgJvVAQGG2QH/ftWAekNz3CqYSUxUnw1AMMc6prlDBPxY
l4AUTd3kbD0f/xIbvhKloSwEVL75D2PIOZf0TMk1hIXUwSuKG50mCw==
=nmn5
-----END PGP SIGNATURE-----
APPENDIX 2
Sources of PGP code, executables and documentation:-
WHAT IS THE LATEST VERSION OF PGP?
Platform(s) Latest Version Distribution File Names
__________________________________________________________________________
| | | |
|DOS, Unix, | Viacrypt PGP 2.7.1 | disk sets |
|Mac, Windows, | | |
|or WinCIM/CSNav | | |
|________________|_____________________|_________________________________|
| | | |
|Hardware-based | Viacrypt 2.7.1 | disk sets |
|PGP/Token | | |
|________________|_____________________|_________________________________|
| | | |
|DOS, Unix, VAX, | MIT PGP 2.6.2 | pgp262.zip (DOS + docs) |
|others | | pgp262s.zip (source) |
| | | pg262s.zip source on CompuServe |
| | | pgp262s.tar.gz (source) |
| | | pgp262s.tar.Z (source) |
| | | pgp262dc.zip (documentation) |
| | | pg262d.zip (docs on CompuServe) |
|________________|_____________________|_________________________________|
| | | |
|Macintosh | MIT PGP 2.6.2 | MacPGP2.6.2-130v1.hqx |
| | Mac version 1.3.0 | m262pgp.hqx (same as above) |
| | | MacPGP2.6.2-130v1.source.asc |
| | | m262pgps.asc (same as above) |
|________________|_____________________|_________________________________|
| | | |
|Power Mac | Zbigniew's "beta" | Fatmacpgp262b131.sea.hqx |
| | | f262pgp.hqx (same as above) |
| | | Fatmacpgp262b131.src.hqx |
| | | f262pgps.hqx (same as above) |
|________________|_____________________|_________________________________|
| | | |
|Amiga | PGP 2.6.2 Amiga 1.4 | pgp262-a14-000.lha |
| | | pgp262-a14-020.lha |
| | | pgp262-a14-src.lha |
| | | PGPAmi262is.lha (international) |
|________________|_____________________|_________________________________|
| | | |
|Atari | Atari MIT PGP 2.6.2 | pgp262st.zip |
| | Atari International | pgp262ib.zip |
|________________|_____________________|_________________________________|
| | | |
|OS/2 | MIT PGP 2.6.2 | pgp262-os2.zip |
| | | on ftp.gibbon.com |
|________________|_____________________|_________________________________|
| | | |
|Non-USA version | PGP 2.6.2i from | pgp262i.zip |
|to avoid RSAREF | Stale Schumacher | pgp262is.zip |
|license. | | pgp262is.tar.gz |
| | | pgp262i-os2.zip |
| | | pgp262i-djgpp.zip |
| | | |
| | Canadian "mutant" | MacPGP262ca124.exe.sea.hqx |
| | not for USA use | MacPGP262ca124.src.sea.hqx |
|________________|_____________________|_________________________________|
Copies of executable code and documentation are available from myself
QTHR, please send an IBM formatted disk with return packaging and postage.
The following files will be returned in compressed format.
------ 6412 23-05-94 23:12 i:\files\pgp\readme.doc
------ 18215 07-05-94 15:15 i:\files\pgp\politic.doc
------ 9506 29-08-94 13:43 i:\files\pgp\z-on-pgp.txt
------ 32134 18-07-95 16:43 i:\files\pgp\wherepgp.txt
------ 62619 28-08-94 13:05 i:\files\pgp\ibm\pgpfront.zip
------ 13689 28-08-94 13:05 i:\files\pgp\ibm\pgpmenu.zip
------ 279328 18-07-95 16:43 i:\files\pgp\ibm\pgp262i.zip
------ 389863 03-06-95 01:44 i:\files\pgp\amiga\pgpami26.lha
------ 606458 29-08-94 09:31 i:\files\pgp\mac\mac23a.pgp
------ 388586 29-08-94 09:40 i:\files\pgp\arch\arcpgp23.spk
------ 18527 29-08-94 09:40 i:\files\pgp\arch\pgpwimp
------ 562 18-07-95 21:27 i:\files\pgp\pub-keys\g8dhe.asc
------ 402 18-07-95 21:26 i:\files\pgp\pub-keys\gb7vrb.asc
------ 390 18-07-95 21:26 i:\files\pgp\pub-keys\g4lgk.asc
------ 426 30-07-95 13:38 i:\files\pgp\pub-keys\g0chi.asc
------ 728 10-08-95 20:55 i:\files\pgp\pub-keys\g7eld.asc
total files 16 total bytes 1827845
WHERE IS PGP ON THE WORLD WIDE WEB?
http://web.mit.edu/network/pgp-form.html
http://colossus.net/wepinsto/wshome.html
UK
01273-688888
ftp://ftp.ox.ac.uk/pub/crypto/pgp
ftp://unix.hensa.ac.uk/pub/uunet/pub/security/virus/crypt/pgp
This is only a small sample of locations and many other sources can be
found.
Last Updated: 04 December 1995