The use of encryption and related services with the NHSnet

A report for the NHS Executive by Zergo Limited

© Crown Copyright 1996

IMG E5254

Jump to page:

Contents

Preface

The report is being made available to individuals and bodies known to be interested. Further copies may be obtained from:

Department of Health
PO Box 410
Wetherby
West Yorkshire
LS23 7LN
Tel: 01937 840250
Fax: 01937 845381

1 Management summary

The main results of this study are that:

• the needed technology has recently become available to allow encryption to be provided across the NHSnet in a versatile and beneficial manner and in a way that is responsive to need and cost. Importantly, the use of encryption by some systems for some data does not require the use of encryption by all systems or for all data
• the NHS's needs should be addressed by a family of related encryption products built on the Red Pike encryption algorithm. This algorithm has recently been made available to the NHS by CESG, the National Technical Security Authority within HMG
• the introduction of encryption facilities will not be a panacea for solving all the information security problems associated with networking NHS systems
• the encryption facilities could be used in a manner which is highly automated and manageable
• the implementation process will be by no means simple. There are a number of management and technical issues that will need to be addressed within the implementation programme for the encryption facilities. However, an approach is identified that will reduce the associated risks to a manageable level
• the recommended facilities should be readily extendible to support the provision and use of related cryptographic services such as Digital Signatures to prevent unauthorised tampering with the communicated data and to link unambiguously the communicated data to the identities of the parties involved in its exchange
• the NHS will need to develop a key management infrastructure to sit across the many different systems that will become encryption-enabled. This infrastructure will require one or more Trusted Third Parties (TTP) management centres, though the staffing requirements for these will be small

• the potential benefits will be considerable if encryption is found to be a precondition for extensive use of the network services by clinicians. The expected costs are small in comparison with the costs of the IT facilities with which they would be used, and in proportion with the expected costs of networking
• the main manpower costs for the NHS will relate to the running of the pilot and subsequent implementations. For these, the NHS will need to provide a few tens of man-years of internal staff resource. There is the potential for approximately £250,000 worth of external expert security consultancy to assist in these programmes. The day to day operation of the TTP(s) will require only a handful of staff, at most eight full time equivalent staff. There will not be the need for many thousands of users to be trained up before encryption can be used
• the possible equipment costs for introducing encryption across the NHSnet could well be in the range £15M to £20M, spread over an implementation programme spanning several years. At the end of this programme, the annual on-going costs could be expected to be in the range £2.5M to £3M.

There are a number of established providers of the needed types of security products that should be able to support the NHS's needs, allowing the NHS to enjoy the benefits of a competitive marketplace. The central management facilities could be provided in a number of ways including either as a bespoke development for operation by the NHS or as a Private Finance Initiative for operation by an external trusted third party service provider.

2 Introduction

However, a number of technical barriers which have made the use of encryption by the NHS difficult in the past have been lowered recently. These include general product developments in the cryptography marketplace, greater experience in the security management of large and diverse networks, and a change in policy and approach by the relevant government department (CESG the Communications-Electronics Security Group). These have, amongst other things, shown that encryption can be employed by organizations which are large and diverse and which do not follow a strictly hierarchical organisational structure.

As a result, and mindful of the possible need for such services, the NHS Executive in September 1997 commissioned Zergo Limited to undertake a study to investigate the ramifications of providing encryption and related services across the NWN.

The Objectives of the study were:

• to examine the contexts in which encryption and other data security services would be required for the exchange of Person Identifiable Data across the NWN
• to describe suitable techniques for implementing these security services
• to identify and describe the many different impacts the recommended facilities would have on the various parties involved in the use and operation of the NWN, including the likely benefits and expected costs for each stakeholder
• to identify and discuss an implementation approach appropriate to the particular environment of the NWN where the end-user organizations enjoy a great deal of autonomy.

The organization of this report is as follows.

• Section 3 discusses the expected uses of cryptographic security services on the NWN. It presents a number of contexts which characterise the transmission of Person Identifiable Data over the NWN, and derives the constraints that the implemented security services would need to satisfy
• Section 4 describes the recommended technologies for providing the encryption facilities. It considers a number of possible approaches and identifies that which would provide the NHS with the most strategic solution
• Section 5 describes the ramifications of implementing NWN encryption according to the recommended approach given in Section 4. It covers the expected impacts of the provision and use of encryption, covering both management and technical issues. It presents a view of the major risks involved, the tasks that the NHS will have to undertake, and the broad timescales and costs that could be expected
• Section 6 presents the likely benefits to be gained from the use of encryption and related services. It discusses these for each of the main stakeholders in the NWN, and shows how the likely benefits relate to the expected costs
• Section 7 outlines an implementation programme showing the route by which the NHS can address the outstanding management and technical issues and prepare for piloting and implementation.

• Appendix B discusses the general form of the encryption facilities that would be needed. It describes the implementation options to hand and how different options might be appropriate for different contexts
• Appendix C discusses the issues relating to the choice of encryption algorithm and key management infrastructure, and makes recommendations regarding the selections to be made.

The Terms of Reference for the study refer to a number of services relating to the protection of data exchanged across the NWN. These services, primarily the use of encryption, form just a subset of the full range of security services to be found within the overall IT security framework and security infrastructure needed for the protection of NHS data. Consequently, only a subset of the security threats applicable to NHS data has been addressed within this study, principally those that arise from eavesdropping on or tampering with data transmitted across the NWN. Other threats are being addressed separately, for example:

• unauthorised access to systems holding sensitive data, owing to insufficiently effective system access controls (the sharing of passwords, unattended terminals being left logged in, etc.)
• inappropriate use of authorised access privileges by NHS staff (for example, through bribery or coercion, or, as is believed to have happened recently, as a consequence of a member of staff assisting someone else whom it was incorrectly assumed was authorised to request the confidential information)
• eavesdropping and tampering on internal LANs within hospitals, offices, and practices
• reduced effectiveness of existing controls through a lack of IT security awareness and general security understanding by users and operators of IT systems.

Finally, it must be noted that this study has been commissioned by the NHS Executive in England in the context of the use of encryption on the NHSnet available to the NHS in England.

3 The context for security services

3.1 Security Threats

• the possibility of unauthorised individuals logging on to the network
• the possibility of eavesdropping on network traffic.

It can be argued that that the type of Person Identifiable Data which will shortly be passed over the NWN has in the past been transmitted between healthcare professionals by mail or by telephone, and that similar risks of disclosure have long existed. However, it is important to realise that the use of electronic means of communication does introduce new security threats and security risks. For example, it is relatively easy to automate the process of sifting through a large amount of text-based message traffic searching for key words and information of particular interest. This kind of eavesdropping is a threat to communicated Person Identifiable Data and is less laborious than that of steaming open mail or tapping telephone conversations.

• deliberate alteration of a message for some malicious purpose such as fraud or sabotage
• the introduction of messages by one user purporting them to have been sent by another (spoofing, for example to obtain confidential data by deception)
• repudiation of a message sent earlier by the sender (for example, the potential disowning of a negligent pathology result).

3.2 Communications Contexts

Looking closer across the many dataflow contexts that need securing, the characteristics of the sum total of the data flows are that it:

• can involve almost all users, each communicating, potentially, with many others
• can touch almost any link of the NWN
• will involve many systems, both national and local
• will involve many different IT platforms, some of which will be relatively new high-specification platforms but most of which will be relatively low-specification platforms
• will involve a variety of higher level communications protocols.

Also, with time, it is expected that the development of more sophisticated health care systems will lead to the exchange of more comprehensive and, therefore, more sensitive clinical data over the NWN. New applications of networking in the health environment are already appearing which also bring further confidentiality demands, for example remote consulting. This particular example would require confidentiality protection of multiple synchronised channels, and possibly of digital mobile radio channels, carrying voice and image as well as data.

