- Email: [email protected]
Securing interoperability between chip card based medical information systems and health networks
International Journal of Medical Informatics 64 (2001) 401– 415 www.elsevier.com/locate/ijmedinf
Securing interoperability between chip card based medical information systems and health networks Bernd Blobel a,*, Peter Pharow a, Volker Spiegel a, Kjeld Engel a, Rolf Engelbrecht b a
Department of Medical Informatics, Medical Faculty, Institute of Biometry and Medical Informatics, Otto-6on-Guericke Uni6ersity Magdeburg, Leipziger Str. 44, D-39120 Magdeburg, Saxony-Anhalt, Germany b GSF-Forschungszentrum fu¨r Umwelt und Gesundheit, MEDIS-Institute, Ingolsta¨dter Landstraße 1, D-85764 Neuherberg, Germany
Abstract Health information systems supporting shared care are going to be distributed and interoperable. Dealing with sensitive personal medical information, such information systems have to provide appropriate security services, allowing only authorised users restricted access rights to the patients’ data according to the ‘need to know’ principle. Especially in healthcare, chip card based information systems occur in the shape of patient data cards providing informational self determination and mobility of the users as well as quality, integrity, accountability, and availability of the data stored on the card, thus improving the shared care of patients. The DIABCARD1 project aims at the implementation and evaluation of a chip card based medical information system (CCMIS) for facilitating communication and co-operation between health professionals in different organisations or departments caring the same patient with diabetes as an example. In co-operation with the EC-funded TrustHealth2 project, communication and application security services needed are provided like strong authentication as well as the derived services such as authorisation, access control, accountability, confidentiality, etc. The solution is based on Health Professional Cards and Trusted Third Party services. In addition to the secure handling of the patient’s chip card and data in DIABCARD workstations, the secure communication between these workstations and related departmental systems has been implemented. Based on the results of this feasibility study, an enhanced security services specification for the DIABCARD example of a CCMIS is provided which will be implemented in the framework of a health network being established in the German federal state Bavaria. Beside the preferred solution of a combination of Patient Identification Card and Patient Data Card, lower level alternatives using card-verifiable certificates are explained in some details. Finally, a few legal issues, future trends like the XML standard set and their implications for the solution presented as well as for distributed health information systems in general are shortly discussed. © 2001 Elsevier Science Ireland Ltd. All rights reserved. Keywords: Health information systems; Smart cards; Security; DIABCARD
* Corresponding author. Tel.: + 49-37-135-42; fax: + 49-67-135-36. E-mail address: [email protected] (B. Blobel). 1 Funded by the European Commission (EC) under TAP HC 1010. 2 Funded by the European Commission (EC) under TAP HC 4023. 1386-5056/01/$ - see front matter © 2001 Elsevier Science Ireland Ltd. All rights reserved. PII: S 1 3 8 6 - 5 0 5 6 ( 0 1 ) 0 0 1 9 3 - 9
402
B. Blobel et al. / International Journal of Medical Informatics 64 (2001) 401–415
1. Introduction For meeting the challenge of the shared care paradigm, the specialisation and decentralisation must be accompanied by comprehensive communication and co-operation. This communication and co-operation may be supported through any kind of networks from a departmental Local Area Network (LAN) up to the Internet. An alternative to networking is the connection of patient’s information with the patient’s being itself: Acting as data subject and data source, but also as carrier of any data collected, the patient can realise the informational self-determination guaranteed by privacy acts and constitutions. In any case, communication and co-operation have to be provided securely.
2. Smart cards in healthcare If an information system shall be held by a human being, an appropriate media is needed for storing data and applications providing the functionality required as well as for communicating data to partners. This generally applies ranging from the use of simple hardware token for specific functions such as identity-related services up to more or less comprehensive portable information systems carried by the information subject. For electronic health information systems held by patients, beside the appropriate carrier also an environment must be provided for the authorised use of information in the sense of collecting, storing, processing, and communicating the data. Starting in Europe, smart cards, i.e. microprocessor cards, are used for both purposes mentioned, i.e. as Patient Data Cards (PDC) and Health Professional Cards (HPC) [1] around the world. Generally, it should be mentioned that the smart card could be deployed in two ways.
On the one hand, the card could bear all information needed, in the case of PDC, e.g. all relevant medical data, as shown in this paper. On the other hand, the card can be used as a pointer providing references and linkages to the information stored in networked systems. However, also a combination of those two principles could be imaginable. Based on the European security infrastructure for health, the paper describes the first security solution for a PDC environment really implemented for the currently used as well as for the next generation DIABCARD architecture. It does not discuss the genuine issues of the DIABCARD project itself, as the DIABCARD data set; the application around; etc. The paper presented concerns the co-operation between two projects funded by the European Commission within the Telematics Applications Programme: DIABCARD [2] and TrustHealth [3]. It deals with the secure use of a specific patient data card, held by the patient as well as its embedding into health networks deploying the European security infrastructure based onHPC and Trusted Third Party (TTP) services. The project-related PDC, the DIABCARD PDC or simply the DIABCARD, facilitates communication and co-operation between General Practitioners (GP) and secondary care departments providing medical services for diabetes patients.
2.1. The DIABCARD PDC Originally, the DIABCARD PDC is a PIN-code-protected smart card containing, the DIABCARE minimal data; the European administrative data set; the European emergency data set; the DIABCARE basic information sheet; the diabetes passport; as well as groups of actual data describing essential information of the last visits, in the ophthalmo-
B. Blobel et al. / International Journal of Medical Informatics 64 (2001) 401–415
logic; the internal; and the foot care department of a Health Care Establishment (HCE) [4]. In the first DIABCARD PDC version, the strong authentication of the patient to the system as well as the mutual authentication between the PDC and the HPC was not supported. Due to those restrictions, some of the security services needed had to be delegated first to the application environment as shown in the next sections.
2.2. The health professional card To ensure communication security, the HPC as a secure token and its related TTP services are used within the European security infrastructure according to the EC TrustHealth project [3,5]. The HPC is a microprocessor card with an additional co-processor specialised for cryptographic algorithms (cryptoprocessor). The authentication provided concerns both the identity and the roles of Health Professionals (HP). The identity certificate issued by the Physicians’ Chamber guarantees the first. The latter are expressed by several different attribute certificates issued by the Physicians’ Chamber (specific domains of care or specific qualifications) or by the Doctors’ Statutory Association ‘Kassena¨ rztliche Vereinigung’ (specific permissions= ‘Erma¨ chtigungen’). The card contains in minimum three private keys with dedicated usage as, e.g. for authentication; digital signature; and decryption (e.g. the session key) as well as the X.509 v3-based certificates bound on those keys3. In the card’s Master File, the global profession (physician, nurse, etc.) is specified. Beside the authentication, the HPC facilitates also the other communication security services implemented using the digital signature mechanism such as integrity and accountability, but also confidentiality directly by encoding the 3
Attribute certificates are not bound on keys.
403
plain text or indirectly by encoding the symmetric session key used. As a result of the authentication procedure and the roles dedicated to the user, communication in the sense of connection respectively system access is permitted or denied. Based on the identity and the roles of the user on the one hand and the decision rules agreed in the security policy on the other, the HPC also enables application security services which are related to that person such as authorisation, access control, integrity, confidentiality, accountability, and audit. As far as medical applications are concerned, an HPC can be used for access to local and remote systems as well as to networks, for any kind of secure transmission of medical and administrative data, for medical prescriptions, and for any kind of electronic business processes within healthcare and welfare. Last but not least, the HPC is designed to get controlled access to patient data on PDCs.
3. The DIABCARD application security solution Fig. 1 shows the security scenarios of the security-enhanced advanced DIABCARD environment. It is based on the general layered security model [6] distinguishing between the concepts of communication security and application security, which may be specified and implemented separately as an advantage of the component paradigm. As mentioned, the userrelated security services are provided by the card bearing the three keys for authentication, integrity, and confidentiality as well as the certificates needed. Storing the certificates on the card enables the use of isolated workstations as specified as the original DIABCARD scenario. In a network environment, certificates may be hold in TTP directories saving storage capacity especially in the context of the
404
B. Blobel et al. / International Journal of Medical Informatics 64 (2001) 401–415
advanced PDC. Furthermore, the certificate management including in-time revocation procedures could be speeded up by that way or even enabled. In the international DIABCARD environment, encoding of data on the DIABCARD PDC using either the PDC or the HPC encoding/decoding key pair will not be used currently to avoid the exclusion of partners not yet enabled for enhanced security services. As a general service however, it is inevitable for enabling, e.g. future home care activities and communications. Establishing a proper security infrastructure however, the PDC confidentiality service will be applied in regional solutions such as German federal states health networks (e.g. in Bavaria). Therefore, PDC confidentiality has been implemented in our demonstrator. Fig. 2 presents the actual DIABCARD system architecture including the interfaces and security services used to provide a secure environment. The architectural components have been explained elsewhere (e.g. [4]). Therefore, the following sections are only
Fig. 1. The DIABCARD security scenarios.
dealing with security services provided for trustworthy use of data and functions within the DIABCARD system.
3.1. Strong authentication and component access control The first step of introducing trustworthiness is the mutual strong authentication between the communicating principals, i.e. user and application. Since applications normally consist of multiple components establishing distributed systems, the mutual authentication has to be provided to all the components involved. Otherwise, the invocation of components not participating in the authentication procedure must be denied. In the DIABCARD example, the components DIABCARD Core System (DCC), the underlying Paradox database (PDD), the DIABCARD Server (DCS) and last but not least the PDC itself are protected by peer-authenticationbased access control for authorised users only (step 1a)–(step 1e). Using an HPC specified within the TrustHealth project (TH.HPC), a single logon is realised. In the DIABCARD PDC version implemented in 1999, the strong authentication of that PDC was not enabled. Since also DCS source code was not available, its components (e.g. the invocation of the DIABCARD Data Access API) could not be protected by access control services. Following, the authentication/access control services have been provided on (step 1a)–(step 1c) only. Therefore, the access control services could only be established via encryption hindering the unauthorised use of those components, being aware that access control and confidentiality services are coherent in certain manner4. The 4 Nevertheless, the latter is more problematic, less stable and trustworthy. Therefore, encryption should be applied, if possible, additionally to prevent unauthorised disclosure when access control is not available (e.g. in de-mounted hard disks).
B. Blobel et al. / International Journal of Medical Informatics 64 (2001) 401–415
405
Fig. 2. Architectural schema and placement of application security services in the DIABCARD workstation.
encryption was performed using a symmetric key, which is either stored on the HPC or in all authorised users’ Personal Security Environment (PSE). Starting the DIABCARD application, only the authorised user could decrypt these protected components for use.
3.2. Authorisation and access control to function and data Based on the roles specified in the HPC certificates and verified during the authentication procedure, the user’s functional and medical data access rights can be derived
406
B. Blobel et al. / International Journal of Medical Informatics 64 (2001) 401–415
(step 2a), (step 2b). In the case of the Paradox database, the authorisation is realised by locking mechanisms not allowing the separate handling of single tables and items. Therefore, its replacement is recommended. Temporarily, authorisation and data access control hindering the separate use of database functions for creation, manipulation or deletion of data have been implemented by encrypting and signing the whole database.
3.3. Accountability The accountability service must be established in the context of creation, deletion or manipulation of information providing nonrepudiation of origin. These function modes have been implemented on the DCC level only (step 3), using the user’s digital signature realised through the employment of his/her specific digital signature key.
3.4. Integrity check Regarding the integrity service (step 4a)– (step 4c), both the integrity of data and programs has to be guaranteed, detecting any manipulation of information as well as of application behaviour. The latter concerns especially manipulations of the security solutions implemented, also including the replacement of complete components. Considering the data integrity check, the data origin authentication service is employed using digital signature mechanisms. Since of the possibility to remove data items or even records from the database, the tables must be protected against any changes or replacements.
3.5. Confidentiality To avoid the misuse of the sensitive med-
ical data by unauthorised persons invoking the database independent of the DIABCARD application, the database has to be encrypted (step 5a). To support multiuser facilities of the data which establish an Electronic Healthcare Record in diabetes, the use of a symmetric algorithm distributing the secret key securely can be applied to implement the confidentiality service. Since the DCS source code was not available, the confidentiality service was also used to hinder any manipulation or bypassing the security services of this component.
3.6. Database security The security services mentioned in the context of storage of information in, and retrieval of information from, the database are only available under certain conditions, accompanied by organisational measures. Thus, if the application is running, the database is not secured (e.g. decrypted). Alternatives enabling all security services mentioned are only achievable through replacing the database by a security-enabled one. This concerns also the accountability service keeping all database functionalities running. Appropriate databases are available on the market (e.g. Oracle 8) and should be taken in consideration for future implementations if required due to the threat and risk assessment.
3.7. Audit In sensitive environments, an audit checking the accountability including non-repudiation for any procedures is an inevitable functionality. Such an audit must be provided in a secure environment disabling any manipulation by the audited person or any unauthorised third party.
B. Blobel et al. / International Journal of Medical Informatics 64 (2001) 401–415
4. The advanced DIABCARD security solution Generally, the first implementation of the secure DIABCARD solution has been a success story. Meeting the genuine challenge of the European Commission, the feasibility of PDC applications based on the European security infrastructure has been demonstrated in 1999 in Magdeburg as well as in Spring 2000 in Munich. In the context of new developments on both the technical and the legal field, however, a strong challenge has been discovered to improve the existing solution in order to meet the needs of health networks and to overcome the disadvantages of current installations mentioned. Still within the DIABCARD project framework, an advanced DIABCARD PDC has been completely specified and partially implemented in the sense of a feasibility study. This advanced DIABCARD PDC contains a cryptographic co-processor by that way enabling all the services for communication security and application security provided by the deployment of cryptographic algorithms. As another way assigned to be deployed in a German project for facilitating management and quality assurance in kidney transplantations, the German HPC specification [7] defines already future interactions between HPC and PDC using card-verifiable certificates (see Section 5.2). By that way, some of the current application-mediated security services might be delegated to the card PSE.
4.1. Additional security ser6ices of the ad6anced DIABCARD Exploiting key-related security services enabled by the advanced DIABCARD, strong authentication of the PDC against the DIABCARD workstation as well as access control
407
services are provided. So, the advanced DIABCARD PDC enables also the access control services (step 1d) and (step 1e) shown in Fig. 2. Adopting the structure of data stored, storage capacity of the PDC and infrastructure of the DIABCARD environment, accountability services could be extended to the PDC including not only the processes of creation and updating of data, but also the processes of card-system interactions. In the same context of key-related security services, integrity and confidentiality of data on the card level are included after establishing the environment needed. The audit of these card-related interactions will be realised in the future.
4.2. Ad6anced application security ser6ices The misuse of the sensitive medical data by unauthorised persons invoking the database independent of the DIABCARD application must be excluded. To support multi-user facilities of the data in the database encrypted for providing confidentiality, the installation of a ticket server distributing a symmetric session key to users authorised through the strong authentication procedure based on the HPC identity key has been specified and tested as way of choice. This advanced solution is also applicable to general EHCR or other systems. Also the audit functionality has been combined with the ticket services and can be red only by the security administrator authorised through his/her smart card based certified strong authentication.
5. The DIABCARD integration in health networks Within the framework of the Bavaria On-
408
B. Blobel et al. / International Journal of Medical Informatics 64 (2001) 401–415
line Initiative of the German federal state Bavaria, this aforementioned advanced DIABCARD will be implemented in large scale demonstrators and evaluated during the next two years as one part of a Bavarian health network. This card will meet the challenges of enhanced security services such as strong authentication of the card holder, digital signature, and cipher functions managed and performed by three card-based asymmetric key pairs in addition to the former Patient Data Card services described above. Using for example the digital signature, the patient’s consent can now be provided and verified electronically.
5.1. The next generation DIABCARD patient data card As already indicated, several restrictions had to be taken into consideration during the process of designing and implementing the former DIABCARD PDC back in 1997/ 1998. On the one hand, the card has not been able to provide all the required security functions at this time. On the other hand, the application itself could be protected only by using a secure ‘shell’ instead of securing the provision of services directly. Regarding security requirements, DIABCARD had to decide about an advanced strategy. Starting with the advanced DIABCARD described above, the next generation DIABCARD will incorporate the functionality of both a Patient Identity Card (PIC) and a PDC. The functions of a PDC have been explained in detail already (see Section 2.1). On the other hand and from a security standpoint, a PIC shows similarities to the HPC card type described in Section 2.2. Thus, the holder of such a PIC is able to provide all security services required, as identification and authentication, digital signatures, and cipher functions. These services have been spe-
cified already so the new approach is able to completely follow existing European and national standards of smart cards. As both the German legislation and the European regulations and recommendations require an evaluated card for enhanced security services, the DIABCARD PIC will follow their requests using certified products only. By the way, the specification of a new data card for diabetes patient could be seen as an approach towards a new generation of patient cards in Germany, as there is a strong need to improve the current health insurance card called ‘Krankenversichertenkarte’ (KVK). The current version has been designed to store only administrative data (name, address, insurance number, insurance company, etc.). A second generation KVK needs to have several medical information items on card. Beside an emergency data set, the data structures might contain information about allergies, about specific medication, or about infectious diseases including HIV, up to a minimised version of an electronic patient record. As said, several aspects have to be taken into account when designing the new DIABCARD PDC. The aforementioned legal situation in Europe will be considered. European law has become national law in most of the member states. The remaining states will follow soon. Nevertheless, in some countries national regulations exist with even higher legal demands which have to be followed. One example is the recent debate of the ‘German Digital Signature Law’ versus ‘European Electronic Signature Standard Initiative’. Germany has already defined a higher level of security requirements within its Digital Signature Law and the related act than the European Council. A process of adaptation is required here to achieve both a technical and an administrative interoperability. Neverthe-
B. Blobel et al. / International Journal of Medical Informatics 64 (2001) 401–415
less, the ‘Qualified Electronic Signature’ which is equivalent to the former German legislation will be used in the sensitive healthcare environment only. On the other hand, the growing need of patients to be properly informed to use their own right of self-determination can be discovered. Along with a growing mobility of people within Europe, there is a requirement for an extended electronic data exchange between different organisations directly or indirectly involved in the process of patients’ care. Summarising these aspects, the new card has to cope both administrative data and medical data. It has to cover several interoperability aspects mentioned to make sure that it can be used in different countries. It has to fulfil more functions than being only a small part of a specific disease-related data set. In other words: DIABCARD is looking for a multi-functional smart card specification in a way that a combination of a Patient Identification Card and a Patient Data Card comes true. This means furthermore that the new DIABCARD PDC needs to be able to offer several applications in parallel. From the card specification point of view, several ‘isolated’ partitions on the card are required. As one can imagine each card-based application may need different security requirements and may of course thus have a different security policy at all. That is why each card application has to be accessable separately. Taking both the memory card specification of the former DIABCARD PDC and the new requirements and conditions mentioned above as well as the availability of new card products into account, the new DIABCARD PDC will contain an emergency data set following European recommendations, the diabetes-related specific data set, the diabetes passport,
409
an information data set about card holder (patient), and security-related functions including keys and probably certificates. The first three information structures have already been specified by a former DIABCARD project phase as well as by other projects and initiatives (e.g. the G7 group, the WHO, etc.). In the following, the application parts of the DIABCARD PDC will be described in a more detailed manner. As far as security functions and the data about the card holder are concerned please refer to the Health Professional Card section earlier in this paper. In order to make such a card respectively specific parts of it readable by almost everyone interoperability aspects play an important role. This is especially true for the emergency data set because, the new DIABCARD PDC needs to set up this service in a way that it is possible for everybody to get access in a case of emergency or even at home just to see what’s on the card. Thus, this emergency data set has to be provided to all users without secure access means. There will be a need for just a parser or browser to read the data without having the chance to delete or update anything. The only security function requested is an integrity check of the data. Based on a successful data integrity check all persons and organisations can use the data being sure they are unchanged and thus valid. When it comes to disease-specific data stored on the card, the new DIABCARD PDC will use both the diabetes passport and the diabetes data set specified in an earlier phase of the DIABCARD project. Taking the new cards with up to 32k RAM into account instead of the 8k cards used for the pure PDC version one can imagine that even here the data set definition can be extended. Nevertheless, the way these diabetes-related
410
B. Blobel et al. / International Journal of Medical Informatics 64 (2001) 401–415
data are stored on the card is completely different from what has been said about the emergency data set. It is a must that the diabetes data set is accessable only by using the health professional’s HPC and presenting a Personal Identification Number (known as PIN) as well as using the HP’s appropriate attribute certificates. As far as the PIN itself is concerned the new card has to provide not only four digits but in minimum six–eight digits, preferably alpha-numerical (similar to the difference between password and passphrase). Only by having successfully presented the authentication PIN to the card, an HP is able to get secure access to patient data. But this means new security requirements also towards the card reader used, as most of them do not even have a keyboard; and if yes, then it is a keyboard with digits 0 – 9 only. A PIN is of course not an ideal solution for the issue of a secure identification and authentication process towards an application. It is simply a combination of possession (the card) and knowledge (the PIN). But as one can imagine such a PIN could easily be forgotten or even be ‘mixed up’ with other PINs for e.g. a cheque card, a credit card, a debit card, etc. The only way to solve this problem is the substitution of this ‘knowledge’ by another type of ‘possession’: biometrics as, e.g. fingerprint, iris, face, voice or similar. Last but not least it is the mechanism how to get data on cards that makes a difference. At the moment, DIABCARD is using a very specific application to read and write the aforementioned diabetes data in sequential records. This means, only the complete data record can be read or written. This is a typical disadvantage of nowadays card application solutions. Future cards should allow to install a relational or an object-oriented data base on the card so the HP is able to
read and write data directly from and to data base thus enabling a technical access to data as easy as possible. A so-called Smart Card Query Language (SCQL) is already in use and could be extended to a real means for accessing card data. Along with this query language, both the data base definition language and, of course, the card operating system have to support direct access to any data on the card following the application security policy.
5.2. Alternati6e solutions for access to cards As mentioned already, the German specification for an Electronic Doctor’s License smart card (‘Elektronischer Arztausweis’) [5] is proposing also a cheaper low-level and easy-to-use mechanism for a card-card interactions between HPC and PDC by the use of card-verifiable certificates (CVC). Herefore, only two security services are used. Firstly, the PDC has to prove its authenticity. Secondly, the HP–using his HPC– has to prove his related access rights to read, write, or update PDC data. The authorisation procedure is therefore, often based on attribute certificates. When proving these access rights, an authentication procedure has to be performed so that in the PDC the related security status can be set. Using a symmetric algorithm, the group key needs to be successfully presented before any access to PDC data items is allowed. Assuming the use of asymmetric algorithms for the DIABCARD PDC access, the certificate holder authorisation certificate C.HP.AUT-CV needs to be successfully presented. The authentication certificate is used in PK-based authentication procedures applied in any HPC–PDC interworking. The principle structure of the card verifiable certificate used is shown in the subsequent figure. The
B. Blobel et al. / International Journal of Medical Informatics 64 (2001) 401–415
411
Fig. 3. Certificate content and certificate headerlist.
sequence of data elements can be described by a headerlist as defined in ISO/IEC 7816-8 [8]. This requires nonetheless a fixed length of each data element [5]. Hereby, the ‘Certificate Profile Identifier (CPI)’ has the purpose to denote the exact structure of the CVC (Fig. 3). It can be considered as an identifier of the card’s internal headerlist describing the concatenation of the data elements including their length so that, e.g. the PK in the CVC can be found by the certificate verifying card (PDC). The ‘Certification Authority Reference (CAR)’ has the purpose of identifying the certificate issuing CA with a distinguished name (DN) in such a way that it can be used as an authority key identifier for referencing the PK to be applied for the certificate verification. Therefore, the CAR consists of the CA name (country code according to ISO 3166 [9] (2 Bytes, e.g. DE= Deutschland) followed by an acronym of the CA (3 Bytes, ASCII characters), and an extension for key referencing (3 Bytes). The ‘Certificate Holder Reference (CHR)’ has the purpose to denote the certificate holder uniquely in such a way that its DN can be used as a subject key identifier for referencing the PK of the certificate holder. The CHR thus consists of a CA Reference CAR (5 Bytes) Extension for key referencing (3 Bytes), if the certificate holder is a CA, or the serial number of the card’s processor
chip (ICCSN, 14 Bytes), if the certificate holder is the card of a health professional. The ‘Certificate Holder Authorisation (CHA)’ has the purpose to denote the access rights of the health professional with respect to data stored in files in the patient data card. The meaning of CHA can be compared with a role based group key when applying symmetrical algorithms. The CHA consists of a prefix denoting the entity assigning the role ID, and the role identifier of the health professional. Fig. 4 shows CHA Role Identifiers relevant for physicians. The PK in a certificate consists of a concatenation of parameters. These parameters, which have a context specific tag, have to be coded as octet string. In the CVC verifying entity (i.e. in the PDC) the occurrence of such a parameter and its length can be described in the headerlist (Fig. 4). The data to be signed are the certificate content. The hash function used and the digital signature input format are denoted by the object identifier (OID). Summarising the intentions of a CVC and the related security services that can be provided, the new DIABCARD approach will strictly orient on a PDC with a cryptographic processor so that, e.g. full service signatures and strong authentication can be performed by the card.
412
B. Blobel et al. / International Journal of Medical Informatics 64 (2001) 401–415
Fig. 4. CHA role ID coding.
6. The DIABCARD communication security solution
information about TTP structure and services may be found, e.g. in [3,11].
For enabling remote DIABCARD workstation databases or the workstation’s integration into departmental systems as well as open health networks, secure communication between the local and remote principals must be guaranteed. For that purpose, a security solution according to the Electronic Data Interchange (EDI) Communication Security standard has been applied. This solution implies, strong mutual authentication; confidentiality; integrity; and accountability services including non-repudiation of origin as well as receipt and is by that way featuring a secure File Transfer Protocol (FTP) [10].
7.1. Legal framework
7. Security infrastructure and basic trends Since currently only a small scale solution is running, TTP services established in the context of our ONCONET [18] in routine according to the international, European, and German specifications and initiatives5 have not yet been used. Alternatively, TTP services have been implemented in the PSE. Extending the pilot, standardised TTP services are inevitable, however, not yet experienced in the context of mobile patients. More 5 In that context, the HPC specifications [[1,3,5]] as well as both the European Trust Services Initiative (ETSI) and the European Electronic Signature Standard Initiative (EESSI) of the EC and ongoing work in ISO TC 215 ‘Health Informatics’ regarding Public Key Infrastructure (PKI) [[12]] must be referred to.
In Europe, the security solution must be based on the European security framework established in the ‘Directive 95/46/EC: On the Protection of Individuals with Regard to the Processing of Personal Data and on the Free Movement of such Data’ [13] the ‘Recommendation R(97)5: On the Protection of Medical Data’ [14] as well as the currently approved European ‘Directive on a Common Framework for Electronic Signatures (Digital Signature Directive)’ [15]. Essential issues will be discussed shortly. In the US, Canada, and some other states, similar legislation is in force. In the European Digital Signature Directive mentioned above, three levels of trustworthiness are defined, starting with the mutual agreement level, coming to the certification infrastructure environment required, and ending up with certified applications and components used. In the healthcare domain, often the highest digital signature level is mandated. Following the establishment of a Digital Signature Law in Germany, TTP services authorities have been initiated which are accredited by the root CA at the German ‘Regulierungsbeho¨ rde’, a body developed from the former Federal Ministry of Postal Services and Telecommunications (RegTP). Until now, the highest level of trustworthiness of the Digital Signature has not been accredited yet. Imagine to create a signed
B. Blobel et al. / International Journal of Medical Informatics 64 (2001) 401–415
document using Microsoft’s Word text processor. In such a case, neither the content at the bit level nor the form of the document can be guaranteed really. Currently, the German Digital Signature Law is being adopted to the European Digital Signature Directive. Beside social and psychological issues, however, the discussion about the acceptance of electronic means in electronic commerce including the business of health deals with the provision of legal evidence. As mentioned above, such a legal evidence concerns, e.g. the originator of a document or information, its content and the context to be applied, but also the form of that document. Therefore, information about the resources and principals (e.g. originator and recipient of information) involved, additional authenticated attributes, context information as well as form characteristics must be exchanged. An important trend, recently obviously, is the establishment of the XML (eXtensible Markup Language) standards set inside and outside the healthcare domain to fulfil these requirements.
7.2. Security solutions within the XML standards set Originally thought as an open document definition and data exchange format to replace the specific format definitions of HL7, EDIFACT, or DICOM, XML has been improved to a general concept for documentbased information systems. Agreements on XML repositories defining tags, concepts, contexts, Data Type Definitions (DTD), Schemas etc. are essential pre-assumptions. Defining content and structure of a document via XML, this meta-language concept additionally consists, e.g. of the XML Schema defining structure and datatypes of the elements involved, of the XPath for navigation, of XSL and XSLT for presentation, of XSL-
413
Fo for stylesheet formatting, of XPointer and XLink for references as well as of XQL supporting queries. The Domain Object Model (DOM) and Resource Description Framework (RDF) enable the integration of XML into applications. By that way, the flexibility concerning the diabetes-related information recorded, stored, processed, and transferred can be optimised, also improving card-network interoperability using XPath, DOM, etc. Also in the security and privacy context of personal medical (and therefore, sensitive) information, medical procedures as well as Healthcare Establishment data, the XML standards set seems to be the appropriate solution to cover services related to communication and to application security services as well. Especially interoperability is enabled in a transparent easy way. The essential services for communicated information as signer authentication, message authentication and message integrity are based on the digital signature mechanism. Considering the XML standard set, this mechanism is defined in the W3C IETF Working Draft XML-Signature Core Syntax and Processing [17] which reflects the XMLSignature Requirements [16]. Regarding the common requirements including the legal ones mentioned above,authentication of internal and external resources,authentication of part or totality of a document,signing of composite documents,detachment of signatures from document (separation of attribution info, manifest and signature),multiple signature (e.g. co-signature, endorsement) must be supported. These requirements have been met by the XML-Signature element structured as BSignature \ (B SignedInfo \ (CanonicalisationMethod) (SignatureMethod) ( BReference (URI=)?\
414
B. Blobel et al. / International Journal of Medical Informatics 64 (2001) 401–415
(Transforms)? (DigestMethod) (DigestValue) B/Reference\ )+ B /SignedInfo \ ) (SignatureValue) (KeyInfo)? (Object)* B/Signature\ where ‘?’ denotes zero or one occurrence; ‘+ ’ denotes one or more occurrences; and ‘*’ denotes zero or more occurrences. The signature validation can be realised as for core validation or reference validation. In the case of signing multiple data objects, the former requires a complete set of references within SignedInfo. The latter enables the validation of parts of the references. To address these challenge, the additional element type Manifest has been defined which may be referenced by SignedInfo References. The syntax is defined as follows: BObject \ B Manifest\ (Reference) B /Manifest\ (/Object) Sometimes, additional information is needed to include assertions about how the signature was produced. Therefore, the SignatureProperties element contains information such as time of signing, ID of supporting components, etc. Defining Core Syntax (Schema Definition, DTD) and Processing, but also the Algorithms required, recommended or optionally, the XML-Signature proposal supports the binding of any kind of information dealing with content, form, and context to the digital signature. Furthermore, it supports healthcare-relevant requirements like the endorsement reflecting the principal’s role within the organisational framework.
Combining these features with XML Digital Signature, a promising way for reliable documents preserving content and form could be opened as well as well structured trustworthy databases and record systems might be realistic. Future developments dealing with that XML standard set can be included in our approach changing both the DIABCARD specification as well as implementation and the underlying security solution.
8. Conclusions The shared care paradigm can be supported specifically by introducing disease-specific PDC. As networking systems, also PDC-based systems must operate in a trustworthy way. Using the European security infrastructure specified in the TrustHealth project, a first solution has been provided for solitaire as well as network-embedded PDC systems. The results have been successfully audited by the European Commission and its acknowledged experts. The next generation of secure PDC is currently under specification for being implemented during the next 2 years in routine. The effort starts in the German federal states Bavaria establishing trustworthy health networks by using different but interoperable technologies.
Acknowledgements The authors are indebted to the European Commission for project funding as well as to the TrustHealth project partners GMD Darmstadt and Giesecke & Devrient Munich for supporting the activities presented.
B. Blobel et al. / International Journal of Medical Informatics 64 (2001) 401–415
References [1] CEN TC 251 (1999) prENV 13729: Health Informatics-Secure User Identification– Strong Authentication using Microprocessor Cards (SEC-ID/CARDS). [2] The DIABCARD-3 project. http://www-mi.gsf.de /diabcard. [3] The European TrustHealth-1 project. http:// www.spri.se/ TH2/default.htm. [4] R. Engelbrecht, V. Bo¨ hm, C. Hildebrand, W. Moser, R. Landgraf, F. Hierl, S. To¨ ppel, B. Blobel, T. Diedrich, ByMedCard — an electronic patient record with chip card functionality, in: L. van den Broek, A.J. Sikkel (Eds.), Health Cards’ 97, Series in Health Technology and Informatics, vol. 49, IOS Press, Amsterdam, 1997, pp. 313 – 317. [5] B. Blobel, P. Pharow, Security infrastructure of an oncological network using health professional cards, in: L. van den Broek, A.J. Sikkel (Eds.), Health Cards ’97, Series in Health Technology and Informatics, vol. 49, IOS Press, Amsterdam, 1997, pp. 323 –334. [6] B. Blobel, G. Bleumer, A. Mu¨ ller, K. Louwerse, E. Flikkenschild, F. Ottes, Current Security Issues Faced by Health Care Establishments. ISHTAR Project HC 1028, Deliverable 09 (Final), February 1997. [7] HPC-Protocol Version 1.0, www.hcp-protocol.de/ engindex.htm. [8] ISO/IEC 7816-8: FDIS 1998 Information technology-Identification cards-Integrated circuit(s) cards with contacts-Part 8: Security related interindustry commands. http://www.iso.ch.
415
[9] ISO 3166 Codes for the representation of names of countries and their subdivisions. http:// www.iso.ch. [10] B. Blobel, P. Pharow, K. Engel, V. Spiegel, R. Krohn, Communication security in open health care network, in: P. Kokol, B. Zupan, J. Stare, M. Premik, R. Engelbrecht (Eds.), Medical Informatics Europe ’99. Series in health technology and informatics, vol. 68, IOS Press, Amsterdam, 1999, pp. 291 –296. [11] P. Pharow, B. Blobel, Trusted third party services for internet security, in: N.E. Mastorakis (Ed.), Recent Advances in Signal Processing and Communications, World Scientific and Engineering Society Press, 1999, pp. 379 –385. [12] ISO DTS 17090 Health Informatics — Public Key Infrastructure. [13] Council of Europe: Directive 95/46/EC, On the Protection of Individuals with Regard to the Processing of Personal Data and on the Free Movement of such Data (OJ L281/31-50,24 october 1995), Strasbourg 1995. [14] Council of Europe: Recommendation 13/2/97(5) on the Protection of Medical Data (and Genetic Data). CJ-PD (97), Strasbourg 1997. [15] Council of Europe: Directive 99/93/EC, On a Common Framework for Electronic Signatures (Digital Signature Directive), Strasbourg 1999. [16] XML-Signature Requirements. http://www.w3. org/1999/WD-xmldsig-requirements-19991014. [17] XML-Signature Core Syntax and Processing. http://www.w3.org/1999/WD-xmldsig-core20010419. [18] B. Blobel, Onconet: a secure infrastructure to improve cancer patients’ care, Eur. J. Med. Res. 5 (2000) 360 –368.
Securing interoperability between chip card based medical information systems and health networks Bernd Blobel a,*, Peter Pharow a, Volker Spiegel a, Kjeld Engel a, Rolf Engelbrecht b a
Department of Medical Informatics, Medical Faculty, Institute of Biometry and Medical Informatics, Otto-6on-Guericke Uni6ersity Magdeburg, Leipziger Str. 44, D-39120 Magdeburg, Saxony-Anhalt, Germany b GSF-Forschungszentrum fu¨r Umwelt und Gesundheit, MEDIS-Institute, Ingolsta¨dter Landstraße 1, D-85764 Neuherberg, Germany
Abstract Health information systems supporting shared care are going to be distributed and interoperable. Dealing with sensitive personal medical information, such information systems have to provide appropriate security services, allowing only authorised users restricted access rights to the patients’ data according to the ‘need to know’ principle. Especially in healthcare, chip card based information systems occur in the shape of patient data cards providing informational self determination and mobility of the users as well as quality, integrity, accountability, and availability of the data stored on the card, thus improving the shared care of patients. The DIABCARD1 project aims at the implementation and evaluation of a chip card based medical information system (CCMIS) for facilitating communication and co-operation between health professionals in different organisations or departments caring the same patient with diabetes as an example. In co-operation with the EC-funded TrustHealth2 project, communication and application security services needed are provided like strong authentication as well as the derived services such as authorisation, access control, accountability, confidentiality, etc. The solution is based on Health Professional Cards and Trusted Third Party services. In addition to the secure handling of the patient’s chip card and data in DIABCARD workstations, the secure communication between these workstations and related departmental systems has been implemented. Based on the results of this feasibility study, an enhanced security services specification for the DIABCARD example of a CCMIS is provided which will be implemented in the framework of a health network being established in the German federal state Bavaria. Beside the preferred solution of a combination of Patient Identification Card and Patient Data Card, lower level alternatives using card-verifiable certificates are explained in some details. Finally, a few legal issues, future trends like the XML standard set and their implications for the solution presented as well as for distributed health information systems in general are shortly discussed. © 2001 Elsevier Science Ireland Ltd. All rights reserved. Keywords: Health information systems; Smart cards; Security; DIABCARD
* Corresponding author. Tel.: + 49-37-135-42; fax: + 49-67-135-36. E-mail address: [email protected] (B. Blobel). 1 Funded by the European Commission (EC) under TAP HC 1010. 2 Funded by the European Commission (EC) under TAP HC 4023. 1386-5056/01/$ - see front matter © 2001 Elsevier Science Ireland Ltd. All rights reserved. PII: S 1 3 8 6 - 5 0 5 6 ( 0 1 ) 0 0 1 9 3 - 9
402
B. Blobel et al. / International Journal of Medical Informatics 64 (2001) 401–415
1. Introduction For meeting the challenge of the shared care paradigm, the specialisation and decentralisation must be accompanied by comprehensive communication and co-operation. This communication and co-operation may be supported through any kind of networks from a departmental Local Area Network (LAN) up to the Internet. An alternative to networking is the connection of patient’s information with the patient’s being itself: Acting as data subject and data source, but also as carrier of any data collected, the patient can realise the informational self-determination guaranteed by privacy acts and constitutions. In any case, communication and co-operation have to be provided securely.
2. Smart cards in healthcare If an information system shall be held by a human being, an appropriate media is needed for storing data and applications providing the functionality required as well as for communicating data to partners. This generally applies ranging from the use of simple hardware token for specific functions such as identity-related services up to more or less comprehensive portable information systems carried by the information subject. For electronic health information systems held by patients, beside the appropriate carrier also an environment must be provided for the authorised use of information in the sense of collecting, storing, processing, and communicating the data. Starting in Europe, smart cards, i.e. microprocessor cards, are used for both purposes mentioned, i.e. as Patient Data Cards (PDC) and Health Professional Cards (HPC) [1] around the world. Generally, it should be mentioned that the smart card could be deployed in two ways.
On the one hand, the card could bear all information needed, in the case of PDC, e.g. all relevant medical data, as shown in this paper. On the other hand, the card can be used as a pointer providing references and linkages to the information stored in networked systems. However, also a combination of those two principles could be imaginable. Based on the European security infrastructure for health, the paper describes the first security solution for a PDC environment really implemented for the currently used as well as for the next generation DIABCARD architecture. It does not discuss the genuine issues of the DIABCARD project itself, as the DIABCARD data set; the application around; etc. The paper presented concerns the co-operation between two projects funded by the European Commission within the Telematics Applications Programme: DIABCARD [2] and TrustHealth [3]. It deals with the secure use of a specific patient data card, held by the patient as well as its embedding into health networks deploying the European security infrastructure based onHPC and Trusted Third Party (TTP) services. The project-related PDC, the DIABCARD PDC or simply the DIABCARD, facilitates communication and co-operation between General Practitioners (GP) and secondary care departments providing medical services for diabetes patients.
2.1. The DIABCARD PDC Originally, the DIABCARD PDC is a PIN-code-protected smart card containing, the DIABCARE minimal data; the European administrative data set; the European emergency data set; the DIABCARE basic information sheet; the diabetes passport; as well as groups of actual data describing essential information of the last visits, in the ophthalmo-
B. Blobel et al. / International Journal of Medical Informatics 64 (2001) 401–415
logic; the internal; and the foot care department of a Health Care Establishment (HCE) [4]. In the first DIABCARD PDC version, the strong authentication of the patient to the system as well as the mutual authentication between the PDC and the HPC was not supported. Due to those restrictions, some of the security services needed had to be delegated first to the application environment as shown in the next sections.
2.2. The health professional card To ensure communication security, the HPC as a secure token and its related TTP services are used within the European security infrastructure according to the EC TrustHealth project [3,5]. The HPC is a microprocessor card with an additional co-processor specialised for cryptographic algorithms (cryptoprocessor). The authentication provided concerns both the identity and the roles of Health Professionals (HP). The identity certificate issued by the Physicians’ Chamber guarantees the first. The latter are expressed by several different attribute certificates issued by the Physicians’ Chamber (specific domains of care or specific qualifications) or by the Doctors’ Statutory Association ‘Kassena¨ rztliche Vereinigung’ (specific permissions= ‘Erma¨ chtigungen’). The card contains in minimum three private keys with dedicated usage as, e.g. for authentication; digital signature; and decryption (e.g. the session key) as well as the X.509 v3-based certificates bound on those keys3. In the card’s Master File, the global profession (physician, nurse, etc.) is specified. Beside the authentication, the HPC facilitates also the other communication security services implemented using the digital signature mechanism such as integrity and accountability, but also confidentiality directly by encoding the 3
Attribute certificates are not bound on keys.
403
plain text or indirectly by encoding the symmetric session key used. As a result of the authentication procedure and the roles dedicated to the user, communication in the sense of connection respectively system access is permitted or denied. Based on the identity and the roles of the user on the one hand and the decision rules agreed in the security policy on the other, the HPC also enables application security services which are related to that person such as authorisation, access control, integrity, confidentiality, accountability, and audit. As far as medical applications are concerned, an HPC can be used for access to local and remote systems as well as to networks, for any kind of secure transmission of medical and administrative data, for medical prescriptions, and for any kind of electronic business processes within healthcare and welfare. Last but not least, the HPC is designed to get controlled access to patient data on PDCs.
3. The DIABCARD application security solution Fig. 1 shows the security scenarios of the security-enhanced advanced DIABCARD environment. It is based on the general layered security model [6] distinguishing between the concepts of communication security and application security, which may be specified and implemented separately as an advantage of the component paradigm. As mentioned, the userrelated security services are provided by the card bearing the three keys for authentication, integrity, and confidentiality as well as the certificates needed. Storing the certificates on the card enables the use of isolated workstations as specified as the original DIABCARD scenario. In a network environment, certificates may be hold in TTP directories saving storage capacity especially in the context of the
404
B. Blobel et al. / International Journal of Medical Informatics 64 (2001) 401–415
advanced PDC. Furthermore, the certificate management including in-time revocation procedures could be speeded up by that way or even enabled. In the international DIABCARD environment, encoding of data on the DIABCARD PDC using either the PDC or the HPC encoding/decoding key pair will not be used currently to avoid the exclusion of partners not yet enabled for enhanced security services. As a general service however, it is inevitable for enabling, e.g. future home care activities and communications. Establishing a proper security infrastructure however, the PDC confidentiality service will be applied in regional solutions such as German federal states health networks (e.g. in Bavaria). Therefore, PDC confidentiality has been implemented in our demonstrator. Fig. 2 presents the actual DIABCARD system architecture including the interfaces and security services used to provide a secure environment. The architectural components have been explained elsewhere (e.g. [4]). Therefore, the following sections are only
Fig. 1. The DIABCARD security scenarios.
dealing with security services provided for trustworthy use of data and functions within the DIABCARD system.
3.1. Strong authentication and component access control The first step of introducing trustworthiness is the mutual strong authentication between the communicating principals, i.e. user and application. Since applications normally consist of multiple components establishing distributed systems, the mutual authentication has to be provided to all the components involved. Otherwise, the invocation of components not participating in the authentication procedure must be denied. In the DIABCARD example, the components DIABCARD Core System (DCC), the underlying Paradox database (PDD), the DIABCARD Server (DCS) and last but not least the PDC itself are protected by peer-authenticationbased access control for authorised users only (step 1a)–(step 1e). Using an HPC specified within the TrustHealth project (TH.HPC), a single logon is realised. In the DIABCARD PDC version implemented in 1999, the strong authentication of that PDC was not enabled. Since also DCS source code was not available, its components (e.g. the invocation of the DIABCARD Data Access API) could not be protected by access control services. Following, the authentication/access control services have been provided on (step 1a)–(step 1c) only. Therefore, the access control services could only be established via encryption hindering the unauthorised use of those components, being aware that access control and confidentiality services are coherent in certain manner4. The 4 Nevertheless, the latter is more problematic, less stable and trustworthy. Therefore, encryption should be applied, if possible, additionally to prevent unauthorised disclosure when access control is not available (e.g. in de-mounted hard disks).
B. Blobel et al. / International Journal of Medical Informatics 64 (2001) 401–415
405
Fig. 2. Architectural schema and placement of application security services in the DIABCARD workstation.
encryption was performed using a symmetric key, which is either stored on the HPC or in all authorised users’ Personal Security Environment (PSE). Starting the DIABCARD application, only the authorised user could decrypt these protected components for use.
3.2. Authorisation and access control to function and data Based on the roles specified in the HPC certificates and verified during the authentication procedure, the user’s functional and medical data access rights can be derived
406
B. Blobel et al. / International Journal of Medical Informatics 64 (2001) 401–415
(step 2a), (step 2b). In the case of the Paradox database, the authorisation is realised by locking mechanisms not allowing the separate handling of single tables and items. Therefore, its replacement is recommended. Temporarily, authorisation and data access control hindering the separate use of database functions for creation, manipulation or deletion of data have been implemented by encrypting and signing the whole database.
3.3. Accountability The accountability service must be established in the context of creation, deletion or manipulation of information providing nonrepudiation of origin. These function modes have been implemented on the DCC level only (step 3), using the user’s digital signature realised through the employment of his/her specific digital signature key.
3.4. Integrity check Regarding the integrity service (step 4a)– (step 4c), both the integrity of data and programs has to be guaranteed, detecting any manipulation of information as well as of application behaviour. The latter concerns especially manipulations of the security solutions implemented, also including the replacement of complete components. Considering the data integrity check, the data origin authentication service is employed using digital signature mechanisms. Since of the possibility to remove data items or even records from the database, the tables must be protected against any changes or replacements.
3.5. Confidentiality To avoid the misuse of the sensitive med-
ical data by unauthorised persons invoking the database independent of the DIABCARD application, the database has to be encrypted (step 5a). To support multiuser facilities of the data which establish an Electronic Healthcare Record in diabetes, the use of a symmetric algorithm distributing the secret key securely can be applied to implement the confidentiality service. Since the DCS source code was not available, the confidentiality service was also used to hinder any manipulation or bypassing the security services of this component.
3.6. Database security The security services mentioned in the context of storage of information in, and retrieval of information from, the database are only available under certain conditions, accompanied by organisational measures. Thus, if the application is running, the database is not secured (e.g. decrypted). Alternatives enabling all security services mentioned are only achievable through replacing the database by a security-enabled one. This concerns also the accountability service keeping all database functionalities running. Appropriate databases are available on the market (e.g. Oracle 8) and should be taken in consideration for future implementations if required due to the threat and risk assessment.
3.7. Audit In sensitive environments, an audit checking the accountability including non-repudiation for any procedures is an inevitable functionality. Such an audit must be provided in a secure environment disabling any manipulation by the audited person or any unauthorised third party.
B. Blobel et al. / International Journal of Medical Informatics 64 (2001) 401–415
4. The advanced DIABCARD security solution Generally, the first implementation of the secure DIABCARD solution has been a success story. Meeting the genuine challenge of the European Commission, the feasibility of PDC applications based on the European security infrastructure has been demonstrated in 1999 in Magdeburg as well as in Spring 2000 in Munich. In the context of new developments on both the technical and the legal field, however, a strong challenge has been discovered to improve the existing solution in order to meet the needs of health networks and to overcome the disadvantages of current installations mentioned. Still within the DIABCARD project framework, an advanced DIABCARD PDC has been completely specified and partially implemented in the sense of a feasibility study. This advanced DIABCARD PDC contains a cryptographic co-processor by that way enabling all the services for communication security and application security provided by the deployment of cryptographic algorithms. As another way assigned to be deployed in a German project for facilitating management and quality assurance in kidney transplantations, the German HPC specification [7] defines already future interactions between HPC and PDC using card-verifiable certificates (see Section 5.2). By that way, some of the current application-mediated security services might be delegated to the card PSE.
4.1. Additional security ser6ices of the ad6anced DIABCARD Exploiting key-related security services enabled by the advanced DIABCARD, strong authentication of the PDC against the DIABCARD workstation as well as access control
407
services are provided. So, the advanced DIABCARD PDC enables also the access control services (step 1d) and (step 1e) shown in Fig. 2. Adopting the structure of data stored, storage capacity of the PDC and infrastructure of the DIABCARD environment, accountability services could be extended to the PDC including not only the processes of creation and updating of data, but also the processes of card-system interactions. In the same context of key-related security services, integrity and confidentiality of data on the card level are included after establishing the environment needed. The audit of these card-related interactions will be realised in the future.
4.2. Ad6anced application security ser6ices The misuse of the sensitive medical data by unauthorised persons invoking the database independent of the DIABCARD application must be excluded. To support multi-user facilities of the data in the database encrypted for providing confidentiality, the installation of a ticket server distributing a symmetric session key to users authorised through the strong authentication procedure based on the HPC identity key has been specified and tested as way of choice. This advanced solution is also applicable to general EHCR or other systems. Also the audit functionality has been combined with the ticket services and can be red only by the security administrator authorised through his/her smart card based certified strong authentication.
5. The DIABCARD integration in health networks Within the framework of the Bavaria On-
408
B. Blobel et al. / International Journal of Medical Informatics 64 (2001) 401–415
line Initiative of the German federal state Bavaria, this aforementioned advanced DIABCARD will be implemented in large scale demonstrators and evaluated during the next two years as one part of a Bavarian health network. This card will meet the challenges of enhanced security services such as strong authentication of the card holder, digital signature, and cipher functions managed and performed by three card-based asymmetric key pairs in addition to the former Patient Data Card services described above. Using for example the digital signature, the patient’s consent can now be provided and verified electronically.
5.1. The next generation DIABCARD patient data card As already indicated, several restrictions had to be taken into consideration during the process of designing and implementing the former DIABCARD PDC back in 1997/ 1998. On the one hand, the card has not been able to provide all the required security functions at this time. On the other hand, the application itself could be protected only by using a secure ‘shell’ instead of securing the provision of services directly. Regarding security requirements, DIABCARD had to decide about an advanced strategy. Starting with the advanced DIABCARD described above, the next generation DIABCARD will incorporate the functionality of both a Patient Identity Card (PIC) and a PDC. The functions of a PDC have been explained in detail already (see Section 2.1). On the other hand and from a security standpoint, a PIC shows similarities to the HPC card type described in Section 2.2. Thus, the holder of such a PIC is able to provide all security services required, as identification and authentication, digital signatures, and cipher functions. These services have been spe-
cified already so the new approach is able to completely follow existing European and national standards of smart cards. As both the German legislation and the European regulations and recommendations require an evaluated card for enhanced security services, the DIABCARD PIC will follow their requests using certified products only. By the way, the specification of a new data card for diabetes patient could be seen as an approach towards a new generation of patient cards in Germany, as there is a strong need to improve the current health insurance card called ‘Krankenversichertenkarte’ (KVK). The current version has been designed to store only administrative data (name, address, insurance number, insurance company, etc.). A second generation KVK needs to have several medical information items on card. Beside an emergency data set, the data structures might contain information about allergies, about specific medication, or about infectious diseases including HIV, up to a minimised version of an electronic patient record. As said, several aspects have to be taken into account when designing the new DIABCARD PDC. The aforementioned legal situation in Europe will be considered. European law has become national law in most of the member states. The remaining states will follow soon. Nevertheless, in some countries national regulations exist with even higher legal demands which have to be followed. One example is the recent debate of the ‘German Digital Signature Law’ versus ‘European Electronic Signature Standard Initiative’. Germany has already defined a higher level of security requirements within its Digital Signature Law and the related act than the European Council. A process of adaptation is required here to achieve both a technical and an administrative interoperability. Neverthe-
B. Blobel et al. / International Journal of Medical Informatics 64 (2001) 401–415
less, the ‘Qualified Electronic Signature’ which is equivalent to the former German legislation will be used in the sensitive healthcare environment only. On the other hand, the growing need of patients to be properly informed to use their own right of self-determination can be discovered. Along with a growing mobility of people within Europe, there is a requirement for an extended electronic data exchange between different organisations directly or indirectly involved in the process of patients’ care. Summarising these aspects, the new card has to cope both administrative data and medical data. It has to cover several interoperability aspects mentioned to make sure that it can be used in different countries. It has to fulfil more functions than being only a small part of a specific disease-related data set. In other words: DIABCARD is looking for a multi-functional smart card specification in a way that a combination of a Patient Identification Card and a Patient Data Card comes true. This means furthermore that the new DIABCARD PDC needs to be able to offer several applications in parallel. From the card specification point of view, several ‘isolated’ partitions on the card are required. As one can imagine each card-based application may need different security requirements and may of course thus have a different security policy at all. That is why each card application has to be accessable separately. Taking both the memory card specification of the former DIABCARD PDC and the new requirements and conditions mentioned above as well as the availability of new card products into account, the new DIABCARD PDC will contain an emergency data set following European recommendations, the diabetes-related specific data set, the diabetes passport,
409
an information data set about card holder (patient), and security-related functions including keys and probably certificates. The first three information structures have already been specified by a former DIABCARD project phase as well as by other projects and initiatives (e.g. the G7 group, the WHO, etc.). In the following, the application parts of the DIABCARD PDC will be described in a more detailed manner. As far as security functions and the data about the card holder are concerned please refer to the Health Professional Card section earlier in this paper. In order to make such a card respectively specific parts of it readable by almost everyone interoperability aspects play an important role. This is especially true for the emergency data set because, the new DIABCARD PDC needs to set up this service in a way that it is possible for everybody to get access in a case of emergency or even at home just to see what’s on the card. Thus, this emergency data set has to be provided to all users without secure access means. There will be a need for just a parser or browser to read the data without having the chance to delete or update anything. The only security function requested is an integrity check of the data. Based on a successful data integrity check all persons and organisations can use the data being sure they are unchanged and thus valid. When it comes to disease-specific data stored on the card, the new DIABCARD PDC will use both the diabetes passport and the diabetes data set specified in an earlier phase of the DIABCARD project. Taking the new cards with up to 32k RAM into account instead of the 8k cards used for the pure PDC version one can imagine that even here the data set definition can be extended. Nevertheless, the way these diabetes-related
410
B. Blobel et al. / International Journal of Medical Informatics 64 (2001) 401–415
data are stored on the card is completely different from what has been said about the emergency data set. It is a must that the diabetes data set is accessable only by using the health professional’s HPC and presenting a Personal Identification Number (known as PIN) as well as using the HP’s appropriate attribute certificates. As far as the PIN itself is concerned the new card has to provide not only four digits but in minimum six–eight digits, preferably alpha-numerical (similar to the difference between password and passphrase). Only by having successfully presented the authentication PIN to the card, an HP is able to get secure access to patient data. But this means new security requirements also towards the card reader used, as most of them do not even have a keyboard; and if yes, then it is a keyboard with digits 0 – 9 only. A PIN is of course not an ideal solution for the issue of a secure identification and authentication process towards an application. It is simply a combination of possession (the card) and knowledge (the PIN). But as one can imagine such a PIN could easily be forgotten or even be ‘mixed up’ with other PINs for e.g. a cheque card, a credit card, a debit card, etc. The only way to solve this problem is the substitution of this ‘knowledge’ by another type of ‘possession’: biometrics as, e.g. fingerprint, iris, face, voice or similar. Last but not least it is the mechanism how to get data on cards that makes a difference. At the moment, DIABCARD is using a very specific application to read and write the aforementioned diabetes data in sequential records. This means, only the complete data record can be read or written. This is a typical disadvantage of nowadays card application solutions. Future cards should allow to install a relational or an object-oriented data base on the card so the HP is able to
read and write data directly from and to data base thus enabling a technical access to data as easy as possible. A so-called Smart Card Query Language (SCQL) is already in use and could be extended to a real means for accessing card data. Along with this query language, both the data base definition language and, of course, the card operating system have to support direct access to any data on the card following the application security policy.
5.2. Alternati6e solutions for access to cards As mentioned already, the German specification for an Electronic Doctor’s License smart card (‘Elektronischer Arztausweis’) [5] is proposing also a cheaper low-level and easy-to-use mechanism for a card-card interactions between HPC and PDC by the use of card-verifiable certificates (CVC). Herefore, only two security services are used. Firstly, the PDC has to prove its authenticity. Secondly, the HP–using his HPC– has to prove his related access rights to read, write, or update PDC data. The authorisation procedure is therefore, often based on attribute certificates. When proving these access rights, an authentication procedure has to be performed so that in the PDC the related security status can be set. Using a symmetric algorithm, the group key needs to be successfully presented before any access to PDC data items is allowed. Assuming the use of asymmetric algorithms for the DIABCARD PDC access, the certificate holder authorisation certificate C.HP.AUT-CV needs to be successfully presented. The authentication certificate is used in PK-based authentication procedures applied in any HPC–PDC interworking. The principle structure of the card verifiable certificate used is shown in the subsequent figure. The
B. Blobel et al. / International Journal of Medical Informatics 64 (2001) 401–415
411
Fig. 3. Certificate content and certificate headerlist.
sequence of data elements can be described by a headerlist as defined in ISO/IEC 7816-8 [8]. This requires nonetheless a fixed length of each data element [5]. Hereby, the ‘Certificate Profile Identifier (CPI)’ has the purpose to denote the exact structure of the CVC (Fig. 3). It can be considered as an identifier of the card’s internal headerlist describing the concatenation of the data elements including their length so that, e.g. the PK in the CVC can be found by the certificate verifying card (PDC). The ‘Certification Authority Reference (CAR)’ has the purpose of identifying the certificate issuing CA with a distinguished name (DN) in such a way that it can be used as an authority key identifier for referencing the PK to be applied for the certificate verification. Therefore, the CAR consists of the CA name (country code according to ISO 3166 [9] (2 Bytes, e.g. DE= Deutschland) followed by an acronym of the CA (3 Bytes, ASCII characters), and an extension for key referencing (3 Bytes). The ‘Certificate Holder Reference (CHR)’ has the purpose to denote the certificate holder uniquely in such a way that its DN can be used as a subject key identifier for referencing the PK of the certificate holder. The CHR thus consists of a CA Reference CAR (5 Bytes) Extension for key referencing (3 Bytes), if the certificate holder is a CA, or the serial number of the card’s processor
chip (ICCSN, 14 Bytes), if the certificate holder is the card of a health professional. The ‘Certificate Holder Authorisation (CHA)’ has the purpose to denote the access rights of the health professional with respect to data stored in files in the patient data card. The meaning of CHA can be compared with a role based group key when applying symmetrical algorithms. The CHA consists of a prefix denoting the entity assigning the role ID, and the role identifier of the health professional. Fig. 4 shows CHA Role Identifiers relevant for physicians. The PK in a certificate consists of a concatenation of parameters. These parameters, which have a context specific tag, have to be coded as octet string. In the CVC verifying entity (i.e. in the PDC) the occurrence of such a parameter and its length can be described in the headerlist (Fig. 4). The data to be signed are the certificate content. The hash function used and the digital signature input format are denoted by the object identifier (OID). Summarising the intentions of a CVC and the related security services that can be provided, the new DIABCARD approach will strictly orient on a PDC with a cryptographic processor so that, e.g. full service signatures and strong authentication can be performed by the card.
412
B. Blobel et al. / International Journal of Medical Informatics 64 (2001) 401–415
Fig. 4. CHA role ID coding.
6. The DIABCARD communication security solution
information about TTP structure and services may be found, e.g. in [3,11].
For enabling remote DIABCARD workstation databases or the workstation’s integration into departmental systems as well as open health networks, secure communication between the local and remote principals must be guaranteed. For that purpose, a security solution according to the Electronic Data Interchange (EDI) Communication Security standard has been applied. This solution implies, strong mutual authentication; confidentiality; integrity; and accountability services including non-repudiation of origin as well as receipt and is by that way featuring a secure File Transfer Protocol (FTP) [10].
7.1. Legal framework
7. Security infrastructure and basic trends Since currently only a small scale solution is running, TTP services established in the context of our ONCONET [18] in routine according to the international, European, and German specifications and initiatives5 have not yet been used. Alternatively, TTP services have been implemented in the PSE. Extending the pilot, standardised TTP services are inevitable, however, not yet experienced in the context of mobile patients. More 5 In that context, the HPC specifications [[1,3,5]] as well as both the European Trust Services Initiative (ETSI) and the European Electronic Signature Standard Initiative (EESSI) of the EC and ongoing work in ISO TC 215 ‘Health Informatics’ regarding Public Key Infrastructure (PKI) [[12]] must be referred to.
In Europe, the security solution must be based on the European security framework established in the ‘Directive 95/46/EC: On the Protection of Individuals with Regard to the Processing of Personal Data and on the Free Movement of such Data’ [13] the ‘Recommendation R(97)5: On the Protection of Medical Data’ [14] as well as the currently approved European ‘Directive on a Common Framework for Electronic Signatures (Digital Signature Directive)’ [15]. Essential issues will be discussed shortly. In the US, Canada, and some other states, similar legislation is in force. In the European Digital Signature Directive mentioned above, three levels of trustworthiness are defined, starting with the mutual agreement level, coming to the certification infrastructure environment required, and ending up with certified applications and components used. In the healthcare domain, often the highest digital signature level is mandated. Following the establishment of a Digital Signature Law in Germany, TTP services authorities have been initiated which are accredited by the root CA at the German ‘Regulierungsbeho¨ rde’, a body developed from the former Federal Ministry of Postal Services and Telecommunications (RegTP). Until now, the highest level of trustworthiness of the Digital Signature has not been accredited yet. Imagine to create a signed
B. Blobel et al. / International Journal of Medical Informatics 64 (2001) 401–415
document using Microsoft’s Word text processor. In such a case, neither the content at the bit level nor the form of the document can be guaranteed really. Currently, the German Digital Signature Law is being adopted to the European Digital Signature Directive. Beside social and psychological issues, however, the discussion about the acceptance of electronic means in electronic commerce including the business of health deals with the provision of legal evidence. As mentioned above, such a legal evidence concerns, e.g. the originator of a document or information, its content and the context to be applied, but also the form of that document. Therefore, information about the resources and principals (e.g. originator and recipient of information) involved, additional authenticated attributes, context information as well as form characteristics must be exchanged. An important trend, recently obviously, is the establishment of the XML (eXtensible Markup Language) standards set inside and outside the healthcare domain to fulfil these requirements.
7.2. Security solutions within the XML standards set Originally thought as an open document definition and data exchange format to replace the specific format definitions of HL7, EDIFACT, or DICOM, XML has been improved to a general concept for documentbased information systems. Agreements on XML repositories defining tags, concepts, contexts, Data Type Definitions (DTD), Schemas etc. are essential pre-assumptions. Defining content and structure of a document via XML, this meta-language concept additionally consists, e.g. of the XML Schema defining structure and datatypes of the elements involved, of the XPath for navigation, of XSL and XSLT for presentation, of XSL-
413
Fo for stylesheet formatting, of XPointer and XLink for references as well as of XQL supporting queries. The Domain Object Model (DOM) and Resource Description Framework (RDF) enable the integration of XML into applications. By that way, the flexibility concerning the diabetes-related information recorded, stored, processed, and transferred can be optimised, also improving card-network interoperability using XPath, DOM, etc. Also in the security and privacy context of personal medical (and therefore, sensitive) information, medical procedures as well as Healthcare Establishment data, the XML standards set seems to be the appropriate solution to cover services related to communication and to application security services as well. Especially interoperability is enabled in a transparent easy way. The essential services for communicated information as signer authentication, message authentication and message integrity are based on the digital signature mechanism. Considering the XML standard set, this mechanism is defined in the W3C IETF Working Draft XML-Signature Core Syntax and Processing [17] which reflects the XMLSignature Requirements [16]. Regarding the common requirements including the legal ones mentioned above,authentication of internal and external resources,authentication of part or totality of a document,signing of composite documents,detachment of signatures from document (separation of attribution info, manifest and signature),multiple signature (e.g. co-signature, endorsement) must be supported. These requirements have been met by the XML-Signature element structured as BSignature \ (B SignedInfo \ (CanonicalisationMethod) (SignatureMethod) ( BReference (URI=)?\
414
B. Blobel et al. / International Journal of Medical Informatics 64 (2001) 401–415
(Transforms)? (DigestMethod) (DigestValue) B/Reference\ )+ B /SignedInfo \ ) (SignatureValue) (KeyInfo)? (Object)* B/Signature\ where ‘?’ denotes zero or one occurrence; ‘+ ’ denotes one or more occurrences; and ‘*’ denotes zero or more occurrences. The signature validation can be realised as for core validation or reference validation. In the case of signing multiple data objects, the former requires a complete set of references within SignedInfo. The latter enables the validation of parts of the references. To address these challenge, the additional element type Manifest has been defined which may be referenced by SignedInfo References. The syntax is defined as follows: BObject \ B Manifest\ (Reference) B /Manifest\ (/Object) Sometimes, additional information is needed to include assertions about how the signature was produced. Therefore, the SignatureProperties element contains information such as time of signing, ID of supporting components, etc. Defining Core Syntax (Schema Definition, DTD) and Processing, but also the Algorithms required, recommended or optionally, the XML-Signature proposal supports the binding of any kind of information dealing with content, form, and context to the digital signature. Furthermore, it supports healthcare-relevant requirements like the endorsement reflecting the principal’s role within the organisational framework.
Combining these features with XML Digital Signature, a promising way for reliable documents preserving content and form could be opened as well as well structured trustworthy databases and record systems might be realistic. Future developments dealing with that XML standard set can be included in our approach changing both the DIABCARD specification as well as implementation and the underlying security solution.
8. Conclusions The shared care paradigm can be supported specifically by introducing disease-specific PDC. As networking systems, also PDC-based systems must operate in a trustworthy way. Using the European security infrastructure specified in the TrustHealth project, a first solution has been provided for solitaire as well as network-embedded PDC systems. The results have been successfully audited by the European Commission and its acknowledged experts. The next generation of secure PDC is currently under specification for being implemented during the next 2 years in routine. The effort starts in the German federal states Bavaria establishing trustworthy health networks by using different but interoperable technologies.
Acknowledgements The authors are indebted to the European Commission for project funding as well as to the TrustHealth project partners GMD Darmstadt and Giesecke & Devrient Munich for supporting the activities presented.
B. Blobel et al. / International Journal of Medical Informatics 64 (2001) 401–415
References [1] CEN TC 251 (1999) prENV 13729: Health Informatics-Secure User Identification– Strong Authentication using Microprocessor Cards (SEC-ID/CARDS). [2] The DIABCARD-3 project. http://www-mi.gsf.de /diabcard. [3] The European TrustHealth-1 project. http:// www.spri.se/ TH2/default.htm. [4] R. Engelbrecht, V. Bo¨ hm, C. Hildebrand, W. Moser, R. Landgraf, F. Hierl, S. To¨ ppel, B. Blobel, T. Diedrich, ByMedCard — an electronic patient record with chip card functionality, in: L. van den Broek, A.J. Sikkel (Eds.), Health Cards’ 97, Series in Health Technology and Informatics, vol. 49, IOS Press, Amsterdam, 1997, pp. 313 – 317. [5] B. Blobel, P. Pharow, Security infrastructure of an oncological network using health professional cards, in: L. van den Broek, A.J. Sikkel (Eds.), Health Cards ’97, Series in Health Technology and Informatics, vol. 49, IOS Press, Amsterdam, 1997, pp. 323 –334. [6] B. Blobel, G. Bleumer, A. Mu¨ ller, K. Louwerse, E. Flikkenschild, F. Ottes, Current Security Issues Faced by Health Care Establishments. ISHTAR Project HC 1028, Deliverable 09 (Final), February 1997. [7] HPC-Protocol Version 1.0, www.hcp-protocol.de/ engindex.htm. [8] ISO/IEC 7816-8: FDIS 1998 Information technology-Identification cards-Integrated circuit(s) cards with contacts-Part 8: Security related interindustry commands. http://www.iso.ch.
415
[9] ISO 3166 Codes for the representation of names of countries and their subdivisions. http:// www.iso.ch. [10] B. Blobel, P. Pharow, K. Engel, V. Spiegel, R. Krohn, Communication security in open health care network, in: P. Kokol, B. Zupan, J. Stare, M. Premik, R. Engelbrecht (Eds.), Medical Informatics Europe ’99. Series in health technology and informatics, vol. 68, IOS Press, Amsterdam, 1999, pp. 291 –296. [11] P. Pharow, B. Blobel, Trusted third party services for internet security, in: N.E. Mastorakis (Ed.), Recent Advances in Signal Processing and Communications, World Scientific and Engineering Society Press, 1999, pp. 379 –385. [12] ISO DTS 17090 Health Informatics — Public Key Infrastructure. [13] Council of Europe: Directive 95/46/EC, On the Protection of Individuals with Regard to the Processing of Personal Data and on the Free Movement of such Data (OJ L281/31-50,24 october 1995), Strasbourg 1995. [14] Council of Europe: Recommendation 13/2/97(5) on the Protection of Medical Data (and Genetic Data). CJ-PD (97), Strasbourg 1997. [15] Council of Europe: Directive 99/93/EC, On a Common Framework for Electronic Signatures (Digital Signature Directive), Strasbourg 1999. [16] XML-Signature Requirements. http://www.w3. org/1999/WD-xmldsig-requirements-19991014. [17] XML-Signature Core Syntax and Processing. http://www.w3.org/1999/WD-xmldsig-core20010419. [18] B. Blobel, Onconet: a secure infrastructure to improve cancer patients’ care, Eur. J. Med. Res. 5 (2000) 360 –368.