Clarke, Roger --- "Cryptography issues in plain text" [1996] PrivLawPRpr 23; (1996) 3(2) Privacy Law & Policy Reporter 24

---

Cryptography issues in plain text

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

Requirements for data transmission security

The requirements of a security regime which addresses these risks are conventionally summarised under four broad headings. For the sender and receiver to be confident in the outcome of their communications, all of these requirements need to be satisfied.

1. Confidentiality or message security

This comprises two separate requirements, that, during a message's transit from sender to receiver:

• no observer can access the contents of the data; and
• no observer can identify the sender and receiver. This notion has very little to do with the legal concept of confidentiality, which derives from the law of confidence. The computer science literature also often misleadingly uses the much more general term `privacy' to refer to
  the very limited requirement of message security.

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:

• the sender can be sure that the message reaches the intended recipient, and only the intended recipient; and
• the recipient can be sure that the message came from the sender and not an imposter. The act by an imposter of sending such a message is referred to as `spoofing'.

4. Non-repudiation by the sender and recipient

This requires that:

• the sender cannot credibly deny that the message was sent by them; and
• the recipient cannot credibly deny that the message was received by them.

A data transmission security regime

A complete protection regime to ensure that these requirements are satisfied comprises many measures, dealing with communications channels; the computers and software used by the sender, the receiver and communications services providers; and organisational arrangements and procedures. Protections cost money and time, and in many circumstances people and organisations accept relatively low levels of confidence in return for lower cost or higher speed. In particular, different levels of security regime quality are likely to be applied to defence communications, funds transfers, normal business communications, and social communications.

This document is concerned with cryptography. It is therefore not discussing a complete protection regime, but only portions of one.

Cryptography -- introduction

Cryptography is an important element of any strategy to address data transmission security requirements. It is the science of converting messages or data into a different form, such that no-one can read them without having access to a `key'. The message may be converted using a `code' (in which case each character in the message is substituted by an alternate one), or a `cypher' (in which case the message as a whole is converted, rather than individual characters).

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.

Symmetric cryptography

Symmetric cryptography involves a single, secret key, which both the message-sender and the message-recipient must have. It is used by the sender to encrypt the message, and by the recipient to decrypt it.

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 (public key) cryptography

Whereas symmetric cryptography has existed, at least in primitive forms, for 2,000 years, asymmetric approaches were only invented in the mid-1970s.

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:

• only one party needs to know the private key; and
• knowledge of the public key by a third party does not compromise the security of data transmissions.

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:

• The key-owner. In this case, the private key never travels outside the owner's premises (or better still outside the owners' secure computer, or chip-card); but the owner must have the technical competence to perform the function.
• A service organisation of the owner's choice. In this case, the private key has to travel from the service organisation to the owner, and the owner has to trust the service organisation either not to keep a copy, or to keep a copy subject to an appropriately high set of security standards.
• A specific government agency or agencies. In this case, the private key has to travel; and trust has to exist; and the location of all private keys is known to, and under the control of, the state.

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

• encrypt messages with their private key;
• read messages sent to them encrypted with their own public key; or
• create a digital signature on messages they send.

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:

• where an employer needs access to the private key used by an employee, especially where the employee has left the organisation. This can be generalised to cover representatives of associations, and executors of the estates of deceased individuals; and
• where a law enforcement agency has reasonable grounds for believing that access to the private key will materially assist in the pursuit of a criminal -- this can (and probably will) be generalised to cover national security interests as well.

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:

• voluntary;
• voluntary for individuals but mandatory for corporations;
• mandatory for all users; or
• mandatory for dealings with government.

and the function might be performed by:

• a service organisation of the key-owner's choice;
• a service organisation which must be licensed, and which, as a condition of the licence, has to satisfy certain 3 conditions; or
• a specified government agency or agencies.

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:

• senders can include their public keys in each message; or
• public keys may be stored in one or more central directories, enabling each party to an exchange to look up the public key of the other party.

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:

• a trusted `public key certification authority' (CA), using:
• a `public key infrastructure' (PKI); within:
• a `public key authentication framework' (PKAF).

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:

• the generation of pairs of private and public keys;
• escrow of private keys;
• storage of public keys; and
• authentication and certification of public keys.

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

Short bibliography

Biddle, (1996) `Digital signature legislation: some reasons for concern' Privacy Right Clearinghouse, April 1996.

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