CR 14302:2002

SLOVENSKI STANDARD
01-oktober-2003
=GUDYVWYHQDLQIRUPDWLND±2NYLUQHGRORþEHRYDUQRVWQLK]DKWHYDK]DQDSUDYHNL
QLVRSULNOMXþHQHVWDOQR
Health informatics - Framework for security requirements for intermittently connected
devices
Ta slovenski standard je istoveten z: CR 14302:2002
ICS:
35.240.80 Uporabniške rešitve IT v IT applications in health care
zdravstveni tehniki technology
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

CEN REPORT
CR 14302
RAPPORT CEN
CEN BERICHT
January 2002
ICS
English version
Health informatics - Framework for security requirements for
intermittently connected devices
This CEN Report was approved by CEN on 14 December 2001. It has been drawn up by the Technical Committee CEN/TC 251.
CEN members are the national standards bodies of Austria, Belgium, Czech Republic, Denmark, Finland, France, Germany, Greece,
Iceland, Ireland, Italy, Luxembourg, Malta, Netherlands, Norway, Portugal, Spain, Sweden, Switzerland and United Kingdom.
EUROPEAN COMMITTEE FOR STANDARDIZATION
COMITÉ EUROPÉEN DE NORMALISATION
EUROPÄISCHES KOMITEE FÜR NORMUNG
Management Centre: rue de Stassart, 36  B-1050 Brussels
© 2002 CEN All rights of exploitation in any form and by any means reserved Ref. No. CR 14302:2002 E
worldwide for CEN national Members.

