The
Risks Involved in Message Transmission

The term message transmission is used here to refer to the
sending of a message from one person or organisation to another, over a
communications link.

The
risks
involved in message transmission are identified in a supporting document. This
document describes the ways in which those risks can be addressed, through the
application of cryptography.

Requirements
for Message 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.

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

no observer can access the contents of the message; and

no observer can identify the sender and receiver.

The term 'confidentiality' is used by computer scientists who specialise in
security matters. This is most unfortunate, because the term has an entirely
different meaning within commerce generally, which derives from the law of
confidence. For this reason, the alternative term 'message content security'
is used in this Module.

Cryptography

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

Cryptology is the science underlying cryptography.
Cryptanalysis is the science of 'breaking' or 'cracking'
encryption schemes, i.e. 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 that has
access to sufficient computing power. Discussions in this area generally
relate to the computing power owned by the U.S. National Security Agency
(NSA).

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.

Symmetric
('Secret Key') 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 NSA stated in the mid-1990s that a 40-bit length was acceptable to them
(i.e. they can crack it sufficiently quickly). Increasing processor speeds,
combined with loosely-coupled multi-processor configurations, are bringing the
ability to crack such short keys within the reach of much less well-funded
organisations. To be 'strong', the key-length therefore needs
to be at least 56 bits in 1998, and it was argued by an expert group as early
as 1996 that 90 bits is a more appropriate length.

Symmetric cryptography provides a means of satisfying the requirement of
message content security, because the content cannot be read without the secret
key. There remains a risk exposure, however, because neither party can be sure
that the other party has not exposed the secret key to a third party (whether
accidentally or intentionally).

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

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. Moreover, if the key is compromised, all of the
message 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'.

The technique does not adequately address the non-repudiation
requirement, because both parties have the same secret key. Hence each is
exposed to the risk of fraudulent falsification of a message by the other, and
a claim by either party not to have sent a message is credible, because the
other may have compromised the key.

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, referred to as a
'key-pair', one of which only the owner knows (the
'private key') and the other which anyone can know (the
'public key').

The advantages of asymmetric cryptography 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 message transmissions.

To crack a mere 40- or 56-bit asymmetric key would be trivially simple,
because there are far fewer sets of keys available (or, expressed more
technically, the 'key-space' is relatively 'sparse'). It is
currently conventional to regard a 1024-bit asymmetric
key-length as being necessary to provide security.

Because of the much greater key-length, encryption and decryption require much
more processing power, or, for a given processor, significantly more processing
time. Messages are sent in large volumes; so the resulting delays are of
considerable consequence.

Applied
Public Key Cryptography

Public key cryptography can be applied as a means of addressing each of the
requirements for message transmission 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.
It is much slower, however, and hence symmetric cryptography is, at least at
present, a more practicable means of protecting the contents of the message
from prying 'eyes'.

Another way in which asymmetric cryptography can be used, is to underwrite
the security of a symmetric encryption scheme.

This can be done by using it to support the secure 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.

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.

Note that this process uses a different key-pair from that used for message
transmission security. The key-pair used for message-security is owned by the
recipient, whereas the key-pair used in this process is owned by the sender.

The sender appends to a message a special, agreed segment within the message.
They encrypt this segment with their private key. The recipient decrypts this
segment using the sender's public key. If the decrypted segment 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 segment is not pre-agreed. Instead, a
'message digest' is created, by processing the actual message
using a special, pre-agreed algorithm (in a similar way to the MAC'ing process
used in symmetric cryptography). The sender encrypts this message digest with
their 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 late 1990s, the conventional approach to protecting the security of
messages during transmission applies a hybrid of symmetric and asymmetric
cryptography. Message content security is achieved using a secret key, with
key management performed using an asymmetric key-pair. Integrity,
authentication and non-repudiation are achieved using a separate asymmetric
key-pair.

An
Example Application - SET

This section provides a brief overview of a particular application of
encryption technology.

The purpose of the Secure Electronic Transactions (SET) specification is to
provide a means whereby credit-card details can be used over an open network
such as the Internet, with a far higher level of fraud-prevention than is
available with manual (flick-flack) machines, and even data-capture at
point-of-sale.

SET is an "open, vendor-neutral, non-proprietary, license-free specification
for securing on-line transactions". It leverages off the existing payment-card
infrastructure and card-base. It is a collaborative initiative, spear-headed
by Visa and MasterCard, but including other important players such as Microsoft
and Netscape.

