This is a scanned version of the report done by Zergo Limited for NHS Executive. Please allow errors due to OCR.

Management summary

Introduction

The context for Security Services

Recommended approach

Implementation issues

Benefits

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

Preface

This report has been accepted by Ministers and by the NHS Executive The report confirms that provision of cryptographic services for NHS-wide 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
Wetherby
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 needed technology has recently become available to allow encryption to be provided across the NHSnet in a versatile and beneficial manner, and in a way that is responsive to need and cost. Importantly, the use of encryption by some systems for some data does not require the use of encryption by all systems or for all data
• the NHS's needs should be addressed by a family of related encryption products built on the Red Pike encryption algorithm. This algorithm has recently been made available to the NHS by CESG, the National Technical Security Authority within HMG
• the introduction of encryption facilities will not be a panacea for solving all the information security problems associated with networking NHS systems
• the encryption facilities could be used in a mariner which is highly automated and manageable
• the implementation process will be by no means simple There are a number of management and technical issues that will need to be addressed within the implementation programme for the encryption facilities. However, an approach is identified that will reduce the associated risks to a manageable level
• the recommended facilities should be readily extendible to support the provision and use of related cryptographic services such as Digital Signatures to prevent unauthorised tampering with the communicated data and to link unambiguously the communicated data to the identities of the parties involved in its exchange
• the NHS will need to develop a key management infrastructure to sit across the many different systems that will become encryption-enabled. This infrastructure will require one or more Trusted Third Part, (TTP) management centres, though the staffing requirements for these will be small
• the potential benefits will be considerable if encryption is found to be a precondition for extensive use of the network services by clinicians. The expected costs are small in comparison with the costs of the IT facilities with which they would be used, and in proportion with the expected costs of networking
• the main manpower costs for the NHS will relate to the running of the pilot and subsequent implementations. For these, the MIS will need to provide a few tens of man-years of internal staff resource. There is the potential for approximately £250,000 worth of external expert security consultancy to assist in these programmes. The day to day operation of the TTP(s) will require only a handful of staff, at most eight full time equivalent staff. There will not be the need for many thousands of users to be trained up before encryption can be used
• the possible equipment costs for introducing encryption across the NHSnet could well be in the range £ 15M to £ 20M, spread over an implementation programme spanning several years. At the end of this programme, the annual on-going costs could be expected to be in the range £2.5M to £3M.

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 organisations 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 1995 commissioned Zergo Limited to undertake a study to investigate the ramifications of providing encryption and related services across the NWN.

The objectives of the study were:

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

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 massaging 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 organisation of this report is as follows.

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

Further technical detail and discussion underpinning the recommended approach to the provision of cryptographic facilities (given in Section 4) is contained in two appendices:

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

The 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:

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

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 possibility of unauthorised individuals logging on to the network
• the possibility of eavesdropping on network traffic.

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 e-mail 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 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:

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

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:

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

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:

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

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 massaging applications, for example the transmission of pathology test results. A several second delay for cryptographic processing would be unlikely to cause problems for the users. At the other extreme is remote consulting where high bandwidth data streams would need to be encrypted with minimal delay and in real time.

The table below summarises this situation.

3.3 The IT environment

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:

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

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 judgement 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 and 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 Organisations) 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 organisations 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 organisations 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:

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

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:

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

The 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:

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

4.4 Take-up of the encryption facilities

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 needs^l. If equipped with a suitable general purpose package, the user would be able to use encryption or not according to an explicit decision that they would make at the time as to whether the traffic they were about to transmit warranted its use.

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

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

This approach means that:

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

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 '17Ps 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 TT'P 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.

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

5 Implementation issues

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:

• clinicians and health care professionals
• clinical professional organisations, such as the BMA
• health care managers
• end-system owners system and network service suppliers press and public.

Each will have its own interests and legitimate concerns, and will require specific attention from the NHS.

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

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

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

6. A strategy will need to be developed for supporting the introduction of encryption facilities into new and existing applications, as described below

• suppliers of existing MIS applications may need encouragement to integrate cryptographic security into their systems - perhaps through the existing Accreditation process
• 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 re-pricing of the service provided
• 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.
7. The legal, commercial and organisational issues surrounding the creation of Trusted Third Parties will have to be investigated. These will need to include.