CONTENTS
FOREWORD . 3
INTRODUCTION. 3
1. SCOPE . 4
2. NORMATIVE REFERENCES. 5
3. DEFINITIONS . 5
4. THE VARIETY OF SYSTEMS FOR INTERMITTENTLY CONNECTED DEVICES. 6
5. THE MAJOR ACTORS INVOLVED AND THEIR INTERESTS . 7
6. INTERACTING WITH CARDS . 8
7. ETHICAL AND LEGAL CONSIDERATIONS. 10
7.1 ETHICAL STATEMENTS .10
7.2 LEGISLATION ON HEALTH CARE DATA AND CARDS. 11
7.3 SOME BASIC PRINCIPLES FOR MEDICAL RECORDS. 12
7.4 RECOMMENDATIONS FOR CARD USE . 12
8. THE SECURITY SERVICES AND THE MEANS TO IMPLEMENT THEM. 14
8.1 CONFIDENTIALITY. 14
8.1.1 Physical card protection is not enough . 14
8.1.2 Data Object protection versus Device and Session protection. 15
8.1.3 Tamper protection of the card. 16
8.1.4 Access Control. 17
8.1.5 Cryptographic authentication . 17
Public key cryptography. 18
8.1.6 Defining classes of health care professionals is the issue . 20
8.1.7 Access conditions and functions. 21
8.1.8 Methods for card holder verification. 22
8.2 INTEGRITY AND QUALITY OF THE DATA. 22
8.2.1 Problems of a complicated data structure. 23
8.2.2 Unalterable. 23
8.3 AVAILABILITY. 25
9. THE PATIENT CARD AND TELEMATICS . 26
9.1 PATIENT CARDS AND ENCRYPTED TRANSFER OF RECORDS. 26
9. 2 PATIENT CARDS AND REMOTE PROOF OF CONSENT. 26
10. HEALTHCARE PROFESSIONAL CARDS.27
11. ISSUES OF INTERNATIONAL FUNCTION OF SECURITY MECHANISMS. 28
11.1 TRUSTED THIRD PARTY SERVICES . 28
11.2 RESTRICTIONS ON THE USE OF ENCRYPTION. 29
GLOSSARY . 30
Foreword
This CEN Report was prepared by CEN/TC 251 Health Informatics, the secretariat of which is held
by SIS – Swedish Standards Institute.
This work is based on several years of discussions on various documents in CEN/ TC 251/ WG 7 and
WG 6 and CEN TC 224/WG 12 . In particular, the work of TC251/PT 7-009 that drafted the ENV
12018 ” Medical Informatics - Identification, Administrative, and common Clinical Data structure for
Intermittently Connected Devices used in Health Care (including machine readable cards)” should be
acknowledged. Many of the concepts explained in this report are in fact underlying the security
objects defined in that standard.
This CEN Report is also based on work carried out within the following CEC projects:
CEC - AIM Eurocards Concerted Action on Extending the use of Patient Data Cards: The Security
Report and Assessment of Health Care Professional Card.
CEC - INFOSEC '94 programme on Electronic Signature and Trusted Third Party Services: Trusted
Health Information Systems: Part 1. Requirements on Electronic Signature Services and Part 2.
Trusted Third Party Services, published by Spri, Swedish Institute for Health Services Development,
Stockholm 1995.
CEC – Health Telematics project TrustHealth 1. Deliverable 2.1 Selection of Security Services and
Interfaces.
Introduction
Intermittently connected devices such as patient cards may carry important clinical information as
well as administrative data of importance to health care delivery. The information regarding an
identifiable individual is always sensitive and with clinical data it is particularly important to provide
appropriate means to ensure the protection of confidentiality. In addition several other security
services must be ensured to protect the patient safety as well as accountability of the professionals
responsible for recording data and reading data from intermittently connected devices.
Health care person devices, particularly microprocessor cards, carried by professionals and other
persons working in the health care sector, may play an important role in the provision of security for
all health information systems for the following core functions; to provide a secure user
authentication, to provide a digital signature mechanism and as a means to carry cryptographic keys
for confidentiality protection of stored and communicated health care information. The authentication
function may serve as a key to protected data on a Patient data card.
1. Scope
This CEN Report is aimed at providing a basis for a planned European Standard on the same subject,
work item Security Requirements for Intermittently Connected Devices. The reason for processing
this document as a formal CEN Report is that it has been requested as immediate guidance to the
current work of CEN TC224/WG12 in its preparation of standards specifying the mechanisms for
implementing security requirements in systems using machine readable cards in health care. The
scope of this report is also to serve as guidance, without being normative, to the many large projects
using cards in health care for both patients, professionals and other persons working in the health care
sector, presently under development in Europe.
This report defines a framework of security requirements in systems with intermittently connected
devices and discusses requirements for the following security services for ICD-systems:
Data Integrity protection
Data Origin and Entity Authentication
Access Control
Confidentiality protection
The report defines security requirements on the ICD-interchange interface between an application
system and an ICD-System. However, the overall security requirements can only be met if certain
requirements on the devices themselves are also followed.
Requirements for establishment of secure sessions with various types of ICDs as well as object related
security services are defined.
The report particularly defines how access to different types of data on intermittently connected
devices could be restricted to different classes of health care persons (professionals and other types of
personnel) or to the patients, especially when multinational access should be allowed. The rights to
read, add, change and delete must be defined separately.
The security policies proposed should also guarantee the authenticity of identification, administrative
and clinical information that may have important implications.
This report gives detailed security requirements for active devices such as microprocessor cards,
which are the only possibilities to implement some of the proposed services. The report also gives
important advice for passive devices such as magnetic stripe card systems or floppy disks. The major
focus is on systems for handling sensitive medical information on devices (mainly cards) held by
patients. However, some requirements on ICDs to be used by health care persons (professionals and
others) are also given. Detailed protocols for interaction between such devices and general medical
information systems for the purpose of secure user identification will be developed within a separate
work item.
2. Normative references
This CEN report incorporates by dated or undated reference, provisions from other publications.
These normative references are cited at the appropriate places in the text and the publications are
listed hereafter. For dated references, subsequent amendments to or revisions of any one of these
publications apply to this standard only when incorporated in it by amendment or revision. For
undated references the latest edition of the publication applies.
ISO 7498-2:1989 Information processing systems - Open systems interconnection Basic
reference model - Part 2: Security architecture.
ISO/IEC 9594-8:1990 Information technology - Open Systems interconnection: The Directory - Part
8: Authentication framework.
ISO/IEC 9798-1:1991 Information technology - Security techniques - Entity authentication
mechanisms - Part 1: General model
ISO/IEC 9796: 1991 Information technology - Open systems interconnection - Digital signature
scheme giving message recovery
ENV 12388: 1996 Medical Informatics – Algorithm for Digital Signature Services
ENV 12018: 1996 Medical Informatics - Identification, Administrative, and common Clinical
Data structure for Intermittently Connected Devices used in Health Care
(including machine readable cards)
3. Definitions
This CEN Report does not introduce any new normative definitions. Please refer to the Glossary in
the end of this document for definitions of commonly used security terms.
4. The variety of systems for intermittently connected
devices
Intermittently connected devices may be used for many different applications and the security issues
will vary accordingly. Patient data cards and cards held by health care professionals and other types of
personnel have attracted particular attention in recent years. For the purpose of this report we are
pointing at some of the differences with regard to administrative and medical uses of patient data
cards. However, it is frequently impracticable to draw a sharp line between these applications. This
report is an analysis of the security issues that arise with patient data cards and possible solutions.
With a few exceptions it does not give recommendations that apply to all patient card systems. The
flexible introduction of standardised security countermeasures based on the needs of the specific
application is emphasised. The combination of medical data with non health care related applications
have been suggested but the security problems involved makes it very difficult to implement.
Aspect Administrative use Medical use
Overall objective Facilitating administrative Improving the quality of care
procedures
Typical data Identification data Essential medical facts:
Insurance details diagnoses, drug therapy, lab
results, hypersensitivity, etc
Main security objective Data Integrity, Protection of Confidentiality and
Securing Payment Data Integrity
The International use
The underlying vision is that patient cards issued in one country should be possible to use not only in
all health care institutions within one country, but throughout Europe. Such usage requires a common
view related to the ethical issues concerning the transfer of personal data between health care
professionals both at a national and international level. It is also necessary to harmonise the
technology used to protect the appropriate security objectives. The details of the technologies require
standardization that is on its way through the European standardization committee, CEN.
It may be possible to some extent to have different authorisation rules in different areas within the
same basic technical framework and yet provide some degree of interoperability. Whereas it should be
possible to restrict the use to a country or even a limited group of users the goal for the patient is
usually to provide maximum mobility of the information within the bounds of confidentiality
principles to aid and improve on the health care delivery process.
A basic principle on the international use of the card is the following:
The card issuer in a country should always be able to decide what can be done with a particular
card, wherever that card is used. In addition, the person that records data on a card should
know whom and under what circumstances could somebody gain access to that data.
In case of a conflict with local laws and practices as may for instance occur when trying to access a
patient card from a different nation, it should be ensured that the proscriptions of the issuing nation
are enforced. This could mean that when a patient with a card from a country not allowing
unconditional access to the data by the patient, comes to a country with different laws, direct access to
such data by the patient is prevented. Another example may be when erasure of data is possible
according to the rules of the issuing country, a health care provider in another country where this
would not be allowed could decide not to enter any information to such a card.
5. The major actors involved and their interests
The Patient must be in the centre
It must be emphasised that a patient card system should be in the interest of the patient. A card with
essential information for health care controlled by the patients may be an important factor to support
the free movement of people in Europe.
This consideration is not only relevant when medical data is included in the card but also when a card
system is used for administration only. This is partly based on the practical fact that a device like a
card is likely to disappear if the carrying person does not feel that its presentation will be of benefit to
him.
The perspective of the patient will be very important in this report and we will come back to this
aspect many times. It is important to consider however, that the patient, the customer in market driven
health care, is frequently in a very weak position. Patients are usually old, frequently very old, and the
disease may make it even worse for the patient to fight for his/her interests in relation to information
systems and patient cards.
Public interest bodies - governments
Because the patient is a weak actor in health care, the governments - national or regional - usually
make a lot of effort to protect the patient in relation to other actors in the health care market. They do
this through legislation but there are also a number of other regulatory instruments and control
functions. It is natural that governments in many countries will take a deep interest in the use of
patient data cards.
Paying bodies
On the other side we have the interests of the organisation that pays the bill for health care. In most
European countries it is not the patient himself, who pays directly, but it is an insurance company or
similar institution, private or as a part of a public health care system.
The Health Care Provider
A fourth party that may have interests to protect in a patient card system, is the health care provider,
either as an individual or institution which may be a commercial or public service body who may have
a commercial interest in the form of the value of the data contained in the medical record. Such an
entity may wish to conceal or not communicate certain patient related information, both
administrative and clinical from potential competitors. Another thing to consider is the necessity of a
card system to provide sufficient information to allow justice to be made in case of malpractice
litigation. In this paper, health care providers will have a wide definition including entities such as
pharmacies, patient transport (ambulances) etc.
Health Care Persons
In addition to the interests of the health care provider institution the people who work there have
interests to protect in relation to the security of a patient card system. These persons are in this
document henceforth referred to as Health Care Persons. This term will include various more or less
well defined professional groups, such as physicians, pharmacists etc. but also other types of
personnel such as administrative clerks etc.
The Card Issuer
The issuer of a patient card may be of different types, a paying institution, a health care provider,
perhaps a national body or an organisation that is primarily just a card issuer. The issuing process
normally includes the setting of the rules that will determine the usage of the cards, memory allocation
and security functions. This freedom may however be limited by legislation. The actual process of
physical personalisation of the cards may well be carried out by another entity under a contract from
the issuer.
6. Interacting with cards
Various entities that interact with patient cards may perform one of the following interactions:
Issuing of cards
This will include setting the rules for access including memory allocation. This will usually also
include the addition of a basic data set at least identifying the cardholder. By issuer we mean the
entity that is responsible for the card issuing, the actual physical personalisation process may be
carried out by another entity under a contract of the issuer.
Reading data
This may include reading of data that was previously added by the same entity or the reading of
information added by another provider.
Adding data
Three types may be identified:
a) Data added that is intended to be read at a later time by the same entity
b) Data directed towards a certain other, perhaps named entity -ies
c) Undirected data, available to many potential users of the information in the future.
Erasing
An important difference is if an entity will attempt to erase data that was added by another entity or if
it is handling its "own" data. A special instance of this occurs when the data is in the form of a
directed ”message” aimed at a given recipient and the data has no further use after having reached its
destination. In this case it may be natural to allow erasure if the medium so permits.
Erasing may be done for three reasons that has different security requirements:
a) Erasing data that is no longer relevant to facilitate finding of relevant information.
b) Erasing data that the patient will no longer agree to have on the card for further spread.
c) Erasing data to free space for new information with a higher priority.
Please note that under some legislations, erasure of information on patient held data cards may not be
allowed in any circumstance.
Modifying data
Modifying may technically be regarded as a three-stage process, reading, erasure and then adding of
new information. It is technically possible that a card or external system may allow the information to
be presented as changed without actually erasing the old data, thereby preserving an audit trail with
respect to the information.
Allocating new space
This may with some types of cards be a separate task, which might limit the availability of memory
for other applications or entities.
7. Ethical and legal considerations
7.1 Ethical statements
Dealing with health is one of the most sensitive matters where ethical principles established through
centuries of professional care are very important. In fact, they date at least back to Hippocrate in the
year of 400 BC The Hippocratic oath is still part of the basic principles of most medical professional
societies in Europe. One of the most important principles also for patient card systems is the
confidentiality statement in free translation:
The health care professional must not reveal the health status or other patient
related facts collected during the care process to others
The way this is usually interpreted in modern health care, with a group of staff caring for one patient,
is that it is important to take every precaution to avoid that information from health records are
accidentally released to people who do not have a caring responsibility for the patient.
How the group of carers is defined and what information is needed to carry out the work is a difficult
question and shows considerable variations in different situations and in different European countries.
A particularly difficult problem is to define the circumstances under which information about a
patient should be given to another health care provider institution. In many cases the consent of the
patient is required for such transfer.
On the other hand:
It is in the interest of the patient, in most cases, that medical facts from their health
record can be made available promptly and efficiently to all health care providers
that will treat him. Such a principle persists even if the patient is not able to actively
give their informed consent.
Without patient data cards or functional standardized data communication, this is rarely the case,
resulting in bad quality of care.
Another basically ethical statement (but in some countries also legislated) is the notion that:
The patient should have adequate information about his health condition in order to
be able to participate in the decision process regarding his treatment plan.
This may be interpreted in various ways but in most cases, this basic principle will be valid:
The patient should be in some control of the medical information on the card.
This means:
• The right to know what is on the card
• The right to exclude certain information from being entered into the card
• The right not to reveal all or any information from the card to a health care provider
• The right to have removed a specific data entry on the card
All of these elements have to be defined separately and are only included here to illustrate some of the
issues. There may be exceptions to the above principles in the case of specific legislations. In some
countries medical data on a card may be regarded as any medical record and as such it may not be
allowed to remove any data. In general, however, medical information on a patient data card is only a
collection of some data copied from original medical records kept by the health care establishments.
There must be high technical demands to ensure data integrity and quality (see below). No individual,
including the patient, should be able to change the information entered onto the card by another
individual. The patient and health care professionals should, however, retain the right to exclude and
remove information from the card if it is in the interest of the patient. The implication of this, in
common with existing medical records, is that whilst the information actually contained in the card
can be trusted, it can never be regarded as being potentially complete. The absence of information on
the card is of no significance. The patient carried card could be regarded as an aid for the patient to
tell the medical history, and similarly to the oral situation, the patient may elect not to disclose all
facts to all health care professionals. It should be emphasised, that this is of course exceptional - in
most cases the patients do their best to give as complete a picture as possible, unfortunately failing too
frequently.
7.2 Legislation on health care data and cards
In probably no country has the legislation specifically addressed the problems associated with the use
of patient data cards for medical information. (The German legislation mandates that all health
insurance companies by law must issue a card identifying the patient and the insurance but this card
specifically may not contain any medical information.)
However, in most countries there are a number of legal provisions dealing with health care
information in general and in particular with data storage and processing of personal health
information. Examples of such legislation may be found in:
• Health care record legislation
• Social security legislation
• Health Care professional legislation
• Archiving legislation
• Confidentiality legislation
• Data protection legislation
In a number of relevant areas there are also international documents of a regulatory nature, though
they are in many cases merely recommendations for national legislators. Examples of these are:
The Council of Europe conventions:
• Recommendation on the Protection of medical data, R(97.5)
• Protection of personal data used for social security purposes, R(86.1)
• Protection of data used for employment purposes
• Communications to third parties of personal data, R(90.19)

