next up previous
Next: Cost Estimates Up: No Title Previous: Threat Model

Trust Structure

Probably the most important architectural issue is the structure of trust. By this we mean how we organise the mechanisms whereby a principal finds out that a particular key may be used for some given purpose. It is well known that trust structures in the electronic world should mirror those in the underlying business or professional practice [71], and as we noted above, this has been agreed in principle between the BMA and the NHS. In this section we would like to consider in more detail precisely what this means, and what it implies for the NHSE's proposed cryptography strategy.

To take a simple example, private investigators obtain personal health information unlawfully by telephoning either the GP or the health authority of the target of their investigation, and claiming to be a hospital doctor involved in the target's emergency care. Such enquiries pose a dilemma: should the GP reveal sensitive information to an unidentified caller and risk a breach of privacy, or withhold it and risk that the patient will come to harm?

This is a live problem; one health authority that has taken the trouble to train staff to use careful telephone procedures [7] is now detecting about thirty false pretext telephone calls per week [41]. This indicates that over a hundred thousand such incidents take place nationwide per annum; most of them go undetected because of the cost and inconvenience of maintaining a high level of staff awareness and telephone discipline.

A cheaper and more convenient solution is possible with secure electronic mail. A hospital doctor who needs information can authenticate himself by digitally signing the request; the GP can check the signature and then encrypt the response using an encryption key that was sent with the signed request, and whose corresponding decryption key is known to the hospital doctor. The problem is now how the GP should recognise the signature as belonging to a bona fide hospital doctor.

The use of `certification authorities' (CAs) is one established way to manage cryptographic keys. An example is given by the new SET protocols for credit card transactions over the Internet; each bank (or group of banks) will establish a service to which customers can send their encryption keys (and the verification keys corresponding to their digital signature keys) and have them certified. This certification has the effect of binding a customer's keys to his or her account number.

But the solution proposed by IMG is to use a `trusted third party' (TTP), or a small number of them, rather than CAs. TTPs differ from CAs in that they retain copies of the private decryption keys in order to provide government access to encrypted traffic if required. They are an initiative of the US government whose objective is to bring the civil use of cryptography under the control of the US government and its allies.

The rationale offered for TTP services is usually as follows. Cryptography is about secrecy; secret communications could help criminals escape detection; so the government must have some means of decrypting everybody's traffic; and, as a quid pro quo, the government can provide a means for users of the Internet to identify each other. So the proposed solution is that TTPs certify users' public encryption keys, while retaining copies of their private decryption keys for use by police and other government agencies.

In the UK, the TTP initiative was launched by the DTI last year, and at a meeting called by the Ministry of Defence on the 27th June to publicise it, a DTI spokesman stated that a condition of TTP licensing would be that all keys used for confidentiality services should be escrowed, i.e. copies would be retained by the TTP and made available to the authorities on demand.

We will discuss the privacy, safety and medico-legal aspects of escrow in more detail in section 5 below. The point we wish to make here is that regardless of whether we are dealing with a TTP or a CA, the number of such services has a significant impact on the usability and thus the cost of the system.

The NHSE's main strategy document strongly favour a single TTP, or a small number of them, for the whole of the NHS. Although it does allow for the possibility that there might be more than one such service, the thrust of the argument assumes that there will be one, and the detailed costings supplied on pp 29 ff imply that there will be at most two (four full time staff equivalent per TTP, and a total budget of eight).

This represents a massive centralisation of the current structures of trust in medicine, which as pointed out in [8] are collegiate rather than bureaucratic.

Signing a doctor's key is the electronic equivalent of recognising that a doctors is in fact a registered medical practitioner. This function is, of course, carried out by the General Medical Council which holds the register of all persons qualified and licensed to practice medicine. Consequently, any government move to set up a national medical TTP could be seen as subsuming one of the essential independent roles of the General Medical Council.

After this point was raised in discussions with officials in May, the supplementary strategy document claimed that the GMC had been suggested in internal discussions as the natural location of the TTP ([86] p 9). We understand that it was argued to the GMC that so long as they had `control' of the TTP it did not really matter who actually operated it. These arguments are of great concern; if they prevail, the effect would be to put key management under nominal clinical control but with the day to day administration in the hands of the NHS Executive, or possibly even a privatised service provider.

The desire of the UK and other governments to centralise trust appears tightly bound up with the key escrow agenda. The GCHQ secure email document declares and intention to centralise all state sector TTPs at the department level, except where geographic dispersal prevents this, and have GCHQ personnel operate them, at least initially [24]. The US National Security Agency, which is driving the whole TTP programme worldwide, attempted to specify ISAKMP -- the future key management protocol for the Internet -- in such a way that there could be at most 65536 certification authorities or trusted third parties in the world. This attempt has now failed. The reason for the attempted centralisation is clear -- governments feel that a small number of key management centres would be easier for them to control.

However, even if it had been the intention of government to have professional registration bodies act as TTPs without external assistance, then surely provision would have been made in the strategy for more than two of them. There would have to be at least one (and for reliability reasons preferably two) for each registrable professional group, i.e. two for doctors, two for nurses, two for dentists, and so on.

But in the Teesside encryption pilot, there will be a single TTP operated initially by BT [81]; their key management scheme is to be adapted from that used in the Clearing pilot. Centralisation appears to be assumed.

Experience from the banking sector has shown that in organisations with decentralised personnel management, centralising trust is difficult, expensive and fragile. The writer advised a bank with 25,000 employees, managed through seven regional personnel offices, trying to administer mainframe passwords at a central site. With thirty staff and much message passing to and from the regions, the task was just about feasible, but was an inefficient way of running things and coped poorly with emergencies. Imposing such a solution on about a million staff in the thousands of NHS and supporting organisations would result in significant risks, costs and service degradation.

As a general principle, keys should be managed where the personnel management is done, and especially so where keys are used to support access control. In New Zealand, for example, a proposal to have doctors' keys managed by officials in the local district hospitals turned out to be impractical. The overhead of calling the hospital for keys to be issued or revoked with every temporary staff change was not supportable. It is now proposed that keys there should be managed at the practice level [40]. In the UK, with some 12,000 general practices, hospitals and community care facilities, centralised key management is even less likely to be workable.

So for practical reasons, cryptographic keys will have to be managed at the provider level. This means developing CA software that can be used by general practices to certify keys for their staff. A consequence of this will be that access by the police and by other government bodies such as social services and benefit agencies to clinical records will involve the knowledge and cooperation of at least one member of clinical staff at the provider -- as is the case at present with manual records and standalone computer systems. This will accord with the agreement that future trust structures should reflect existing ones.

It is unthinkable that the Government would wish to change this arrangement and permit access to practice databases without the partners being aware of the intrusion, as this would represent a very significant change in trust relationships and would create extensive public alarm. The EC Data Protection Directive would have to be considered, as would the Data Protection Registrar's recent comments on key escrow to the effect that under section 8.2 of the European Convention on Human Rights, the invasion of privacy is permissible only where there is a `pressing social need' [35].

No reasoned argument has been made for changing the current ethical provisions for access to medical information which currently give patients control over who has access to their records. The BMA's security principles are designed to give patients authority over the data flows originating from their records. The BMA will resist any moves that undermine this approach.

next up previous
Next: Cost Estimates Up: No Title Previous: Threat Model

Ross Anderson
Mon Oct 6 12:47:34 BST 1997