• the Terms of Reference for establishing the TTPs
• the need for or form of charging for the TTP's services
• legal conditions under which TTPs will be able to release information under their control or care
• to whom TTPs will release each category of information
• the liabilities that will fall to the operators of the TTP, to the NHS centrally and to the NHS user in the event of a failure in the TTP's controls
• what kind of entity could be acceptable as a TTP, e.g.:

• NHS central organisation
• A Trust
• Specialist commercial security organisation
• Government department

The pilot will allow these TTP issues to be exercised and will help the NHS to determine its long term position with regard to the provision of TTP services. From these and related considerations, the NHS will then be able to determine its requirements for controls on the TTPs. The contracting of TTP services will then need to be framed with attention being given to the relevant legislative frameworks as they exist within English law.

5.2 Technical Issues

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

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

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

It will be desirable to have more than one system used within the plot 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.

8. CESG has not taken detailed performance measurements for Red Pike as these would vary according to the application and platform concerned. The NHS will need to obtain precise performance figures applicable to the range of IT platforms that the user community is expected to use, preferably before the design of the pilot is commenced. However; having seen a description of the algorithm, Zergo would expect that its performance will be acceptable and, indeed, has the capability to outperform many existing encryption algorithms such as DES.
9. The secure storage of secret cryptographic keys win 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 user's 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:

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

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

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

and that will affect the distribution of the costs between different funding sources. For each new system brought in, the normal costing cycle will 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.

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

Operation, Maintenance and Support
The first TTP will require a small team of staff to handle the initialisation of the users' security facilities in whichever form they are implemented, and for the periodic management of high-level cryptographic keys. The lower-level keys will be managed automatically. The level of staffing at the T'FP 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:
either

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

or

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

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 7rP 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 degree 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 subsection, 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 to Global Cost (GC) models based on broad global assumptions.

5.3.4.1 Component Costs

We give both one-off costs for the item of equipment and the annual on-going costs for, running the items.

5.3.4.2 Costs for example situations

To illustrate the use of these costs, we have applied them to some representative situations.

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

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

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.

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
Patients will benefit from the actual increase in security on the N~, 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 MIS, and from the increased quality of service provided by the healthcare prnfess1.ons that will come with the increased automation and networking of MIS 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 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 ~d 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 MIS 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 pan 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 MIS 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. Though the study here has focused on the protection of Person Identifiable Data, there is nothing in the technology or approach recommended that restricts its use to this type of data. The encryption and related facilities could be used to protect any sensitive data exchanged across the NWN including contracting and management data.
6. The result of following CESG's advice in the choice of encryption algorithm is that (subject to independent confirmation of the algorithm's Strength - see Section 5.2 above) the level of security provided on the NWN will be higher than that in many conventional Banking systems. This wilt 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:

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

7.2 Planning and Outline Specification

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.

• Confirm its strategy for cryptographic algorithms and key management in the light of the results of the above steps.
• Decide, what controls it might wish to have put on access to keys held at the TTPs.
• 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 is 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 wilt be necessary to strike a balance between choosing applications and areas which are representative of the main problems which will be encountered in frill 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. The preparation of a number of technical standards and specifications will be needed. wherever possible, these should be based on existing standards. The following will be required.

• key management standards
• specification for the key management systems at a trusted third party depending on the nature of the pilot implementation, the following may be required
• standards for cryptographically protected exchanges in the NWN
• an API specification for a standard cryptographic software architecture tool lit
• for each application involved in the pilot, a specification for adding the cryptographic capabilities.
5. Agree a contractual basis for the participation of both suppliers and users in each stage of the pilot.
6. Ensure the availability of appropriate types of cryptographic software and hardware products that might be required.
7. Develop the first stages of the key management infrastructure as necessary for the first stage of the pilot.
8. Design, develop, implement and test any modifications necessary to enable each of the applications and systems involved in the pilot to make use of encryption.
9. Carry out a security awareness programme for the users including any specific guidance necessary for users to understand and use the cryptographic facilities provided under the first pilot project. Develop the training needed for the operators and management of the pilot 1Tp.
10. Implement and run the first stage of the pilot.
11. Carry out a preliminary evaluation of the results of the pilot at the earliest feasible milestone. Use these results to plan any changes to the remainder of the first stage pilot programme.
12. Carry out a full evaluation at the end of the planned pilot programme and adapt the plans for successive pilot stages and the preliminary planning for full implementation, as needed in the light of the results.

