Note: this document was scanned from a paper copy of
the report. There may be some scanning errors.
[cover]
The use of encryption and related services with the NHSnet
A report for the NHS Executive by Zergo Limited
Published by the NHS Executive
April 1996
© Crown Copyright 1996
IMG E5254
Jump to page:
1 2 3 4
5 6 7 8
9 10 11
12 13 14
15 16 17
18 19 20
21 22 23
24 25 26
27 28 29
30 31 32
33 34 35
36 37 38
39 40 41
42 43 44
45 46 47
48 49 50
51 52 53
54 55 56
57 58 59
60 61
[page1]
Contents
1 Management summary
2 Introduction
3 The context for Security Services
4 Recommended approach
5 Implementation issues
6 Benefits
7 Implementation
Appendix A Terms of reference from
the NHS Executive
Appendix B An outline architecture
Appendix C Algorithms and key management
Appendix D Glossary of terms
IMG reference number: E5254
[page2]
Preface
This report has been accepted by Ministers and by the NHS Executive. The
report confirms that provision of cryptographic services for NHSwide use
would be costly and complex. Acceptance of this report only implies commitment
to start piloting. Further action will depend on the outcome of the trials.
The report is being made available to individuals and bodies known to
be interested. Further copies may be obtained from:
Department of Health
PO Box 410
Wetherby
West Yorkshire
LS23 7LN
Tel: 01937 840250
Fax: 01937 845381
[page3]
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 manner which is highly automated
and manageable
-
the implementation process will be by no means simple. There are a number
of management and technical issues that will need to be addressed within
the implementation programme for the encryption facilities. However, an
approach is identified that will reduce the associated risks to a manageable
level
-
the recommended facilities should be readily extendible to support the
provision and use of related cryptographic services such as Digital Signatures
to prevent unauthorised tampering with the communicated data and to link
unambiguously the communicated data to the identities of the parties involved
in its exchange
-
the NHS will need to develop a key management infrastructure to sit across
the many different systems that will become encryption-enabled. This infrastructure
will require one or more Trusted Third Parties (TTP) management centres,
though the staffing requirements for these will be small
[page4]
-
the potential benefits will be considerable if encryption is found to be
a precondition for extensive use of the network services by clinicians.
The expected costs are small in comparison with the costs of the IT facilities
with which they would be used, and in proportion with the expected costs
of networking
-
the main manpower costs for the NHS will relate to the running of the pilot
and subsequent implementations. For these, the NHS will need to provide
a few tens of man-years of internal staff resource. There is the potential
for approximately £250,000 worth of external expert security consultancy
to assist in these programmes. The day to day operation of the TTP(s) will
require only a handful of staff, at most eight full time equivalent staff.
There will not be the need for many thousands of users to be trained up
before encryption can be used
-
the possible equipment costs for introducing encryption across the NHSnet
could well be in the range £15M to £20M, spread over an implementation
programme spanning several years. At the end of this programme, the annual
on-going costs could be expected to be in the range £2.5M to £3M.
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.
[page5]
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.
[page6]
2 Introduction
The NHS is in the early stages of implementing the NHS-Wide Network (NWN)
also known as the NHSnet. The NWN has an associated NWN Security Policy
and Codes of Connection, and guidelines on the use of access controls on
the network. The network does not presently have any general provision
for the use of encryption or related cryptographic services for protecting
the confidentiality of data transmitted across the network.
However, a number of technical barriers which have made the use of encryption
by the NHS difficult in the past have been lowered recently. These include
general product developments in the cryptography marketplace, greater experience
in the security management of large and diverse networks, and a change
in policy and approach by the relevant government department (CESG the
Communications-Electronics Security Group). These have, amongst other things,
shown that encryption can be employed by organizations which are large
and diverse and which do not follow a strictly hierarchical organisational
structure.
As a result, and mindful of the possible need for such services, the
NHS Executive in September 1997 commissioned Zergo Limited to undertake
a study to investigate the ramifications of providing encryption and related
services across the NWN.
The Objectives of the study were:
-
to examine the contexts in which encryption and other data security services
would be required for the exchange of Person Identifiable Data across the
NWN
-
to describe suitable techniques for implementing these security services
-
to identify and describe the many different impacts the recommended facilities
would have on the various parties involved in the use and operation of
the NWN, including the likely benefits and expected costs for each stakeholder
-
to identify and discuss an implementation approach appropriate to the particular
environment of the NWN where the end-user organizations enjoy a great deal
of autonomy.
[page7]
This report draws on a requirements study carried out by C International
Ltd. The scope of that study was to identify all current and expected future
information flows (both interactive sessions and messaging oriented) that
might need to use encryption facilities across the NWN. Given the high
number of potential data flows, it was decided to focus the analysis on
the primary healthcare sector. This was expected to embrace all the issues
concerning security and would be focusing attention on an area of particular
security concern. This analysis was supplemented by a high level review
of other areas of the NHS to ensure that all significant security requirements
had been identified. The findings of the requirements study were ratified
through a workshop held in December 1995. A summary of the findings is
included within Section 3 of this report.
The organization of this report is as follows.
-
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.
[page8]
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.
[page9]
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.
[page10]
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
email to the wrong e-mail address) if the (unintended) recipient did not
posses the correct decryption keys.
It can be argued that that the type of Person Identifiable Data which
will shortly be passed over the NWN has in the past been transmitted between
healthcare professionals by mail or by telephone, and that similar risks
of disclosure have long existed. However, it is important to realise that
the use of electronic means of communication does introduce new security
threats and security risks. For example, it is relatively easy to automate
the process of sifting through a large amount of text-based message traffic
searching for key words and information of particular interest. This kind
of eavesdropping is a threat to communicated Person Identifiable Data and
is less laborious than that of steaming open mail or tapping telephone
conversations.
[page11]
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.
[page12]
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.
[page13]
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 messaging applications,
for example the transmission of pathology test results. A several second
delay for cryptographic processing would be unlikely to cause problems
for the users. At the other extreme is remote consulting where high bandwidth
data streams would need to be encrypted with minimal delay and in real
time.
The table below summarises this situation.
|
Delays of a second
or more unacceptable |
Delays of several
seconds acceptable |
Low data throughput |
Text-based interactive
session |
Messaging |
Medium data throughput |
Windows-based
interactive session |
Some file transfer |
High data throughput |
Remote consulting,
high data rate link between
acute unit and FM supplier |
Some file transfer |
[page14]
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, UNIX systems, VMS systems, more unusual operating
systems such as PICK, and of course PC-based systems running under network
operating systems such as Novell and Windows NT as well as DOS and Windows
-
the continuing use of obsolescent hardware platforms such as outdated PCs
with limited processing power
-
application programs spanning a wide range of qualities of design and of
support. These include user written applications, applications where the
supplier has since gone out of business, and applications where the design
and documentation is so fragile or so poorly understood that they cannot
safely be modified.
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.
[page15]
4 Recommended approach
This section presents a summary of Zergo's recommended approach to the
provision of encryption facilities. Further supporting detail describing
the rationale behind the recommendations is presented in Appendices B and
C towards the end of this report.
This section, and the remainder of this report, employ a number of technical
terms which may not be familiar to some readers. Appendix D contains a
glossary to assist the interested reader.
4.1 Introduction
The study of the communications contexts has shown that there are many
cases where the value or sensitivity of the information exchanged is sufficient
that the use of encryption would be appropriate. This judgment is based
on an assessment of the magnitude of the possible impact on one or more
parties if confidential data were to be disclosed.
Adding encryption across the NWN as a whole has recently become technically
feasible. And, drawing on the wealth of experience available from the Financial
Services sector, the operation of encryption across a wide and diverse
user community (of many thousands of users) has been shown to be manageable.
It is not necessary for the encryption facilities to be implemented everywhere
at once. A planned and phased implementation programme can be adopted with
the benefits of encryption beginning to flow from the start. The implementation
process will require care and effort, and the implementation programme
is expected to take several years to complete. A number of technical and
management issues will need to be addressed in the early stages. For those
users in need of encryption capabilities in the short term, alternative
interim options are available. These are discussed at the end of this section.
4.2 Choice of Encryption Algorithm
A number of encryption algorithms, public domain and proprietary, exist.
However, strong encryption algorithms are not available for general use,
and those algorithms which are available for general use (for example,
in the form of commercial off-the-shelf products) are not regarded as adequately
strong for the protection of Person Identifiable Data. Consequently, the
selection of a suitable encryption algorithm is not, in this situation,
straightforward.
[page16]
Given the national interest in the proper protection of Person Identifiable
Data, the advice of the National Technical Security Authority, CESG, has
been sought on the choice of encryption algorithm. CESG's advice is that,
in the case of the NHS, there are security benefits to be obtained from
avoiding the use of encryption algorithms which are in the public domain.
CESG has recently been able to make available to the NHS (and to others,
including non-financial sector organizations) a suitable non-public domain
algorithm known as Red Pike. This encryption algorithm is very new,
but there are already a small number of products available on the market
which use it, and a wider range of products which use related algorithms
and which could quickly and simply be modified to use Red Pike. Consequently,
the NHS need not fear that it might become locked in to a single product
or single supplier if it were to adopt Red Pike as its preferred
encryption algorithm.
For the suppliers of encryption products, the NHS would represent a
large user community, and this size of potential market would encourage
the development of an active and competitive market in Red Pike products.
Also, the NHS is not alone in wanting to encourage the development of an
active Red Pike marketplace. Many large international Organizations
outside the Financial Services sector are in need of similar encryption
facilities. And, at the same time, HMG has a number of initiatives currently
underway which will lead to the development of Red Pike-based systems.
For example, a CCTA-driven initiative to allow suppliers to government
departments to submit proposals electronically, and an Inland Revenue-driven
initiative to allow small businesses to file Tax returns electronically.
These Organizations should add their weight to the NHS's to encourage a
wide range of commercial off-the-shelf (COTS) products to be developed.
4.3 Technical Approach
In light of the conclusions drawn from studying the many dataflow contexts
described in the previous section of this report, and in view of the NHS's
networking strategy, the NHS's network security strategy should, in the
large, favour providing the encryption facilities to the host system whenever
possible and, only if justified on a case by case basis, provide it directly
on the network itself.
[page17]
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
[page18]
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 needs1. If equipped with a suitable general
purpose package, the user would be able to use encryption or not according
to an explicit decision that they would make at the time as to whether
the traffic they were about to transmit warranted its use.
Hence, there are a number of routes by which users might arrive at the
use of encryption, as follows:
-
by default, because the use of encryption had been written into the application
-
by choice, because in view of their judgment of the risks the users requested
the system provider to implement encryption with the system, and they accepted
the extra cost
-
each at their individual discretion, where they would have a general purpose
encryption utility such as a secure E-mail package and they could decide
on a case-by-case basis that a particular message needed to be encrypted.
[Footnote 1]
1 As is discussed in Appendix C, PGP has a number
of shortcomings in this context. The main shortcomings are:
-
it is designed for a messaging environment and would not
be usable for interactive communications
-
it uses an algorithm controlled by a single Swiss company
-
it does not integrate well with commonly found of office
e-mail packages, making it difficult to use for the non-technical user
-
its key management does not make it easily scalable beyond
small numbers of users.
[page19]
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.
[page20]
Given the size of the NHS community and the need for the simplest of means
for initialising the users' encryption facilities, the NHS will need to
develop a key management infrastructure which is built on the use of what
are known as asymmetric methods, and using one or more Trusted Third Party
(TTP) facilities. These TTPs would play a role in the secure initialisation
of the users' encryption facilities (they could, for example, perform EDIFACT-style
key notarisation) and in the periodic changing of some of the users' keys.
The TTPs would provide a secure means by which users could obtain the appropriate
high-level cryptographic keys of other users to allow two parties ultimately
to exchange encrypted data. These high-level keys obtained from the TTPs
would not normally be the keys used to protect the exchanged data; those
keys would be generated and exchanged automatically and bilaterally between
the two communicating parties. Hence, the TTPs themselves would not need
to be involved in each exchange of encrypted data. The TTPs would represent
only a small overhead to the use of encryption on the network and would
add only a negligible amount of additional network traffic.
The TTPs would not require a large establishment for their daily operation.
TTP services could be provided by one or more external service providers
or by the NHS itself. As the keys being managed will include end-system
keys, not just network keys, the TTPs should not be provided by the NWN
suppliers as part of the NWN service. Indeed, the TTPs could be used to
manage a wide range of cryptographic keys, not just those associated with
the use of these Red Pike encryption facilities, and to provide
associated services which are not essentially cryptography based. For example,
if there were the need, a TTP could be used to provide a general Directory
Service for the NWN. The NHS will need to investigate the liability issues
associated with the operation of these TTPs (for example, any liabilities
that might arise from errors leading to the creation of a key certificate
for an unauthorised user), to determine whether there are any constraints
or limitations on the TTP services being provided by external suppliers
or whether they would need to be provided by NHS entities, and to determine
for itself the services they could be allowed to provide and the operational
constraints and controls that will be needed.
[page21]
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.
[page22]
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 sufficiency widely
available (being controlled by a single vendor, or under other restrictions)
or, if they are widely available, are recognised to be of inadequate strength.
The widely available form of RC4 has been shown through published attacks
to suffer from this latter shortcoming. The users would need to be aware
of these problems and would need to accept the associated risks if they
were to use such algorithms.
[page23]
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
-
For many not familiar with the subject, the issues relating to the use
of encryption and key management can seem complex and obscure. The NHS
will need to present its security decisions and proposed encryption approach
carefully when dealing with the many stakeholders. These include primarily:
-
clinicians and health care professionals
-
clinical professional organisations, such as the BMA
-
health care managers
-
end-system owners
-
system and network service suppliers
-
press and public.
Each will have its own interests and legitimate concerns, and will require
specific attention from the NHS.
Zergo believes that each stakeholder should be able to support the recommended
encryption approach. Significantly in the NHS's favour is that, by using
Red Pike, the NHS will (subject to independent confirmation of the
strength of the algorithm - see Section 5.2 below) be using a stronger
encryption algorithm than the Data Encryption Standard (DES), an algorithm
that has been used for over ten years within the Banking sector. This should
assure all concerned that the NWN can be a suitably secure vehicle for
the exchange of confidential Person Identifiable Data. In addition, the
NHS can demonstrate that it has sought and taken expert advice from both
HMG s security advisors and from independent experts on the cryptographic
tools it should use. Zergo is confident that no significant criticism of
the Cryptographic adequacy in today's environment of the NHS's current
encryption proposals should remain outstanding.
[page24]
-
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.
-
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.
-
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.
-
The NHS may need to steer an intermediate course between forbidding the
use of the NWN for the transmission of certain types of data in unencrypted
form (which might be unacceptable to some users) and leaving it to the
users unaided to decide whether to use the encryption tools that are offered.
This latter option would require a high level of security awareness from
the users, and this is not likely to be present generally across the user
community.
An Executive Board policy decision would be needed on the approach to
be adopted with respect to the take-up of encryption facilities within
NHS systems and the NWN. It will need to be decided where the responsibilities
should lie for deciding on the extent to which encryption should be used,
and on what would be considered suitable timescales over which the take-up
of encryption should occur. Then, guidance will be needed for system owners
to support them in complying with the policy, and for system providers
to help them interpret the policy consistently. The NHS might wish to facilitate
a forum of user representatives and other interested parties which issues
guidance to the wider user community on the use of the encryption facilities
with the NWN. This presents the NHS management with an opportunity to take
the initiative on the setting and presentation of security issues and standards.
The guidance would need to be written in the context of the current Data
Networking Security Policy, Guidelines, and Codes of Connection.
[page25]
-
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 NHS 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 repricing 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.
-
The legal, commercial and Organizational issues surrounding the creation
of Trusted Third Parties will have to be investigated. These will need
to include:
-
the Terms of Reference for establishing the TTPs
-
the need for or form of charging for the TTP's services
-
Legal conditions under which TTPs will be able to release information under
their control or care
-
to whom TTPs will release each category of information
-
the liabilities that will fall to the operators of the TTP, to the NHS
centrally and to the NHS user in the event of a failure in the TTP's controls
-
what kind of entity could be acceptable as a TTP, eg.:
-
NHS central Organization
-
A Trust
-
Specialist commercial security organization
-
Government department.
The pilot will allow these TTP issues to be exercised and will help the
NHS to determine its long term position with regard to the provision of
TTP services. From these and related considerations, the NHS will then
be able to determine its requirements for controls on the TTPs. The contracting
of TTP services will then need to be framed with attention being given
to the relevant legislative frameworks as they exist within English law.
[page26]
5.2 Technical Issues
-
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.
-
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.
-
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.
-
Early in the development of the NWN encryption pilot, it will be necessary
for the NHS to develop a detailed Key Management design for the core of
the key management infrastructure. This will be highly specialised work
requiring expert cryptographic assistance. Zergo advises that the NHS should,
at this stage, also seek further input from CESG to confirm that the resultant
scheme is of a sound design. CESG is expected to be strongly supportive
of the NHS's development of a key management infrastructure and can be
expected to offer its assistance in this and various other stages of the
pilot development.
[page27]
-
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.
-
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.
-
The NHS will need to identify a small number of candidate systems for use
in the encryption pilot programme. The NHS-Wide Clearing System (NWCS)
may well be a suitable candidate for the first stage of the pilot, and
there is already in place a plan to pilot the use of encryption with the
NWCS. This NWCS encryption pilot is, itself, having to address the same
issues as have been addressed in this study regarding the selection and
use of cryptographic and key management tools. Hence, it should not be
disadvantaged by being used as the first NWN encryption pilot.
It will be desirable to have more than one system used within the pilot
programme, in order to prove the feasibility of encryption across the wide
range of different systems. For example, it will be important for one of
the pilot systems to be one which involves GPs directly. Consequently,
the pilot should be a staged pilot with each stage being of successive
complexity.
[page28]
-
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.
-
The secure storage of secret cryptographic keys will have to be addressed
for each of the different types of end-site attached to the NWN. In situations
where all the cryptographic functions are implemented in software to reduce
cost, the storage of secret keys on disk always brings some residual risk
of disclosure or unauthorised access to the keys, even when the keys are
themselves stored encrypted under some other key. An alternative way to
protect the keys is to store them on some kind of removable medium or token.
It is expected that, increasingly, NHS users will be using smart cards
for system access and then the users keys could be stored on the smart
card itself instead of on the user's workstation. A number of other such
options can be identified. In all cases, it is important that, for any
system, its detailed design gives adequate consideration to the issue of
recovery from the loss of such a token. Once the implementation has started
and before it has completed there will be a considerable period of time
during which some but not all of the end users will have been encryption-enabled.
This raises an issue to do with managing the interworking between users
and applications where some will and others will not be equipped with encryption
facilities. The staged implementation programme where whole systems are
brought on-stream one at a time should minimise the size of this issue.
It may become necessary in some situations to allow the user the discretion
to determine whether or not a message should be encrypted depending on
whether the recipient is capable of decrypting such a message. In practice,
each situation will have to be examined and appropriate choices will have
to be made on a case-by-case basis.
[page29]
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. Whilst it must be understood
that the costs are only indicative, every effort has been taken to ensure
that the costs given are reasonable and useful.
[page30]
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.
[page31]
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 w ill
need to be followed, business cases developed and procurement managed.
[page32]
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 TTP will
depend on the rate at which users are brought onboard, the need to operate
dual-control over some of the more sensitive TTP operations, and the need
to provide cover for absence (holidays and sickness). It is not expected
that the TTP would need to provide support out of normal daytime working
hours; the period of cover provided each day could be determined according
to perceived need. On this basis, a manning level of four to six staff
is suggested. During periods of active implementation, these staff may
be fully utilised; during steady-state operation of the TTP, they need
be only part-time utilised, allowing them to perform other tasks. It is
assumed that maintenance and support of the equipment (TTP and user equipment)
would be provided as part of the equipment purchase costs.
[page33]
Beyond the pilot, the NHS has two options for the development of further
TTP support. It could:
either
-
remain with a single TTP, having the pilot m be established as the single
management point for all NHS encryption-enabled systems, taking each system
under its cover as the encryption facilities are increasingly widely implemented
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 TTP functions should be
no higher than, say, eight staff.
Review and On-going Enhancement
There will be the need to monitor the performance of the encryption
infrastructure and there may, periodically, be the need for its enhancement.
These will become apparent as the use of encryption advances within the
NHS and cannot be predicted. They will fit within the normal cycle of infrastructure
development.
5.3.4 Equipment Costs
The equipment needed will include the equipment in the TTP and end-system
encryption equipment, and the latter will vary according to the manner
of the various implementations. It is not possible for this report to provide
a definitive overall cost for implementing encryption on the NWN because
there is a wide range of parameters which will influence each implementation
and which cannot be determined at this stage. The overall cost will vary
according to the balance of hardware versus software implementation, the
number and variety of systems running on large or midrange hosts, the allocation
of development risk between the NHS and suppliers, and so forth. Also,
the distribution of costs between the various funding sources will vary
to some decree depending on the financing approaches used.
[page34]
Consequently, the approach we have adopted is as follows. We begin by presenting
typical indicative costs (both one-off costs and on-going annual costs)
for some of the main components that are likely to be needed somewhere
within the NWN. We then, in the following sub-section, use these to derive
broad indicative costs for adding encryption to the NWN for a number of
general user examples. Finally, we derive broad indicative costs for the
NWN as a whole using two Global Cost (GC) models based on broad global
assumptions.
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.
One-off Costs |
Key Management Infrastructure
The development of the key management and other
facilities for the TTPs, including conformance testing tools
for evaluating conformance of the users' encryption
facilities to the NHS's key management specification |
£250,000 |
Applies equally to
both Global Cost
(GC) models |
Modification of an existing application
in a "non-invasive" manner to utilise communications
encryption facilities |
£20,000 |
Applies equally to
both GC models |
Modification of an existing application
to incorporate full application level communication encryption facilities
using an API and an encryption tool-kit. |
£75,000 |
Applies to GC
model 2 only |
The price of a (PC) software license
for upgrade/additional software adding software encryption
facilities to an existing PC application where there is a
large market (1000 or more eg. at a GP Practice). This
price will be for negotiation with the supplier and could be
lower than $100 if the number of user licenses purchased
is high |
£100 |
Applies to GC
model 2 only |
The price of a (server) software licence
for upgrade/additional software adding software encryption
facilities to an existing server application (eg. at a Trust
Hospital). This price will be for negotiation with the supplier
and could depend on the number of users supported |
£5,000 |
Applies to GC
model 2 only |
The price of a hardware unit
to handle encryption of a 64Kbit/sec communications link |
£2,500 |
Applies to GC
model 1 only |
The price of a hardware unit
to handle encryption of a dial-up communications link |
£1,800 |
Applies to GC
model 1 only |
[page35]
On-going annual costs |
Key Management Infrastructure
On the basis of the TTP(s) requiring a total of eight full
time equivalent staff. |
£400,000 |
Applies equally to
both GC models |
Maintenance charges |
15% of the
one-off
equipment
costs |
Applies equally to
both GC models |
5.3.4.2 Costs for example situations
To illustrate the use of these costs, we have applied them to some representative
situations.
Example 1: Small GP Practice |
5 GPs with 3 support staff
sharing a single PC running
a UNIX based practice
system. |
Procurement cost
£100 for a software
upgrade licence, adding
software-based
communications encryption
facilities to the existing
application |
Support cost
assumed as 15% of
purchase cost,
ie. £15 p.a. |
Example 2: Large GP Practice |
10 GPs with 7 support staff
and 2 health visitors, using
15 terminals on a UNIX
client-server system running
over a LAN. The system has
connections to the LAN at
the local hospital |
Procurement cost
£100 per terminal for a
software licence, adding
software-based
communications encryption
facilities to the existing
application,
ie. £1,500 |
Support cost
assumed as 15% of
procurement cost,
ie. £225 p.a. |
[page36]
Example 3: Acute Hospital |
PAS System
MUMPS based, supplier no
longer maintaining the
system |
Procurement cost
5 hardware encryption units
at £2,500 each to handle
traffic from GPs etc. across
the NWN
ie. total procurement cost
£12,500 |
Support cost
assumed as 10% of
procurement cost,
ie £1,250 p.a. |
Order Communication
System |
No encryption as its
communications are internal
only. |
Standalone Theatre
System
Recent and UNIX based,
supporting the main theatre
on the hospital campus and
a small theatre in the
community which is linked
to the system via the NWN. |
Procurement cost
2 hardware encryption units
at £2,500 each. Total cost
£5,000. |
Support cost
assumed as 10% of
procurement cost,
ie. £500 p.a. |
Radiology System
MUMPS based, due to be
replaced in the next two
years. |
It is assumed it would be
decided not to add
encryption facilities to this
system. |
Pathology System
Recent, UNIX based. |
Procurement cost
£5,000 for a software
upgrade licence adding
encryption capabilities to
the existing application. |
Support costs
at 15% of procurement
cost, £750 p.a. |
Contract Management |
Procurement cost
£5,000 for a software
upgrade licence adding
encryption capabilities to
the existing application. |
Support costs
at 15% of procurement
cost, £750 p.a. |
Office System
This is used to
communicate via E-mail with
GPs, Health Authorities and
Community Trusts. It is
assumed there are 10
terminals on this system |
Procurement cost
10 software licences at
£100 each adding
encryption facilities to each
of the ten terminals. Total
cost £1,000. |
Support costs
at 15% of procurement
cost £150 p.a. |
Link to FM Supplier
This hospital is linked to its
FM supplier, where the main
systems are located, over
the NWN. |
Procurement cost
for 4 hardware encryption
devices at £2,500 each to
secure the link, £10,000.
(The link is assumed to be
duplicated for resilience |
Support costs
at 10% of procurement
costs, £1,000 p.a. |
Total |
Procurement cost
for acute unit
£38,500 |
Support cost for acute unit
£4,400 p.a. |
[page37]
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.
[page38]
This model is based on the assumption that all encryption
is carried out in hardware
Global Cost Model 1 |
Item |
Description |
Setup-up
cost (£) |
On-going
cost (£) |
Key management |
Development of Infrastructure
Assume at most 8 full-time
equivalent staff at the TTP |
£250,000 |
£400,000 |
External Security
Expertise |
Primarily relating to the
encryption pilots |
£250,000 |
Acute sites |
250 sites, 2 encryptors per site
@ £2,500 each plus 15% p.a.
maintenance |
£1,250,000 |
£187,500 |
Community sites |
200 sites, 2 encryptors per site
@ £2,500 each plus 15% p.a.
maintenance |
£1,000,000 |
£150,000 |
FHSA sites |
100 sites, 2 encryptors per site
@ £2,500 each plus 15% p.a.
maintenance |
£500,000 |
£75,000 |
DHA sites |
1000 sites, 2 encryptors per site
@ £2,500 each
plus 15% p.a. maintenance |
£500,000 |
£75,000 |
GP practices |
9000 sites, 1 encryptor
per site @ £1,800 each
plus 15% p.a. maintenance |
£16,200,000 |
£2,430,000 |
National Systems2 |
Assume 15 additional systems,
2 network encryptors per site |
£75,000 |
£11,250 |
Total cost for Global
Cost Model 1 |
|
£20,025,000 |
£3,328,750 |
|
[Footnote 2]
2 The analysis focused on systems "owned by" acute/community/primary
organisations. There are a number of patient-based systems that do not
fit within any one of these categories such as Breast Screeening, Organ
Donor, etc. To cover these, the costs for an additional 15 systems was
added.
[page39]
This model is assumes that all encryption is carried out
by software. For costing purposes all but the GP systems are assumed to
be done as software modificatoins delivering a full applicatoin-level solution.
The GP solutions are to add software for communications encryption only.
Global Cost Model 2 |
Item |
Description |
Setup-up
cost (£) |
On-going
cost (£) |
Key Management |
Development of Infrastructure
Assume at most 8 full-time
equivalent staff at the TTP |
£250,000 |
£400,000 |
External Security
Expertise |
Primarily relating to the
encryption pilots |
250,000 |
Acute Systems |
PAS |
Software modifications
to 10 systems @ £75,000 each
plus 15% p.a. maintenance |
£750,000 |
£112,500 |
HISS |
Software modifications
to 6 systems @ £75,000 each
plus 15% p.a. maintenance |
£450,000 |
£67,500 |
Pathology |
Software modifications
to 20 systems @ £75,000 each
plus 15% p.a. maintenance |
£1,500,000 |
£225,000 |
A&E |
Software modifications
to 6 systems @ £75,000 each
plus 15% p.a. maintenance |
£450,000 |
£67,500 |
Nursing |
Software modifications
to 6 systems @ £75,000 each
plus 15% p.a. maintenance |
£450,000 |
£67,500 |
Maternity |
Software modifications
to 6 systems @ £75,000 each
plus 15% p.a. maintenance |
£450,000 |
£67,500 |
CMS |
Software modifications
to 6 systems @ £75,000 each
plus 15% p.a. maintenance |
£450,000 |
£67,500 |
Office Systems |
Software modifications
to 5 systems @ £75,000 each
plus 15% p.a. maintenance |
£375,000 |
£56,250 |
Community systems
(Provider and
Child Health
Systems) |
Software modifications
to 9 systems @ £75,000 each
plus 15% p.a. maintenance |
£675,000 |
£101,250 |
FHSA/DHA
systems |
The Exeter system, which is
MUMPS based, and district
support systems. |
£2,000,000 |
£300,000 |
National Systems |
15 systems, such as Breast
screening, which are not owned
by any of the identified
organisations |
£1,125,000 |
£168,750 |
GP Systems |
Licence fees:
3000 sites @ £1,500 each
and 6000 sites @ £100 each,
plus 15% p.a. maintenance |
£5,100,000 |
£765,000 |
Total cost for Global
Cost Model 2 |
|
£14,275,000 |
2,466,250 |
|
[page40]
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.
Summary |
|
|
Setup-up
cost (£) |
On-going
cost (£) |
GP systems |
Global Cost Model 1 |
£16,200,000 |
£2,430,000 |
|
Global Cost Model 2 |
£5,100,000 |
£765,000 |
Other systems |
Global Cost Model 1 |
£3,835,000 |
£898,750 |
|
Global Cost Model 2 |
£9,175,000 |
£1,701,250 |
Total |
Global Cost Model 1 |
£20,025,000 |
£3,328,750 |
|
Global Cost Model 2 |
£14,275,000 |
£2,466,250 |
[page41]
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 NWN,
and the level of benefit will increase in time with the degree of implementation
achieved. As Person Identifiable Data exchanged over the network is increasingly
protected, the risk to the patient of its disclosure and the possibility
of embarrassment or consequential financial penalty, will fall. Patients
will also benefit from having increased confidence in the practices of
the NHS, and from the increased quality of service provided by the healthcare
professions that will come with the increased automation and networking
of NHS systems enabled by NWN encryption.
Clinicians and health care professionals
These will benefit from being able to make wider use of the NWN so
that they achieve a reduction in bureaucracy and give better service to
their clients. Lack of encryption may have been a barrier to this in the
past, and this need no longer be the case with the introduction of encryption-enabled
systems. The level of benefit will increase with the extent of the implementation
of the encryption facilities.
To the degree that the encryption facilities are used to provide services
other than network encryption, the clinicians and health care professionals
would be able to protect confidential information in their care against
other threats. For example, the use of encryption to protect data stored
on PCs or hand-held equipment would protect the data from disclosure if
the equipment were lost or stolen.
Health Care Managers
Health Care Managers are responsible for the end-systems and are, amongst
other things, responsible for ensuring that their systems are adequately
secure for the purposes to which they are to be used. To the degree that
their systems are exposed to networking security risks and these risks
are not otherwise covered by other countermeasures, the addition of encryption
to the NWN will provide them with an effective tool to manage those risks.
Encryption could be added in a way that was responsive to the business
need and technical environment. They will then be able to direct their
attention to addressing the other non-networking security risks to their
end-systems, and to fulfilling their responsibility to manage the full
profile of risks faced by their systems. Health care managers will also
benefit from being able to develop systems and automate processes that
could not have been developed or automated without the improved security
facilities that would now become available.
[page42]
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.
-
Overall, the level of security risk faced by NHS systems will be reduced
as network security disclosure risks are reduced.
-
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.
-
The API approach to encryption proposed as part of the recommended approach
can easily be extended to provide the functionality needed to deliver message
integrity protection, user authentication and message source authentication.
Encryption in a variety of forms can also be used to support the stronger
enforcement of access control across systems, though care must be taken
to ensure that it does not interfere with or run across the desired access
control systems. Consequently, the strategic approach provides the NHS
with a highly cost-effective manner of addressing these further security
concerns.
-
Depending on the particular form of their implementation, some of the technologies
proposed to satisfy the need for encryption on the NWN can be used to address
security needs which exist outside the NWN, including the encryption of
data transmitted over other networks such as local LANs, the encryption
of data stored on hard disks, the management of cryptographic keys for
non-NWN systems, and so forth. Consequently, again, the strategic approach
provides the NHS with a highly cost-effective manner of addressing these
further security concerns.
[page43]
-
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.
-
The result of following CESG's advice in the choice of encryption algorithm
is that (subject to independent confirmation of the algorithm's strength
- see Section 5.2 above) the level of security provided on the NWN will
be higher than that in many conventional Banking systems. This will help
the NHS to counter any criticism of the NWN's security approach in so far
as confidentiality is concerned.
[page44]
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.
-
The NHS will need to have further, more detailed discussions with CESG
to:
-
understand the details underpinning CESG's position regarding the use of
encryption in the NWN, to air any particular concerns regarding, for example,
the availability of Red Pike to non-UK systems providers, the possibility
of the NHS being allowed to use alternative algorithms, expectations regarding
a possible national key management infrastructure and so forth
-
agree on any outstanding policy decisions that CESG may need to make
-
determine what assistance CESG may be able to provide to the NHS as it
puts its encryption strategy into practice.
-
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.
-
The NHS should seek legal advice on the possible implications of the legislative
framework as far as this might affect its use of TTPs.
-
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.
[page45]
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 18 months to
complete. The successive overlapping stages of the pilot could each take
nine to twelve months to complete.
Major steps within the first stage of the pilot would include:
-
Arrange for the necessary budget provisions for the Pilot programme to
be made.
-
Identify the objectives of the piloting exercise and from the results identify
suitable applications and areas of the network for involvement within the
Pilot. It will be necessary to strike a balance between choosing applications
and areas which are representative of the main problems which will be encountered
in full implementation, and ensuring that the pilot remains manageable.
Consequently. there may be a need for more than one pilot stage, each successive
one of increasing technical complexity.
-
Develop an overall plan for the pilot programme.
[page46]
-
The preparation of a number of technical standards and specifications will
be needed. Wherever possible, these should be based on existing standards.
The following will be required:
-
key management standards
-
specification for the key management systems at a trusted third party
Depending on the nature of the pilot implementation, the following may
be required
-
standards for cryptographically protected exchanges in the NWN
-
an API specification for a standard cryptographic software architecture
"tool kit"
-
for each application involved in the pilot, a specification for adding
the cryptographic capabilities.
-
Agree a contractual basis for the participation of both suppliers and users
in each stage of the pilot.
-
Ensure the availability of appropriate types of cryptographic software
and hardware products that might be required.
-
Develop the first stages of the key management infrastructure as necessary
for the first stage of the pilot.
-
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.
-
Carry out a security awareness programme for the users including any specific
guidance necessary for users to understand and use the cryptographic facilities
provided under the first pilot project. Develop the training needed for
the operators and management of the pilot TTP.
-
Implement and run the first stage of the pilot.
-
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.
-
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.
[page47]
7.4 Main Implementation Process
Agreement will need to be reached with the early adopters of encryption
regarding the relative implementation priorities to be given to each of
their systems. These priorities will be drawn up on the basis of commercial,
practical and security risk considerations as well as in the light of the
pilot results. If the results of the pilot show that few modifications
to the pilot technology (user, system or TTP technologies) are required
for the initial phases of implementation, then the implementation process
could begin almost immediately after the completion of the first stage
of the pilot. The priority phases of implementation would probably take
at least two years.
Steps to consider in the implementation process would include:
-
Define any necessary criteria for agreeing priorities for implementing
encryption in systems.
-
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.
-
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.
-
Develop and test any new technical features needed for the TTPs or key
management infrastructure as implementation progresses.
-
Carry out further user security awareness programmes including any specific
guidance necessary for users to understand and use the cryptographic facilities
being implemented.
[page48]
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
-
NHS-wide networking is intended to enable many-to-many communications for
NHS users in pursuit of their legitimate NHS business. Much of this communication
will be administrative, financial or statistical information but, increasingly
it will include clinical information about patients such as referral and
discharge letters, laboratory requests and results, and contract minimum
data sets.
-
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
-
The NHS Executive seeks advice on
-
the purposes for which these services can be used, the contexts and the
extent to which they might be used in each context
-
the probable costs and benefits which would accrue in each context, and
to which parties they would accrue
-
the most suitable standards and types of product to be used
-
the additional costs and implications of providing these services on a
national NHS basis in such a fashion that they are available for use when
those communicating NHS information think it appropriate.
[page49]
-
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.
[page50]
Appendix B
An outline architecture
-
Encryption can be applied to the NWN in any of several ways. It can be
applied:
-
on a link-by-link basis (eg. GP system to NWN Point of Presence (POP),
NWN POP to NWN switch, between NWN switches, NWN Switch to Acute system;
in hardware or software) as illustrated in Figure 1
Figure 1
-
or on an end-to-end basis as illustrated in Figure 2.
Figure 2
[page51]
There are two principal ways in which end-to-end encryption can be provided:
-
within the networking infrastructure (eg, within the TCP, X.25 or Frame
Relay communications protocol; in hardware or software) as illustrated
in Figure 3
Figure 3
-
or at the application level (eg, GP system to Acute system) where it can
either be built in to the application itself or called by the network service
(eg. the User Agent in a messaging system) (in software, possibly with
hardware to assist the performance) as illustrated in Figure 4.
Figure 4
[page52]
The preferred strategy must be to favour providing the encryption facilities
to the networked application whenever possible and only where needed on
a case by case basis to provide it directly on the network itself. There
are several advantages to be gained by this:
-
reusability of the security software - to allow the security facility to
be used by more than one application if needed
-
versatility of the security software - to allow the security facility more
easily to meet the varied needs of different contexts
-
independence of the security code - from the networking protocol (EDIFACT,
SMTP, File Transfer, etc.)
-
information would not be available in readable plain language at intermediate
switching points
-
more cost-effective security- where multiple NWN links are involved
-
increased security coverage - where it might be possible to protect the
sensitive data within some parts of the end-system prior to its delivery
to the NWN. For example this strategy might provide protection against
eavesdropping in LAN systems.
-
Encryption can either be carried out in physically separate hardware units
or it can be carried out by software running on end systems eg. GP System,
PAS, Pathology system, Messaging user agent. Hardware solutions are generally
more expensive than software solutions, and can bring associated problems
of the control of shipments (under government regulations controlling the
export of strong encryption algorithms). On the other hand, hardware will
generally deliver better throughput performance than software.
Many applications in the NWN are of the messaging or file transfer type
so that throughput is not a prime consideration. Cost is of importance,
particularly at the GP end. Consequently, the software solution will often
be the most appropriate. Having said that, there may well be some situations
where hardware may still be appropriate, for example:
-
remote diagnosis systems (teleconsulting), where the time available for
encrypting/decrypting an image may be severely limited (here an alternative
implementation might be software with hardware assistance)
-
where an NWN link is replacing a leased line (eg. Kilostream or Megastream)
carrying legacy system traffic, eg. acute unit to FM supplier link. Here
simplicity is likely to dictate an implementation in stand-alone "black
box" encryptors or an encrypting communications card or modem
-
Router to Router links between local members of a natural community (likely
to be implemented with stand-alone "black box" encryptors).
[page53]
-
Software encryption solutions can be chosen to operate at a variety of
levels of the protocol stack. It can be argued that by positioning the
encryption function high in the stack, encryption becomes independent of
the functionality in the lower layers. This would make it possible to change
the underlying communications protocol without affecting the encryption
function, and avoid the need to decrypt and re-encrypt when passing the
transmitted data through a gateway which changes the communications protocol.
However, it is likely that there will be some situations where the application
is not amenable to this. For example, a legacy system for which there is
no longer a business case for its being changed, or for which the necessary
programming and support skills are no longer readily available. In these
situations, there can be case-by-case advantages to putting the encryption
facility in the lower levels of the protocol stack. This may arise more
often in the early days of the implementation programme and for legacy
systems, less often as time progresses.
For any system, the preferred form of implementation will need to be
determined by an analysis of the options and constraints. There should
be no system or platform for which, if encryption or related services are
required, it would not be possible to find a feasible implementation. Hence,
encryption in one or other of the forms mentioned above should be feasible
for mainframe or midrange host systems, client/server and PC-based systems,
messaging and interactive systems, and so forth. It is believed that there
are a considerable number of systems within the NHS which have been developed
using MUMPS. MUMPS contains its own communications handlers and it has
been suggested that these cannot readily be adapted to call encryption
routines. If this is confirmed by further technical analysis, MUMPS systems
may find they are not able to use the network-level security software option.
In this case, they would be constrained to use other options, either application-level
(Security API) software or network-attached (hardware) line encryption
devices.
-
To allow interoperability between different implementations, software encryption
must conform to a defined set of standards. There is a need to avoid the
requirement for every application developer to become an expert in programming
cryptography. These two considerations lead to the concept of defining
a standard set of cryptographic software tools which present a standard
Security Application Programming Interface (Security API). In a client/server
environment, these tools may be provided by a separate cryptographic server.
[page54]
-
De facto standards are emerging for such Security APIs (for example, the
GSSAPI - the Generic Security Services API). Most security product suppliers
are already working with these types of standards. Variations in the software
used to support these Security APIs will be required to port the Security
API across different operating system platforms: eg. UNIX PC Windows, MVS.
-
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.
-
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.
-
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.
[page55]
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.
-
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.
-
Conventional symmetric algorithms that are in the public domain, for example,
RC4 (40 bit equivalent key length - often found in Internet security products)
or DES (56 bit equivalent key length - widely used throughout the Banking
sector), would not be adequate to the NHS's needs. There are no stronger
symmetric algorithms in the public domain which are not restricted in one
way or another (by patent or by other controls) and which would, therefore,
be available for use throughout the NHS.
[page56]
-
The published E-mail security package PGP would not be suitable
as a strategic solution to satisfy the requirement for NWN encryption.
-
PGP is designed for the one way messaging environment and could
not be used for interactive communications
-
PGP uses an algorithm which is patent controlled (the IDEA algorithm
for which the patent is held by a Swiss company ASCOM). Hence, the NHS
would be tied to a single algorithm supplier which was both a commercial
organization and non-UK based
-
PGP is available either unsupported as freeware or as a commercial
version from a single supplier. Neither option would be attractive strategically
to the NHS
-
PGP does not define a mechanism for the convenient distribution
of encryption keys. This would severely limit its suitability for such
a large community as the NHS. It is also, for this reason, vulnerable to
"man in the middle" attacks in which an attacker arranges for a sender
of information to be provided with his public key in place of the public
key of the intended destination of the information. The attacker is then
able to decrypt the information and send it on to the true destination
using the correct public key.
This problem can be overcome with the use of a Trusted Third Party (TTP),
and, indeed, a TTP is required for the proposed solution. However, this
means that PGP could not be used as a strategic solution in its
current form. Its wide scale use would require the modification of the
package by the supplier to include interfaces to a TTP infrastructure
-
PGP does not integrate well with standard of office e-mail packages.
For the non-technical user, PGP would require the development of
a front-end to de-skill its user interface. Again, this means that PGP
could not be used as a strategic solution in its current form
-
CESG has also advised that there are significant security advantages to
using unpublished algorithms rather than published algorithms. However,
unpublished algorithms will be either proprietary, unaccepted by the cryptographic
community, or strictly controlled by the governments that have developed
them. Any one of these would make the algorithm either unacceptable or
unavailable to the NHS.
[page57]
The NHS is, therefore, in the constrained position of needing to use an
encryption algorithm that is sufficiency strong for its protection needs
but which can also be made available across the NHS as a whole and to the
NHS's many systems suppliers. Until recently, no such algorithm existed
to be used by the NHS. However, within the last 12 months, this situation
has changed. CESG has responded to this situation, which the NHS shares
with many other large organisations outside the government or Financial
Services sectors, by developing an algorithm known as Red Pike.
The recommendation from CESG, and supported by Zergo, would be that the
NHS should use this algorithm to meet its data encryption needs.
Red Pike has been released only recently and a number of necessary
National Policy decisions were made by CESG in the last months of 1995
relating to its distribution and use. Red Pike can be implemented
in software as well as in hardware, and in a number of forms to facilitate
its use with a variety of systems and on a variety of platforms. There
are no standards covering the use of Red Pike. However, Red Pike
has been designed to share a number of characteristics with DES, for which
there are many public standards. Hence, Red Pike could easily be
used in accordance with those standards. And Red Pike can be released
in appropriate forms to the NHS's suppliers, including those that are not
solely UK-based.
-
Whenever a cryptographic algorithm is used for data encryption, one or
more encryption keys will need to be exchanged or agreed between the two
parties (the sender and the receiver) so that only the authorised receiver
is able to decrypt traffic encrypted by the sender. This process is known
as Key Management.
Among the users of the NHS-wide networking system, there will be many
users of encryption and, for each user, potentially many other users for
which it will require new or unique keys to ensure secure communication.
Hence, for many of the users, and certainly when looking across the NHS
community as a whole, there will be many keys to be managed. For this reason
of very large scale, it will be essential for the NHS to have a Key Management
infrastructure that includes the use of asymmetric key management methods.
This would exclude the use by the NHS of the most long-standing and,
therefore. widely used key management standards (for example. the ANSI
X9.17 standard). However, asymmetric key management methods have been used
and well proved in large networks (many thousands of users) in the last
five years, and suitable international standards are now in existence for
these.
[page58]
-
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).
-
HMG has, for a number of years, been developing its ideas for a national
Public Key Management Infrastructure having what is known as Key Recovery
(KR) capabilities. HMG's interest in Key Recovery is driven by its Law
Enforcement needs. Papers describing schemes with this capability are now
in the public domain for review and comment. It is expected that eventual
national policy in this area, supported by legislation, will involve the
use of KR capabilities shaped closely along the lines indicated by current
papers.
It is strongly expected that the UK national scheme will be built around
the use of D-H techniques. It is even more certain that the UK national
scheme will not be built on the use of RSA techniques. Consequently, the
advice from CESG, supported by Zergo, would be that the NHS should develop
a Key Management infrastructure that uses D-H rather than RSA techniques.
-
The NHS should consider, when it designs the details of its key management
infrastructure, whether it wishes to implement the KR capability within
it or not. For example, the NHS should determine whether it would be necessary
for the NHS itself, under suitable controls, to have the ability to decrypt
selected traffic in order to check that the encryption capabilities it
provides to the end users are not being misused for criminal or fraudulent
ends. The NHS would also need to ensure that the key management infrastructure
it developed was resilient in the event of the failure of a piece of equipment
storing encryption keys. This resilience could be provided in a number
of ways, one of which could be through the use of a KR capability.
The NHS could reserve its options in this regard by following a two
stage strategy: it could develop a first stage infrastructure which used
D-H without the KR capability; to be extended in a second stage when or
if desirable to include the KR capability. The first stage might be needed
only for the pilot. Alternatively, if the NHS so wished, the first stage
could be used all the way through nation-wide implementation. It must be
realised that, if the KR capability were to be introduced, it would lead
to very tight operational controls being needed at the TTPs.
[Footnote 3]
3 DSA uses cryptographic keys and fuynctions which are
very close to those used by D-H. Consequently, even though Digital Signatures
cannot be provided by Red Pike, they can be introduced easily using
functions implemented within the D-H key management scheme.
[page59]
-
The D-H functionality (with or without KR capability) will allow two networked
end-systems to agree a symmetric key for bilateral use. This key may be
used as the Red Pike key for message encryption. Alternatively,
it might better be used to protect (by encryption) a second Red Pike
key, that key then being exchanged between the two end-systems and being
the one used for message encryption.
This use of encryption keys to encrypt other encryption keys is a well
established Key Management technique and can be used to allow the frequent
and automatic changing of message keys without the overhead of renewing
frequently the higher-level D-H keys. Indeed, it is not unusual to have
a multi-layered hierarchy of symmetric keys allowing the key at the top
of the hierarchy to be changed only rarely whilst the keys at the bottom
of the hierarchy can be changed automatically with each and every message.
The NHS should build in to its Key Management infrastructure the flexibility
to allow this key hierarchy technique to be used wherever needed.
-
A D-H key management infrastructure could be used to manage asymmetric
keys as well as symmetric keys. As was mentioned in the footnote to Point
6 above, the processes used by D-H can be extended simply to provide the
DSA digital signature algorithm. DSA could be used for generating the necessary
certificates for asymmetric keys, whether they were DSA keys or RSA keys,
and according to whichever standard (for example, version 3 of the X.509
standard) that was required. Consequently, the NHS would have the option
of using its D-H key management infrastructure as the basis for the management
of other keys as might be needed for any future interworking with other
schemes, for example those which might be used in other European countries.
-
The solution outlined above will take some time to implement, in part because
of the need to pilot the technology being introduced. It is appropriate,
in this case, to consider what shorter term, non-strategic solutions might
exist. The options to consider are:
-
existing suitable COTS (Commercial off-the-shelf) products that use other
algorithms besides Red Pike
-
products that would be appropriate for only a limited range rather than
all applications.
[page60]
The general problem with COTS products which do not use Red Pike
are that they are either not available for the NHS's use or, if they are,
they do not have an adequate level of cryptographic strength. There is
one specific product, PGP, which does not suffer from these drawbacks.
That has been dismissed as not being a suitable strategic solution for
the NHS (see earlier in this Appendix), and a number of those reasons would
also limit its suitability as a short-term solution. There are a growing
number of E-mail security products, either on or coming to the market,
which address some of the shortcomings of PGP, and one of these
(at least one, to Zergo's knowledge) has recently been upgraded to incorporate
the Red Pike algorithm. That product would have the following advantages
as an interim solution for the NHS:
-
it is an E-mail security utility, and that would make it appropriate for
a good proportion of the NHS's immediate need
-
it already has Red Pike in it, increasing its compatibility with
the recommended strategic solution
-
it integrates with ordinary office E-mail systems (which addresses a major
drawback of PGP)
-
it works with a D-H key management layer (though a rather cut down version
compared to the recommended strategic solution)
-
it is available today.
This product should not be seen as a strategic solution for the NHS for
many of the same reasons that PGP is not (see earlier in this Appendix),
and those are:
-
it is designed for messaging and could not be used for interactive communications
-
there is only the one supplier
-
it does not have a mechanism for the convenient distribution of encryption
keys, which would limit its suitability for such a large community as the
NHS.
However, it might have some value as a short term, interim solution for
a limited range of applications, and would warrant further investigation
for adoption in this capacity. That further investigation should also identify
any other such products which may be on or about to enter the market.
[page61]
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