IP based Smartcards_shuja-atha_ by gopishrine


Information technology have penetrated deep in every part of this technical world. Security has become a major factor to be considered in all real time systems. This paper is aimed at integrating smart card technology with the communication infrastructure to support a nationwide health-care information system. Based on the existing features, the required functionality is discussed in this paper, starting with smart cards and ending with electronic data interface (EDI) technology. The current architecture is investigated in light of emerging standards and available commercial products. Technical and architectural solutions are given to enable a real-time and EDI-based environment for a general set of applications in the medical sector, supported by the flexibility and security of modern smart card technologies. The new system is based on smart cards using symmetric key cryptography and an Internet protocol (IP) network that links computers within institutions and provides connection to the Internet. Currently only elementary transactions of insurance relevant data are supported. The final goal is to provide an infrastructure basis that integrates this system with other telematics solutions in the national health-care information system. This paper includes

 

a full deployment of public key technology; a further transition from a DBMS transaction-based system to a real EDI environment, where this transition should be based on widely available web technology;


Integration of the OCF into the insurance card system architecture as its benefits make it superior to the current "easy to deploy" solution.

Keywords: Smart cards, EDI, Health-care information system infrastructure.

Health institutions and health providers in Europe and other parts of the world are rapidly introducing health-care information systems. Deployment of the latest smart card technology is common to several of these projects and is envisaged as becoming a regular component in the coming years. The evolution of smart-card-based medical information systems is oriented not only to manipulation of health-related data but also to support of all transactions in the healthcare sector. Different standards are used for the implementations of electronic patient records are mutually incompatible, and systems are based on outdated technology that presents barriers to further integration or extension without substantial re-engineering. Furthermore, medical data, information, and documents are stored on media systems ranging from classic data collections (which still account for 70% of all data) to computer-assisted systems. The development of a nationwide health-care information system is a long-term process with a number of components and development directions. Ever new developments are taking place. In 1995 the Health Insurance Institute of Slovenia (HIIS) started a project of introducing smart cards nationwide. This is now becoming an important component of a further improved and integrated nationwide health-care information system. The new system is based on smart cards using symmetric key cryptography and an Internet protocol (IP) network that links computers within institutions and provides connection to the Internet. Currently only elementary transactions of insurance relevant data are supported. The final goal is to provide an infrastructure basis that integrates this system with other telematics solutions in the national health-care information system. This system has to be in line with specific standards in the field of smart cards and health-care information systems. It also has to be in line with more general standards related to EDI, computer communications, and public key infrastructure. And finally, the system has to be based on widely available commercial solutions in order to reduce costs and enhance reliability, which basically implies web technology.


Particular architectural issues need to be addressed to achieve a level of modularity that will not limit future integration of new services. These issues are interoperability of the smart card solutions and platforms, chip independence of applications on smart cards, independence of card issuer and card reader vendors, and dynamic downloading of applications. In addition, scalable and widely accepted standardized solutions for authenticated access and secured transactions, along with secure execution of different applications on smart cards, have to be considered. Last but not least, the role of the insurance card must be clearly identified and this will be discussed in the following sections.

Smart card:
A smartcard is a plastic card containing a small chip that includes a microprocessor and memory. The same size as a credit card, it has gold contacts that allow other devices to communicate with the card. It can contain more data than a magnetic strip and can be programmed to reveal only the relevant information. Encryption techniques secure the data, and the processor allows it to be programmed for different applications.

Physical structure of smart card:
The physical structure of a smart card is specified by the International Standards Organisation (ISO) 7810, 7816/1 and 7816/2. Generally it is made up of three elements. The plastic card is the most basic one and has the dimensions of 85.60mm x 53.98mm x 0.80mm. A printed circuit and an integrated circuit chip are embedded on the card. Figure 1 shows an overview of the physical structure of a smart card.

Figure 1: Physical structure of a smart card