From our study of the characteristics of the communications contexts we derive the conclusion that, if encryption is to be effective in preventing eavesdropping and in preventing outsiders not equipped with the necessary technology and encryption keys from communicating with networked systems, then it should be capable of being made available at all endpoints in the network and in a form capable of protecting any data transmitted to any other endpoint.

What is required to achieve this is not so much a single encryption product as a general encryption service based upon a family of encryption products, a service which can be used to protect any type of communication involving any pair or group of NWN network endpoints. The protection needed will be against eavesdropping and to prevent anyone, either insiders or outsiders not equipped with the necessary encryption facilities and keys, from communicating with networked systems.

• pathology/radiology test results (integrity protection and source authentication)
• referral details (source authentication)
• items of service (source authentication and non-repudiation).

It is worth remarking that the contexts studied place a range of different performance requirements (in terms of response time and throughput) on any cryptographic service. At one extreme, there are pure messaging applications, for example the transmission of pathology test results. A several second delay for cryptographic processing would be unlikely to cause problems for the users. At the other extreme is remote consulting where high bandwidth data streams would need to be encrypted with minimal delay and in real time.

The table below summarises this situation.

3.3 The IT environment

• a wide variety of hardware and operating system platforms, ranging through mainframe MVS systems, UNIX systems, VMS systems, more unusual operating systems such as PICK, and of course PC-based systems running under network operating systems such as Novell and Windows NT as well as DOS and Windows
• the continuing use of obsolescent hardware platforms such as outdated PCs with limited processing power
• application programs spanning a wide range of qualities of design and of support. These include user written applications, applications where the supplier has since gone out of business, and applications where the design and documentation is so fragile or so poorly understood that they cannot safely be modified.

4 Recommended approach

This section, and the remainder of this report, employ a number of technical terms which may not be familiar to some readers. Appendix D contains a glossary to assist the interested reader.

4.1 Introduction

Adding encryption across the NWN as a whole has recently become technically feasible. And, drawing on the wealth of experience available from the Financial Services sector, the operation of encryption across a wide and diverse user community (of many thousands of users) has been shown to be manageable. It is not necessary for the encryption facilities to be implemented everywhere at once. A planned and phased implementation programme can be adopted with the benefits of encryption beginning to flow from the start. The implementation process will require care and effort, and the implementation programme is expected to take several years to complete. A number of technical and management issues will need to be addressed in the early stages. For those users in need of encryption capabilities in the short term, alternative interim options are available. These are discussed at the end of this section.

4.2 Choice of Encryption Algorithm

For the suppliers of encryption products, the NHS would represent a large user community, and this size of potential market would encourage the development of an active and competitive market in Red Pike products. Also, the NHS is not alone in wanting to encourage the development of an active Red Pike marketplace. Many large international Organizations outside the Financial Services sector are in need of similar encryption facilities. And, at the same time, HMG has a number of initiatives currently underway which will lead to the development of Red Pike-based systems. For example, a CCTA-driven initiative to allow suppliers to government departments to submit proposals electronically, and an Inland Revenue-driven initiative to allow small businesses to file Tax returns electronically. These Organizations should add their weight to the NHS's to encourage a wide range of commercial off-the-shelf (COTS) products to be developed.

4.3 Technical Approach

• reusability of the security software - to allow the host's local security facility to be used by more than one application if needed
• versatility of the security software - to allow the security facility more easily to meet the varied needs of different systems or contexts
• independence of the security software from the networking protocol (EDIFACT, SMTP, File Transfer, etc.) allowing the one security facility to be used across more than one networking protocol, and protecting the security facility from needing to be changed whenever changes are made to the networking protocol
• more cost-effective security - wherever multiple NWN links are involved in the transmission of data between end-systems
• increased security coverage - where it might facilitate protecting sensitive data within some parts of end-systems prior to its delivery to the NWN.

Encryption facilities will be needed in a variety of forms according to communications context and IT platform, and should be provided in a range of forms to meet this need; there is no single solution to meet all needs.

The encryption facilities could be needed:

• most often implemented in software, but they may need to be implemented in hardware in a few situations where performance criteria mandate it (such as for the encryption of links between acute units and the suppliers of their Facility Managed IT, or for high throughput/short response time applications such as tele-medicine)
• in some cases as a Security API (a piece of service software called directly by the business application, that delivers a standard set of cryptographic functions through a highly structured standard interface) for application systems or networking systems to call
• in some cases built into the lower levels of the networking infrastructure itself where it could, for example, intercept calls to communications software so it could encrypt or decrypt the transmitted data. Solutions of this kind would be needed where more complex internal modifications to an existing application would not be feasible, or where constrained by timing or migration issues

• the possible need for the encryption and key management facilities to be built on to provide, in addition, Digital Signatures for message protection, message source authentication and non repudiation, and/or to support the strong authentication of people or systems. These are the two most important needs after encryption, and would usually favour an API-based approach to encryption.
• the need to avoid impacting the end-system for reasons of urgency, reducing cost or reducing risk. This would usually favour a network-level approach to encryption.

4.4 Take-up of the encryption facilities

The encryption facilities could at the same time, also be implemented in the form of a general purpose security package independent of any one system or context, for example as a general purpose message/file/data encryption package such as PGP (see Appendix C), though PGP itself would not be appropriate to the NHS's needs1. If equipped with a suitable general purpose package, the user would be able to use encryption or not according to an explicit decision that they would make at the time as to whether the traffic they were about to transmit warranted its use.

Hence, there are a number of routes by which users might arrive at the use of encryption, as follows:

• by default, because the use of encryption had been written into the application
• by choice, because in view of their judgment of the risks the users requested the system provider to implement encryption with the system, and they accepted the extra cost
• each at their individual discretion, where they would have a general purpose encryption utility such as a secure E-mail package and they could decide on a case-by-case basis that a particular message needed to be encrypted.

[Footnote 1]

1 As is discussed in Appendix C, PGP has a number of shortcomings in this context. The main shortcomings are:

• it is designed for a messaging environment and would not be usable for interactive communications
• it uses an algorithm controlled by a single Swiss company
• it does not integrate well with commonly found of office e-mail packages, making it difficult to use for the non-technical user
• its key management does not make it easily scalable beyond small numbers of users.

• for some applications, such as national applications, there will need to be central policy defining where and how the encryption facility is to be used
• for other systems, there will need to be standards or guidance developed to help the users determine if the cost of encryption is warranted given the risks. As these will impact suppliers to the NHS, the NHS Executive should have an interest in what standards or guidance are provided. The NHS Executive may wish to co-ordinate and drive the development of these standards or guidelines
• for general use encryption packages, the users may wish to seek guidance on when to use encryption and when not.

In the case of existing applications that might need to be upgraded to use encryption, it will be necessary for developers to incorporate the encryption facilities in to the existing system following the analysis of a business case comparing the perceived needs and expected costs.

4.5 Trusted Third Parties

The TTPs would not require a large establishment for their daily operation. TTP services could be provided by one or more external service providers or by the NHS itself. As the keys being managed will include end-system keys, not just network keys, the TTPs should not be provided by the NWN suppliers as part of the NWN service. Indeed, the TTPs could be used to manage a wide range of cryptographic keys, not just those associated with the use of these Red Pike encryption facilities, and to provide associated services which are not essentially cryptography based. For example, if there were the need, a TTP could be used to provide a general Directory Service for the NWN. The NHS will need to investigate the liability issues associated with the operation of these TTPs (for example, any liabilities that might arise from errors leading to the creation of a key certificate for an unauthorised user), to determine whether there are any constraints or limitations on the TTP services being provided by external suppliers or whether they would need to be provided by NHS entities, and to determine for itself the services they could be allowed to provide and the operational constraints and controls that will be needed.

4.6 Key Management Infrastructure

