Note: this document was scanned from a paper copy of the report. There may be some scanning errors.

The use of encryption and related services with the NHSnet

A report for the NHS Executive by Zergo Limited

Published by the NHS Executive
April 1996

© Crown Copyright 1996

IMG E5254

Jump to page:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61


1 Management summary
2 Introduction
3 The context for Security Services
4 Recommended approach
5 Implementation issues
6 Benefits
7 Implementation
Appendix A Terms of reference from the NHS Executive
Appendix B An outline architecture
Appendix C Algorithms and key management
Appendix D Glossary of terms
IMG reference number: E5254


This report has been accepted by Ministers and by the NHS Executive. The report confirms that provision of cryptographic services for NHSwide use would be costly and complex. Acceptance of this report only implies commitment to start piloting. Further action will depend on the outcome of the trials.

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
West Yorkshire
LS23 7LN
Tel: 01937 840250
Fax: 01937 845381


1 Management summary

Zergo Limited has been commissioned by The Information Management Group of The NHS Executive (IMG) to undertake a study looking at the ramifications of using encryption and related services across the NHS-Wide Network (NWN) also known as the NHSnet. The principal requirement, which is for the confidentiality of Person Identifiable Data, is assumed. The study is to consider the ways in which encryption could be provided across the network, in the context of those networked systems that exchange Person Identifiable Data. It is then to recommend how encryption could best be provided to meet the NHS's requirement given the current relevant technical and business strategies, and to advise the NHS on the ramifications of that approach including the likely costs and benefits that would arise. Finally, it is to consider in what ways the encryption approach could be extended to provide other related network security services in a cost-effective manner.

The main results of this study are that:

The study considers the range of contexts with which encryption might be appropriate and concludes that there are many. From this it goes on to deduce that what is required is a small family of related encryption products rather than just a single product. The family of products would allow encryption to be provided according to the needs of individual systems. Encryption could be provided either as part of the user's application or in conjunction with the user's networking facilities. It could be provided for those systems that require it without it being necessary for all systems to use it regardless of need. And the needed central management facilities (one or more TTPs - trusted facilities to manage cryptographic keys on behalf of users) would be readily scalable, allowing an initially small management facility to be established, and for this subsequently to take on the support of a growing community of users without the need for a large central management or Head Office team.

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.

The study recommends that the encryption facilities should be implemented in a staged manner which allows the management and technical issues to be addressed in a controlled and steady way. A staged pilot should be defined to prove the feasibility of using encryption across the NHSnet, to test its use with a number of different types of system, and to allow the measurement of a number of technical and management parameters. After consideration of the results of the first stage of the pilot, a strategy should be defined for implementing the encryption facilities in stages to cover both new and existing networked systems according to priority and need. It should be expected that implementations could be started before all the stages of the pilot have been completed. The implementation program is likely to extend over a number of years, though the benefits from using encryption will be felt from the first stage of the implementation. An outline of the steps that will be needed for the pilot and subsequent implementations is given within this report.

2 Introduction

The NHS is in the early stages of implementing the NHS-Wide Network (NWN) also known as the NHSnet. The NWN has an associated NWN Security Policy and Codes of Connection, and guidelines on the use of access controls on the network. The network does not presently have any general provision for the use of encryption or related cryptographic services for protecting the confidentiality of data transmitted across the network.

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:

This report draws on a requirements study carried out by C International Ltd. The scope of that study was to identify all current and expected future information flows (both interactive sessions and messaging oriented) that might need to use encryption facilities across the NWN. Given the high number of potential data flows, it was decided to focus the analysis on the primary healthcare sector. This was expected to embrace all the issues concerning security and would be focusing attention on an area of particular security concern. This analysis was supplemented by a high level review of other areas of the NHS to ensure that all significant security requirements had been identified. The findings of the requirements study were ratified through a workshop held in December 1995. A summary of the findings is included within Section 3 of this report.

The organization of this report is as follows.

Further technical detail and discussion underpinning the recommended approach to the provision of cryptographic facilities (given in Section 4) is contained in two appendices: The original Terms of Reference for the study from the NHS Executive are included as Appendix A. Finally, a Glossary of the main security terms used within the report is provided in Appendix D.

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:

It is important for the reader to understand that the use of encryption on the NWN will not be a universal security panacea and that it will not address all of the NHS's security requirements; in particular, encryption should not be seen as a substitute for having adequate access controls on the end-systems. Other controls will be required within the end-systems themselves, and these are the responsibility of the owners of each end-system. These fall outside the scope of the current study.

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

Current concerns about NWN security are centred on two main threats: The primary concern is that, by either of these methods, an attacker might gain access to confidential Person Identifiable Data The threat of unauthorised access to the network is being addressed through a number of controls including strong user authentication methods, and these are the subject of other work. Addressing the remaining eavesdropping threat is the subject of the present study, and it is this which leads to the consideration of encryption as a possibly suitable countermeasure. However, encryption, if used appropriately, does have further value in that it can help prevent unauthorised access to networked systems or data. Unauthorised users would find themselves unable to access these systems because they would not possess the correct decryption keys. Again according to implementation, authorised users might obtain some protection against accidental or deliberate misrouting of data (posting confidential data to an open discussion group, sending a confidential email to the wrong e-mail address) if the (unintended) recipient did not posses the correct decryption keys.

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.

The types of cryptographic techniques needed to counter network eavesdropping can often be used to deal with a number of other data security threats which also exist on the NWN, though those requirements may not be as much to the fore as eavesdropping. These include: However, there are a number of other threats that will not be addressed by the use of network encryption, for example, the abuse of access by authorised users. As has been said, these other threats are being addressed separately by the NHS Executive, and they are not dealt with within the scope of this report.

3.2 Communications Contexts

The conclusion drawn from the study of communications contexts by C International was that there is, or will be, a wide range of information flows between a wide range of communicating entities where unauthorised disclosure could, potentially, give rise to significant and undesirable impacts.

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

Messaging (including E-mail) is the largest single type of NWN communications context and is expected to remain so for some time. However, other types of communication (file transfer, interactive system access, tele-medicine) are significant and will become more so with time. Many users are expected to access the NWN via dial-up links. Hence, it is important that any solution adopted should be capable of protecting these. The NWN will also be used for broadcast traffic (though, by its nature, most of the broadcast traffic will not be confidential), and it is important that any solution adopted should be capable of protecting this.

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.

The study of contexts also revealed a potential need for other cryptographic services such as message integrity protection, source authentication, and non-repudiation. For example: However, confidentiality is seen to be the widest requirement. This justifies the requested approach which was of focusing first on the encryption solution and then examining ways by which the encryption solution could be extended cost-effectively to support these additional security services.

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.

Delays of a second
or more unacceptable
Delays of several
seconds acceptable
Low data throughput Text-based interactive
Medium data throughput Windows-based
interactive session
Some file transfer
High data throughput Remote consulting,
high data rate link between
acute unit and FM supplier
Some file transfer

3.3 The IT environment

Any technical solution intended to provide countermeasures to the threats discussed above will have to be capable of working with the variety of computer systems that are candidates for connection to the NWN. Some important characteristics of these systems are: Probably the most common computing environment found around the NWN will be a PC running DOS or Windows. The cost of any encryption facilities introduced will need to be modest or small in proportion to the base cost of this common IT platform.

4 Recommended approach

This section presents a summary of Zergo's recommended approach to the provision of encryption facilities. Further supporting detail describing the rationale behind the recommendations is presented in Appendices B and C towards the end of this report.

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

The study of the communications contexts has shown that there are many cases where the value or sensitivity of the information exchanged is sufficient that the use of encryption would be appropriate. This judgment is based on an assessment of the magnitude of the possible impact on one or more parties if confidential data were to be disclosed.

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

A number of encryption algorithms, public domain and proprietary, exist. However, strong encryption algorithms are not available for general use, and those algorithms which are available for general use (for example, in the form of commercial off-the-shelf products) are not regarded as adequately strong for the protection of Person Identifiable Data. Consequently, the selection of a suitable encryption algorithm is not, in this situation, straightforward.
Given the national interest in the proper protection of Person Identifiable Data, the advice of the National Technical Security Authority, CESG, has been sought on the choice of encryption algorithm. CESG's advice is that, in the case of the NHS, there are security benefits to be obtained from avoiding the use of encryption algorithms which are in the public domain. CESG has recently been able to make available to the NHS (and to others, including non-financial sector organizations) a suitable non-public domain algorithm known as Red Pike. This encryption algorithm is very new, but there are already a small number of products available on the market which use it, and a wider range of products which use related algorithms and which could quickly and simply be modified to use Red Pike. Consequently, the NHS need not fear that it might become locked in to a single product or single supplier if it were to adopt Red Pike as its preferred 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