The printed circuit conforms to ISO standard 7816/3 which provides five connection points for power and data. The printed circuit protects the circuit chip from mechanical stress and static electricity. Communication with the chip is accomplished through contacts that overlay the printed circuit. The capability of a smart card is defined by its integrated circuit chip. Typically, an integrated circuit chip consists of a microprocessor, read only memory (ROM), nonstatic random access memory (RAM) and electrically erasable programmable read only memory (EEPROM) which will retain its state when the power is removed.

Health Insurance Card System: current status
The Health Insurance Card System uses two types of smart cards:

 Health Insurance Card
The insurance card serves for identification and as a crypto device medium for carrying administrative data. It will gradually replace the conventional health-care booklet to eliminate extensive administrative procedures. The card stores insured persons' details, contribution obligor's data, data concerning compulsory and voluntary health insurance, and data on selected personal physicians and organ donation. Introduction of electronic prescription is currently taking place. Other applications (electronic order for technical aids, documentation of issued drugs, medical record pointers, and G7 emergency data set) will be achieved in not more than five years.

 Health Professional Card
The professional card is introduced to ensure access rights for accessing identification data on the insurance card and, in the future, various remote databases. It contains the cardholders' identification number, serial number, cardholder's first name and surname, profession, specialization, country code, Institute of Public Health number, and type of authorization. If a cardholder is not a physician, the professional card also contains the country code of the authorized legal entity, Institute of Public Health number of the authorized legal entity, and its title.

Infrastructure of Health Insurance Card System:
Currently the infrastructure of the health insurance card system consists of two subsystems.


The first subsystem is a network of self-service terminals, where insurance data can be updated, using the insurance card. Self-service terminals are connected to two central databases at the HIIS and the Adriatic insurance company. This communication is done through a secure communication channel that is based on a proprietary solution. The second subsystem consists of personal computers (PCs) at doctors' offices, where insurance cards are used after the process of mutual authentication with the professional card. The doctors' PCs use standalone proprietary applications without a real-time remote communication.

Drawbacks of the current system
Support of public key technology and infrastructure
One of the main problems is the use of symmetric cryptography-based smart cards that affect a large part of the whole system architecture. The most likely transition scenario includes web servers as front-ends to database management systems, while on the other side, web browsers will serve as front-ends to smart cards. Secure channels between web browsers and servers could be established this way, which is, however, not an ideal solution. End-to-end secure channels are the final goal in order to ensure security from smart cards to peer entities over the network. This requires smart-card technology capable of X.509 certificate and Secures Socket Layer (SSL) operations. Currently, this is not economically feasible, but will change in the near future. Support of public-key operations is also needed for deployment of IPv6, the latter being choice at the level of transport protocols. However, network providers are not able to offer this service and a nationwide public key infrastructure does not yet exist. Another problem involves professional-card-based access rights that are realized with symmetric group keys. In order to preserve the rest of the architecture of the information system and to support backward traceability of data, we are investigating the following scenario:  Every professional card has a unique chip serial number with a clear and evident link to a card serial number. Thus each item of data in the information system can have an associated unique attribute.  Software in the system has to support this attribute, invoking appropriate modification of database records.



The symmetric cryptography-based professional card has to be replaced with an asymmetric professional card and X.509v3 certificate, where the chip serial number can be included in the extensions of a certificate. The overall security of the current system relies heavily on keeping symmetric group

keys secret. These keys are stored and used only by smart cards and never leave the cards. The decision to share the same key among many cards was based on the assumption that smart cards can provide a high level of protection against seizure of key material, which is discussed in the next subsection.