A D-H key management infrastructure would not preclude the use of other algorithms, for example RSA, if that were needed for interworking with other systems such as those in use in other European countries. A D-H based infrastructure could easily be extended to support DSA (a standard Digital Signature algorithm) based functions which could then be used for the generation of suitable RSA (or, for that matter, DSA) key certificates.

The actual design of the NHS's key management infrastructure will emerge in the early stages of the proposed pilot programme (see Section 5.1). The first stage of the pilot will carry the main burden of establishing the core key management infrastructure. Hence, the design for this will need to be covered early in the pilot. Though it would not be wise or appropriate to design the key management infrastructure within this study, the expected general shape of the infrastructure can already be sketched out (see Appendix C).

4.7 Short-Term or Interim solutions

Other interim solutions are possible but have disadvantages, as follows.

• the use of other available government algorithms. The National Technical Security Authority, CESG, has a number of encryption algorithms both hardware and software, one of which, Rambutan, (a hardware chip) might be used where more sensitive information needs to be protected and/or high bandwidth communications are required. A small number of trusts have already investigated the possibility of using Rambutan equipment for network protection. This algorithm is available only within hardware devices, not in software, and is not available to all NHS users as Red Pike will be, which is why it has not been recommended here as part of the strategic approach. However, its use could be suitable in some particular situations
• the use of published and available algorithms. For example, some users might wish to use the E-mail security package PGP. There are a number of substantial reasons why PGP cannot be considered as a strategic solution (see Appendix C and the earlier note in Section 4.4). PGP users would need to be aware of the shortcomings of this package and would need to accept these and the associated risks if they were to use it
• the use of unpublished but available algorithms. Some users might wish to use proprietary algorithms, for example RC4 which is used in a number of Internet applications. These algorithms are either not sufficiency widely available (being controlled by a single vendor, or under other restrictions) or, if they are widely available, are recognised to be of inadequate strength. The widely available form of RC4 has been shown through published attacks to suffer from this latter shortcoming. The users would need to be aware of these problems and would need to accept the associated risks if they were to use such algorithms.

5 Implementation issues

5.1 Management Issues

1. For many not familiar with the subject, the issues relating to the use of encryption and key management can seem complex and obscure. The NHS will need to present its security decisions and proposed encryption approach carefully when dealing with the many stakeholders. These include primarily:
• clinicians and health care professionals
• clinical professional organisations, such as the BMA
• health care managers
• end-system owners
• system and network service suppliers
• press and public.
Each will have its own interests and legitimate concerns, and will require specific attention from the NHS.

Zergo believes that each stakeholder should be able to support the recommended encryption approach. Significantly in the NHS's favour is that, by using Red Pike, the NHS will (subject to independent confirmation of the strength of the algorithm - see Section 5.2 below) be using a stronger encryption algorithm than the Data Encryption Standard (DES), an algorithm that has been used for over ten years within the Banking sector. This should assure all concerned that the NWN can be a suitably secure vehicle for the exchange of confidential Person Identifiable Data. In addition, the NHS can demonstrate that it has sought and taken expert advice from both HMG s security advisors and from independent experts on the cryptographic tools it should use. Zergo is confident that no significant criticism of the Cryptographic adequacy in today's environment of the NHS's current encryption proposals should remain outstanding.

[page24]
2. The implementation of encryption facilities across the NWN will need to be taken carefully. The NHS will need to develop an implementation strategy that includes a staged encryption pilot, and carefully staged subsequent implementations, that takes full account of the many management and technical issues involved. Migration to the new cryptographically enabled versions of standard applications will require particularly careful planning.
3. The NHS will need to decide which section within the IMG should be responsible for managing the programme of implementing encryption on the NWN. The whole implementation programme will be quite complex to manage and will require a high level of senior management commitment and support.
4. As has been mentioned, Red Pike is a non-published algorithm supplied by CESG. CESG has made a number of significant national policy decisions concerning the release and supply of Red Pike encryption facilities for use by the NHS. When the pilot is being defined, and in particular when the detailed key management design is being developed (see below), there may be a few residual policy decisions needing to be made by CESG.
5. The NHS may need to steer an intermediate course between forbidding the use of the NWN for the transmission of certain types of data in unencrypted form (which might be unacceptable to some users) and leaving it to the users unaided to decide whether to use the encryption tools that are offered. This latter option would require a high level of security awareness from the users, and this is not likely to be present generally across the user community.

An Executive Board policy decision would be needed on the approach to be adopted with respect to the take-up of encryption facilities within NHS systems and the NWN. It will need to be decided where the responsibilities should lie for deciding on the extent to which encryption should be used, and on what would be considered suitable timescales over which the take-up of encryption should occur. Then, guidance will be needed for system owners to support them in complying with the policy, and for system providers to help them interpret the policy consistently. The NHS might wish to facilitate a forum of user representatives and other interested parties which issues guidance to the wider user community on the use of the encryption facilities with the NWN. This presents the NHS management with an opportunity to take the initiative on the setting and presentation of security issues and standards. The guidance would need to be written in the context of the current Data Networking Security Policy, Guidelines, and Codes of Connection.

[page25]
6. A strategy will need to be developed for supporting the introduction of encryption facilities into new and existing applications, as described below.
7. suppliers of existing NHS applications may need encouragement to integrate cryptographic security into their systems - perhaps through the existing Accreditation process
8. injecting requirements for added cryptographic security into projects already running as Private Finance Initiatives may disturb the underlying business case and thus be resisted by the developers, or lead to a repricing of the service provided
9. the additional costs of implementing cryptographic security may impair the business case for some systems which do not have the prospect of a large customer base. It may never be cost effective to migrate some legacy systems (older generation systems) or "dumb" systems to incorporate cryptographic security.
10. The legal, commercial and Organizational issues surrounding the creation of Trusted Third Parties will have to be investigated. These will need to include:
• the Terms of Reference for establishing the TTPs
• the need for or form of charging for the TTP's services
• Legal conditions under which TTPs will be able to release information under their control or care
• to whom TTPs will release each category of information
• the liabilities that will fall to the operators of the TTP, to the NHS centrally and to the NHS user in the event of a failure in the TTP's controls
• what kind of entity could be acceptable as a TTP, eg.:
• NHS central Organization
• A Trust
• Specialist commercial security organization
• Government department.
The pilot will allow these TTP issues to be exercised and will help the NHS to determine its long term position with regard to the provision of TTP services. From these and related considerations, the NHS will then be able to determine its requirements for controls on the TTPs. The contracting of TTP services will then need to be framed with attention being given to the relevant legislative frameworks as they exist within English law.

5.2 Technical Issues