In light of the conclusions drawn from studying the many dataflow contexts described in the previous section of this report, and in view of the NHS's networking strategy, the NHS's network security strategy should, in the large, favour providing the encryption facilities to the host system whenever possible and, only if justified on a case by case basis, provide it directly on the network itself.
There are several advantages to be gained by providing the encryption facilities to the host rather than the network: However, despite these benefits, in the early stages of the implementation programme it may be appropriate to provide the encryption predominantly in the lower levels of the networking protocols in order to minimise some of the technical risks.

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:

The preferred form of implementation in any situation will vary according to a number of considerations. The two considerations most likely to influence the form of implementation are:

4.4 Take-up of the encryption facilities

In whichever of the above forms the encryption facilities are implemented, it is expected that they will, on the whole, be incorporated into the NWN on a system by system basis. Over a period of time, increasing numbers of systems will be brought on stream using encryption until all the systems that have a business case for using encryption are so protected.

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:

[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.
This approach means that: New applications will be able to incorporate the encryption facilities they need, in the form that is most appropriate to them, from the start within their design. Hence, for each new system, the cryptographic sub-system could be designed according to business and technical needs, and in line with the applicable NHS cryptographic standards or guidelines. The use of NHS cryptographic standards will channel the systems developers towards the reuse of a standard set of cryptographic products.

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

With Red Pike, as with any symmetric encryption algorithm, for two parties to be able to exchange encrypted traffic they need to have a way to establish and manage the shared keys. Again, the advice of CESG was sought about the possible need to interwork with any future national key management infrastructure. CESG's advice was most helpful and, while not leading to the introduction of any specific functionality into the recommended NWN key management infrastructure, has influenced the recommendations made in this report so that they allow for this possibility.
Given the size of the NHS community and the need for the simplest of means for initialising the users' encryption facilities, the NHS will need to develop a key management infrastructure which is built on the use of what are known as asymmetric methods, and using one or more Trusted Third Party (TTP) facilities. These TTPs would play a role in the secure initialisation of the users' encryption facilities (they could, for example, perform EDIFACT-style key notarisation) and in the periodic changing of some of the users' keys. The TTPs would provide a secure means by which users could obtain the appropriate high-level cryptographic keys of other users to allow two parties ultimately to exchange encrypted data. These high-level keys obtained from the TTPs would not normally be the keys used to protect the exchanged data; those keys would be generated and exchanged automatically and bilaterally between the two communicating parties. Hence, the TTPs themselves would not need to be involved in each exchange of encrypted data. The TTPs would represent only a small overhead to the use of encryption on the network and would add only a negligible amount of additional network traffic.

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

There are two options for the type of technology that could be used for the key management infrastructure, RSA technology or Diffie-Hellman (D-H) technology (see Appendix C for a description of these terms and technologies). The technology that Zergo recommends the NHS should use is the D-H technology. This will allow the NHS to reserve its options regarding the possibility of interworking with any future national key management infrastructure. It is highly likely that any such national infrastructure would be based on D-H technology. It is almost certain that it would not be based on RSA technology. In all other significant aspects, including intrinsic security strength, the two technologies are equivalent. Hence, a D-H key management infrastructure is the more strategic of the two available options.

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

It is acknowledged that the strategic approach recommended in this report will require some time to be piloted and implemented, and that this would not provide all users with encryption capabilities in the immediate term. For those users that have a more urgent need to use encryption other, interim options are available. These could be used within the NWN on a case-by-case basis and would not inhibit or interfere with the strategic developments as they come on-stream. However, they would not allow the users to interwork with the strategic approach as it was increasingly implemented. They should, therefore, be seen as interim steps for the short term, and it should be expected that they would need to be replaced at some time in the future when interoperability with other strategically protected end-systems was required.
Possibly the most attractive of the available short-term solutions would be to use products such as E-mail packages that implement the Red Pike algorithm. There is at least one such product available now, and it is expected that more will follow. These will remain short-term or non-strategic solutions, for the reasons discussed in Appendix C. Further investigation by the NHS is recommended before this class of product can be endorsed.

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


5 Implementation issues

Adding encryption onto the NWN is technically feasible, the encryption processes and encryption facilities could be managed, and a planned and phased implementation approach would be needed. Adding encryption across the network would not be a simple task, and it would bring with it a number of technical and management issues that would need to be addressed carefully, as well as bringing many benefits. These are discussed here.

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:
  2. 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.

  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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.

  8. A strategy will need to be developed for supporting the introduction of encryption facilities into new and existing applications, as described below.
  9. suppliers of existing NHS applications may need encouragement to integrate cryptographic security into their systems - perhaps through the existing Accreditation process
  10. 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
  11. 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.
  12. The legal, commercial and Organizational issues surrounding the creation of Trusted Third Parties will have to be investigated. These will need to include:
  13. 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.
  5. [page27]
  6. 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.
  7. 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.)
  8. 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.

  9. 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.
  10. 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.

  11. 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.
  12. 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