Smart card security:
It is unrealistic to assume that information stored in a smart card can be protected from a capable motivated opponent backed up with significant funding. Furthermore, low-cost, noninvasive attacks are possible using differential power analysis. This method is based on measurements of a circuit's power consumption. In addition to large-scale power variations due to instruction sequence, there are effects relating to the data values being manipulated. When an encryption algorithm is publicly known, a relatively small number of power consumption traces are needed to test possible key candidates. A similar approach may be used with electromagnetic radiation traces. Although techniques exist for preventing differential power analysis and related attacks, new methods of successful attack are possible in the future. Reducing the number of cards that share the same key can significantly reduce the damage caused by a successful attack. As each insurance card may interact with each professional card, the number of different key pairs is high. Increasing the number of different key pairs in the system soon reaches the limit posed by the size of available memory on the card. Public key cryptography, in which each card has its own private key, minimizes the damage caused by revealing key material.

User authentication:
Owning a valid insurance card authenticates a user, while authenticity of a card is verified through cryptographic algorithms. To support better authentication, PIN (personal identification number)-enabled cards are being considered. However, the PIN is easy to forget, especially by older people. There is also a problem with organ donors. More promising methods for user authentication are based on human biometry. Several approaches are being developed,


e.g., fingerprint sensor, face recognition, hand geometry, and retinal scans. The technology is improving very fast and error rates are becoming acceptable. Currently, the false rejection rate is typically below 0.1%, while the false acceptance rate is below 0.001%. An interesting interim approach exists, which would partially solve the problem of card forgery. The more medically relevant data are on the card, the less the likelihood of its misuse. As these data are the basis for treatment, getting a wrong blood group, for example, could be fatal.

Specification of EDI and interactions for the health-care sector
In an open environment, where various entities from different administrative domains (e.g., hospitals, pharmacies, and insurance companies) exchange data, support of EDI is mandatory. However, there are only some particular specifications that could be used in a medical sector, such as a physician letter (HL7), hospital-to-hospital documentation (EDIfact), etc. Many of them are intended for other business sectors. Therefore costly converters are needed, which poses problems for true interoperability. To make things worse, there are some basic data sets, like electronic patient records, that have yet to be standardized. For the successful introduction of EDI, data sets have to be defined and they have to be stable. Appropriate documents should be defined along with transactions, that is, the sequence of steps and corresponding documents that are exchanged. Thus complete EDI support requires a set of protocols for conducting highly structured exchanges of data between different organizations. There is currently a notable lack of such specifications in the health-care sector. It should be noted that basic documents in the field of smart cards and their interoperability are already three to four years old. In the meantime, web technology has become an obvious choice for conducting e-business. Therefore the above-mentioned documents need to be revised to take into account widely accepted technological changes. Web technology is the most widespread and efficient technology that supports on-line transactions and it should be considered seriously.

General architecture :
The starting point is a transition to public-key-based architecture. Also for this reason, web technology will become the basis for the insurance card project. It will present transport means for complete document transactions, especially as many necessary security features are 6

provided by default through SSL layer. The most common architecture for a smart-card-based information system is shown in figure 2(a). Transactions are based on exchange of small chunks instead of complete documents. Such a system could be described as DBMS (Data Base Management System), a transactions-oriented rather than an EDI-oriented one, which is also the case with the insurance card project. The required architecture is given in figure 2(b).

Figure(2) : A Common model of Interoperable Architecture of a Smart-Card-Based Information System(left) and a Web Centric Smart-Card-Based Information System

Another notable difference between the two models is their support of real time transactions. The first one significantly relies on e-mail; it is therefore an off-line system with additional requirements for infrastructure. The second one is an on-line system with "all in a box" solutions.

Open Card Framework, PC/SC, and the insurance card system
The environment where smart card-enabled application will be executed should not limit developers. The same holds true for smart cards and card terminals. We have an architecture (see figure 3) for a typical client in the insurance card system. It is based on the Open Card Framework (OCF) specification that embeds personal computer/smart card (PC/SC) specification. These are two industrial initiatives for integrating smart cards into computer systems. Microsoft and several other companies introduced PC/SC to enable PC applications to exploit smart cards for security and e-commerce-related applications, but it does not support non-