1. As Red Pike, the recommended encryption algorithm, is not yet well known and, as a consequence, has not yet achieved wide acceptance in the public domain, it should be subject to independent review by an expert who is acceptable to the commercial and public domains as well as to the owners of the algorithm, CESG. The objective of this will be to obtain authoritative assurance that no agency external to the NHS could reasonably decrypt data which has been encrypted by the NHS. This review will be an important part of the NHS managing the presentation of its encryption approach. It will also give the NHS confidence that its interests are being properly represented by CESG when it advises on the use of Red Pike.
2. The newness of Red Pike means that, though there are already a number of suppliers that can provide Red Pike cryptographic tools, there is currently only a limited range of products available. However, given the size of the NHS market alone, as the NHS makes these suppliers aware of its needs it can expect that appropriate products will be developed to meet these needs. This need for new product development will add to the technical risks of developing NWN encryption. However, Zergo believes that the additional risk will be slight given that Red Pike has been designed to allow it to be used in conventional products as a simple replacement for conventional encryption algorithms.
3. Some of the systems used by the NHS may also be marketed by their suppliers for use in other countries in addition to the UK. Suppliers will be looking for architectural solutions to adding encryption to their products, which are capable of adaptation for use in those countries. Solutions based on high-level APIs, International Standards or de-facto standards, and modular cryptography, as recommended here, will likely be more acceptable in these situations.
4. Early in the development of the NWN encryption pilot, it will be necessary for the NHS to develop a detailed Key Management design for the core of the key management infrastructure. This will be highly specialised work requiring expert cryptographic assistance. Zergo advises that the NHS should, at this stage, also seek further input from CESG to confirm that the resultant scheme is of a sound design. CESG is expected to be strongly supportive of the NHS's development of a key management infrastructure and can be expected to offer its assistance in this and various other stages of the pilot development.
[page27]
5. The NHS will need to define a set of technical standards for cryptographic security to ensure both conformance with the agreed key management arrangements and reliable and secure interworking between applications. The standards will evolve as each of the pilot and implementation stages is executed, and will cover topics such as the frequency of key changes for each main class of application or device, the need to use a new key with each message rather than to have static message keys, and so forth.
6. There are a number of formal schemes which the NHS could use for this evaluation process, and the most appropriate of these would be the ITSEC/ITSEM scheme jointly administered by the DTI and CESG to provide commerce / industry and government customers with assured IT security products. (Although government high security projects have been the main customers for this certification scheme, more general acceptance by industry has been encouraged by a recent reciprocal arrangement with Germany, whereby, to a certain level, each nation's ITSEC certificates can be recognised by the other.)

However, there are many drawbacks associated with the use of the ITSEC/ITSEM scheme for software products, chiefly those of cost and delay. Other options include the use of expert and independent system testers but without using the formal ITSEC/ITSEM methodology, and the use of the NHS's own IT resources. The NHS would need to evaluate carefully whether to use the ITSEC/ITSEM scheme or one of the other evaluation options.

7. The NHS will need to identify a small number of candidate systems for use in the encryption pilot programme. The NHS-Wide Clearing System (NWCS) may well be a suitable candidate for the first stage of the pilot, and there is already in place a plan to pilot the use of encryption with the NWCS. This NWCS encryption pilot is, itself, having to address the same issues as have been addressed in this study regarding the selection and use of cryptographic and key management tools. Hence, it should not be disadvantaged by being used as the first NWN encryption pilot.

It will be desirable to have more than one system used within the pilot programme, in order to prove the feasibility of encryption across the wide range of different systems. For example, it will be important for one of the pilot systems to be one which involves GPs directly. Consequently, the pilot should be a staged pilot with each stage being of successive complexity.

[page28]
8. CESG has not taken detailed performance measurements for Red Pike as these would vary according to the application and platform concerned. The NHS will need to obtain precise performance figures applicable to the range of IT platforms that the user community is expected to use, preferably before the design of the pilot is commenced. However, having seen a description of the algorithm, Zergo would expect that its performance will be acceptable and, indeed, has the capability to outperform many existing encryption algorithms such as DES.
9. The secure storage of secret cryptographic keys will have to be addressed for each of the different types of end-site attached to the NWN. In situations where all the cryptographic functions are implemented in software to reduce cost, the storage of secret keys on disk always brings some residual risk of disclosure or unauthorised access to the keys, even when the keys are themselves stored encrypted under some other key. An alternative way to protect the keys is to store them on some kind of removable medium or token. It is expected that, increasingly, NHS users will be using smart cards for system access and then the users keys could be stored on the smart card itself instead of on the user's workstation. A number of other such options can be identified. In all cases, it is important that, for any system, its detailed design gives adequate consideration to the issue of recovery from the loss of such a token. Once the implementation has started and before it has completed there will be a considerable period of time during which some but not all of the end users will have been encryption-enabled. This raises an issue to do with managing the interworking between users and applications where some will and others will not be equipped with encryption facilities. The staged implementation programme where whole systems are brought on-stream one at a time should minimise the size of this issue. It may become necessary in some situations to allow the user the discretion to determine whether or not a message should be encrypted depending on whether the recipient is capable of decrypting such a message. In practice, each situation will have to be examined and appropriate choices will have to be made on a case-by-case basis.

5.3 Costs

5.3.1 Introduction

• planning and outline specification
• procurement, design, development, testing and implementation of the pilots
• possible cost of earlier replacement of any systems not suitable for upgrading to introduce encryption
• running the pilots
• updating the Accreditation Specifications
• system migration and implementation
• training
• operation, maintenance and support
• review and on-going enhancement.

Below, the general size of the possible lifecycle costs of introducing encryption and other security services onto the NWN are indicated, grouped separately into manpower and equipment costs. It must be stressed that, for both groups, these costs are only indicative and should be taken as broad planning estimates, not as upper limits. The actual costs to the NHS will, of course, depend on many parameters including the balance between the use of NHS staff and outside assistance, the balance between hardware and software implementations, and so forth. Whilst it must be understood that the costs are only indicative, every effort has been taken to ensure that the costs given are reasonable and useful.

5.3.2 Costs Summary

We use two different global cost models to calculate the possible equipment costs for introducing encryption throughout the NWN. The purpose of these two models is to show the order of magnitude of the equipment costs for two widely differing models with different assumptions as to how the facilities would be implemented. These two models should not be taken as giving upper and lower bounds to the possible total costs. Indeed, the two results derived are still of the same order of magnitude as each other. Hence, we can conclude that the possible equipment costs for introducing encryption across the NWN could well be in the range £15M to £20M. These would be spread throughout the implementation programme which would last for several years. At the end of this, the annual on-going costs could be in the range £2.5M to £3M.

5.3.3 Manpower Costs

Running the pilot
Each stage of the pilot should be operated for at least six months, assuming it is successful. During this time there will be phased evaluations to ensure that the results of the pilot stage are taken on-board as they become available. This task can be performed primarily with NHS staff.

Updating the Accreditation Specifications
At some intermediate stage, the Accreditation Specifications for GP systems will need to be amended to include the encryption facilities. The changes to the specifications will need to be agreed with representatives of the GP systems supplier community and signed off by the NHS Executive. A period of time, at least a year, will then be needed to allow the suppliers to respond to the changes. This task can be performed primarily by NHS staff with some expert security consultancy assistance. Possible security consultancy fees - £20,000.

System Migration and Implementation
The cost of this part of the programme is largely the cost of bringing each new system in under the security umbrella. For each system there will be the normal planning, design, development, testing and implementation cycle, and this cost will vary widely according to the nature of the system and the manner in which encryption is added. Different approaches to covering the costs may well be appropriate for different types of system:

• General Practice Systems
• Acute Unit Systems
• Community Systems
• National NHS systems (NHS-wide Clearing Service, etc.).

The resourcing required for the development of the encryption facilities by the system vendor will be borne by the NHS within the equipment costs of the products purchased. For further guidance on what these costs might be, see the equipment costs given below.

Training
The encryption facilities should operate with a high degree of automation and the users should not need a high level of training in their use. A degree of user security awareness training could be beneficial but this would be general training and would not need to be specific to the use of the encryption tools. Specific training will be required for the operators of the TTP, and it is assumed that this would be provided as part of the development of the TTP (see below). Possible cost of training the TTP operators - at least £20,000.

Operation, Maintenance and Support
The first TTP will require a small team of staff to handle the initialisation of the users? security facilities in whichever form they are implemented, and for the periodic management of high-level cryptographic keys. The lower-level keys will be managed automatically. The level of staffing at the TTP will depend on the rate at which users are brought onboard, the need to operate dual-control over some of the more sensitive TTP operations, and the need to provide cover for absence (holidays and sickness). It is not expected that the TTP would need to provide support out of normal daytime working hours; the period of cover provided each day could be determined according to perceived need. On this basis, a manning level of four to six staff is suggested. During periods of active implementation, these staff may be fully utilised; during steady-state operation of the TTP, they need be only part-time utilised, allowing them to perform other tasks. It is assumed that maintenance and support of the equipment (TTP and user equipment) would be provided as part of the equipment purchase costs.

either

• remain with a single TTP, having the pilot m be established as the single management point for all NHS encryption-enabled systems, taking each system under its cover as the encryption facilities are increasingly widely implemented

• decide to develop further TTPs as each stage of the implementation progresses, with each TTP having a specific community of users that it supported.

Review and On-going Enhancement
There will be the need to monitor the performance of the encryption infrastructure and there may, periodically, be the need for its enhancement. These will become apparent as the use of encryption advances within the NHS and cannot be predicted. They will fit within the normal cycle of infrastructure development.

5.3.4 Equipment Costs

5.3.4.1 Component Costs

5.3.4.2 Costs for example situations

5.3.4.3 Total Cost to the NHS

In view of imponderables of this nature, costing based on detailed analysis of systems would require a large number of assumptions and could not be accurate to better than an order of magnitude. We have, therefore. here, derived costs based on two grossly simplified models representing two extremes of implementation, in order to show the range of costs that might be experienced. All the costs are based on current values and make no allowance for inflation or for depreciation.

[Footnote 2]

2 The analysis focused on systems "owned by" acute/community/primary organisations. There are a number of patient-based systems that do not fit within any one of these categories such as Breast Screeening, Organ Donor, etc. To cover these, the costs for an additional 15 systems was added.

Information about the above systems is not complete. Details about the number of different systems used within the NHS and the number of major versions of these systems will need to be reviewed. For purposes of high-level costing, it is assumed here that there are four versions or types of each of the above systems.

6 Benefits

Patients
Patients will benefit from the actual increase in security on the NWN, and the level of benefit will increase in time with the degree of implementation achieved. As Person Identifiable Data exchanged over the network is increasingly protected, the risk to the patient of its disclosure and the possibility of embarrassment or consequential financial penalty, will fall. Patients will also benefit from having increased confidence in the practices of the NHS, and from the increased quality of service provided by the healthcare professions that will come with the increased automation and networking of NHS systems enabled by NWN encryption.

Clinicians and health care professionals
These will benefit from being able to make wider use of the NWN so that they achieve a reduction in bureaucracy and give better service to their clients. Lack of encryption may have been a barrier to this in the past, and this need no longer be the case with the introduction of encryption-enabled systems. The level of benefit will increase with the extent of the implementation of the encryption facilities.

To the degree that the encryption facilities are used to provide services other than network encryption, the clinicians and health care professionals would be able to protect confidential information in their care against other threats. For example, the use of encryption to protect data stored on PCs or hand-held equipment would protect the data from disclosure if the equipment were lost or stolen.

Health Care Managers
Health Care Managers are responsible for the end-systems and are, amongst other things, responsible for ensuring that their systems are adequately secure for the purposes to which they are to be used. To the degree that their systems are exposed to networking security risks and these risks are not otherwise covered by other countermeasures, the addition of encryption to the NWN will provide them with an effective tool to manage those risks. Encryption could be added in a way that was responsive to the business need and technical environment. They will then be able to direct their attention to addressing the other non-networking security risks to their end-systems, and to fulfilling their responsibility to manage the full profile of risks faced by their systems. Health care managers will also benefit from being able to develop systems and automate processes that could not have been developed or automated without the improved security facilities that would now become available.

The NHS Executive

1. Overall, the level of security risk faced by NHS systems will be reduced as network security disclosure risks are reduced.
2. The provision of encryption will encourage the wider use of the NWN for mainstream applications. Hence, encryption will allow the NHS to realise more fully the considerable benefits associated with the NWN. Also, having the encryption and related capabilities in place will be an important enabler of future IT initiatives allowing new systems opportunities to be realised.
3. The API approach to encryption proposed as part of the recommended approach can easily be extended to provide the functionality needed to deliver message integrity protection, user authentication and message source authentication. Encryption in a variety of forms can also be used to support the stronger enforcement of access control across systems, though care must be taken to ensure that it does not interfere with or run across the desired access control systems. Consequently, the strategic approach provides the NHS with a highly cost-effective manner of addressing these further security concerns.
4. Depending on the particular form of their implementation, some of the technologies proposed to satisfy the need for encryption on the NWN can be used to address security needs which exist outside the NWN, including the encryption of data transmitted over other networks such as local LANs, the encryption of data stored on hard disks, the management of cryptographic keys for non-NWN systems, and so forth. Consequently, again, the strategic approach provides the NHS with a highly cost-effective manner of addressing these further security concerns.
[page43]
5. Though the study here has focused on the protection of Person Identifiable Data, there is nothing in the technology or approach recommended that restricts its use to this type of data. The encryption and related facilities could . be used to protect any sensitive data exchanged across the NWN including contracting and management data.
6. The result of following CESG's advice in the choice of encryption algorithm is that (subject to independent confirmation of the algorithm's strength - see Section 5.2 above) the level of security provided on the NWN will be higher than that in many conventional Banking systems. This will help the NHS to counter any criticism of the NWN's security approach in so far as confidentiality is concerned.

