Protocol Problems

Recently the NHS Executive has been urging providers to ensure that they can deal with the year 2000 problem. Yet the encryption pilots use a mechanism -- X.509 certificates -- which has only a two digit date field.

X.509 has other problems. It was originally designed an an authentication protocol, with non-repudiation added as an afterthought. As a result, the support that it offers for digital signatures is less than ideal. Its trust model may be thought of as similar to a credit card -- certificates have an expiry date (like credit cards) and there is a `certificate revocation list' of revoked certificates (like the hot card list of a credit card company).

This trust model has a number of limitations, including:

1. X.509 certificates vouch for identities rather than roles. This may be enough for retail commerce, but in healthcare it is common for an individual to have a number of distinct roles: the same person may be simultaneously a patient, a GP, a coroner and a board member of a local NHS trust. Identity certificates are not adequate to support this..

   Roles are also of great value in reducing the cost of administration. If a bank has 50,000 staff and 100 separate applications on its system, and one tried to administer each user's access rights separately, then this would involve managing 5,000,000 bits of security state, which would be expensive and error prone. However, all but a handful of staff can have their access rights completely specified by allocating them to one of a small number of roles, such as `teller' and `assistant branch accountant'.

2. X.509 does not support dual control. It will often be desirable for doctors' keys to be signed by more than one certifier; we envisage that a typical doctor's working key would be signed by a long-term personal key that was in turn signed by the GMC, and also by the hospital or general practice where he or she was employed [12]. In this way we can ensure that the medico-legal aspects of electronic trust are made explicit; both the doctor and the provider are liable for actions taken.

   Dual control is also important to prevent the compromise of a single certifier causing the entire system to fail: so long as a certificate still has one trustworthy signature, it can still be used. Such robustness is a vital attribute of medical systems.

3. In X.509, certificate revocation is the sole responsibility of whoever created the certificate in the first place. This is less than optimal in healthcare, where there are good reasons to want some certificates to be issued by one principal and revoked if necessary by others. For example, a hospital doctor's certificate should be able to be revoked by the hospital (in case he leaves or is dismissed), by himself (in case he resigns), and by the GMC (in the event that he is struck off).
4. X.509 offers poor support for signatures that must persist for a long time, such as the signatures on archived medical records and other legal documents that might be the subject of dispute many years after all the relevant certificates have expired.

At the very least, if X.509 is to be used, then health service specific extensions will have to be developed, tested and agreed. But it is prudent to note that although X.509 certificates are being introduced in a number of electronic commerce applications, there is a growing realisation that the standard is inadequate for more general use, and alternatives are being developed. (The front runner at present appears to be Microsoft's SDSI.)

It is also prudent to note that although the computer and communications industries are merging, their standards processes have not. Where there is a conflict, the computer industry standard usually wins. There are several reasons for this. To succeed, a communications standard must be supported by a wide range of computer systems; and the product cycle of computer companies is about fifteen months compared with fifteen years for phone companies.

The NHS already has expensive experience of this conflict. A policy to have X.400 (the phone company standard) adopted for electronic messaging is encountering resistance, as computer companies -- and independent users such as GPs -- at present see much more relevance to their business needs with SMTP instead. This mistake should not be repeated with certificates.

The IMG strategy inherits from X.509 the lack of support for necessary features such as year 2000 compliance, roles, dual control, and long-lived documents. However the GCHQ protocol, if adopted in its entirety, would introduce other problems too.

Firstly, users' keys are derived from their names; so a user whose key is compromised cannot be issued a new key, but only a copy of the same old compromised key. In addition, security labels (which in the medical context would mean access control lists) are not protected and could thus be manipulated by attackers. This is directly contrary to DTI guidance on protective security marking [29].

Secondly, this fragility extends to the escrow aspects. In the GCHQ proposal (and also in the Teesside and NWCS pilots as far as we can see), a single official has the power to remove all the protection offered by the cryptographic mechanisms. This is not a necessary attribute of escrow systems; the US government's Clipper initiative, for example, uses two escrow agents so that a single rogue official cannot completely break the system [27]. So even if key escrow eventually becomes a legal requirement, it is possible to implement it much more safely than the IMG proposes to. Further problems with the GCHQ protocol are described in [14].

Finally, IMG agreed at the July meeting that the protocols at least would be public. It is of considerable concern that we have been supplied only with project board minutes, not with technical documentation of the protocols that have been implemented in the Teesside and NWCS pilots.