The Open platform standard has been defined by Visa in order to create multi application chip card systems.
Indeed, the adoption of the chip cards on a mass scale has been slow to develop, due to the lack of compatibility among the different vendor implementations of chip cards.
The open platform standard includes card and terminal specifications, as well as all development tools needed. These components define a smart card platform upon which standardized applications can be added.
The Open Platform permits working with different cards and operating systems.
10.1.2.1.1 Open platform card specification
In order to understand all the technical aspects related to the personalization of open platform cards, it is important to present the architecture of the card, all its components and the set of instructions and concepts available for these entities.
10.1.2.1.1.1 Card Architecture
The Open Platform card architecture can be seen as a set of components ensuring hardware and vendor-neutral interfaces to applications and off-card management systems.
All the applications on an OP card can coexist in a secure runtime environment. The other components are the card manager, which is the administrator of the OP card, the security domains and the open platform API.
Runtime environment and hardware neutral API Card Manager Provider Security Domain Provider Security Domain Open Platform API
Provider Application
Provider Application
The runtime environment of an OP card is not only responsible for providing the different applications with a hardware neutral API but also for ensuring the security aspects. Thus, the storage and the execution space for each application remain separate so that the data and the code cannot be corrupted.
Open platform Application Programming Interface
This API provides some applications access to services used for the management of the card.
The current examples of the implementation of the OP API are based on Java Card [JC]. It is however important to say that there are two other leading technologies in applications development which are Windows for smart cards and Multos.
Applications
The applications are software components present on the card to perform various functions. These components can coexist in a multi-applications environment and could be classified in two types:
o Applications present in the “immutable” persistent memory. These components can only be disabled but not altered.
o Applications present in the “mutable” persistent memory. They can be loaded, installed or even removed at any stage of the card life cycle.
Card Manager
The card manager is one of the most important administrative components of an open platform card. It can also be seen as an on-card application performing a set of administrative commands.
The functions of the card manager could be described as follows: o Command dispatch
Selection of a specific application and commands dispatch to this selected component.
o Content Management
Verification, loading, installation and removal o Security management
Locking and termination processes, privilege management and event logging.
o Secure communication support
Provided for applications during personalization and runtime.
The card manager is also considered as the on card representative of the card issuer (by containing his specific security keys)
Security domains
The security domain concept has been defined in order to allow application providers to use their own cryptographic keys. The security domain is a kind of privileged security application representing the application provider on the card.
Security domains can also have three additional privileges: o Mandated DAP (Data Authentication Pattern)
The security domain is in this case “always” used to verify integrity during the loading process.
o DAP verification
Allow an application provider to own a security domain used to verify the integrity of the application during the loading process.
o Delegated Management
This privilege can be used for delegated loading, installation and deletion.
10.1.2.1.1.2 Security aspects of the OP Cards
Security Architecture
One of the important security aspects of open platform cards was implicitly presented in the previous section. Indeed, the runtime environment properties and the security domain concept ensure the memory and execution separation on one hand, and the ownership privilege on the other hand.
The open platform cards also support many cryptographic functions based on symmetric (such as the Data Encryption Standard algorithm) and asymmetric (such as the Rivest/Shamir/Adelman algorithm) concepts.
These functions are used for instance to compute cryptograms or signatures involved in integrity check.
A “secure channel” concept is provided by the OP card in order to ensure an authenticated, authorized and confidential information exchange between an on card application and an off card host.
The mutual authentication is achieved by checking that the card and the host have knowledge of the same secret keys. Encrypting the APDU command sent to the card performs the confidentiality. The integrity of the APDU is reached by the sender computing a Message Authentication Code (MAC). Finally, the integrity of the “sequence” of commands sent to the card is achieved by an algorithm chaining (typically DES in CBC mode) of the calculation of the different MACs.
Host Application Card Application
Secure Channel Secure Channel
Key Sets
Key Sets
Clear Data Clear Data
Figure 26: Secure Messaging Overview
10.1.2.1.2 APDU Commands APDU Concept
The “Application Protocol Data Unit” is the commands-protocol defined under ISO7816 and used at a low level to communicate with the card.
Figure 18: APDU command protocol
Open Platform APDU Commands
o DELETE command
The command is used either to ask the card manager or the security domain (with the appropriate privilege) to physically or logically delete a uniquely identifiable object (the “logical” deletion is for instance necessary for applications present in the immutable persistent memory).
o GET DATA command
This command is used in order to retrieve a specific data object from the card. o GET STATUS command
The GET STATUS command is performed when the “status” of an on-card entity is needed.
o INSTALL command
This command is used in order to install a specific application or a security domain on the card. There are three types of install requests: The first is used to make an application “selectable”, the second to notify about an upcoming loading process and the third to really install the application on the card.
o LOAD command
The “LOAD” command is performed in order to load the byte-codes of the Load File inside the card. This mechanism is done for a single block at a time. o PUT KEY command
The command is used in three cases
o One or multiple keys have to be changed in an existing key set version.
o The existing key set version has to be replaced. o A new key set is added.
o SELECT command
Selecting a specific application is important in order to access its services. o SET STATUS command
This command can be seen as the complementary command of “GET STATUS”. In this case the status of a specific entity is changed on the card. o INITIALIZE UPDATE command
This is the initialisation command of the secure channel. It is used to transmit card and session data between the card and the server.
o EXTERNAL AUTHENTICATE command
The command is used in order to ensure the authentication of the host by the card, to establish the secure channel and to determine the security level required within this channel.