7 Implementation

7.1 Preliminary Confirmations

1. The NHS will need to have further, more detailed discussions with CESG to:
• understand the details underpinning CESG's position regarding the use of encryption in the NWN, to air any particular concerns regarding, for example, the availability of Red Pike to non-UK systems providers, the possibility of the NHS being allowed to use alternative algorithms, expectations regarding a possible national key management infrastructure and so forth
• agree on any outstanding policy decisions that CESG may need to make
• determine what assistance CESG may be able to provide to the NHS as it puts its encryption strategy into practice.
2. The NHS will need to confirm the cryptographic strength of Red Pike by obtaining an independent expert view. CESG has already indicated its willingness to allow such a review, and the precise Terms of Reference for the review will need to be agreed with them.
3. The NHS should seek legal advice on the possible implications of the legislative framework as far as this might affect its use of TTPs.
4. Investigate the extent of any support or assistance that might be available from other government departments, for example from the DTI, to assist in the development of parts of the key management infrastructure.

7.2 Planning and Outline Specification

1. Confirm its strategy for cryptographic algorithms and key management in the light of the results of the above steps.
2. Decide, what controls it might wish to have put on access to keys held at the TTPs.
3. Build a Project Strategy that covers staged piloting and staged implementation. Decide on the pilot projects and determine whether to use the Clearing Service for the first stage of the pilot. Decide on an initial outline implementation programme. This can carry implications regarding the preferred order of priority for protecting NHS systems using the NWN. Obtain an Executive Board decision on the approach to be adopted with respect to the take-up of encryption facilities within NHS systems and the NWN, and on what would be considered suitable timescales over which the take-up should occur.

7.3 The Pilot Programme

Major steps within the first stage of the pilot would include:

1. Arrange for the necessary budget provisions for the Pilot programme to be made.
2. Identify the objectives of the piloting exercise and from the results identify suitable applications and areas of the network for involvement within the Pilot. It will be necessary to strike a balance between choosing applications and areas which are representative of the main problems which will be encountered in full implementation, and ensuring that the pilot remains manageable. Consequently. there may be a need for more than one pilot stage, each successive one of increasing technical complexity.
3. Develop an overall plan for the pilot programme.
[page46]
4. The preparation of a number of technical standards and specifications will be needed. Wherever possible, these should be based on existing standards. The following will be required:
• key management standards
• specification for the key management systems at a trusted third party
Depending on the nature of the pilot implementation, the following may be required
• standards for cryptographically protected exchanges in the NWN
• an API specification for a standard cryptographic software architecture "tool kit"
• for each application involved in the pilot, a specification for adding the cryptographic capabilities.
5. Agree a contractual basis for the participation of both suppliers and users in each stage of the pilot.
6. Ensure the availability of appropriate types of cryptographic software and hardware products that might be required.
7. Develop the first stages of the key management infrastructure as necessary for the first stage of the pilot.
8. Design, develop, implement and test any modifications necessary to enable each of the applications and systems involved in the pilot to make use of encryption.
9. Carry out a security awareness programme for the users including any specific guidance necessary for users to understand and use the cryptographic facilities provided under the first pilot project. Develop the training needed for the operators and management of the pilot TTP.
10. Implement and run the first stage of the pilot.
11. Carry out a preliminary evaluation of the results of the pilot at the earliest feasible milestone. Use these results to plan any changes to the remainder of the first stage pilot programme.
12. Carry out a full evaluation at the end of the planned pilot programme and adapt the plans for successive pilot stages and the preliminary planning for full implementation, as needed in the light of the results.