It is important that the whole life cycle costs of introducing encryption onto the NWN are considered, not just the purchase costs of the equipment. The life cycle costs include, along with the equipment purchase or licence costs, the manpower costs of: Though much of the above project manpower could be provided by the NHS from its own staff resources, there will be the need for the NHS to obtain external assistance at a number of stages.

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

The day to day operation of the encryption facilities should be essentially transparent to the users. For this reason, there will not be the need for, and associated costs of, many thousands of users being trained up before encryption can be used. Similarly, the day to day operation of the TTP(s) will require only a small number of staff and, consequently, will require only modest on-going resourcing. The main manpower costs relate to the running of the pilot and subsequent implementations. For these, the NHS will need to provide of order a few tens of man-years of staff resource, some proportion of which might be bought-in general project consultancy rather than provided from internal staff. In addition to this, there is the potential, overall, for of order £250,000 worth of external expert security consultancy to assist in these programmes.

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

Planning and outline specification
The first step for the NHS after accepting the report will be to develop a plan to carry the strategy forward. This will include determining an outline specification for the technical architecture, for which the NHS will require some expert security consultancy assistance. Possible security consultancy fees - at least £20,000.
Procurement, design, development, testing and implementation of the pilots
The first stage of the pilot will carry the burden of establishing the core of the key management infrastructure. Successive stages of the pilot and subsequent implementations may enhance and build upon this core infrastructure but will each carry a rapidly diminishing share of the infrastructure development For a modestly sized first stage pilot, this part of the work may take of order nine to twelve months to execute. For an extensive first pilot, it is likely to take considerably longer. As well as the NHS staff involved, there will be the need for a mix of external security assistance. Possible security consultancy fees - £100,000. Successive stages of the pilot should require a lower level of external security assistance, possibly £50,000.

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:

and that will affect the distribution of the costs between different funding sources. For each new system brought in, the normal costing cycle w ill need to be followed, business cases developed and procurement managed.
It can be expected that each system's implementation programme would require a few man-years of NHS staff resources in total. However, only a small part of this would be extra to the normal implementation costs for the system and attributable directly to the implementation of the encryption facilities. Hence, if encryption is added in to a system's existing implementation programme, for example either for a new system or for a revised one that is put back into service following other system enhancements, the marginal extra resources needed to manage the encryption aspects of the implementation will be only a small part of the whole programme's resourcing needs.

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.

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.

Beyond the pilot, the NHS has two options for the development of further TTP support. It could:


Or The strategy for the development of TTPs would evolve as the NHS gained experience in their use. If only a single TTP were developed, even once the encryption facilities were fully implemented across the NWN, it should not be necessary for there to be a sizeable number of staff performing central administration tasks. If multiple TTPs were developed, the accumulated TTP staffing would be higher owing to the reduction in the economies of scale achieved. However, each TTP would likely have only a small staffing requirement, with the minimum number of staff being four, and these might be involved only part time in performing TTP functions. In either situation, the full time equivalent staffing level for the TTP functions should be no higher than, say, eight staff.

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

The equipment needed will include the equipment in the TTP and end-system encryption equipment, and the latter will vary according to the manner of the various implementations. It is not possible for this report to provide a definitive overall cost for implementing encryption on the NWN because there is a wide range of parameters which will influence each implementation and which cannot be determined at this stage. The overall cost will vary according to the balance of hardware versus software implementation, the number and variety of systems running on large or midrange hosts, the allocation of development risk between the NHS and suppliers, and so forth. Also, the distribution of costs between the various funding sources will vary to some decree depending on the financing approaches used.
Consequently, the approach we have adopted is as follows. We begin by presenting typical indicative costs (both one-off costs and on-going annual costs) for some of the main components that are likely to be needed somewhere within the NWN. We then, in the following sub-section, use these to derive broad indicative costs for adding encryption to the NWN for a number of general user examples. Finally, we derive broad indicative costs for the NWN as a whole using two Global Cost (GC) models based on broad global assumptions. Component Costs

