D3.2: A study on PKI and biometrics

Title: CASE STUDY: MOBILE SIGNATURES

Mobile signatures are electronic signatures that are created using a mobile device and rely on signature or certification services in a location independent telecommunication environment. They allow signatory mobility beyond fixed, secure desktop workstation with trusted, personal signing equipment [FRR03]. Although using mobile devices for signature creation has several shortcomings (e.g. display size, communication costs, limited computing power), the high market penetration of cell phones and the mobility gained make this effort potentially successful and promising.

Two possible signing approaches in the mobile environment have been proposed in the past: signatures created in centralised signing server environments located at service providers such as mobile network carriers; and electronic signatures created inside the signer’s mobile device using a smart card.

Server Based Electronic Signatures

Server based electronic signatures are signatures created by a service provider for a specific customer. illustrates such a server infrastructure. With server based signatures it is important to distinguish between signatures that have a corresponding certificate issued under the name of the customer and signatures with certificates issued under the name of the service provider or an employee of this provider.

In the first case it is necessary that the customer transfer his private key to the service provider. However, according to the related EU directive, to achieve the status of an advanced signature the signature has to be created by means that the signatory can maintain under his sole control. By giving away his private key this premise cannot be fulfilled [FRR03]. In the case of signatures whose certificates are issued under the name of the service provider it cannot be assumed that these signatures are the legal signatures of the customer.

They are signatures of the signature service provider and only enable an identification of the provider. Those signatures can achieve the status of advanced signatures with qualified certificates as long as they fulfil the requirements of Annex I and are provided by certification service provider who fulfils the requirements of Annex II. Therefore, the signature service provider acts as a replacement for the customer. However, based solely on the signature of the provider it cannot be verified that the customer really authorised the signature. Neither the integrity nor the fact that the user authorised it can be proven. There are possible technical solutions to accomplish the integrity and accountability of his authorisation but they require a security environment on mobile devices that would enable the device itself to create qualified signatures [RAN03].

Figure 3‑: Sever based electronic signature infrastructure

Client Based Electronic Signatures

Signatures can be created inside the mobile device using a secure signature creation device which has to fulfil the requirements of Annex III. Using a multiple smart card solution, the signature smart card, certified by a certification provider, is inserted into the mobile device which already contains the usual SIM-card. Therefore, the signature process takes place on the mobile device and the user is essentially able to use any signature card available on the market. This can be achieved by either exchanging the SIM-card with the signature card (Dual Chip) or by having an additional chip card reader within the mobile device (Dual Slot). The first solution is very inconvenient for the signatory, since he has to switch off the phone to exchange the cards for the signature creation and again to use the phone functionality. In the latter case, a specialised mobile phone is required that has multiple smart card slots which almost none of the current mobile phones do.

It would also be possible to use a single smart card that contains the SIM telephone functions, as well as the secure signature creation device. This can be achieved either by leaving some free space on the SIM-card, on which the components of the signature creation device can be installed later on, or by shipping SIM-cards with pre-installed signature functionality that has to be initialised and activated.

One proposal is the usage of evaluated smart cards suitable for qualified electronic signatures which are extended by the SIM functionality and usable through a unified interface, e.g. with the USIM specification TS 21.111. Another approach might be the migration and evaluation of USIM with a full WAP/WIM implementation for the purpose of lawful mobile signing. Evaluation must be carried out with ITSEC or Common Criteria within an evaluation process similar to the evaluation summarised in [FUC00].

Using a single smart card for both functionalities provides the most convenient solution for the signatory. He can sign documents and distribute them via communication services of his cell phone like GPRS or UMTS. To ensure that the requirements of directive are met, it is necessary to provide some sort of reliable access control to the signature functions. The usual PIN used to control the access to the telephone functions is not sufficient, since users can keep their phones and SIMs unlocked for convenience. Like traditional signature cards, SIM-cards can be certified according to security evaluation criteria and are under control of the user.

However, using a single smart card for multiple purposes raises new questions and challenges. The SIM-card is issued by the telecommunication provider, while the SSCD is issued by a certification service provider. Combining both functions in one card raises the question of who will have control over the keys and certificates. 