7.4 Main Implementation Process

Steps to consider in the implementation process would include:

1. Define any necessary criteria for agreeing priorities for implementing encryption in systems.
2. For each system, ensure that reasonable care has been taken by the system owner to make adequate budgetary provision for the security elements, including planning for the implementation and testing of the encryption processes.
3. Update and extend as needed the specifications produced at the start of the pilot programme. Produce any additional specifications needed for types of system not included in the pilot.
4. Develop and test any new technical features needed for the TTPs or key management infrastructure as implementation progresses.
5. Carry out further user security awareness programmes including any specific guidance necessary for users to understand and use the cryptographic facilities being implemented.

Appendix A

Terms of Reference from the NHS Executive

The use of Digital Signatures and Encryption in the context of NHS wide Networking

1. NHS-wide networking is intended to enable many-to-many communications for NHS users in pursuit of their legitimate NHS business. Much of this communication will be administrative, financial or statistical information but, increasingly it will include clinical information about patients such as referral and discharge letters, laboratory requests and results, and contract minimum data sets.
2. In order to ensure that the network architecture is appropriate to future needs a study is required which explores the practical issues of using the following security services:
• Digital Signatures to provide strong authentication and integrity checking
• Trusted Third Party facilities for certifying encryption keys
• Encryption for confidentiality
3. The NHS Executive seeks advice on
• the purposes for which these services can be used, the contexts and the extent to which they might be used in each context
• the probable costs and benefits which would accrue in each context, and to which parties they would accrue
• the most suitable standards and types of product to be used
• the additional costs and implications of providing these services on a national NHS basis in such a fashion that they are available for use when those communicating NHS information think it appropriate.
[page49]
4. The study requires sound and up-to-date understandings of the NHS and the relevant technologies. These are unlikely to be found in one person. The study team will need to include people with the highest level of expertise in each of these fields. The following issues must be understood:
• the complexity of the management arrangements of the reformed NHS and the complex interactions of the various groups of health professionals and other NHS staff
• the rich variety of IT systems in use and the measures in hand to install shared administrative registers and a nation-wide clearing service for contract data
• the available security standards for providing the services listed at 2 above
• the products that are currently available or could rapidly become available to the NHS to match the appropriate standards
• the complexities of key management in a very large organisation where there is a great deal of autonomy in its constituent parts.
Proposals are invited for carrying out this study. An early start is essential, but the completion date will be determined in the light of chosen study proposals.

Appendix B

An outline architecture

1. Encryption can be applied to the NWN in any of several ways. It can be applied:
• on a link-by-link basis (eg. GP system to NWN Point of Presence (POP), NWN POP to NWN switch, between NWN switches, NWN Switch to Acute system; in hardware or software) as illustrated in Figure 1
Figure 1
• or on an end-to-end basis as illustrated in Figure 2.
Figure 2
[page51] There are two principal ways in which end-to-end encryption can be provided:
• within the networking infrastructure (eg, within the TCP, X.25 or Frame Relay communications protocol; in hardware or software) as illustrated in Figure 3
Figure 3
• or at the application level (eg, GP system to Acute system) where it can either be built in to the application itself or called by the network service (eg. the User Agent in a messaging system) (in software, possibly with hardware to assist the performance) as illustrated in Figure 4.
Figure 4
[page52] The preferred strategy must be to favour providing the encryption facilities to the networked application whenever possible and only where needed on a case by case basis to provide it directly on the network itself. There are several advantages to be gained by this:
• reusability of the security software - to allow the security facility to be used by more than one application if needed
• versatility of the security software - to allow the security facility more easily to meet the varied needs of different contexts
• independence of the security code - from the networking protocol (EDIFACT, SMTP, File Transfer, etc.)
• information would not be available in readable plain language at intermediate switching points
• more cost-effective security- where multiple NWN links are involved
• increased security coverage - where it might be possible to protect the sensitive data within some parts of the end-system prior to its delivery to the NWN. For example this strategy might provide protection against eavesdropping in LAN systems.
2. Encryption can either be carried out in physically separate hardware units or it can be carried out by software running on end systems eg. GP System, PAS, Pathology system, Messaging user agent. Hardware solutions are generally more expensive than software solutions, and can bring associated problems of the control of shipments (under government regulations controlling the export of strong encryption algorithms). On the other hand, hardware will generally deliver better throughput performance than software.

Many applications in the NWN are of the messaging or file transfer type so that throughput is not a prime consideration. Cost is of importance, particularly at the GP end. Consequently, the software solution will often be the most appropriate. Having said that, there may well be some situations where hardware may still be appropriate, for example:

• remote diagnosis systems (teleconsulting), where the time available for encrypting/decrypting an image may be severely limited (here an alternative implementation might be software with hardware assistance)
• where an NWN link is replacing a leased line (eg. Kilostream or Megastream) carrying legacy system traffic, eg. acute unit to FM supplier link. Here simplicity is likely to dictate an implementation in stand-alone "black box" encryptors or an encrypting communications card or modem
• Router to Router links between local members of a natural community (likely to be implemented with stand-alone "black box" encryptors).
[page53]
3. Software encryption solutions can be chosen to operate at a variety of levels of the protocol stack. It can be argued that by positioning the encryption function high in the stack, encryption becomes independent of the functionality in the lower layers. This would make it possible to change the underlying communications protocol without affecting the encryption function, and avoid the need to decrypt and re-encrypt when passing the transmitted data through a gateway which changes the communications protocol. However, it is likely that there will be some situations where the application is not amenable to this. For example, a legacy system for which there is no longer a business case for its being changed, or for which the necessary programming and support skills are no longer readily available. In these situations, there can be case-by-case advantages to putting the encryption facility in the lower levels of the protocol stack. This may arise more often in the early days of the implementation programme and for legacy systems, less often as time progresses.

For any system, the preferred form of implementation will need to be determined by an analysis of the options and constraints. There should be no system or platform for which, if encryption or related services are required, it would not be possible to find a feasible implementation. Hence, encryption in one or other of the forms mentioned above should be feasible for mainframe or midrange host systems, client/server and PC-based systems, messaging and interactive systems, and so forth. It is believed that there are a considerable number of systems within the NHS which have been developed using MUMPS. MUMPS contains its own communications handlers and it has been suggested that these cannot readily be adapted to call encryption routines. If this is confirmed by further technical analysis, MUMPS systems may find they are not able to use the network-level security software option. In this case, they would be constrained to use other options, either application-level (Security API) software or network-attached (hardware) line encryption devices.

4. To allow interoperability between different implementations, software encryption must conform to a defined set of standards. There is a need to avoid the requirement for every application developer to become an expert in programming cryptography. These two considerations lead to the concept of defining a standard set of cryptographic software tools which present a standard Security Application Programming Interface (Security API). In a client/server environment, these tools may be provided by a separate cryptographic server.
[page54]
5. De facto standards are emerging for such Security APIs (for example, the GSSAPI - the Generic Security Services API). Most security product suppliers are already working with these types of standards. Variations in the software used to support these Security APIs will be required to port the Security API across different operating system platforms: eg. UNIX PC Windows, MVS.
6. Consequently, it is likely that different systems will favour different forms of implementation of the encryption facilities, and these should, therefore, be provided in a variety of forms according to context - there will be no single solution to meet all needs. The NHS should expect to use:
• mostly software, but there may be a need for a small amount of hardware
• in the short term, mostly software low in the communications stack to minimise the impact on the end-systems and the associated technical risks
• in the longer term, mostly Security API software called by application systems or networking systems, though retaining some instances where encryption is built into the lower levels of the networking infrastructure.
7. Where the Security API approach is selected, suppliers of applications may then have to modify their applications to make appropriate calls to Security API functions to encrypt traffic routed over the NWN.
8. New applications will be able to incorporate the requisite encryption facilities from the start within their design. Existing applications will need to judge the business case for adding in the security facilities. The API approach would often minimise the cost and effort of introducing encryption, and this would be a major benefit to that approach. But there may be cases where the developer does not believe a business case exists.

