Global Platform March 3, 2009Posted by tcarlyle in global platform, SIM Cards.
Tags: global platform, key management, personalization, sim, smart cards
I said that I was going to post about context information, but since I’ve been reading about the Global Platform on the last days, I felt that I was better to post about it. Also because, the Global Platform standards are not the easiest ones to read and it would be nice if someone sees this post and comment any wrong interpretation I may have done or assure that what I’m writting is actually right =)
The GlobalPlatform is a cross-industry organization working towards the maintenance and promotion of multi-application smart cards standards. The organization encompass members around 50 from several different industries such as financial institutions, telecommunication providers, smart card and terminal manufacturers, software developers, etc. [An overview of the GlobalPlatform smart card specification]
The relations between the GlobalPlatform and ETSI were initiated in 1999, to standardize the OTA application download and management, and theirs specifications became the de-facto standard for applet management in the java card platform. The standards covers not only the smart cards, but also the terminals and readers that interact with them.
Two of the main components of the Global Platform standards about the cards are the the Security Domains (which can be seen as special types of applications) and the Card Manager, which in the new version of the standards correspond to the Issuer Security Domain, the GlobalPlatform Environment (OPEN) and the Cardholder verification methods.
The card manager represents the card issuer and is the main responsible for the security in the card, since it is the entity that dispatches the APDUs and selects applications inside the card, perform secure memory management, controls the content management (installation, selection and removal of applications in the card) and it controls the card’s life cycle (which is stored in the card Registry).
In the other hand, the security domain represents a secured region under the control of the security domain owner (either the card Issuer or an application provider) and isolated from the other domains. Only the issuer security domain (which is in control of the telecom operator in the case of the SIM cards) can interfere on the others, and this interference is restricted to either the creation or removal of a domain (it can not modify a domain).
The security domains allow the domain owner to provide cryptographic services such as key handling, encryption, decryption, digital signature generation and verification, and those services can be shared with other applications, through mechanisms that depends on the implementation of the GlobalPlatform on the card system (for example shareable interfaces, Java RMI). It is also responsible for verifying the Load File Data Block Signature, Data Authentication Pattern (DAP), for load file operations under its security domain.
Each application is linked to a security domain and they can access the services of their domain to perform cryptographic functions and ensure confidentiality and integrity during personalization and runtime. The application is initially associated with the Security Domain which loads it, but it can be extradited to another security domain during the loading process or afterward.
Therefore, there are two approaches for the SIM card to host a secure application from a third party service provider.
In the first approach, the application could have its security domain created during the personalization phase of the card (before it leaves the factory) and have the domain keys created at that phase, so the initial keys would be only managed at the secure personalization site. Then, the master key (which generated each card key) can be managed only inside the HSM (Hardware Security Module) and without the disclosure of the key to the issuer. Due to the fact that the operator does not know the key values at any point, this option can be considered more secure for the content provider (that could be a bank for example), but once the keys have already been created, their value can be later updated, but their characteristics (size, algorithm used) cant be changed.
The second solution involves the creation of the service provider security domain via OTA, targeting the card manager and using the issuer domain to put a temporary key. Then the temporary master key is transferred to the Service Provider which can use it to update the card. This case leaves more flexibility, once the choices of defining the security domain are taken after the card has been issued (so it can also target the legacy cards already on the market). In the other hand, the service provider may not accept on having the telecom operator with the key information in the beginning of the process.
The main issue here is that the banks or very secure service providers have very high security requirements that unable to go for the last mentioned approach. And it is somehow complicated and may be even expensive to exchange master keys and personalize security domains for too many service providers in advance. Although the issuer can generate a few RFU master keys and card keys to be used afterwards, and, as long as the master keys are protected under a secure storage such as a HSM, the service provider could exchange the key later and take the advantage the user’s with cards that have already been personalized have his key.
It seems that in this new release of the GlobalPlatform Standard (the 2.2) the Card Content Management can be performed by relying exclusively on asymmetric cryptography and PKI. I’ll try to take a look into it.