The simple solution is that the deploying service provider also initialises the signature secrets to act as a trust provider for their customers. At first glance this seems reasonable, since some of the European carriers already own and maintain trust centres (i.e. Deutsche Telekom), but there are several shortcomings, which make this approach impractical. First of all the customer wants to leave the store with his SIM-card right away, so he can use his mobile phone instead of waiting several weeks for the certification process to be completed. Furthermore, binding the keys to a carrier creates a great hindrance for the customer if in the future he chooses to switch to a cheaper carrier. From the carrier’s point of view this would of course be advantageous. From the customer’s perspective, however, it would be much better to be able to choose freely between different certification service providers. Also, owing to the lack of success of the signature market so far [LiRo05] most providers will probably be reluctant to invest in building and maintaining their own trust centre to provide certification services. Simply, they do not want to change their distribution channels unless they expect an increase in revenue. Therefore, a different solution for mobile signing and certification is needed, that allows separation of subscriber information and certification services [ROS04].

Certification on Demand

The mobile operator could sell SIM-cards equipped with a key generator for one or more key pair(s) that can be used for the signing functionality. After obtaining the SIM-card from the mobile operator, the customer can then generate the keys and activate the signature component and the public key(s) can be certified by any Certification Service Provider on demand.

Through the separation of the telephone functionality and the (possibly later) certification of the user’s identity by a certification service provider, both functions can be sold separately and can be obtained from different providers. The carrier will probably face increased costs for the signature capable SIM-card but can also expect increasing traffic caused by signature services. All distribution channels will remain unchanged. illustrates the necessary steps for the distribution of the SIM-card and the certification process.

Figure 3‑: Certification on Demand Protocol

1. The carrier gives his IMSI/Ki pairs to a card manufacturer.

2. The card manufacturer returns a SIM card containing an IMSI/Ki pair, a key generator for the signature application and the public key of the RootCA to the carrier. 

3. The SIM card is sold to the customer and the carrier provides a null pin that is used to generate the keys and activate the signing functionality. 

4. The customer generates the keys and activates the signing functionality by entering the null pin.  

5. The customer registers at a Registration Authority of his choice, providing identification information and his public key. 

6. The customer sends his identification information signed with his private key over the air to the Certification Authority.  

7. The Registration Authority sends the public key and the identification information to the Certification Authority. 

8. If the information provided by the customer and the Registration Authority match, the Certification Authority issues a certificate for the customer and sends it over the air to his mobile phone. 

9. The user can verify the validity of his certificate by checking the certificate issued by the RootCA of the Certification Service Provider (CSP). 

This protocol makes no changes to the existing distribution infrastructure of mobile operators. The steps 1 to 3 remain the same way they used to be, apart from the fact that the card manufactures puts additional information and functionality (signature key generator, public key of RootCA) on the SIM card. In order to ensure that the card manufacturer does not know the private key of the user the key generation should be done by the card. The customer is not forced to certify his keys and can use the SIM for telephone functionality only. He could also activate the signing functionality without going through the certification process, for example as a security token. If he wants to be able to make legal binding electronic signatures, he has to go through the complete process to obtain a qualified certificate. He can do this by freely choosing the CSP.  

The null pin to generate the keys and activate the signing functionality in step 4 is used to ensure that no signatures can be created before the customer has control over the SIM card. If the signature application has been activated before, the user will recognise this when entering the null pin. Step 6 could be omitted but serves as insurance for the customer to ensure that the integrity of his identification information will be preserved. If the customer wants to change his CSP, he only has to repeat steps 5 to 9 with his new CSP. If the customer wants to change his carrier, he has to go through the whole protocol again, but can register with his current Certification Service Provider [ROS04].  

Special Aspects of Mobile Signatures

Mobile signatures are made with mobile devices and therefore constraints have to be addressed that are not present in traditional signing infrastructures. 

Implementation and security of mobile electronic signatures

A mobile signature creation system is composed of two elements: The signature creation application itself on the mobile device and the cryptographic module on the UICC/SIM card. A generic architecture of mobile signature system is shown on . The cryptographic engine performs the real signature calculation after a successful user authentication.

Figure 3‑: Mobile signature system architecture

In case of using a UICC/SIM card as secure signature creation device, the security of the mobile device components should be guaranteed as well. Communication paths between application modules are especially vulnerable. Some possible attacks on the signature application are presented in .

The mobile signature application fulfils the following functions: 

• input and formatting of data to be signed  

• user identification and authentication 

• hash value calculation 

• signature attribute visualisation (optional) 

• cryptographic engine interface 

Trusted dialogs (“What You See Is What You Sign”) and ensuring the integrity of temporal data are the most essential problems of the signature application security. Mobile device execution environments when selected as implementation platform for signature application should provide the following features: 