Appendix C

Algorithms and key management

Two entities exchanging encrypted data across the NWN will need to share common cryptographic keys whilst ensuring that the keys used for decrypting data are kept secret. The mechanisms for exchanging these keys securely must, as far as possible, be invisible to the users of the systems involved.

1. For data encryption, the NHS will need to use symmetric rather than asymmetric algorithms. This is to provide acceptable performance in software implementations, and compactness of code. Symmetric algorithms can also be used to provide message and data integrity protection, and source authentication, and can be used in strong methods of user authentication, but not for generating Digital Signatures.
2. Conventional symmetric algorithms that are in the public domain, for example, RC4 (40 bit equivalent key length - often found in Internet security products) or DES (56 bit equivalent key length - widely used throughout the Banking sector), would not be adequate to the NHS's needs. There are no stronger symmetric algorithms in the public domain which are not restricted in one way or another (by patent or by other controls) and which would, therefore, be available for use throughout the NHS.
[page56]
3. The published E-mail security package PGP would not be suitable as a strategic solution to satisfy the requirement for NWN encryption.
• PGP is designed for the one way messaging environment and could not be used for interactive communications
• PGP uses an algorithm which is patent controlled (the IDEA algorithm for which the patent is held by a Swiss company ASCOM). Hence, the NHS would be tied to a single algorithm supplier which was both a commercial organization and non-UK based
• PGP is available either unsupported as freeware or as a commercial version from a single supplier. Neither option would be attractive strategically to the NHS
• PGP does not define a mechanism for the convenient distribution of encryption keys. This would severely limit its suitability for such a large community as the NHS. It is also, for this reason, vulnerable to "man in the middle" attacks in which an attacker arranges for a sender of information to be provided with his public key in place of the public key of the intended destination of the information. The attacker is then able to decrypt the information and send it on to the true destination using the correct public key.

This problem can be overcome with the use of a Trusted Third Party (TTP), and, indeed, a TTP is required for the proposed solution. However, this means that PGP could not be used as a strategic solution in its current form. Its wide scale use would require the modification of the package by the supplier to include interfaces to a TTP infrastructure

• PGP does not integrate well with standard of office e-mail packages. For the non-technical user, PGP would require the development of a front-end to de-skill its user interface. Again, this means that PGP could not be used as a strategic solution in its current form
4. CESG has also advised that there are significant security advantages to using unpublished algorithms rather than published algorithms. However, unpublished algorithms will be either proprietary, unaccepted by the cryptographic community, or strictly controlled by the governments that have developed them. Any one of these would make the algorithm either unacceptable or unavailable to the NHS.
[page57] The NHS is, therefore, in the constrained position of needing to use an encryption algorithm that is sufficiency strong for its protection needs but which can also be made available across the NHS as a whole and to the NHS's many systems suppliers. Until recently, no such algorithm existed to be used by the NHS. However, within the last 12 months, this situation has changed. CESG has responded to this situation, which the NHS shares with many other large organisations outside the government or Financial Services sectors, by developing an algorithm known as Red Pike. The recommendation from CESG, and supported by Zergo, would be that the NHS should use this algorithm to meet its data encryption needs.

Red Pike has been released only recently and a number of necessary National Policy decisions were made by CESG in the last months of 1995 relating to its distribution and use. Red Pike can be implemented in software as well as in hardware, and in a number of forms to facilitate its use with a variety of systems and on a variety of platforms. There are no standards covering the use of Red Pike. However, Red Pike has been designed to share a number of characteristics with DES, for which there are many public standards. Hence, Red Pike could easily be used in accordance with those standards. And Red Pike can be released in appropriate forms to the NHS's suppliers, including those that are not solely UK-based.

5. Whenever a cryptographic algorithm is used for data encryption, one or more encryption keys will need to be exchanged or agreed between the two parties (the sender and the receiver) so that only the authorised receiver is able to decrypt traffic encrypted by the sender. This process is known as Key Management.

Among the users of the NHS-wide networking system, there will be many users of encryption and, for each user, potentially many other users for which it will require new or unique keys to ensure secure communication. Hence, for many of the users, and certainly when looking across the NHS community as a whole, there will be many keys to be managed. For this reason of very large scale, it will be essential for the NHS to have a Key Management infrastructure that includes the use of asymmetric key management methods.

This would exclude the use by the NHS of the most long-standing and, therefore. widely used key management standards (for example. the ANSI X9.17 standard). However, asymmetric key management methods have been used and well proved in large networks (many thousands of users) in the last five years, and suitable international standards are now in existence for these.

[page58]
6. There are two acceptable techniques for the asymmetric key management of symmetric keys. These involve the use of RSA or Diffie-Hellman (D-H) methods. Each technique could be used to provide an acceptably secure Key Management infrastructure. Each would lead to the use of one or more TTPs in a hierarchy if needed. Each could support the use of hashing, and of asymmetric Digital Signature techniques (using the RSA or DSA³ algorithms respectively).
7. HMG has, for a number of years, been developing its ideas for a national Public Key Management Infrastructure having what is known as Key Recovery (KR) capabilities. HMG's interest in Key Recovery is driven by its Law Enforcement needs. Papers describing schemes with this capability are now in the public domain for review and comment. It is expected that eventual national policy in this area, supported by legislation, will involve the use of KR capabilities shaped closely along the lines indicated by current papers.

It is strongly expected that the UK national scheme will be built around the use of D-H techniques. It is even more certain that the UK national scheme will not be built on the use of RSA techniques. Consequently, the advice from CESG, supported by Zergo, would be that the NHS should develop a Key Management infrastructure that uses D-H rather than RSA techniques.

8. The NHS should consider, when it designs the details of its key management infrastructure, whether it wishes to implement the KR capability within it or not. For example, the NHS should determine whether it would be necessary for the NHS itself, under suitable controls, to have the ability to decrypt selected traffic in order to check that the encryption capabilities it provides to the end users are not being misused for criminal or fraudulent ends. The NHS would also need to ensure that the key management infrastructure it developed was resilient in the event of the failure of a piece of equipment storing encryption keys. This resilience could be provided in a number of ways, one of which could be through the use of a KR capability.

The NHS could reserve its options in this regard by following a two stage strategy: it could develop a first stage infrastructure which used D-H without the KR capability; to be extended in a second stage when or if desirable to include the KR capability. The first stage might be needed only for the pilot. Alternatively, if the NHS so wished, the first stage could be used all the way through nation-wide implementation. It must be realised that, if the KR capability were to be introduced, it would lead to very tight operational controls being needed at the TTPs.

[Footnote 3]

3 DSA uses cryptographic keys and fuynctions which are very close to those used by D-H. Consequently, even though Digital Signatures cannot be provided by Red Pike, they can be introduced easily using functions implemented within the D-H key management scheme.

[page59]
9. The D-H functionality (with or without KR capability) will allow two networked end-systems to agree a symmetric key for bilateral use. This key may be used as the Red Pike key for message encryption. Alternatively, it might better be used to protect (by encryption) a second Red Pike key, that key then being exchanged between the two end-systems and being the one used for message encryption.

