Privacy Law and Policy Reporter
Roger Clarke's primer on issues of data-transmission security.This paper provides lay-person explanations of the elements of data-transmission security, key concepts of cryptography, and relevant aspects of key generation, secure deposit of private keys, private key escrow, public key certification and multi-function certification authorities. It is intended to be read with my article `Crypto-confusion' (see p 30 this issue) or separately.
`Data transmission' is used here to refer to the sending of a message from one person or organisation to another, over a communications link. A variety of risks are involved in data transmission (see p 26).
1. Confidentiality or message security
This comprises two separate requirements, that, during a message's transit from sender to receiver:
2. Integrity of data content
This requires that the data cannot be changed or lost during transmission, either accidentally, or because of an action by any party.
3. Authentication of the sender and recipient
This requires that:
4. Non-repudiation by the sender and recipient
This requires that:
This document is concerned with cryptography. It is therefore not discussing a complete protection regime, but only portions of one.
Cryptology or cryptanalysis is the science of `breaking' or `cracking' encryption schemes, that is, discovering the decryption key.
A `strong encryption scheme' is one that cannot be cracked in a sufficiently short time that the security of the message is threatened, even using the most powerful computers available for the task.
With a `weak encryption scheme', on the other hand, there is a significant risk that the key can be discovered by an organisation which has access to sufficient computing power. The organisation which has more computing power than anyone else is the US National Security Agency (NSA). NSA would like everyone, especially the US Administration, to believe that organised crime, foreign governments, large foreign companies and other bogeymen are not far behind them (a claim which may or may not be true).
There are several aspects of a scheme that determine its strength. One of particular importance is the key-length needed to make it highly unlikely that a cracking attempt will be successful.
Cryptography comprises two distinct classes: symmetric and asymmetric.
The US National Security Agency regards a 40-bit length as acceptable to them (by which they mean they are confident they can crack it sufficiently quickly that they can decrypt any message they want to). To be `strong', the key-length therefore needs to be at least 56 bits, and it has been argued recently by an expert group that 90 bits is a more appropriate size.
It is a means of satisfying the requirement of confidentiality or data content security, because the content cannot be read without the secret key.
It can also be used to address the integrity and authentication requirements. The sender creates a summary of the message, or `message authentication code' (MAC), encrypts it with the secret key, and sends that with the message. The recipient then re-creates the MAC, decrypts the MAC that was sent, and compares the two. If they are identical, then the message that was received must have been identical with that which was sent.
The technique does not adequately address the non-repudiation requirement, however, because both parties have the same secret key, and hence each is exposed to fraudulent falsification of a message by the other.
A major difficulty with symmetric schemes is that the secret key has to be possessed by both parties, and hence has to be transmitted from whomever creates it to the other party. But if the key is compromised, all of the data transmission security measures are undermined. The steps taken to provide a secure mechanism for creating and passing on the secret key are referred to as `key management'.
Asymmetric cryptography involves two related keys, one of which only the owner knows (the `private key') and the other which anyone can know (the `public key'). The advantages are that:
To crack a mere 40- or 56-bit asymmetric key would be trivially simple, because there are far fewer sets of keys (to express it a little more technically, the `key-space' is relatively sparse). It is currently conventional to regard a 1028-bit asymmetric key-length as being necessary.
Asymmetric cryptography can be used to address each of the requirements for data transmission security, or to assist in overcoming the key management problem in a symmetric encryption scheme.
Confidentiality or message security
The sender encrypts the message, not with their own key, but using the intended recipient's public key. The receiver decrypts using their private key. This is a more secure approach than symmetric cryptography, because the decryption key need never be in the possession of anyone other than the owner.
Integrity, authentication and non-repudiation
The technique can be used to address all of the integrity, authentication and non-repudiation requirements. Because the technique is somewhat complex, it is explained below in a succession of steps.
The sender appends to a message a special, agreed additional block of code. He encrypts this block of code with his private key. The recipient decrypts this additional block of code using the sender's public key. If the decrypted message is identical to what the two parties had previously agreed, then the recipient can be sure that the message has been sent by the purported sender, and that the sender cannot credibly deny having sent it. Hence the authentication and non-repudiation requirements are satisfied.
This technique can be taken a step further, to address the integrity requirement as well. The additional block of code is not pre-agreed. Instead, a `message digest' is created, by processing the actual message using a special algorithm (in a similar way to the MAC'ing process used in symmetric cryptography). The sender encrypts this message digest with his private key, to produce what is called a `digital signature' (because it performs much the same function as a written signature, although it is much harder to forge).
The recipient re-creates the message digest from the message that they receive, uses the sender's public key to decrypt the digital signature that they received appended to the message itself, and compares the two results. If they are identical, then the contents of the message received must be the same as that which was sent (satisfying the integrity requirement), the message can only have been sent by the purported sender (satisfying the authentication requirement), and the sender cannot credibly deny that they sent it (satisfying the non-repudiation requirement).
In the US, the National Institute of Standards and Technology (NIST) established a federal digital signature standard (DSS) during the period 1991-94. Many states are in the process of establishing legal frameworks for digital signatures, most of them based on Utah's 1995 legislation. A commentary on matters of concern about the Utah model, including privacy aspects, is provided by Biddle (1996).
Management of secret keys
Alternatively, asymmetric cryptography can be used to underwrite the security of a symmetric encryption scheme, by supporting confidential transmission of a new secret key from the originator to the other party. Under this approach, the new secret key is encrypted using the recipient's public key, and then sent. Only the recipient has the recipient's private key, and hence only the recipient can decrypt the message and recover the new secret key.
Generation of pairs of private and public keys
Because of the nature of the mathematics underlying asymmetric cryptography, the pairs of keys are created as part of the same process. Three main choices exist as to who performs key-generation:
This choice of who generates key-pairs is one of the issues at the heart of the current cryptography debates.
Secure deposit of private keys
If a person or organisation loses their private keys, they are unable to
In order to address this risk, it is strongly advisable that every private key be placed into deposit in some location separate from that person's normal workstation. Because of the risks involved if the private key comes to be known by some other person, the deposit needs to be subject to an appropriately high set of security standards. Software products are emerging to support companies in the performance of secure deposit (for example, Wayner 1996).
Escrow of private keys
`Escrow' is an arrangement whereby something is placed on deposit with a trusted party, but may be accessed by third parties under certain conditions. It was originally used for title deeds for real property, and is used for source-code for software packages. Escrow can also be used for private keys, in which case it is referred to as `private key escrow', which is commonly shortened to `key escrow'.
There are a number of conditions under which it may be appropriate for access by third parties to the key to be authorised. These include:
If security is to be sustained (and, indeed, privacy protected), accesses to escrowed keys need to be subject to very careful designed and implemented controls, for example a prior requirement of legal authority (such as a search warrant), granted by a member of the judiciary.
Key escrow might be:
and the function might be performed by:
These choices, and indeed the very question as to whether private key escrow should be implemented, lie at the heart of the current cryptography debates. For example, `Corporate and individual rights to privacy are placed in question by the current US Government escrow proposal and process. This is so because of the mandatory nature of the proposal resulting from the key escrow requirement itself and the oversight role government proposes to play in the accreditation process and business practices of an escrow agent.' (Netscape, 1996).
Access and certification of public keys
Asymmetric schemes depend on the public keys of people and organisations being publicly available. The most practicable methods of achieving this are:
Either of these approaches is subject to `spoofing', that is, an imposter can send a message with a valid key, or store a valid key in a directory, and thereby fool the other party into thinking the message came from a particular person or organisation.
To address this risk, the concepts have been created of:
If a party to a message-exchange wishes to acquire the public key of the other party, or to check that the public key they already have for the other party is valid and up-to-date, they use that party's identity to look up a certificate in a directory, and receive back a message containing that person's or organisation's public key. The message is signed and encrypted by the certification authority using its own private key, and the recipient decrypts it using the certification authority's public key.
An international standard for certificates of this kind has existed for several years, documented within the CCITT standard X.509. Services of this nature are being offered in the US. In Australia, Telstra operates such a scheme for its own use and that of one or two major clients, and Australia Post is also preparing to launch a generally-available scheme, which it calls KeyPost. A Draft Australian Standard for a public key authentication framework (DR96078) was published in April 1996 (see details in this issue). Also relevant is a protocol called the Secure Electronic Transactions (SET) standard, published jointly by MasterCard and Visa (SET 1996).
Multi-function certification authorities
The preceding paragraphs have endeavoured to present the complete set of concepts in a logical sequence of development. Unfortunately, the separation of ideas and functions has been considerably muddied in practice.
In particular, many of the proposals for public-key certification/authentication frameworks and certification authorities, including the Draft Australian Standard, envisage the authorities performing multiple functions, including:
Whether an organisation that performs the third and fourth functions should also perform the first and/or second functions is central to the current arguments between crypto-anarchists and crypto-authoritarians.See http://www.anu.edu.au/people/Roger.Clarke/11/cryptosecy for `live' copy of this document.
Roger Clarke, Roger Clarke, Xamax Consultancy Pty Ltd
Burns and Christofis, (1995) `Certification of public keys: your electronic credentials' EDICAST 26 (October/November 1995), pp.6-8, and at http://www.pa.gov.au/eco/edicast/edic26/ec26.htm#11
Chaum, (1995) `Digital signatures and smart cards', Digicash bv, Amsterdam, October 1995, at http://www.digicash.com/publish/digsig/digbig.html
EPIC `Cryptography policy', at http://www.epic.org/alert/
Garfinkel, (1995) `PGP: Pretty Good Privacy', O'Reilly & Associates, 1995, esp. Chaps 2-6 and the Glossary.
Litterio, (1995) `Cryptography: the study of encryption', at: http://world.std.com/~franl/crypto/
Netscape (1996) `Netscape policy on encryption export', at http://www.netscape.com/newsref/ref/encryption_export.html
OTA (1995) `Issue update on information security and privacy in network environments', Chap 2: Overview of the 1994 OTA report on information security and privacy, June 1995, at: ftp://otabbs.ota.gov/pub/infosec.update/07ch2.txt and ftp://otabbs.ota.gov/pub/pdf/infosec.update and mirrored at: http://www.anu.edu.au/people/Roger.Clarke/II/07ch2.txt and http://www.anu.edu.au/people/Roger.Clarke/II/03ch2.pdf
(Note: The Office of Technology Assessment regrettably closed its doors in September 1995, when Congress withdrew its funding. Its pages live on for the time being, but are at imminent risk of disappearing; hence the mirroring of this particularly valuable description of the technology and identification of the `key' issues).
RSA (1995) `RSA's frequently asked questions about today's cryptography', at: http://www.rsa.com/rsalabs/faq/faq_gnrl.html
SA (1996) `Strategies for the Implementation of a public key authentication framework in Australia' Standards Australia, DR96078, April 1996.
Schneier, (1996) `Applied cryptography' Wiley, 2nd ed, 1996
SET (1996) `Secure Electronic Transactions Specification', February 1996, at MasterCard and Visa.
Utah Digital Signature Act, 1995 http://www.state.ut.us/ccjj/digsig/
Wayner P. (1996) `Don't lose your crypto keys' BYTE (May 1996) p 137.
Whittle, (1996) `Public key authentication framework for Australia' http://www.ozemail.com.au/~firstpr/crypto/pkaf-1.htm