• user identification mechanism 

• memory separation between processes 

• software and data integrity proof 

• trusted user interface: exclusive use of display and keyboard  

Figure 3‑: Security-critical operation in the signature application flow

The majority of today’s mobile devices do not conform to these requirements. Mobile operation systems sharing the mobile market provide minimum security only. Some new solutions, for example, from the Linux community or new platform security additions in Symbian OS v9.1 advance mobile devices in the direction to be personal trustworthy devices.

Data Transfer

First of all, any traffic that is necessary will be charged to the customer. Therefore, it is essential to create as little data traffic as possible in order that the customer accepts the additional costs. In the case of the signature creation, traffic is only necessary for the download of the document to be signed, if at all. In the process of signature verification, several documents, especially the keys of all CAs involved have to be downloaded in order to ensure the integrity of the verification process. 

Revocation lists are a particular concern that have to be dealt with. In order to be up to date with the latest revocation lists the customer has to be “online” to get access to the current status of all the signatures and certificates involved. This could lead to lots of data being transferred and much additional cost. Standards such as ISIS-MailTrusT can be useful as well as concepts of server-centric support in document verification [FRI02].

It would also be possible for the CSP to sponsor the additional data traffic in order to get customers to accept and use mobile signatures.  

Storage

Mobile devices usually have a limited amount of storage space. This is even more critical if one has to store the data on the SIM-card itself. Therefore, the mobile signature application should, whenever possible, try to store the necessary information on a server of the service provider. This of course is in contrast to the goal of minimising the necessary traffic for signature applications. Therefore, a trade-off has to be struck between cached information and information to be transferred. This is particularly important for the storage of root certificates, certification chains and certificate revocation lists for offline verification. This problem might be solved by increasing storage space on mobile devices and by the ability of modern devices to use external storage such as SDCards. 

Enabling Security Infrastructures

There is a need for corporations to provide their mobile workforce with secure access to the corporate ‘back end’. To date, security tokens have been used to allow this functionality. These tokens are expensive and stored on extra hardware that needs to be carried around and can easily be lost. Putting these credentials on a SIM, that will be placed in the mobile phone, reduces the risk of losing the credential as well as lowering the costs. But some corporations greatly object to leaving their private keys and certificates in the hands of their mobile operator.

With Certification on Demand (COD) the corporation’s IT security department can obtain COD-enabled SIMs from the corporation’s cellular contractor and initialise them for the corporate mobile security infrastructure. The WiTness project sponsored by the European Union implemented such an infrastructure. shows an application scenario where a “pervasive salesman” has secure, corporate-controlled access to all data available to him in the corporate information system. Access is controlled by a security module based on a SIM with additional security functionality [ROS05].

Figure 3‑: WiTness Pervasive Salesman Scenario

Multilateral secure financial transactions

Storing bank credentials on a SIM may help the migration from plastic to mobile phones. A COD infrastructure allows financial institutions to certify and enable mobile subscribers to use banking services online through their mobile terminal and SIM. Credentials could be certified by the bank itself, like the credentials used on bank cards. Therefore, the bank can still have the control over the credentials while the mobile operator still can issue the SIM cards without giving their IMSI/Ki pairs away to the bank. This would enable the bank, on the basis of the credentials stored in the SIM, to offer services such as transactions, brokerage or checking the account balance. This functionality can and has been realised without the Certification on Demand protocol - but only if the banks and carriers are willing to cooperate. In the Czech Republic T-Mobile [T-Mo05] and the Czech banks agreed to send their critical information to Giesecke & Devrient, a card manufacturer who started producing banking enabled SIMs [G&D05]. However, the COD protocol would enable banks to use SIMs as credentials without having a contract with the mobile operator. In [MUN05] it has been shown that usage of such an infrastructure could be beneficial for mobile brokerage customers, empowering them to react more quickly and more securely to incoming ad hoc messages.

Enabling mobile electronic consent and identity management

Many mobility applications rely on the user’s consent in reducing his privacy in return for a particular service. Examples are location based services on cellular networks, situation based marketing scenarios and tracking technology following users to support them with information they need in-time and in-place. A secure provable electronic consent of users can be achieved using electronic signatures on SIM-created credentials that may contain information about time, intent and recipient of the electronic consent. Research has found SIMs to be on the edge of a global identity management infrastructure [RAN04]. In the near future, personal or role attributes customised for particular application areas (e.g. online dating, identity management) could be managed on SIMs on demand from their owners [ROS05].