This use of encryption keys to encrypt other encryption keys is a well established Key Management technique and can be used to allow the frequent and automatic changing of message keys without the overhead of renewing frequently the higher-level D-H keys. Indeed, it is not unusual to have a multi-layered hierarchy of symmetric keys allowing the key at the top of the hierarchy to be changed only rarely whilst the keys at the bottom of the hierarchy can be changed automatically with each and every message. The NHS should build in to its Key Management infrastructure the flexibility to allow this key hierarchy technique to be used wherever needed.

10. A D-H key management infrastructure could be used to manage asymmetric keys as well as symmetric keys. As was mentioned in the footnote to Point 6 above, the processes used by D-H can be extended simply to provide the DSA digital signature algorithm. DSA could be used for generating the necessary certificates for asymmetric keys, whether they were DSA keys or RSA keys, and according to whichever standard (for example, version 3 of the X.509 standard) that was required. Consequently, the NHS would have the option of using its D-H key management infrastructure as the basis for the management of other keys as might be needed for any future interworking with other schemes, for example those which might be used in other European countries.
11. The solution outlined above will take some time to implement, in part because of the need to pilot the technology being introduced. It is appropriate, in this case, to consider what shorter term, non-strategic solutions might exist. The options to consider are:
• existing suitable COTS (Commercial off-the-shelf) products that use other algorithms besides Red Pike
• products that would be appropriate for only a limited range rather than all applications.
[page60] The general problem with COTS products which do not use Red Pike are that they are either not available for the NHS's use or, if they are, they do not have an adequate level of cryptographic strength. There is one specific product, PGP, which does not suffer from these drawbacks. That has been dismissed as not being a suitable strategic solution for the NHS (see earlier in this Appendix), and a number of those reasons would also limit its suitability as a short-term solution. There are a growing number of E-mail security products, either on or coming to the market, which address some of the shortcomings of PGP, and one of these (at least one, to Zergo's knowledge) has recently been upgraded to incorporate the Red Pike algorithm. That product would have the following advantages as an interim solution for the NHS:
• it is an E-mail security utility, and that would make it appropriate for a good proportion of the NHS's immediate need
• it already has Red Pike in it, increasing its compatibility with the recommended strategic solution
• it integrates with ordinary office E-mail systems (which addresses a major drawback of PGP)
• it works with a D-H key management layer (though a rather cut down version compared to the recommended strategic solution)
• it is available today.
This product should not be seen as a strategic solution for the NHS for many of the same reasons that PGP is not (see earlier in this Appendix), and those are:
• it is designed for messaging and could not be used for interactive communications
• there is only the one supplier
• it does not have a mechanism for the convenient distribution of encryption keys, which would limit its suitability for such a large community as the NHS.
However, it might have some value as a short term, interim solution for a limited range of applications, and would warrant further investigation for adoption in this capacity. That further investigation should also identify any other such products which may be on or about to enter the market.

Appendix D

Glossary of terms

Asymmetric algorithm
A cryptographic algorithm in which the keys used for encryption and decryption are different, and for which it is computationally infeasible to determine the decryption key (which is kept private) from the encryption key (which can then be made freely available).

CESG (Communications - Electronics Security Group)
The National Technical Security Authority within HMG. A LTK government department with responsibility for ensuring the security of government electronic communications and Information Technology.

COTS
The acronym "Commercial off-the-shelf' used for products which can be purchased and installed as-is without needing extensive customisation to make them suitable.

Cryptography
The field of technology using mathematically constructed techniques and algorithms to protect data. The fundamental requirement of these is that some protection processes, for example the decryption of encrypted data or the creation of digital signatures, cannot feasibly be performed without precise knowledge of a particular data string (known as the key) even if all the other input data is known. This requires that the key must not be obtainable from knowledge of the algorithm and the output data.

DES
A long-standing (about 20 years) public domain symmetric algorithm widely used within the Financial Services sector. It is not normally available to users in other commercial sectors unless it is used by them only in relation to the protection of financial data.

Digital Signature
A digital value or checksum that can be used to prove or verify that the data in a message has not been changed in an unauthorised manner whilst the message has been in transit across a network or in storage. The term is usually reserved for checksums calculated using asymmetric techniques, where only the originator of the message can generate the digital signature but many people can verify it.

Diffie-Hellman
A method by which two parties can agree upon a secret encryption key that is known only to them and which cannot be determined by an eavesdropper listening to the dialogue by which the parties agree the key. Named after the inventors of the technique in the mid 1970's.

DSA (Digital Signature Algorithm)
A US Federal Information Processing Standard which describes an algorithm for creating and checking digital signatures.

Equivalent key length
For symmetric algorithms, a rule-of- thumb measure of the believed strength of the algorithm. For well constructed logarithms, the most efficient way to crack the algorithm (obtain the secret key from knowledge of the algorithm and the encrypted data) is to try each of the many possible keys until the correct key is stumbled upon by chance. This is known as an exhaustive key search. The number of keys in the key space that has to be searched in this way is 2n where n is the length of the secret key in bits. Hence, this gives a measure of the expected effort to crack the algorithm and can be used (but only as a rule-of-thumb) to compare the relative strengths of different algorithms.

ITSEC/ITSEM Scheme
ITSEC stands for IT Security Evaluation Criteria and is a set of criteria against which a product could be evaluated to test the level of security it provides. ITSEM is the IT Security Evaluation Methodology and is a formal methodology that Commercial Licensed Evaluation Facilities (CLEFS) must follow if they are to perform ITSEC evaluations with a view to the evaluated product being awarded an internationally recognised certificate.

Key Certificate
A data record that authenticates the owner of a public key for an asymmetric algorithm. It is issued by a certification authority (often a TTP) and is protected by a digital signature, allowing the certificate to be verified widely. The certificate may also contain other fields besides the value of the key and the name of the owner, for example an expiry date.

Key Management
A general term for a number of processes or practices involved in the secure creation, storage, exchange, use and deletion of cryptographic keys.

Key Recovery
A capability that can be added in to some Key Management schemes to allow the encryption keys to be recovered by a trusted body under strict controls.

Message integrity
Protecting a message against its unauthorised modification, often by the originator of the message generating a digital signature.

Non-repudiation
Protecting a message against the originator of the message later being able to repudiate the message, i.e. claim that it was generated by someone else. Relevant in some EDI or payment systems where someone might wish to repudiate a large order or funds transfer sent electronically but in error.

Rambutan
A restricted HMG encryption algorithm.

RC4
A proprietary (U.S.) algorithm widely implemented in, for example, internet protocols.

Red Pike
An HMG encryption algorithm developed for use by non-central government organisations (possibly commercial) working with government. It is represented by HMG as being stronger than DES, the encryption algorithm normally used within the Banking sector, though at the same time being releasable (under some constraints) beyond central government.

RSA (Rivest Shamir and Adelmann)
An asymmetric algorithm for encryption and decryption which may also be used for the creation of digital signatures. The acronym refers to the names of the three developers of the algorithm.

Security API (Security Application
programming Interface) A piece of software capable of providing defined standard security services, usually drawing on an underlying set of cryptographic processes. The services are called by application programs and return their results via highly structured and well defined software interfaces.

Source Authentication
Being able to verify that a message was sent by the claimed originator, often provided by the originator being required to calculate a digital signature on the message before sending it.

Symmetric algorithm
A cryptographic algorithm in which (in contrast to an asymmetric algorithm) the same key is used for encryption and for decryption. Hence, the encryption key cannot be made public as this would immediately expose the decryption key (which is the key that needs to remain secret).

ThamesBridge
A restricted HMG encryption algorithm, less restricted than Rambutan but more so than Red Pike.

(TTP) Trusted Third party
An organisation trusted by parties wishing to exchange cryptographically secured messages, to manage cryptographic keys on their behalf. TTPs may also provide other services relating to the use of cryptographic facilities