The scheme involves the use of digital signatures based on public key
encryption, as a means of authenticating all participants in a card-based
payment transaction.

The operation of SET depends on software that implements a series of protocols
being installed in the workstations or servers of four kinds of people and
organisations.

These are:

cardholders;

merchants;

payment gateways / acquirers; and

certification authorities.

The simplified representation that follows describes the two key elements:

Each of the participants has to create a key-pair, store the private key in
a secure manner, and make the public key available to organisations that seek
it.

SET envisages a hierarchy of certification authorities (CAs), independent from
other CA hierarchies. These are:

a `root CA' (God) that certifies payment-processing organisations like
Visa, MasterCard and AmEx;

a CA run by or for each payment-processing organisation, which certifies
its member-institutions / banks / card-issuers; and

a CA run by each card-issuer that certifies its cardholders.

A cardholder will (quite probably unconsciously) acquire a certificate from
the CA of their card-issuer, a copy of which they can provide whenever they
make a purchase. Each card-issuer will acquire a certificate from the CA of
each payment-processing organisation that they use. Each payment-processing
organisation will acquire a certificate from the root CA.

Since it was announced with much fanfare in 1996, progress in implementing
SET has been slow. This is because the scheme is complex, and depends on many
participants conforming with the specification.

A particular concern is that the scheme contains nothing that manages
participants' private keys. It appears that these will need to be stored on
participants' workstations and servers, or on additional peripherals installed
on workstations and servers to handle a secure token (probably a chip-card).

Infrastructure
for Digital Signatures

Two conditions need to be satisfied, in order that public-key digital
signatures can satisfy message transmission security needs:

For a digital signature to be of high quality (i.e. not readily subject to
spoofing and repudiation), it needs to be generated using a 'private key' which
is held under highly secure conditions by the person concerned.

Quite clearly, it is impractical for a private key to be memorised in the way
that passwords and PINs are meant to be memorised. An appropriate device to
support secure storage of a private key is a chip, and the most practical
carrier for such a chip at present is a smart-card.

Access to the private key stored on a chip needs to be protected in some
manner, such that only the owner can use it. One approach is to protect it
with a PIN or password; but this provides only a moderate level of security.

An emergent approach is for the card itself to refuse access to the private
key, except when the card measures some aspect of the holder's physical person,
and is satisfied that it corresponds sufficiently closely (using 'fuzzy
matching') to the measure pre-stored in the card. Examples of such
'biometrics' include the patterns formed by rods and cones on the retina, and
the geometry of the thumb.

A significant difficulty that has to be addressed, however, is that, because a
business entity cannot itself act, it is dependent on the actions of one or
more humans acting on its behalf. In addition to the security measures needed
in respect of a person's own digital signature, further measures are needed, in
order to reduce the likelihood of error or fraud by one or more persons,
involving misapplication of the business entity's private key.

During the mid-to-late 1990s, the emergent PKI has been the subject of
feverish efforts in the United States, with initiatives in the technical,
organisational and legal arenas (e.g.
Utah
1995).

In Australia, efforts by a Standards Australia committee (PKAF 1996) and
subsequently by a committee convened by the Commonwealth Minister for
Communications and the Arts (NPKI 1998) have resulted in measures being
proposed to ensure that an appropriate public key infrastructure is put into
place. The matter has also been addressed from the perspective of the
interests of Commonwealth Government agencies (
OGIT
1998). At least one organisation is ready to offer public certification
authority (CA) services, as soon as that infrastructure is in place (Australia
Post, with its KeyPost service).

The work of developing technical standards for the Australian PKAF is being
undertaken by the Standards Australia IT/12/4/1 Committee.

Further concerns are that the law as it presently stands may not recognise
digital signatures as being the equivalent of (or better than) a written
signature. A United Nations Model Law on Electronic Commerce (
UNCITRAL
1996) recommends an approach for addressing such problems. In March 1998,
an Electronic Commerce Expert Group working in conjunction with the
Commonwealth Attorney-General's Department, produced a report which recommended
modifications to the law to ensure that digital signatures are accepted in law
as evidence that a person originated a message (
ECEG
1998).

Another problem that may undermine the intended PKI is a lack of clarity about
the liabilities of CAs, or a degree of risk exposure that makes the business of
being a CA too unattractive. Various proposals have been made as to how to
ensure that the business of a CA is tenable, including the American Bar
Association (ABA 1995) and the United Nations (
UNCITRAL
1998) at Articles 11 and 12. Laws defining the extent of liability have
been passed in some jurisdictions, e.g. the State of Utah as long ago as 1995.

Issues
in Public Key Cryptography

Public key cryptography is relatively new and technically complex. It
raises many public policy issues.

Because of the nature of the mathematics underlying asymmetric cryptography,
the pairs of keys are created as part of a single 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, and all parties must have grounds to be
confident about the quality of the key-generation process (e.g. through audit
and certification of software packages or of hardware, such as smart cards);

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.
Once again the quality must be assured (e.g. through audit and certification of
service organisations); or

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. Some form
of assurance is needed that the State, and agencies of the State, will not
abuse that trust.

This choice of who generates key-pairs is one of the issues at the heart of
the cryptography debates of the last few years (
Clarke
1996).

If a person or organisation loses their private key, they are unable to:

encrypt messages with their private key; and

read messages sent to them encrypted with their own public key.

If the private key is stored only on a person's workstation or chip, it is
vulnerable to theft, loss, damage and malfunction of that device. In order to
address those risks, 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.

'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 individuals or organisations may
have a legitimate interest in gaining access to the private keys of other
parties. These include:

where an organisation seeks access to the private key
used by an officer, employee or agent, especially where the person no longer
fulfils that role on behalf of the organisation;

where an executor acts on behalf of the estate of a
deceased individual;

where a law enforcement agency seeks access to a private
key in order to materially assist in the investigation of a serious crime; and

where a national security agency seeks access to a
private key in order to materially assist in the protection of national
security.

If, however, security is to be sustained (and, indeed, if privacy is to be
protected), any access to escrowed keys would need to be subject to very
careful designed and implemented controls, e.g. a prior requirement of legal
authority (such as a search warrant), granted by a senior member of the
judiciary.

If key escrow is implemented, it 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:

one or more individuals and/or service organisations 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 conditions; or

a specified government agency or agencies.

The question as to whether private key escrow should be implemented, and if
so how, lie at the heart of the cryptography debates of the last few years (
Clarke
1996). It is important that the distinction be appreciated between secure
deposit (for the benefit of the key-owner) and key escrow (for the benefit of a
third party). This has become confused during the public debates.

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;

senders can store them at an accessible site (e.g. using FTP or HTTP); 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', i.e.
an imposter can send a message which includes a public key, or
store a public 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 can 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.

In order to reduce the amount of network traffic involved, and hence the
elapsed time of a transaction, it is feasible for certificates to be provided
by the sender (in a manner analogous to a letter applying for a job being
accompanied by a set of letters from referees attesting to the applicant's
identity and good character).

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 United States. In Australia, Telstra
operates such a scheme for its own use and that of one or two major clients,
and Australia Post has launched a scheme called KeyPost, which it intends to
make generally available.

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
Australian Standards document MP75 (PKAF 1996), 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 (
Clarke
1996).

A PKI could have potentially grave impacts on privacy, depending on how it
is implemented. Greenleaf and Clarke (
1997)
identify and examine the following impacts of digital signature technology on
privacy:

expects adaptation of existing standards to meet the need to be slow; and

considers 'web of trust' PKI to be more likely to satisfy the need.

A further issue is that some government agencies and some corporations are
running a 'technological imperative' agenda in an effort to convert anonymous
transactions into identified transactions. The privacy interest runs
emphatically counter to attempts to convert anonymous into identified
transactions.

The cluster of tensions that has arisen between those who believe in the need
for strong control of society by nation-states and those who value individual
freedoms much more highly has reached serious proportions, and could get much
worse. Cryptography in general, and the strategies adopted in relation to
public key infrastructure in particular, are at the centre of these debates. A
depiction of the contrary positions of 'crypto-anarchists' and
'crypto-authoritarians' is at
Clarke
(1996).

This document deals with only one particular aspect of security, that which
relates to message transmission. Message transmission security needs to be
established within the context of a complete protection regime comprising a
comprehensive set of 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.

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

PKAF (1996) 'Strategies for the Implementation of a Public Key Authentication
Framework (PKAF) in Australia' Standards Australia, MP75, 1996

The content and infrastructure for these community service pages are provided by Roger Clarke through his consultancy company, Xamax.

From the site's beginnings in August 1994 until February 2009, the infrastructure was provided by the Australian National University. During that time, the site accumulated close to 30 million hits. It passed 50 million in early 2015.