oSIST prEN 13608-3:2006
Health informatics - Security for healthcare communication - Part 3: Secure data channels
Health informatics - Security for healthcare communication - Part 3: Secure data channels
Medizinische Informatik - Sicherheit für die Kommunikation im Gesundheitswesen - Teil 3: Sicherheit für Datenkanäle
Informatique de santé - Sécurité des communications dans le domaine de la santé - Partie 3 : Canaux de communication de données sécurisés
Zdravstvena informatika – Varnost komuniciranja v zdravstvenem varstvu – 3. del: Varni podatkovni kanali
General Information
Relations
Standards Content (Sample)
SLOVENSKI STANDARD
oSIST prEN 13608-3:2006
01-februar-2006
Zdravstvena informatika – Varnost komuniciranja v zdravstvenem varstvu – 3. del:
Varni podatkovni kanali
Health informatics - Security for healthcare communication - Part 3: Secure data
channels
Medizinische Informatik - Sicherheit für die Kommunikation im Gesundheitswesen - Teil
3: Sicherheit für Datenkanäle
Informatique de santé - Sécurité des communications dans le domaine de la santé -
Partie 3 : Canaux de communication de données sécurisés
Ta slovenski standard je istoveten z: prEN 13608-3
ICS:
35.240.80 Uporabniške rešitve IT v IT applications in health care
zdravstveni tehniki technology
oSIST prEN 13608-3:2006 en
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.
---------------------- Page: 1 ----------------------
oSIST prEN 13608-3:2006
---------------------- Page: 2 ----------------------
oSIST prEN 13608-3:2006
EUROPEAN STANDARD
DRAFT
prEN 13608-3
NORME EUROPÉENNE
EUROPÄISCHE NORM
November 2005
ICS Will supersede ENV 13608-3:2000
English Version
Health informatics - Security for healthcare communication - Part
3: Secure data channels
Informatique de santé - Sécurité des communications dans
le domaine de la santé - Partie 3 : Canaux de
communication de données sécurisés
This draft European Standard is submitted to CEN members for enquiry. It has been drawn up by the Technical Committee CEN/TC 251.
If this draft becomes a European Standard, CEN members are bound to comply with the CEN/CENELEC Internal Regulations which
stipulate the conditions for giving this European Standard the status of a national standard without any alteration.
This draft European Standard was established by CEN in three official versions (English, French, German). A version in any other language
made by translation under the responsibility of a CEN member into its own language and notified to the Management Centre has the same
status as the official versions.
CEN members are the national standards bodies of Austria, Belgium, Cyprus, Czech Republic, Denmark, Estonia, Finland, France,
Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Slovakia,
Slovenia, Spain, Sweden, Switzerland and United Kingdom.
Recipients of this draft are invited to submit, with their comments, notification of any relevant patent rights of which they are aware and to
provide supporting documentation.
: This document is not a European Standard. It is distributed for review and comments. It is subject to change without notice and
Warning
shall not be referred to as a European Standard.
EUROPEAN COMMITTEE FOR STANDARDIZATION
COMITÉ EUROPÉEN DE NORMALISATION
EUROPÄISCHES KOMITEE FÜR NORMUNG
Management Centre: rue de Stassart, 36 B-1050 Brussels
© 2005 CEN All rights of exploitation in any form and by any means reserved Ref. No. prEN 13608-3:2005: E
worldwide for CEN national Members.
---------------------- Page: 3 ----------------------
oSIST prEN 13608-3:2006
prEN 13608-3:2005 (E)
Contents Page
Foreword.3
Introduction .4
1 Scope .6
2 Normative references .6
3 Terms and definitions .6
4 Symbols and abbreviations .11
5 Requirements.12
Annex A (informative) TLS overview .14
Annex B (informative) Usage examples .17
Annex C (informative) Securing of existing protocols with TLS .19
Annex D (informative) Plaintext recovery .22
Bibliography .23
2
---------------------- Page: 4 ----------------------
oSIST prEN 13608-3:2006
prEN 13608-3:2005 (E)
Foreword
This document (prEN 13608-3:2005) has been prepared by Technical Committee CEN/TC 251 “Health
informatics”, the secretariat of which is held by NEN.
This document is currently submitted to the CEN Enquiry.
This document will supersede ENV 13608-3:2000.
EN 13608 consists of the following parts, under the general title Health informatics — Security for Healthcare
Communication:
Part 1: Concepts and Terminology
Part 2: Secure Data Objects
Part 3: Secure Data Channels
This standard is designed to meet the demands of the Technical Report CEN/TC251/N98-110 Health
Informatics — Framework for security protection of health care communication.
This standard is drafted using the conventions of the ISO/IEC Directive Part 3.
All annexes are informative.
3
---------------------- Page: 5 ----------------------
oSIST prEN 13608-3:2006
prEN 13608-3:2005 (E)
Introduction
The use of data processing and telecommunications in health care must be accompanied by appropriate
security measures to ensure data confidentiality and integrity in compliance with the legal framework,
protecting patients as well as professional accountability and organizational assets. In addition, availability
aspects are important to consider in many systems.
In that sense, the multipart standard prEN 13608 has the intention of explaining and detailing to the healthcare
end user the different alternatives they have to cope with in terms of security measures that might be
implemented to fulfil their security needs and obligations. Incorporated within this is the standardization of
some elements related to the information communication process where they fall within the security domain.
In the continuity of the Framework for security protection of health care communication (CEN/TC251/N98-110),
hereafter denoted the Framework, whose CEN Report aimed at promoting a better understanding of the
security issues in relations to the healthcare IT-communication, this European standard shall aid in producing
systems to enable health professionals and applications to communicate and interact securely and therefore
safely, legitimately, lawfully and precisely.
The multipart standard prEN 13068 is key communication security standard that can be generically applied to
a wide range of communication protocols and information system applications relevant to healthcare, though
they are neither complete nor exhaustive in that respect. This standard must be defined within the context and
scenarios defined by the TC251 work programme, in which the messaging paradigm for information system
interaction is one of the essentials, as it was reflected by the Framework (Framework for security -protection
of health care communication.)
Secure Data Channel
This part 3 of the European standard on Security for Healthcare Communication describes how to securely
communicate arbitrary octet streams by means of a secure data channel communication protocol.
NOTE This standard does not specify methods related to availability, storage or transportation of key certificates or
other infra-structural issues, nor does it cover application security aspects such as user authentication.
A secure data channel is defined for the purposes of this standard as a reliable communication protocol that
implements the following security services:
1) authentication of communicating entities prior to the communication of any other data preservation of
data integrity;
2) preservation of confidentiality of the communicated data.
A secure data channel protocol operates in two distinct phases which, however, may be repeated:
1) negotiation phase: authentication of communicating entities (e.g. exchange of certificates),
negotiation of the cipher suite to be used, derivation of a shared secret using a key exchange
algorithm;
2) communication phase: transmission of user data encrypted according to the negotiated cipher suite.
In addition the secure data channel can be closed by either party when it is no longer required.
4
---------------------- Page: 6 ----------------------
oSIST prEN 13608-3:2006
prEN 13608-3:2005 (E)
The concept of a secure data channel can be best understood by looking at it’s properties, especially in
comparison with the properties of a secure data object (prENV 13608-2).
1) Interactivity: the negotiation phase allows the communicating entities to interactively agree upon a
cipher suite that meets both parties’ security policies for the communication scenario in question (e.g.
national vs. international communication). If the cipher suite negotiation is unsuccessful, no
communication session is established.
2) Transience: the secure data channel, being part of a layered communication protocol, receives and
delivers unsecured user data from and back to the calling layer. The encrypted representation of the
data is transient (e.g. available only during transmission) and unavailable to the calling layer (e.g.
application).
3) Performance: after the establishment of the cipher suite and shared secret during the negotiation
phase, there is no need to use the computationally resource intensive asymmetric cryptographic
algorithms during the communication phase. On the other hand, because of the transience of the
encrypted representation of the data, encryption must be performed during the communication
process and cannot be pre-computed off-line.
4) Forward secrecy: can be easily implemented as part of the key exchange protocol.
5) Completeness: since the authentication of the communicating entities (e.g. certificate exchange) is
part of the protocol, no additional out-of-band communication (e.g. look-up of certificates in a trusted
directory) is required to use the secure data channel, except if certificate revocation lists are used.
6) Transparency: a secure data channel can be implemented such that it’s upper service access point
resembles it’s lower service access point (e.g. TCP/IP socket interface). This allows the easy
addition of security services to existing non-security-aware systems and protocols by integrating the
secure data channel as an additional layer in the communication protocol stack. A well-known
example for this approach is ”Secure HTTP” (HTTP over SSL3).
The IETF Transport Layer Security (TLS) specification is a description of how to provide a secure data
channel. Although TLS is an IETF specification, it is not limited to TCP/IP. TLS only requires the presence of a
reliable transmission protocol. This means that ”TLS over OSI” would be possible if desired. This European
standard defines a set of profiles used within TLS for use within healthcare communication over secure data
channels.
5
---------------------- Page: 7 ----------------------
oSIST prEN 13608-3:2006
prEN 13608-3:2005 (E)
1 Scope
This European standard specifies services and methods for securing interactive communications used within
healthcare.
Interactive communications are defined for the purposes of this standard as scenarios where both systems
are online and in bi-directional communication simultaneously. Securing in this European standard includes
the preservation of data integrity, the preservation of confidentiality with respect to the data being
communicated, and accountability in terms of authentication of one or both communicating parties.
NOTE Examples of interactive communication are the download of HTML content over the Internet, a DICOM
communication, or remote login to a computer.
This European standard does not specify methods related to availability of the interactive communication,
certification and certificate management and key management. Neither does this European standard specify a
mechanism for concealing that a communication session is in progress. This European standard does not
specify the methods or services required to secure the communicating systems themselves.
2 Normative references
The following referenced documents are indispensable for the application of this document. For dated
references, only the edition cited applies. For undated references, the latest edition of the referenced
document (including any amendments) applies.
ISO 7498-2, Information processing systems — Open Systems Interconnection — Basis reference mode —
Part 2: Security architecture.
ISO 8824, Information technology — Open Systems Interconnection — Specification of Abstract Syntax
Notation One (ASN.1) (Version 2 1991-04-24).
ISO 9594-8, Information technology — Open Systems Interconnection — The Directory: Authentication
framework.
ISO 10181-1, Information technology — Open Systems Interconnection — Security frameworks for open
systems: Overview.
RFC 2246, Internet Engineering Task Force: The TLS (Transport Layer Security) Protocol, RFC 2246.
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
3.1
accountability
the property that ensures that the actions of an entity may be traced uniquely to the entity
[ISO 7498-2]
3.2
asymmetric cryptographic algorithm
an algorithm for performing encipherment or the corresponding decipherment in which the keys used for
encipherment and decipherment differ
[ISO 10181-1]
6
---------------------- Page: 8 ----------------------
oSIST prEN 13608-3:2006
prEN 13608-3:2005 (E)
3.3
authentication
process of reliably identifying security subjects by securely associating an identifier and its authenticator
See also data origin authentication and peer entity authentication
[ISO 7498-2].
3.4
availability
property of being accessible and useable upon demand by an authorised entity
[ISO 7498-2]
3.5
certificate revocation
act of removing any reliable link between a certificate and its related owner (or security subject owner),
because the certificate is not trusted any more whereas it is unexpired
3.6
certificate holder
an entity that is named as the subject of a valid certificate
3.7
certificate user
an entity that needs to know, with certainty, the public key of another entity
[ISO 9594-8]
3.8
certificate verification
verifying that a certificate is authentic
3.9
certification
use of digital signature to make transferable statement about beliefs of identity, or statements about
delegation of authority
3.10
certification authority
an authority trusted by one or more users to create and assign certificates. Optionally the certification authority
may create the users' keys
[ISO 9594-8]
3.11
ciphertext
data produced through the use of encipherment. The semantic content of the resulting data is not available
[ISO 7498-2]
3.12
ciphersuite
an encoding for the set of bulk data cipher, message digest function, digital signature algorithm and key
exchange algorithm used within the negotiation phase of TLS
7
---------------------- Page: 9 ----------------------
oSIST prEN 13608-3:2006
prEN 13608-3:2005 (E)
3.13
communication protection profile
CPP
a statement of systematic translation form communication security needs to technological concepts
3.14
communication security
security of security objects communicated between security subjects
3.15
confidentiality
the property that information is not made available or disclosed to unauthorised individuals, entities, or
processes
[ISO 7498-2]
3.16
cryptography
the discipline which embodies principles, means, and methods for the transformation of data in order to hide
its information content, prevent its undetected modification and/or prevent its unauthorised use
[ISO 7498-2]
3.17
cryptographic algorithm
cipher
an algorithm used to transform data to hide its information content which is used in the process of encryption
(see 3.22)
3.18
data integrity
the property that data has not been altered or destroyed in an unauthorised manner
[ISO 7498-2]
3.19
data origin authentication
the corroboration that the source of data received is as claimed
[ISO 7498-2]
3.20
decryption
decipherment
process of making encrypted data reappear in its original unencrypted form. The reversal of a corresponding
reversible encipherment
3.21
digital signature
data appended to, or a cryptographic transformation (see cryptography) of a data unit that allows a recipient of
the data unit to prove the source and integrity of the data unit and protect against forgery e.g. by the recipient
[ISO 7498-2]
3.22
encryption
encipherment
the cryptographic transformation of data (see cryptography) to produce ciphertext
[ISO 7498-2]
8
---------------------- Page: 10 ----------------------
oSIST prEN 13608-3:2006
prEN 13608-3:2005 (E)
3.23
forward secrecy
technique of ensuring that the communicated data is only decipherable for a limited time span by the
communicating parties
NOTE After that time the communicating parties typically achieve forward secrecy by destroying cryptographic keys.
This prevents an attacker from coercing the communicating parties into decrypting old ciphertext.
3.24
hash function
a (mathematical) function that maps values from a (possibly very) large set of values into a smaller range of
values
[ISO 10181-1]
3.25
integrity
the property of being unmodified by any kind of unauthorised security subject
3.26
key
a sequence of symbols that controls the operations of encipherment and decipherment
[ISO 7498-2]
3.27
key distribution
process of publishing, or transferring to other security subjects a cryptographic key
3.28
key exchange algorithm
an algorithm used to derive a shared secret over an open communications channel
3.29
key generation
process of creating a cryptographic key
3.30
key management
the generation, storage, distribution, deletion, archiving and application of keys in accordance with a security
policy
[ISO 7498-2]
3.31
message recovery
process of a third party decrypting an encrypted message
3.32
one-way function
a (mathematical) function that is easy to compute but, when knowing a result, it is computationally infeasible
to find any of the values that may have been supplied to obtain it
[ISO 10181-1]
3.33
one-way hash function
a (mathematical) function that is both a one-way function and a hash function
[ISO 10181-1]
9
---------------------- Page: 11 ----------------------
oSIST prEN 13608-3:2006
prEN 13608-3:2005 (E)
3.34
peer entity authentication
the corroboration that a peer entity in an association is the one claimed
[ISO 7498-2]
3.35
plaintext
intelligible data, the semantic content of which is available
3.36
private key
a key that is used with an asymmetric cryptographic algorithm and whose possession is restricted (usually to
only one entity)
[ISO 10181-1]
3.37
public key
a key that is used with an asymmetric cryptographic algorithm and that can be made publicly available
[ISO 10181-1]
3.38
secret key
key which is kept secure and only disclosed to parties intended to have access to data protected by it
3.39
security
the combination of availability, confidentiality, integrity and accountability
NOTE From an end-user perspective this encompasses auditability thereby constituting a guarantee that data items
and, more generally any kind of security object, has not been altered, modified, disclosed, or with held by any kind of
security subject in an unauthorized manner with respect to the security policy.
3.40
security object
object
a passive entity that contains or receives information [ITSEC]
NOTE Access to an object potentially implies access to the information it contains.
EXAMPLE Typical objects in the healthcare domain are: medical records, or files containing medical data.
3.41
security policy
the set of laws, rules, and practices that regulate how an organisation manages, protects, and distributes
sensitive information [TCSEC]
3.42
security protocol
a formal detailed specification describing the implementation of a set of security functions
3.43
security procedure
a specification for a protocol designed to implement a security policy
10
---------------------- Page: 12 ----------------------
oSIST prEN 13608-3:2006
prEN 13608-3:2005 (E)
3.44
security service
a service, provided by a layer of communicating open systems, which ensures adequate security of the
systems or of data transfers
[ISO 7498-2]
3.45
security subject
subject
an active entity, generally in the form of a person, process or device that causes information to flow among
objects or changes the system state. Technically, a process/domain pair [TCSEC]
NOTE According to the Object-Oriented paradigm, a subject is usually called a principal.
3.46
user certificate
public key certificate
certificate
the public keys of a user, together with some other information, rendered unforgeable by encipherment with
the private key of the certification authority which issued it
[ISO 9594-8]
Note such kinds of certificates might be dedicated, on the basis of public key certification techniques, to
attributes (i.e., attribute certificate), or digital signatures (i.e., signature certificate).
4 Symbols and abbreviations
3DES Triple DES
CORBA Common Object Request Broker Architecture
DES Data Encryption Standard
DICOM Digital Imaging and Communications in Medicine
HTML HyperText Markup Language
HTTP HyperText Transfer Protocol
IETF Internet Engineering Task Force
IIOP Internet Inter-ORB Protocol
MIME Multimedia Internet Message Extensions
ORB Object Request Broker
PKCS#7 Public Key Cryptography Standard #7
RFC Request For Comment
RSA Rivest-Shamir-Adleman
SDC Secure Data Channel
11
---------------------- Page: 13 ----------------------
oSIST prEN 13608-3:2006
prEN 13608-3:2005 (E)
SMTP Simple Mail Transfer Protocol
SSL3 Secure Sockets Layer, version 3
TLS Transport Layer Security
UML Unified Modelling Language
5 Requirements
5.1 Transport layer protocol
Systems complying with this European standard shall implement communication of healthcare data in
accordance with the IETF Transport Layer Security specification RFC 2246.
5.2 Mandatory cipher suites
Systems complying with this European standard shall support the following cipher suites within the TLS
protocol to provide the cryptographic services defined in RFC 2246:
TLS-DH-RSA-WITH-3DES-EDE-CBC-SHA1
TLS-RSA-WITH-3DES-EDE-CBC-SHA1
NOTE 1 These cipher suites do not provide forward secrecy
NOTE 2 Full definitions of the above cipher suites are to be found in RFC 2246
5.3 Optional cipher suite for forward secrecy
Systems complying with this European standard may additionally support the following cipher suite within the
TLS protocol to provide the cryptographic services defined in RFC 2246:
TLS-DHE-RSA-WITH-3DES-EDE-CBC-SHA1
Systems which choose to support this cipher suite shall negotiate it with preference to the cipher suites
defined in clause 5.2.
NOTE 1 This cipher suite provides forward secrecy. See 3.23 forward secrecy
NOTE 2 Forward Secrecy makes it harder for attackers to compromise confidential information in transit in encrypted
form, and so is more secure than the use of non-forward secret cipher suites.
NOTE 3 Some National legislations prohibit the use of forward secrecy in terms of non recoverable encryption.
5.4 Avoidance of encipherment susceptible to brute force attacks
Systems complying with this European standard shall not negotiate cipher suites providing less than 80 bits of
symmetric effective key space. They shall also not support key exchange algorithms providing less than
768 bits of RSA or DH key asymmetric strength.
NOTE It is understood that the key lengths required to prevent brute force attacks increases over time. The
requirements laid out in this clause reflect the state of the art at the time of writing this document and the effective key
lengths offered by the TLS cipher suites as specified in RFC 2246.
12
---------------------- Page: 14 ----------------------
oSIST prEN 13608-3:2006
prEN 13608-3:2005 (E)
5.5 Other cipher suites
Systems complying with this European standard may support and negotiate other cipher suites as long as the
systems fulfil the requirements laid out in clauses 5.2 and 5.3 and the cipher suites fulfil the requirements laid
out in clause 5.4.
5.6 Security considerations
Systems complying with this European standard shall not provide backwards compatibility with SSL versions 1
and 2.
5.7 Client authentication
Systems complying with this European standard may implement TLS client authentication.
Although there may be applications of this European standard within healthcare that do not require client
authentication, it may be desirable for some applications.
13
---------------------- Page: 15 ----------------------
oSIST prEN 13608-3:2006
prEN 13608-3:2005 (E)
Annex A
(informative)
TLS overview
A.1 Introduction
Figure A.1 — Secure healthcare communication
Figure A.1, a UML use case diagram [OMG 97-08-02], is a representation of a client and server
communicating via a secure data channel. The healthcare data transported over the channel can be of any
format, and the communication channel transport protocol can be any providing a reliable connection oriented
channel.
The TLS protocol makes a distinction between the client and the server user. The client is the user who
initiates the communication channel. The server typically is waiting, and ready to accept connection attempts.
An application compliant with this European standard shall use the methodology defined in clause 5 to
participate in the creation and use of a secure data channel.
EXAMPLE If the system is being used to communicate healthcare information over a standard HTTP web document
delivery system, a TLS connection would be opened between the client and the server, requests would be made by the
client, and data would be returned by the server. All communications between the client and server after the secured link
was established would be sent under the channels security layer.
14
---------------------- Page: 16 ----------------------
oSIST prEN 13608-3:2006
prEN 13608-3:2005 (E)
A.2 Establishing Connection
Figure A.2 — Establishing secure data channel
Figure A.2, a UML sequence diagram shows a client and server creating a secure data channel. A session
having been initiated, client and server channel parameters and cipher suites are negotiated, the server and
client are optionally authenticated, then further communication over the channel is protected by the negotiated
security functions. After use the channel is closed by exchange of close session requests.
A.3 Cipher suites
TLS is parameterisable and extensible in the security primitives it uses as the building blocks to provide
authentication, confidentiality, key exchange and integrity. Each TLS server and client will be aware of a set of
cipher suites (and some minimal set of required cipher suites to guarantee interoperability). The cipher suite
capabilities are negotiated at session start, and a cipher suite is chosen from the intersection of cipher suites
that the server and client share.
15
---------------------- Page: 17 ----------------------
oSIST prEN 13608-3:2006
prEN 13608-3:2005 (E)
The building blocks parameterisable are:
1) Confidentiality primitive, a cipher for encryption of data in bulk (a block or stream cipher, e.g. 3DES
[DES]).
2) A integrity check in the form of a keyed MAC (Message Authentication Code), HMAC is used which
is based on a message digest function (e.g. HMAC-SHA1), where SHA1 [SHA-1] is the Secure Hash
Algorithm, a NIST standard (US National Institute of Standards).
3) An authentication method, providing a digital signature algorithm (e.g. RSA signature, or DSS
signature algorithms).
NOTE The digital signature algorithm also makes use of a message digest as part of the algorithm.
4) A method for negotiating confidentiality keys, a key negotiation algorithm (e.g. RSA key exchange, or
Diffie-Hellman key exchange).
The set of bulk data cipher, message digest function, digital signature algorithm and key exchange algorithm
are used to describe a cipher suite. TLS describes a set of 28 cipher suites, of which the following are a few
examples:
TLS-DHE-DSS-WITH-3DES-EDE-CBC-SHA
Being Diffie-Hellman Ephemeral (temporary Diffie-Hellman keys for key exchange) with DSS signatures (US
NIST (National Institute of Standards) Digital Signature Standard), triple DES block cipher CBC (Cipher Block
Chaining) mode with the EDE (Encrypt, Decrypt, Encrypt) form of triple DES, using HMAC-SHA1 for integrity
checksum.
And:
TLS-RSA-WITH-RC4-128-SHA
Being RSA key exchange, and RSA signatures, and RC4 stream cipher with 128 bit keys for bulk data
encipherment, and HMAC-SHA1 for integrity checking.
16
---------------------- Page: 18 ----------------------
oSIST prEN 13608-3:2006
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.