The EU directive:
Directive on protection personal data from 1995 to be implemented in

National legislation in 1998.
Digital data stored in electronic systems require special care to ensure authenticity and proof of
originator. The digital signature techniques using cryptographic methods (see more below) may be
used in lieu of the handwritten signature in ink on original paper documents. Electronic documents
may, however, in some countries require special legal provisions to be legally valid. In 1998 most
European countries are working on such changes and Germany and Italy had already adopted “digital
signature legislations”. A draft directive on “Electronic signatures” was issued by the Commission in
May 1998 and it is likely that within a short time all European Union states will have such legislation,
particularly regulating certification authorities.
7.3 Some basic principles for medical records
• The patient health care history and treatment shall be documented in a health care record
• The original record must be retained by the health care institution/provider that generated the
information
• The integrity of health care data must be ensured appropriately. I.e. it is important to make sure
that recorded data is not lost deliberately or by accident, nor removed, altered or added to without
authorisation.
• There must be efficient protection of the confidentiality of health information.
• Access to data should only be granted on a need to know basis. As far as is technically feasible,
access rights should be differentiated dependent on the type of data, the opinion of the patient and
the health care professionals already having access.
• The origin of health care data should be possible to trace. This is valid for cards as well as for
traditional records. It is important to be able to distinguish between first hand information or
decision and secondary relayed information. Time, place and person are all important in this
traceability.
7.4 Recommendations for card use
• Patient carried data cards may contain important parts of health records but can not replace them.
This information should be regarded as a copy of the original records
• The patient should have the right both to not present the card and not to have data added to it
without any form of discrimination taking place. The patient should however be informed that
should the above occur, the potential quality of care may be adversely affected. An exception to
this right may occur in either specific legislation or as part of a contract with a health care insurer.
• It is important to define the purpose of storing data in the health record and on a card. It may not
be possible to define access conditions based on the purpose of reading it.
• Card information is intended to be used primarily by persons other than those who entered it. It is
thus a form of data communication although the destination may not be known at the time of data
entry.
• The general principle should be that no health information is communicated to another health care
provider unless the patient agrees explicitly, or is judged to should have approved it, if that
decision had been possible. For cards this is particularly important and there should be no
exceptions to this principle. Otherwise the patients will have fear of carrying and presenting their
cards in an unacceptable way.
• Health care information should be accurate and of a high quality. Incorrect information should be
clearly indicated in both the original record and the card. The removal of the erroneous
information from a card should only be undertaken where steps exist to provide an accurate audit
trail to be preserved in order to protect both the interests of patient and carer.
• The operations of users of health care information systems should be possible to audit through
appropriate logging of data. Audit logs are usually not required nor feasible on patient data cards.
The health care system interaction with cards could however, very well be logged.
8. The security services and the means to implement them
Security of information systems in general deals with the provision of services in the following four
major areas:
• Confidentiality
Protection from unauthorised readers