Win32-based systems. Therefore other providers, including Gemplus and Schlumberger, recognized the need for a common framework to support smart cards on other platforms. This has resulted in the OCF specification, which addressed in particular the independence of the host operating system and transparent support of different multi-application cards and management schemes. It is especially important for the insurance card project that the OCF specification supports card readers with multiple slots. Such readers are needed in health-care applications, where a master smart card has to be present in the same reader to unlock the use of the second card belonging to a patient.

Figure 3: Client architecture Several of the above stated objectives regarding the insurance card system are met by OCF. The OCF is independent of the underlying operating system because it is implemented in JAVA. All OCF components written in JAVA become immediately available on any JAVAenabled platform, be it a client at the doctor's office, a database server, or a self-service terminal. The interoperability of the smart card solutions and the independence of the system from specific card issuer and card reader vendor can be achieved. In addition, a transparent support of different multi-application cards can be achieved, something which will be required in a future health-care information system.

JAVA card considerations
JAVA card provides the solution to the above-mentioned problems. Currently, card applets should not require extensive processing. Therefore an efficient SSL-like end-to-end protocol between the card and a remote server is not possible. Such implementation would 8

require an additional cryptographic processor. Some manufacturers offer JAVA cards with crypto processor, but export laws prohibit their global use. The need for a cryptographic processor is evident also from the performance measures that was carried out on the Cyber flex JAVA card in some companies. Some significant limitations of the JAVA card environment are:     the size of RAM is too small and it can be accessed only through local variables, time-consuming applets require periodic communication with the card reader in order to reset work waiting time, EEPROM has a limited number of writes which can be a problem for computations with many loops, and No garbage collection is supported by the JAVA virtual machine. The current processing requirements for the insurance card and the professional card are low as the cards perform only authentication and file system access. This will not be the case in the future. Other applications, such as storing digital prescription, establishing an end-to-end secure channel, and authenticating the user with biometry techniques, will make higher demands. When current cards will be redeemed, JAVA card will be most likely deployed

Basic requirements:
Basic requirements, as discussed in this paper are:    a full deployment of public key technology; a further transition from a DBMS transaction-based system to a real EDI environment, where this transition should be based on widely available web technology; Integration of the OCF into the insurance card system architecture as its benefits make it superior to the current "easy to deploy" solution. Regarding the first requirement, things are more or less obvious. Regarding the second bullet, a complete and comprehensive EDI set of health-care-sector-related specifications, suitable for the web environment, is needed. Regarding the third requirement, the design of future insurance card system will be based on JAVA cards, but its system capabilities have to be improved. And finally, the role of smart cards can be clearly identified: they will serve for authentication, for storage of minimal data sets, and as pointers to appropriate data sets in a network.


Scope for Future Improvement:
  More efficient techniques and algorithms can be designed in this smart card based technologies. Integrating the biometric method of identification in the smart cards can be implemented in some innovative ways.

The health insurance card System is on the point of full-scale deployment. Together with networking activities it provides an infrastructure that will support further development of the national health-care information system. We expect to achieve significant benefits with the employment of web and JAVA Card technologies. The development of the health-care information system is an ongoing intensive process, and at present, it is undergoing renovation, which provides a good opportunity for introducing advanced solutions.


1.ZZZS, Technical Specification of the Health Professional Card and Health Insurance Card, version 1.0, 30 July 1997. 2.ZZZS, System Protection of Communication between Health Insurance Card and Selfservice Terminals, The first phase report, January 1998 (confidential). 3.C. Adams, S. Farrell, Internet X.509 Public Key Infrastructure Certificate Management Protocols, IETF, March 1999. 4.M. Kaiserswerth, The OpenCard Framework and PC/SC, IBM, March 1998. 5. ISO, Electronic data interchange for administration, commerce and transport (EDIFACT), 9735, parts 1 through 8, Geneva, 1998. 6. D. Markwell, editor, Healthcards Interoperability of Healthcard Systems, G7 Interoperability Specification, G7 GII SP6, 1996.


To top