7.4 Main Implementation Process

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 plot show that few modifications to the plot 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 plot. 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 'any-to-any' communications for NHS users in pursuit of their legitimate NHS business. Much of this communication will be administrative, financial or statistical information but increasingly it will include clinical information about patients such as referral and discharge letters, laboratory requests and results, and contract Minimum data sets.
2. In order to ensure that the network architecture is appropriate to future needs a study is required which explores the practical issues of using the following security services:

• Digital Signatures to provide strong authentication and integrity checking
• Trusted Third Party facilities for certifying encryption keys
• Encryption for confidentiality
3. The NHS Executive seeks advice on

• the purposes for which these services can be used, the contexts and the extent to which they might be used in each context
• the probable costs and benefits which would accrue in each context, and to which parties they would accrue
• the most suitable standards and types of product to be used
• the additional costs and implications of providing these services on a national NHS basis in such a fashion that they are available for use when those communicating NHS information think it appropriate.
4. The study requires sound and up-to-date understandings of the NHS and the relevant technologies. These are unlikely to be found in one person. The study team will need to include people with the highest level of expertise in each of these fields. The following issues must be understood:

• the complexity of the management arrangements of the reformed NHS and the complex interactions of the various groups of health professionals and other NHS staff
• the rich variety of IT systems in use and the measures in hand to install shared administrative registers and a nation-wide clearing service for contract data
• the available security standards for providing the services listed at 2 above
• the products that are currently available or could rapidly become available to the NHS to match the appropriate standards
• the complexities of key management in a very large organisation where there is a great deal of autonomy in its constituent parts.

Proposals are invited for carrying out this study. An early start is essential, but the completion date will be determined in the light of chosen study proposals.

Appendix B - An outline architecture

1. Encryption can be applied to the NWN in any of several ways. It can be applied:

• on a link-by-link basis (e.g. GP system to NWN Point of Presence (POP), NWN Pop to NWN switch, between NWN switches, NWN switch to Acute system; in hardware or software) as illustrated in Figure 1

• or on an end-to-end basis as illustrated in Figure 2.


There are two principal ways in which end-to-end encryption can be provided:

• within the networking infrastructure (e.g., within the TCP, X.25 or Frame Relay communications protocol; in hardware or software) as illustrated in Figure 3

• or at the application level (e.g., GP system to Acute system) where it can either be built in to the application itself or called by the network service (e.g. the User Agent in a massaging system) (in software, possibly with hardware to assist the performance) as illustrated in Figure 4


The preferred strategy must be to favour providing the encryption facilities to the networked application whenever possible, and only where needed on a case by case basis to provide it directly on the network itself. There are several advantages to be gained by this:

• reusability of the security software - to allow the security facility to be used by more than one application if needed
• Versatility of the security software - to allow the security facility more easily to meet the varied needs of different contexts
• independence of the security code - from the networking protocol (EDIFACT, SMTP, File Transfer, etc.)
• information would not be available in readable plain language at intermediate switching points
• more cost-effective security - where multiple NWN links are involved
• increased security coverage - where it might be possible to protect the sensitive data within some parts of the end-system prior to its delivery to the NWN. For example this strategy might provide protection against eavesdropping in LAN systems.
2. Encryption can either be carried out in physically separate hardware units or it can be carried out by software running on end systems e.g. GP System, PAS, Pathology system, Messaging user agent. Hardware solutions are generally more expensive than software solutions, and can bring associated problems of the control of shipments (under government regulations controlling the export of strong encryption algorithms). On the other hand, hardware will generally deliver better throughput performance than software.

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

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

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