•
Integrity
Original content maintained
• Availability
Information should be possible to retrieve when needed

• Accountability
The property that the actions of an entity can be traced

All of these aspects are highly relevant in health care information systems and patient card systems in
particular.
Please note that the security of the system requires functions in several components: the local
computer hardware, the card reader, the software in the local computer, the card itself, the card
issuing process etc.
8.1 Confidentiality
8.1.1 Physical card protection is not enough
The requirements for confidentiality services will of course differ dependent on the type of
information stored on the card but most applications of patient data cards carry some degree of
sensitivity. The patient must be protected from exposing private medical information to unauthorised
persons. Normally the card is protected by the cardholder and it will only be given voluntarily to
persons the patient considers being authorised in some way. However, the patient needs help by a
technical system to protect the information in many situations.
The card may be lost or stolen and if the card has been given away within a health care institution the
technology must protect patient confidentiality. The requirement for specific equipment including
software to read the stored information reduces the risk of unauthorised access, but this type of
protection is not sufficient.
The card may also contain several different types of information that should be disclosed only to
specific classes of health care personnel. This is another reason why access control technology is
required to protect confidentiality.
It is also important to establish rules for how data from a patient card may be handled when
permission to read has been granted. It is impossible from the card security system as such to
distinguish between simple reading by an authorised professional and storing a copy of patient card
information in a secondary system. Administrative rules for this must be set up and possibly
controlled by the authorities in various countries. In many countries the legislation allows access to
confidential patient data only for certain purposes, but mainly to treat that patient. The control of the
intended use of the data can not be provided by the card system alone.
8.1.2 Data Object protection versus Device and Session protection
In the work of the European standardization body the CEN/TC 251/PT009 produced a definition of a
“Data Interchange methodology” for cards used in health care (or as they are called more generally in
standardization, ‘Intermittently Connected Devices’ (ICDs)). It contains several important principles
for the following discussion.
The combination of an ICD with an ICD Connecting device unit is an ICD-System. This
communicates with an application over the ICD-Interchange interface defined in ENV 12018.
ICD-Application
System
ICD-Interchange Interface
ICD
Connecting
ICD-SYSTEM unit
ICD
The ICD-Application System, the ICD-Connecting Device Unit and the ICD-Interchange Interface
may be implemented in many different physical ways. The Interface level as defined in this European
Prestandard does not correspond to any physical connection between units. In many systems e.g. using
existing passive card readers, software drivers may perform part of the services required by the ICD-
Connecting device unit in the same physical computer system as the ICD-Application System.
ENV 12018 defines a large number of data objects to be transferred to/from a card. The objects are
defined, as they shall appear at the interface above. A fundamental concept here is the session of
communication with a card that is established when a card is connected. Many of the security
provisions operate during this session whereas others are connected to the stored data objects
themselves.
The following transmission oriented services can be implemented using microprocessor cards:
• Access control
The active provision of access to data on the card based on certain conditions such as PIN-
presentation or cryptographic authentication of health care personnel cards.