We give both one-off costs for the item of equipment and the annual on-going costs for running the items.
One-off Costs
Key Management Infrastructure
The development of the key management and other
facilities for the TTPs, including conformance testing tools
for evaluating conformance of the users' encryption
facilities to the NHS's key management specification
£250,000 Applies equally to
both Global Cost
(GC) models 
Modification of an existing application
in a "non-invasive" manner to utilise communications
encryption facilities
£20,000 Applies equally to
both GC models
Modification of an existing application
to incorporate full application level communication encryption facilities using an API and an encryption tool-kit.
£75,000 Applies to GC
model 2 only
The price of a (PC) software license
for upgrade/additional software adding software encryption
facilities to an existing PC application where there is a
large market (1000 or more eg. at a GP Practice). This
price will be for negotiation with the supplier and could be
lower than $100 if the number of user licenses purchased
is high
£100 Applies to GC
model 2 only
The price of a (server) software licence
for upgrade/additional software adding software encryption
facilities to an existing server application (eg. at a Trust
Hospital). This price will be for negotiation with the supplier
and could depend on the number of users supported
£5,000 Applies to GC
model 2 only
The price of a hardware unit
to handle encryption of a 64Kbit/sec communications link
£2,500 Applies to GC
model 1 only
The price of a hardware unit
to handle encryption of a dial-up communications link
£1,800 Applies to GC
model 1 only
On-going annual costs
Key Management Infrastructure
On the basis of the TTP(s) requiring a total of eight full
time equivalent staff.
£400,000 Applies equally to
both GC models
Maintenance charges 15% of the
Applies equally to
both GC models Costs for example situations