4. To allow interoperability between different implementations, software encryption must conform to a defined set of standards. There is a need to avoid the requirement for every application developer to become an expert in programming cryptography. These two considerations lead to the concept of defining a standard set of cryptographic software tools which present a standard Security Application Programming Interface (Security API). In a client/server environment, these tools may be provided by a separate cryptographic server.
5. De facto standards are emerging for such Security APIs (for example, the GSS- API - 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: e.g. LTNIX, PC Windows, MVS.
6. Consequently, it is likely that different systems will favour different forms of implementation of the encryption facilities, and these should, therefore, be provided in a variety of forms according to context - there will be no single solution to meet all needs. The NHS should expect to use:

• mostly software, but there may be a need for a small amount of hardware
• in the short term, mostly software low in the communications stack to minimise the impact on the end-systems and the associated technical risks
• in the longer term, mostly Security API software called by application systems or networking systems, though retaining some instances where encryption is built into the lower levels of the networking infrastructure.
7. Where the Security API approach is selected, suppliers of applications may then have to modify their applications to make appropriate calls to Security API functions to encrypt traffic routed over the NWN.
8. New applications will be able to incorporate the requisite encryption facilities from the start within their design. Existing applications will need to judge the business case for adding in the security facilities. The API approach would often minimise the cost and effort of introducing encryption, and this would be a major benefit to that approach. But there may be cases where the developer does not believe a business case exists.

Appendix C - Algorithms and key management

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 D~ (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. The published E-mail security package PGP would not be suitable as a strategic solution to satisfy the requirement for NWN encryption.

• PGP is designed for the one way messaging environment and could not be used for interactive communications
• PGP uses an algorithm which is patent controlled (the IDEA algorithm for which the patent is held by a Swiss company ASCOM). Hence, the NHS would be tied to a single algorithm supplier which was both a commercial organisation and non-UK based
• PGP is available either unsupported as freeware or as a commercial version from a single supplier. Neither option would be attractive strategically to the NHS
• PGP does not define a mechanism for the convenient distribution of encryption keys. This would severely limit its suitability for such a large community as the MIS. It is also, for this reason, vulnerable to 'man in the middle" attacks in which an attacker arranges for a sender of information to be provided with his public key in place of the public key of the intended destination of the information. The attacker is then able to decrypt the information and send it on to the true destination using the correct public key.

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

• PGP does not integrate well with standard office e-mail packages. For the non-technical user, PGP would require the development of a front-end to dc-skill its user interface. Again, this means that PGP could not be used as a strategic solution in its current form
4. CESG has also advised that there are significant security advantages to using unpublished algorithms rather than published algorithms. However, unpublished algorithms will be either proprietary, unaccepted by the cryptographic community, or strictly controlled by the governments that have developed them. Any one of these would make the algorithm either unacceptable or unavailable to the NHS.

The NHS is, therefore, in the constrained position of needing to use an encryption algorithm that is sufficiently 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 DFS, for which there are many public standards. Hence Red Pike could easily be used in accordance with those standards. And Red Pike can be released in appropriate forms to the NHS's suppliers, including those that are not solely UK-based.

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

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

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

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

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

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

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

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

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

10. A D-H key management infrastructure could be used to manage asymmetric keys as well as symmetric keys. As was mentioned in the footnote to Point 6 above, the processes used by D-H can be extended simply to provide the DSA digital signature algorithm. DSA could be used for generating the necessary certificates for asymmetric keys, whether they were DSA keys or RSA keys, and according to whichever standard (for example, version 5 of x.509 standard) that was required. Consequently, the NHS would have the option of using its D-H key management infrastructure as the basis for the management of other keys as might be needed for any future interworking with other schemes, for example those which might be used in other European countries.
11. The solution outlined above will take some time to implement, in pan because of the need to pilot the technology being introduced. It is appropriate, in this case, to consider what shorter term, non-strategic solutions might exist. The options to consider are:

• existing suitable COTS (Commercial off-the-shelf) products that use other algorithms besides Red like
• products that would be appropriate for only a limited range rather than all applications.

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; PG? 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 PGI', and one of these (at least one, to Zergo's knowledge) has recently been upgraded to incorporate the Red Pike algorithm. That product would have the following advantages as an interim solution for the NHS.

• it is an E-mail security utility, and that would make it appropriate for a good proportion of the NHS's immediate need
• it already has Red Pike in it, increasing its compatibility with the recommended strategic solution
• it integrates with ordinary office E-mail systems (which addresses a major drawback of PG?)
• it works with a D-H key management layer (though a rather cut down version compared to the recommended strategic solution)
• it is available today.

This product should not be seen as a strategic solution for the NHS for many of the same reasons that PGP is not (see earlier in this Appendix), and those are.

• it is designed for messaging and could not be used for interactive communications
• there is only the one supplier
• it does not have a mechanism for the convenient distribution of encryption keys, which would limit its suitability for such a large community as the NHS.

However, it might have some value as a short term, interim solution for a limited range of applications, and would warrant further investigation for adoption in this capacity. That further investigation should also identify any other such products which may be on or about to enter the market.

Appendix D - Glossary of terms

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

Rambutan
A restricted HMG encryption algorithm.

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

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

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

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

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

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

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

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