•
Secure messages
The establishment of a secure session using cryptography to obtain:
Confidentiality     - With enciphered messages
Data integrity      - Using signatures or message authentication codes
Please note that the cryptographic procedures in this case take place during the transmission
session.
Transmission between cards and application systems is usually quite local to e.g. a PC-work station.
However, in some applications the transmission to the intelligent card application may take place over
unsecured networks. It is in this situation that the secure messaging may be important.
With Object oriented security the provision of confidentiality or integrity has to be provided using
cryptographic procedures prior to the storage of the data objects. Encrypted data objects have the
advantage of allowing security also on passive memory devices such as IC-memory cards or laser
optical cards. However, the problems of controlling access using decryption in the reader device or
application system becomes very difficult to solve in a large international system with several system
suppliers. The standard proposal provides means for using this type of security to all objects through
the accessory attributes.
In addition to the protection provided by cryptographic means to stored and transmitted objects, it
may be desirable in certain contexts to describe some requested security functionality as attributes
indicating a ”Security level” as it is now present in the draft ENV which allows specification of Read,
Write, Update and Erase conditions. It is important to remember that such attributes added to objects
are only information to the object handling systems that should implement a corresponding
functionality to protect the objects as indicated, but the Security level attributes themselves do not
give any protection.
ISO standardization of security mechanisms
The ISO/IEC JTC1/SC 17 has produced the ISO/IEC 7816 series of standards that defines many basic
aspects of communication with a microprocessor card. However, the part four which defines Inter-
industry commands has a very rudimentary description of security features and to date most real
products contain proprietary functions for security. However, there is now a draft ISO/IEC 7816 part 8
available that attempts to specify very generic security functionality of microprocessor cards. In 1998
there are however no card products available that implement even part of this rich functionality. For
future healthcare card standards on the subject this standard when approved shall be of great
importance. The discussion in this CEN Report is kept at a more general level to be more easily
accessible for a hopefully broad discussion on principles.
8.1.3 Tamper protection of the card
The traditional basic principle for confidentiality protection is to have a physically protected area with
some kind of a lock mechanism to give controlled access. Today’s microprocessor cards provide
excellent methods to physically protect sensitive data that can be accessed only through control of the
card operating system.
The lock mechanism may operate through the use of secret codes such as the PIN-code (Personal
Identification Number) that is used in many card systems. A personal code offers the advantage of
giving the patient one way of controlling the card but for several reasons, a medical card system could
not be completely dependent on the patient being able to actively unlock a card.
The codes however, may also be system specific and be distributed to various authorised persons. The
problems with this are somewhat similar to the distribution of encryption keys. Please note the
distinction between certain key codes that may be used in most microprocessor cards to unlock certain
functions and an encryption key that is also a number that may be used with an encryption algorithm
to E.g. decrypt some coded information.
In modern IC-cards the physical lock may be opened not by a simple code but via a cryptographic
challenge-response mechanism. This has a distinct advantage, as no secret codes need to be exposed
outside of the card. This is certainly preferable if widely used system specific authorities should be
distributed.
8.1.4 Access Control
Access control services of active patient data cards should preferably include the following facilities:
Differential access to various data dependent on cardholder verification (patient PIN-code) and/or
authentication of health care professional class.
The process starts with the patient card actively authenticating the user (or system) that is to be
granted access to data. The authentication of the user will only occur once in the beginning of the
session. It is then up to the access control system of the card to control the request for a specific data
object against the stored security requirements for that object and the authenticated identity and
credentials of the user health care professional.
8.1.5 Cryptographic authentication
Cryptography may be used for many purposes including enciphering of text to provide confidentiality
in the insecure world outside of the card but there are other major uses that will be briefly described
here.
One of the major functions of cryptography in smart cards is for a challenge response authentication
of a card.
The figure below shows the principle. DES as an example here is a standardized encryption algorithm
and is used widely in the financial community.
The Principle of challenge-response authentication
1. All users have a personal card with microprocessor.
2. The card is ”opened” with a personal PIN-code. This is never sent over the
communication line
3. The target computer sends a random number as a challenge to the card that with the help
of some encryption algorithm and a secret personal key, encrypts the random number and
sends it back for verification.
4. In the target computer a corresponding calculation is made to verify that the card has the
claimed identity and is in possession of the right key. In the case of a symmetric algorithm
as DES, the same secret key has to be present on both ends. With the use of asymmetric
techniques, the host only needs to have the corresponding public key not the same private
key held by the user on his card.
Terminal with
Target computer Random challenge
with access to the card encrypts the
Encrypted Response
key of the user chall-enge using
Public key cryptography
The principle, that has become feasible recently with standard smart cards, is to use asymmetric
p
...