WAP PKI

When discussing wireless PKI, it is also important to consider its implementation in WAP (Wireless Application Protocol). One of the leaders in WAP PKI is SmartTrust (http://www.smartrust.com), a company focused on infrastructure software for managing and securing mobile e-services. As its solution is one of the most powerful, we have included an overview of it here. This information is provided by Sten Lannerstr m, one of our contributing authors, and is included here with permission from SmartTrust.

WAP is a protocol suite capable of running on top of other protocols, even on top of TCP/IP (or maybe more realistically , above UDP/IP). WAP becomes useful in 3G ( next generation wireless) solutions, as some protocols within WAP are more suitable for a mobile device than traditional higher IP protocols. The mobility side, with low signal quality and re-sending, especially stresses the need for dedicated high-level protocols (for instance, WSP/WTP/UDP/IP instead of HTTP/TCP/IP).

WAP PKI Model

The WAP PKI Model is described in the WAP 2.0 specification. The current WAP PKI model embraces three basic certificate items:

• CA Public Key Certificates used for WTLS Class 2

• Client Public Key Certificates used for WTLS Class 3

• Client Public Key Certificates used with WMLScript SignText

There is a slight difference in the format of CA and WTLS (Wireless Transport Layer Security protocol) Server certificates compared to traditional X.509 certificates. Hence, in WAP, we need to distinguish between server and client certificates. In "traditional" PKI, this was not really an issue, but in WAP they differ in structure depending on location; that is, a client certificate versus a server certificate, so we should describe them separately.

• Server certificate ” The WAP Gateway certificate needs to be downloaded into the WAP client for server (gateway) authentication purposes. As computing capabilities in most WAP client devices are limited, the certificate format is slightly different from traditional X.509. The main problem area requiring processing capabilities is in handling ASN.1 parsing, which is required to interpret a standard X.509 certificate.

• Client certificate ” The WAP client needs certificates for two basic purposes:

  1. To be capable of handling client authentication for WTLS sessions (WTLS Class 3).

  2. To support WMLScript SignText, which involves digital signatures. WAP client certificates are X.509-based, and are basically identical to traditional certificates being used in the fixed Internet. Client certificate information (a certificate URL rather than the complete certificate) is defined to be stored in a WIM (WAP Identity Module). In traditional wired networks, it is common for the client to carry the complete certificate information locally. In contrast, WAP WTLS Class 2 can be handled without the use of client certificates, and thus without a WIM.

WTLS Class 2

WTLS Class 2 provides the capability for the client to authenticate the identity of the gateway with which it is communicating. The authentication mechanism is almost identical to traditional SSL (HTTPS) used with Web servers. However, the WTLS protocol is optimized for low-bandwidth bearer networks with relatively long latency.

WTLS Class 3

WTLS Class 3 adds client authentication through having the client respond to a challenge during the initial session negotiation. WTLS Class 3 requires access to a private key to sign the challenge message sent from the gateway server. The private key is stored within a tamperproof device ”the WIM. The traditional SIM necessary in GSM (Global System for Mobile Communication) networks is a suitable place for the WIM.

WMLScript SignText

When handling electronic transactions, there is often a requirement to involve more security than just authenticating the parties. Signing a transaction order, such as transferring money from your account to someone else's, typically requires some approval from your side (your signature). Functionality obtained through the WAP signText() method provides for standardized digital signatures on visible text-based content. The Crypto.signText function specifies a signed content format to be used to convey signed data both to and from WAP devices.

The WAP client browser identifies certain tags in the WMLScript and activates the Crypto.signText function. A call to the signText() method displays the exact text to be signed, and can further include user text input. Upon user confirmation, the text string is digitally signed using a signature key with a cryptographic algorithm based on either RSA or ECC.

The WAP browser should use a special signature key distinct from the WTLS authentication keys. A WIM might be used for private signature key storage and signature computation.

WAP Certificate Management

Certificate management procedures and functionality within WAP is not much different from certificate management in a traditional wired Internet PKI environment. The following list describes typical issues included in PKI certificate management:

• Certificates need an issuer, commonly the CA.

• The CA needs to provide a policy behind the certificates that the users understand and trust.

• All entities ( clients and servers) need to find and install the CA certificate in a trusted way.

• Entities that are the subject of a certificate need to provide accurate information and prove possession of the key to be certified.

• The CA needs to verify subject information prior to issuing a certificate; this applies to both server and client certificates.

• The private key needs to be securely created, of good quality, and protected from unauthorized use. This is the case for all involved parties.

• Servers need to obtain client certificates (if used) in some way, typically supplied by the client or retrieved from a directory.

• Clients need to obtain server certificates in some way typically supplied by the server or retrieved from a directory.

• When there is a need to break up the trust for a key or a certificate, it should be possible to revoke the certificate.

• When validating a certificate or a signature based on a certificate, it should be possible to check the status of the certificate in question.

• When a certificate expires on normal grounds (time), it should be possible to renew the certificate ”through rollover for example, as in the case of a CA certificate.

Limitations

In the issues listed in the preceding , there are minor differences in WAP as compared to traditional fixed PKI, the most obvious being the format of the server certificate as it is not compliant with X.509.

Much of the client environment support for PKI is taken care of by the browser tool, which in the case of WAP is the WAP client browser. If PKI is considered fairly immature in the traditional wired Internet, the case is unfortunately worse in the WAP environment. Wireless PKI (WPKI) requires a device with a WAP 2.0-compliant browser tool, examples of which are, sadly, difficult to find at the time of this writing.

The PKI model in WAP does not include status checking of server certificates, other than for expiration. WAP WTLS certificates are instead intended to be short lived ” perhaps less than 48 hours. As most client devices lack centralized control of system clocking, and furthermore have limited capabilities of handling time zones, this check will not be precise. However, it should be noted that although the fixed environment easily has the opportunity to include checking against a CRL (Certificate Revocation List) or through OCSP (Online Certificate Status Protocol), most fixed client applications do not check for more than expiration.

WAP Security Token

A basic requirement for a secure token is that it provide for both tamperproof storage of private keys and execution of the algorithm resulting in a digital signature. Preferably, the token should also be able to handle key generation internally and securely, and with good quality. Other information such as a client certificate or its URL can also be stored in the security token, should this be convenient , but it is not a requirement from a security perspective.

This security token is called a WIM, a name that resembles the Subscriber Identity Module (SIM) that is a central component within GSM, and which is named USIM in the coming 3G wide-area mobile generation. A device hosting a WIM can essentially do this in four different ways:

• In a combined SIM/WIM chip

• In separate SIM and WIM chips

• As a dual slot device for an easily-removable WIM

• A hardware component WIM effectively built into the device

Combined SIM/WIM Chip

The SIM and the WIM share the same physical chip as two different applications. The WIM requires that the smart card support cryptographic algorithm processing, making the cost of the chip higher compared to traditional SIM chips. Having two applications on the chip also requires more memory compared to a traditional SIM chip. Existing subscribers would need to swap into a new SIM. For practical reasons, the WIM basically needs to be pre-personalized ”that is, have its structure prepared at the time the card is created. Hence, the structure of both SIM and WIM has to be created at time of manufacturing. It is fully possible to have the Wireless Internet Browser (WIB) as an additional application on such a chip. A combined SIM and WIM would have a rather clear business model, with the operator being mainly responsible for deployment.

Most of today's devices would support this, as a one-slot configuration by far is the most common hardware configuration for existing devices. From a hardware perspective, this solution would hardly affect the device manufacturer at all. One additional major benefit is that a combined SIM and WIM overcomes one of the most severe limiting factors in PKI ”the need for smart card reader devices on the client side when using a secure token.

Separate SIM and WIM Chips

With separate slots for SIM and WIM inside the mobile device, both reside within individual smart card chips. The traditional SIM is not affected, and its cost and capabilities remain intact. Existing subscribers would not need to swap in a new SIM. The WIM is installed in a separate smart card chip meeting necessary cryptographic requirements. An alternative solution would be to use tamperproof hardware-key-ring tokens connected through USB, such as the iKey from Rainbow Technologies. They do not need to be pre-personalized at a common occasion, and their cost can easily be separated. Separate SIM and WIM would be beneficial in a business model where the mobile operator does not control WIMs. On the other hand, it might be difficult to find a suitable business model for WIM deployment. The final cost for a SIM and a WIM is, however, higher compared to a combined chip, should a mobile operator take care of WIM control.

Separate SIM and WIM chips would require an additional slot inside the mobile device or a USB connector on the outside, and this would affect cost for the device. Not many current handset devices have such a configuration, but an extra slot can potentially be supported through an add-on device, limiting the effect for device manufacturers.

Dual-Slot Device

The dual slot option possesses exactly the same benefits and drawbacks as the previously described separate SIM and WIM option (Table 15.1). The main difference with a dual-slot device is the intended mode of use. It is still two separate slots, but in this case, the intent is to have easily removable WIM. The WIM would typically be the size of a traditional credit card, and not the typical size of a SIM; a USB-connected token would also work in this scenario. However, it is questionable if this solution would be attractive and fit in the business model for an operator subsidizing handsets for its subscribers. A PKCS #15 formatted-WIM in standard format could potentially function as a traditional smart card security token, making it feasible to use it in the fixed Internet world with a traditional smart card reader.

Dual-slot devices are not common today, and the cost of producing them would be higher than any otherwise compatible single-slot device. An add-on device, as in the previous case, can potentially take care of dual slot support, limiting the cost for device manufacturers.

Hardware Component WIM

A hardware component inside the device would not, like the two previous cases, interfere with the SIM. Nevertheless, the WIM should be tamperproof, and that would place special requirements on the hardware component and its assembly. An additional hardware component would raise the cost of the device, though perhaps not as much as a second slot. One very basic issue with the WIM is that private keys stored inside the structure should always be impossible to copy. The digital signature key should never have a backup copy, nor should this be possible. With the WIM in a tamperproof chip, it is possible to move the WIM from one device into another, thus maintaining personal credentials and certificates.

For DRM purposes this is understandable, but from a personal identity angle, it is not suitable. Should you get a new device, you would need to repeat the process of getting certificates for your new keys. This process should not be too cumbersome, but it would still require some attention from the end user ”perhaps requiring a second physical visit to a registration center. Such tiny matters might prohibit the use of new devices, and the life cycle for end-user devices would be extended.

Table 15.1. Comparison of WIM Styles

WIM Style	Strength	Weakness
Combined	Existing hardware configuration in today's handsets	WIM pre-personalizes at the same time as the SIM
	Cost efficient	Requires SIM swap for existing subscriber
	Easy to deploy	SIM-centric
	Clear business model
Separate	Can deploy WIM separately	New type of devices
	Operator independence	Additional cost for hardware Complex deployment
Dual-Slot	Can deploy WIM separately	New type of devices
	WIM can be used in traditional reader environment	Additional cost for hardware
	Operator independence	Not in line with the business model of operator subsidizing devices Complex deployment
Hardware Component	Easy to deploy	Not in line with handset manufacturer business model?
	Cost efficient	Trust issues apply
		Complete certificate renewal when switching device Handset-centric

WAP Certificate Enrollment

A complete description of the standard requirements for WPKI can be found in the wireless specification WAP-217-WPKI-20010424-a. Certificate enrollment can be done in several different ways; of central importance is often the proof-of-possession process. Proof-of-possession involves having the subject requesting a certificate utilize the private key in the request creating digitally signed data. It is thereby possible to verify that the requesting subject was in possession of (that is, had access to) the key associated with the public key that was a part of the request.

In a wireless environment, this is something preferably handled remotely at a time suitable for the end user. Because current wireless devices have limited display and computing processing power, enrollment needs to be done slightly differently than with fixed Internet certificate enrollment.

Certificate Request

It is a common misunderstanding that the general approach of issuing certificate requests would be based on the principle of "what you see is what you sign." When discussing certificate enrollment based on standard approaches such as PKCS #10 requests , it is quite obvious that the end user does not actually see what is being signed. A PKCS #10 request contains an ASN.1-encoded structure of binary data not very suitable for the human eye (or mind). When it comes to certificate enrollment, it is far more important, from a human perspective, to understand "what is going on." This is acknowledged in the WAP WPKI standards, and the request is therefore adjusted to a user point of view. WAP standards recommend that some out-of- band (foreign) data be used in connection with certificate enrollment, and that the process is protected against replay attacks.

The user communicates through the mobile device with a PKI portal. The PKI portal might then restructure the information (other than the public key and subject identity, as it is core to the certificate request) and create a suitable request to a CA. The PKI portal in this respect takes the role of a registration authority (RA) issuing a certificate request based on any standard suitable to the CA in question.

Certificate Delivery

The WAP standard does not dictate how the result of a successfully issued certificate should be announced, and it does not dictate that the client obtain information on where the issued certificate is stored. In the simplest scenario, the user is notified that a certificate has been successfully issued. In this case, the WIM will not contain any details about the certificate other than the public key identity. Alternatives to this are to deliver a full X.509 certificate, or a pointer location (URL) to the actual location of the issued certificate. This requires the WIM to be capable of receiving an OTA (Over-the-Air) update with the relevant data. After this is done successfully, the user is informed about the status of the request.

WAP does not prohibit the process of storing predefined data within the WIM. Predefined data can be loaded at the time of pre-personalization. Such information could contain trusted CA certificates and predefined pointers to locations where client certificate(s) can be found. If the pre-personalization takes place before knowing the subject of the WIM, then the client certificate must be based on identity data linked to the token itself (see device certificate below).

Device Certificate

A device that has a private key capability (like WIM) might be supplied to the user with initial certificates that are not personalized for the actual user. Hence, the user still needs to obtain a certificate that binds the public key with a user identity, and the device certificate aids in this process.

A device certificate is the device manufacturer's quality guarantee regarding the key, the device storing the key, and the related procedures. The device manufacturer might also formulate a related practice statement, and security evaluation or audit procedures might be used. Examples of issuers of device certificates are

• Operators issuing SIM-WIM cards

• Smart card manufacturers

The RA, in order to accept a public key, might need to be aware that the corresponding private key is contained in a secure device, and handled in a secure way in all circumstances. This could be required because of business-related security reasons, or because of legislation regarding digital signatures.

Security of the key pair needs to be guaranteed by the manufacturer (or issuer) of the device. Security of a private-public key pair includes the following criteria:

• It is a good quality key pair (randomness, algorithm and so on).

• No copies of the private key are left outside the device if the key pair was generated outside the device. (This applies at least for keys used for digital signatures.)

• It is not feasible to obtain the private key from the device afterward.

• PINs protecting the use of the private key are well-managed.

WAP Certificate Enrollment Using the Delivery Platform

Certificate enrollment in a WAP environment based on SIM/WIM can be accomplished without an explicit WAP PKI portal. Returning to our example, the SmartTrust Certificate Portal can already handle certificate enrollment requests from a mobile device. By using the certificate portal with other components supplied in the delivery platform, it is possible to enroll certificates for WAP WIM. Although currently not a part of the standard product, this concept is available at the time of this writing (Figure 15.3).

Figure 15.3. SmartTrust PKI delivery platform.

Service and Device Management (SDM)

Mobile operators are faced with launching services using different technologies based on multiple standards, and often on proprietary infrastructures . The SmartTrust DP Service and Device Management consist of two main modules, SIM File Management (SFM) and Wireless Service Management (WSM). SFM enables vendor-independent OTA SIM file management through standard protocols, (according to GSM 03.48 Remote File Management specification GSM 03.48 RFM). Proprietary vendor-specific OTA protocols from all major SIM suppliers are also supported, giving the operator full SIM vendor-independence and a real multi-SIM solution. The SFM module also enables operators to implement advanced services based on OTA updates of standard GSM files (as defined in GSM 11.11), as well as operator-specific files.

WIM file information such as certificate URL pointers can be updated OTA. WAP provisioning through Service and Device Management (SDM) is the first step to widening the concept of Service OTA Device Management to devices other than SIM cards. Using a standard Web browser, SmartTrust WAP Assistant provides simple self-provisioning capabilities to WAP subscribers. The settings of the handset's WAP parameters are modified via SMS by using handset-specific OTA service messages.

The Wireless Service Management (WSM) tool is used to personalize the subscriber's WIG services menu OTA by updating two entities on the SIM: the SAT menu and the WIB script files.

Content Provider Services can be developed without the need for specific GSM knowledge, which is why any content provider or consultant can be used for specific service development. The Wireless Internet Gateway (WIG) (Figure 15.4) is connected to one or more content providers by plain HTTP or in secure mode HTTPS using standard SSL. On top of this, different types of application security can be added. The WIG utilizes SIM Application Toolkit (SAT) Messaging (according to GSM 03.48) for secure data transport between the SIM and the WIG.

Figure 15.4. SmartTrust Wireless Internet Gateway.

The WIG is SIM card-independent and interacts on the client side with the Wireless Internet Browser residing on the SIM. The WIB is a generic application that can be implemented on any SIM card type. The WIB receives WML Web pages from the server and converts them into SIM Application Toolkit commands. The Web pages are presented on the mobile phone through the handset's user interface.

The WIG can handle "push out" of data to the mobile phone. It can push normal text SIM, and the operator can define which content providers should have access to this functionality. The WIG can also push out requests according to WAP "Push Access Protocol" ”for example, server-initiated sessions. This could be used for pushing out a signing request during a WAP transaction ”the subscriber requests something using her WAP browser, and the signature request pops up for her to confirm the transaction.

Trusted Operator Services (TOS)

The Trusted Operator Services (TOS) package brings the capability to provide security services based on wireless PKI or traditional symmetric schemas for applications residing on the content provider side. The TOS provide the core services necessary and can help to abstract the otherwise inherent complexity of PKI.

The TOS is of a set of services logically packaged under a common name including the following items:

• Signature Gateway

  Receiving digital signatures from the mobile device enfolding them into a standardized signature structure based on PKCS #7 (Public Key Cryptography Standards #7). The signature delivered to the content provider application is also WAP-compliant.

• Certificate Portal (also known as WCES)

  The Certificate Portal manages the authentication data necessary for certificate enrollment in a wireless environment. For online enrollment, it remotely matches (proof-of-possession) user identities with one-time-passwords by verifying the signature being made by the end user. As the requirements on the certificate enrollment process will vary because of legislation and other reasons, it is designed to offer a flexible adaptation of this process. The Certificate Portal is interfacing with the CA system that finally issues the certificate and distributes it to a directory. It can provide for the same mechanisms as a WAP PKI portal with a WAP browser client when combined with the SDM module within the delivery platform.

• OCSP responder

  The OCSP responder is a premium service handling the IETF PKIX Online Certificate Status Protocol (OCSP) and a fully-compliant OCSP responder according to RFC 2560. The OCSP protocol enables end-user client software and remote servers to validate certificates against revocation without having to handle certificate revocation lists.

• Services Portal for security (pending)

  The Services Portal for security envisages a technology-independent XML interface hiding the complexity inherent in building applications based on PKI services. By interacting with the Services Portal, enabling secure mobile services becomes less complex, and application-development time is reduced considerably.

WIB with Plug-ins

The Wireless Internet Browser resides on the SIM card. It is a generic application and SmartTrust makes the specifications available for free to all SIM card vendors that want to implement it. As of today, more than 15 SIM card vendors have imple-mented the WIB, and some of the major vendors already provide the WIB on their SIM cards as standard. SmartTrust also certifies the different implementations by request from the SIM card vendor or the customer.

Supporting and enhancing WAP with the delivery platform requires a SIM containing both the WIM and the WIB. Suppliers of SIM cards such as G&D, MicroElectronica and Setec, can create combined WIM/WIB/SIM, in which both applications (WIM and WIB) are accessing the same private key(s) on request.

WIM functionality is essentially about fulfilling a "what you see is what you sign" operation and signing a challenge during WTLS Class 3 negotiation. The SmartTrust Wireless Internet Browser, based on SIM Application Toolkit technologies, already has commercial implementations containing the following functionalities:

• Symmetric 3DES-based signatures (message authentication codes)

• Symmetric 3DES-based field encryption

• Derived Unique Key Per Transaction (DUKPT) for banking transactions

• Master/Session key handling

• WAP SignText-compliant RSA signatures

• RSA signing of challenges and hash values (used for session negotiation and signing material presented in other media)

• RSA-based decryption of public keys so they can decrypt documents and contracts that are presented in another media

The WIB is tailored with the preceding functionalities through a secure plug-in concept. At the time of execution, the specific functionality is called for by the application in a traditional way using WML tags.

Certificate Enrollment

The Certificate Portal can provide for the same mechanisms as a WAP PKI portal with a WAP browser client when combined with the SDM module within the delivery platform. The Certificate Portal interfaces with the CA system that finally issues the certificate and distributes it to a directory.

The Certificate Portal would proceed according to its general process and answer to a certificate enrollment request initiated from the WIB client environment. The Certificate Portal would then interact with and request all necessary WIM file updates by the SDM module within the delivery platform. The SDM module performs file updates OTA that are otherwise supposed to be handled by the WAP client software upon receiving response from a WAP PKI portal. After the certificate enrollment is finalized, the WAP client can utilize the SIM/WIM in its standard manner.

WAP certificates can also be created in a batch scenario. This would typically be of help when replacing non-WIM cards with WIM-enabled SIM cards for a large user base. However, this would not allow for an end-user private key proof-of-possession mechanism, and this is regarded by many authorities as a weakness. A CA should typically require that the certificate information linking a specific subject with a public key (and inherently , the associated private key) is accurate and can be evaluated.