A mobile phone has a limited amount of screen space available to display a message. It should therefore be considered to be used for signing in one of three ways:
• As a Class 1DM, where the message is small enough to be presented on the phone’s display. In this case, the complete SCA, including SDP and DHC, reside in the SIM together with the SSCD.
• As a Class 2DM, where the message is small enough to be presented on the phone’s display. However, in this case, the SDP and DHC reside in the Mobile Equipment and the SSCD in the SIM.
• As a Class 2DH system, where the message is too large to be presented on the phone, and therefore only a hash value is presented and signed.
9.1.1 Displaying the complete message on the phone
The message to be signed is sent to the mobile phone, using the WMLScript signText command or a similar function. The mobile phone presents the message on the screen, hashes the message and signs it using the private key stored in the mobile phone.
In this case, there are actually two ways of implementing the SCA:
• SCA in ME – In this case, the SCA resides in the Mobile Equipment, and just transmits the hash value to the SIM card, which needs to establish a trusted channel with the SCA to receive the DTBSR, and to transmit back the SDO (Signed Data Object). It also needs a trusted channel for the input of authentication data from the keypad of the ME.
• SCA in SIM itself – In this case, the SCA resides in the SIM together with the SSCD, thus sharing the computing engine of the SIM. Through the phone’s SIM Toolkit API, the SCA only uses the phone’s display as SDP (viewer) and keypad as input device for authentication data (PIN). The SIM card would in this case actually implement a type 1DM System.
9.1.2 Displaying only a hash value on the phone
The message to be signed is too large to be presented on the screen of the ME. The message is instead presented for example in a Web-browser residing on a PC. The signing application then hashes the message, and sends the hash to the phone for signing. In order to ensure that the hash value has not been tampered with in transit, a part of the hash value is presented as a hexadecimal string both in the
browser/viewer and on the screen of the phone.
When only a hash value is sent to the phone for signing, the SCA actually consists of two parts: one in the mobile phone and one in the remote terminal, containing the SDP as well as DHC. Together, the two parts of the SCA have to ensure the integrity of the DTBSR (hash value) sent from the remote terminal to the phone.
This can be done by comparing the hash values presented in both parts of the SCA, thus letting the user verify their correctness.
9.2 SSCD platform functions
9.2.1 Personalisation
Personalisation encompasses SCD/SVD Generation and SCD import or SVD export as necessary.
There are two possibilities for performing key generation:
• Key generation performed outside the card. This means that the SSCD will be a Type 2 device according to [SSCD PP], with a requirement for a Trusted Channel for SCD import. In this case, key generation will usually be performed by the manufacturer of the SIM card, or by the mobile operator. The SIM will then be delivered to the user with pre-generated keys.
• Key generation in the smart card itself, “on-board key generation”. A SIM card with on-board key
generation would constitute an SSCD Type 3 device according to [SSCD PP]. Key generation can then either be initiated by the manufacturer, the operator or the user himself after receiving the SIM.
The second step of personalisation is the Certificate Generation, which has been addressed in section 7.1.3.
9.2.2 User authentication
The mobile phone provides an excellent mechanism to obtain user intention. The screen and input (keypad) are connected and protected from interference. It is very easy to have the user enter a sequence of numbers that are displayed on the screen to verify intention rather than just clicking with a mouse or selecting a single button.
User authentication encompasses input of the Signatory's verification authentication data (SVAD), i.e.
authentication data provided by the user for authentication as signatory. For the mobile phone, this means a numeric PIN code entered by the user on the mobile phone’s keypad. It is recommended that the PIN code is not displayed in clear when typed. The SSCD must thus provide support for a trusted path to the PIN keypad.
However, in contrast with the ordinary PIN for the SIM card, the user authentication for the signature function must be entered for each signature operation.
After a pre-defined number of erroneous attempts, the SIM card will be blocked. It can then only be unblocked by entering a PIN Unblocking Key (PUK).
9.2.3 Trusted channels and trusted path
The following trusted channels and paths can be foreseen for the mobile phone platform:
• A trusted channel is required for SCD import to the SSCD from the SSCD Type 1, when key generation is performed outside the SIM card
• A trusted channel is required for SVD export from the SSCD to the CGA, when key generation is performed in the SIM card
• A trusted channel is required for DTBSR import to the SSCD from the SCA. This is of course most easily achieved in a Class 1 System, when both the SSCD and the SCA reside in the SIM card. When the SCA resides in the Mobile Equipment, the requirements for the trusted channel depend heavily on the operating system of the ME.
• A trusted path is required for the user’s input of the authentication data (PIN) from the keypad of the phone to the SSCD.
9.3 SSCD environment
In all use cases above, the SSCD is implemented in the SIM card. The mobile phone comprises the
"immediate environment", with screen, keypad and SCA (except where the SCA is implemented in the SIM together with the SSCD).
As long as the user employs his own mobile phone, he will regard this as a trusted environment.
However, if he at some point in time decides to put his SIM card in a different mobile phone, he may want to ensure that this new mobile phone can be trusted, and not is a manipulated mobile phone, compromising the signing function.
10 Implementation guidelines for PDA
The Personal Digital Assistant (PDA) has rapidly become a personal tool for everyone. With the advent of communication services for a PDA, there is a need for using the PDA as a signature creation system.
The PDA can be designed to be all classes of systems: 1DH, 1DM, 2DH and 2DM.