To illustrate the use of these costs, we have applied them to some representative situations.
Example 1: Small GP Practice
5 GPs with 3 support staff
sharing a single PC running
a UNIX based practice
Procurement cost
£100 for a software
upgrade licence, adding
communications encryption
facilities to the existing
Support cost
assumed as 15% of
purchase cost,
ie. £15 p.a.
Example 2: Large GP Practice
10 GPs with 7 support staff
and 2 health visitors, using
15 terminals on a UNIX
client-server system running
over a LAN. The system has
connections to the LAN at
the local hospital
Procurement cost
£100 per terminal for a
software licence, adding
communications encryption
facilities to the existing
ie. £1,500
Support cost
assumed as 15% of
procurement cost,
ie. £225 p.a.
Example 3: Acute Hospital
PAS System
MUMPS based, supplier no
longer maintaining the
Procurement cost
5 hardware encryption units
at £2,500 each to handle
traffic from GPs etc. across
the NWN
ie. total procurement cost
Support cost
assumed as 10% of
procurement cost,
ie £1,250 p.a.
Order Communication
No encryption as its
communications are internal
Standalone Theatre
Recent and UNIX based,
supporting the main theatre
on the hospital campus and
a small theatre in the
community which is linked
to the system via the NWN.
Procurement cost
2 hardware encryption units
at £2,500 each. Total cost
Support cost
assumed as 10% of
procurement cost,
ie. £500 p.a.
Radiology System
MUMPS based, due to be
replaced in the next two
It is assumed it would be
decided not to add
encryption facilities to this
Pathology System
Recent, UNIX based.
Procurement cost
£5,000 for a software
upgrade licence adding
encryption capabilities to
the existing application.
Support costs
at 15% of procurement
cost, £750 p.a.
Contract Management Procurement cost
£5,000 for a software
upgrade licence adding
encryption capabilities to
the existing application.
Support costs
at 15% of procurement
cost, £750 p.a.
Office System
This is used to
communicate via E-mail with
GPs, Health Authorities and
Community Trusts. It is
assumed there are 10
terminals on this system
Procurement cost
10 software licences at
£100 each adding
encryption facilities to each
of the ten terminals. Total
cost £1,000.
Support costs
at 15% of procurement
cost £150 p.a.
Link to FM Supplier
This hospital is linked to its
FM supplier, where the main
systems are located, over
the NWN.
Procurement cost
for 4 hardware encryption
devices at £2,500 each to
secure the link, £10,000.
(The link is assumed to be
duplicated for resilience
Support costs
at 10% of procurement
costs, £1,000 p.a.
Total Procurement cost
for acute unit
Support cost for acute unit
£4,400 p.a.
[page37] Total Cost to the NHS

The total cost of implementing the recommended encryption approach is obviously an important parameter. This cost will depend on a large number of imponderables, for example the outcome of discussions with suppliers about the feasibility and cost of adding software-based encryption facilities to their products.

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.

This model is based on the assumption that all encryption is carried out in hardware 
Global Cost Model 1
Item Description Setup-up
cost (£)
cost (£)
Key management Development of Infrastructure
Assume at most 8 full-time
equivalent staff at the TTP
£250,000 £400,000
External Security
Primarily relating to the
encryption pilots
Acute sites 250 sites, 2 encryptors per site
@ £2,500 each plus 15% p.a.
£1,250,000 £187,500
Community sites 200 sites, 2 encryptors per site
@ £2,500 each plus 15% p.a.
£1,000,000 £150,000
FHSA sites 100 sites, 2 encryptors per site
@ £2,500 each plus 15% p.a.
£500,000 £75,000
DHA sites 1000 sites, 2 encryptors per site
@ £2,500 each
plus 15% p.a. maintenance
£500,000 £75,000
GP practices 9000 sites, 1 encryptor
per site @ £1,800 each
plus 15% p.a. maintenance
£16,200,000 £2,430,000
National Systems2 Assume 15 additional systems,
2 network encryptors per site
£75,000 £11,250
Total cost for Global
Cost Model 1
£20,025,000 £3,328,750
[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.

This model is assumes that all encryption is carried out by software. For costing purposes all but the GP systems are assumed to be done as software modificatoins delivering a full applicatoin-level solution. The GP solutions are to add software for communications encryption only. 
Global Cost Model 2
Item Description Setup-up
cost (£)
cost (£)
Key Management Development of Infrastructure
Assume at most 8 full-time
equivalent staff at the TTP
£250,000 £400,000
External Security
Primarily relating to the
encryption pilots
Acute Systems
PAS Software modifications
to 10 systems @ £75,000 each
plus 15% p.a. maintenance
£750,000 £112,500
HISS Software modifications
to 6 systems @ £75,000 each
plus 15% p.a. maintenance
£450,000 £67,500
Pathology Software modifications
to 20 systems @ £75,000 each
plus 15% p.a. maintenance
£1,500,000 £225,000
A&E Software modifications
to 6 systems @ £75,000 each
plus 15% p.a. maintenance
£450,000 £67,500
Nursing Software modifications
to 6 systems @ £75,000 each
plus 15% p.a. maintenance
£450,000 £67,500
Maternity Software modifications
to 6 systems @ £75,000 each
plus 15% p.a. maintenance
£450,000 £67,500
CMS Software modifications
to 6 systems @ £75,000 each
plus 15% p.a. maintenance
£450,000 £67,500
Office Systems Software modifications
to 5 systems @ £75,000 each
plus 15% p.a. maintenance
£375,000 £56,250
Community systems
(Provider and
Child Health
Software modifications
to 9 systems @ £75,000 each
plus 15% p.a. maintenance
£675,000 £101,250
The Exeter system, which is
MUMPS based, and district
support systems.
£2,000,000 £300,000
National Systems 15 systems, such as Breast
screening, which are not owned
by any of the identified
£1,125,000 £168,750
GP Systems Licence fees:
3000 sites @ £1,500 each
and 6000 sites @ £100 each,
plus 15% p.a. maintenance
£5,100,000 £765,000
Total cost for Global
Cost Model 2
£14,275,000 2,466,250
There will also be a requirement for a few tens of man years of NHS internal resource (some of which may be provided by external agencies).

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.

cost (£)
cost (£)
GP systems Global Cost Model 1 £16,200,000 £2,430,000
Global Cost Model 2 £5,100,000 £765,000
Other systems Global Cost Model 1 £3,835,000 £898,750
Global Cost Model 2 £9,175,000 £1,701,250
Total Global Cost Model 1 £20,025,000 £3,328,750
Global Cost Model 2 £14,275,000 £2,466,250

6 Benefits

Each stakeholder will obtain some benefits from the use of encryption on the NWN, though these may well be different for different stakeholders.

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 Data Protection Registrar
The DPR will wish to be assured that Person Identifiable Data is protected when transmitted across the NWN. Neither the current Data Protection legislation nor the recently agreed EU Data Protection Directive mandates the use of encryption; that is a matter of national interpretation. However, it should be expected with confidence that the DPR would be pleased to see that personal data was encrypted on the NWN.

The NHS Executive

The NHS Executive would benefit in a number of ways from the introduction of encryption on the NWN.
  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.
  5. [page43]
  6. 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.
  7. 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

It is envisaged that many of the actions outlined below would be managed and carried out by the NHS Information Management Group, calling on assistance from external consultants as required. Owners of the applications may have to play a part in negotiating with application suppliers regarding the addition of encryption facilities, particularly if suppliers are not willing to carry the full development risk of the modifications themselves. The procurement strategy will need to pay attention to this possibility and aim to avoid it where possible.

7.1 Preliminary Confirmations

A number of preliminary steps will be required to establish a firm direction for subsequent work. It is estimated that these will take in the order of three months to complete.
  1. The NHS will need to have further, more detailed discussions with CESG to:
  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

Following the satisfactory completion of the preliminary confirmations, the NHS will be able to advance into the planning of its implementation strategy. It will need to:
  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

A multi-stage pilot programme may be needed before major implementation is attempted. The initial tasks within this programme will involve specification and development work before pilot testing can begin. It is estimated that the first stage of the pilot would take between a year and 18 months to complete. The successive overlapping stages of the pilot could each take nine to twelve months to complete.

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.
  4. [page46]
  5. 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:
  6. Depending on the nature of the pilot implementation, the following may be required
  7. Agree a contractual basis for the participation of both suppliers and users in each stage of the pilot.
  8. Ensure the availability of appropriate types of cryptographic software and hardware products that might be required.
  9. Develop the first stages of the key management infrastructure as necessary for the first stage of the pilot.
  10. 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.
  11. 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.
  12. Implement and run the first stage of the pilot.
  13. 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.
  14. 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

Agreement will need to be reached with the early adopters of encryption regarding the relative implementation priorities to be given to each of their systems. These priorities will be drawn up on the basis of commercial, practical and security risk considerations as well as in the light of the pilot results. If the results of the pilot show that few modifications to the pilot technology (user, system or TTP technologies) are required for the initial phases of implementation, then the implementation process could begin almost immediately after the completion of the first stage of the pilot. The priority phases of implementation would probably take at least two years.

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 Terms of Reference for the study, provided by the NHS Executive are given below.

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:
  3. The NHS Executive seeks advice on
  4. [page49]
  5. 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:
  6. 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:
  2. [page51]
    There are two principal ways in which end-to-end encryption can be provided:
    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:
  3. 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.
  4. 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:

  5. 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.
  6. 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.

  7. 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.
  8. [page54]
  9. 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.
  10. 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:
  11. 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.
  12. 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

This appendix describes the process by which the study has arrived at its recommendations regarding the encryption algorithm and key management infrastructure that should be used. We do not attempt in this report to provide the user with an introduction to the use of cryptography or to the measurement of its capabilities. There are a number of available texts and reference sources which make the subject accessible to the interested reader and which should be available in any good sized technical library.

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.
  3. [page56]
  4. The published E-mail security package PGP would not be suitable as a strategic solution to satisfy the requirement for NWN encryption.
  5. 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.
  6. [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.

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

  9. 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 DSA3 algorithms respectively).
  10. 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.
  11. 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.

  12. 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.
  13. 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.

  14. 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.
  15. 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.

  16. 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.
  17. 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:
  18. [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: 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: 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

Algorithm (Cryptographic Algorithm)
The mathematical process by which a cryptographic key and some input data are combined to create a cryptographically useful result. Usually the required result is either an encrypted version of the data derived from plain text input data (the encryption process) or plain text derived from encrypted input data (the decryption process). However, it may also be a digital signature or a cryptographic checksum or Message Authentication Code (MAC). The result is cryptographically useful if it bars anyone other than those authorised to use the cryptographic tools from decrypting the encrypted data or tampering with the data.

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.

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.

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.

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.

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

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.

A restricted HMG encryption algorithm.

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

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