Nokia WAP Phone Security FAQ version 1.1

(updated 16-July-04)

The following is a list of frequently asked questions about the security features in Nokia WAP phones. The covered areas are Certificates, WTLS protocol implementation, WMLScript Crypto Library implementation and Wireless Indentity Module (WIM). For additional information, see Nokia WAP Phone Security document at Browsing/WAP Documents section.

Certificates
Wireless Transport Layer Security, WTLS
WMLScript Crypto Library
Wireless Identity Module, WIM
WIM and Java™ Technology

Certificates

• What is a certificate?

• A certificate is a piece of data that is used to bind a public key with the identity of the owner of that key (i.e., the certificate owner - often referred to as the "subject" in the certificate). In order to make sure that no one can insert a false identity in the certificate, the certificate is digitally signed by a certificate authority (the certificate issuer). The certificate also identifies the certificate issuer. Thus, you can trust a certificate to the degree that you trust the certificate issuer.

• What is a server certificate?

• A server certificate is a certificate that has been issued to a server (or in WAP, a WAP gateway certificate). The identity of the certificate owner is usually the name (e.g., the name of the bank).

• What is a CA certificate?

• CA is a Certificate Authority. A CA certificate contains the public key of the authority that has signed the gateway certificate. Because CA certificates are needed in order to verify gateway certificates, they need to be stored in the device.

• What is a root CA certificate?

• A root CA certificate is a self-signed CA certificate, that is, a CA certificate that has been signed by a private key that matches the public key contained in the certificate itself. In Root CA certificates the subject name is the same as the issuer name.

• What is a trust anchor?

• A trust anchor is a CA certificate that you have installed in the device and that therefore acts as the anchor of your trust in a Public Key Infrastructure. Often, but not always, a trust anchor is a root CA certificate.

• What is a trust hierarchy?

• A simplified example of a common class of trust hierarchies is illustrated below.

  

  In this illustration, it is assumed that root certificate CA X is installed in the device, whereas root certificate CA Y is not. This means that root CA X is assumed to be a trust anchor in the device. Accordingly, the user of the device trusts that CA X only issues certificates to organizations or persons who have proven that:

  • Their identity is correct
  • They are the rightful owner of a private key that matches the public key to be stored in their certificate.
  • They do not reveal their private key to other persons/organizations.

  With this CA certificate, the device can then verify that, for example, the identity and public key given in CA certificates 1 and 2 as well as in end-user certificate C can be trusted. Furthermore, this implies that the device can use CA1 and CA2 to verify that the public key and identity contained in the certificates of end-user certificates A, B, and D can be verified. However, end-user certificate E and CA certificate 3 cannot be verified, because these certificates were issued by root CA Y.

• What certificate information links it to the certificate following it in a certificate chain?

• A certificate contains (among other things) a subject name and an issuer name. The issuer name identifies the CA that issued the certificate. The subject name, on the other hand, is the identity of the subject that owns the public key in the certificate. That is, the issuer name in certificate 1 in a chain must be identical to the subject name in certificate 2 in the chain. It continues in the following way: The issuer name in certificate 2 in the chain must be identical to the subject name in certificate 3 in the chain, etc.

• Why do I need a CA certificate?

• A certificate is needed when you are connecting, for example, to a banks WAP service and you want to be sure that the server you are connecting to is what it claims to be (e.g., the bank). If you do not have the correct CA certificate in your phone (i.e., the one that belongs to the CA that issued the server certificates you usually received when connecting to a gateway/server), the phone cannot verify that the server/gateway certificate is valid. Hence, you do not know whether the server is what it claims to be.

• Which certificate types are supported by Nokia devices?

• In general, WTLS certificates and X.509 certificates are supported by Nokia devices. However, the answer is product-specific as to whether both are supported and for what purpose.

• What Wireless Public Key Infrastructure (WPKI) download mechanisms are supported by Nokia devices.

• If a device supports WPKI, the following MIME types are supported: application/vnd.wap.hashed-certificate, application/vnd.wap.signed-certificate, and application/vnd.wap.cert-response (the latter is only supported if private key operations, like WMLScript crypto.signText, are supported in the device). In addition, in the CertResponse content type, the referral method is not supported.

• How do I get a CA certificate into my Nokia device?

• You must download the certificate from an XHTML page (example given below) or from a WML page. When the device receives a special MIME type, the device stores the certificate until the user exits the browser. Once the user has exited the browser, he or she has the opportunity to see the details (issuer, owner, validity period, etc.), verify the fingerprint, and possibly store the certificate if the user can accept it based on the information provided in the display. For WTLS CA certificates downloaded to a device that does not support WPKI the correct MIME type is application/vnd.wap.wtls-ca-certificate. If a device supports WPKI, the MIME types specified in the WPKI specification (and mentioned in the previous answer) should be used.

  On the server side, it is important that the server is configured to hand out certificates with the correct MIME type. For example, if CA certificates are stored with the suffix .cer, then the server should be configured to automatically associate this file suffix with the correct MIME type.

  Here is an example of an XHTML certificate download page:

  <?xml version="1.0"?>
  <!DOCTYPE html PUBLIC "-//WAPFORUM//DTD XHTML Mobile 1.0//EN"
  "http://www.wapforum.org/DTD/xhtml-mobile10.dtd" >
  
  <html xmlns="http://www.w3.org/1999/xhtml">
  <head>
  <title>Certificate Download</title>
  </head>
  <body>
  <p>
  <a href="CACertificate.cer">Download a CA Certificate </a>
  </p>
  </body>
  </html>

• Using WAP push, can certificates or a link pointing to certificates be pushed to a Nokia device?

• The WPKI specification states that certificates may not be received via push, so certificates cannot be pushed directly to a Nokia device. However, it is possible to push a URI to the device, for loading in the browser, which can point to a certificate for download.

• How can I make sure that services do not become too complicated when supporting a multiple certificates download mechanism?

• To avoid complications that may arise from supporting a multiple certificate download mechanism, use dynamic content (CGI, servlets, php, etc.) to detect the MIME types supported by the device. If the device supports one of the WPKI MIME types (application/vnd.wap.hashed-certificate, application/vnd.wap.signed-certificate, application/vnd.wap.cert-response), then generate content (on the fly) that only hands out certificates for these certificate types. Otherwise, generate content (on the fly) that supports the old certificate download mechanism.

Wireless Transport Layer Security (WTLS)

• Do Nokia devices cache WML content from a secure connection?

• Yes, they do. However, the recent Nokia devices empty the cache whenever a browser settings set is changed. This way, content from a secure connection will not be available on an unsecured connection.

• Why do I get "Secure Server Unknown" when establishing a secure connection with WTLS?

• You will see this message if the server did not send its server certificate (probably because it didn’t have any). Hence, the device could not check the identity of the server. In plain language, this means that you have privacy (encryption) and integrity verification (meaning that it is guaranteed that no one can change the data sent), but you do not know to whom you are sending your data. You might think you are communicating with your bank, but you cannot be certain.

• Why do I get "Issuer Unknown" when establishing a secure connection with WTLS?

• You will see this message if the device received a server certificate but could not verify that the identity of the server given therein was correct. This is because you do not have the correct CA certificate (the CA certificate of the CA that issued the server certificate) in the device. Check the "Issuer" field in the server certificate details to see which CA certificate you need to download.

• With WTLS, who decides whether server authentication is performed or not?

• It is up to the gateway to indicate whether authentication is needed or not. The following describes the approximate procedure:

  First, the device sends a message to the WAP protocol gateway indicating that security should be negotiated. The message contains a list of the algorithms that the device supports. The WAP protocol gateway selects the algorithms it wants to use for the secure connection and may optionally return its certificate so that the device can check the identity of the WAP protocol gateway. The user is then notified that security has been accepted by the WAP protocol gateway. If the device was unable to check the received gateway certificate, or if the certificate was invalid, the user will also be shown the information contained in the gateway certificate. Note that there is no user interaction concerning the selection of certificates; there are no user/client certificates in the device, and the selection of the proper CA certificate used to check gateway certificates is done automatically.

• Why do I frequently lose a secure connection on GPRS?

• The reason for this may be the deployment of Network Address Translators (NATs) in the operator's infrastructure. A NAT is used to artificially increase the number of IP addresses available; the NAT translates port numbers on its interface to the public Internet to private IP addresses on the operator’s intranet. The mapping is not permanent; each port number to IP address is only valid for some limited period of time. If this time is too short, the mapping related to a WTLS connection may terminate before the secure connection is actually terminated by the user. This will result in the WAP server no longer recognizing the client (because the port number that the WAP server sees when the client tries to send packets to it has changed), and the WAP server will therefore terminate the connection. The solution is to increase the mapping lease time in the NAT.

• When I do Content Download (COD) with WTLS over GPRS, why is the browser's secure connection always lost right after the Content Download has ended?

• When you start a Content Download from a WAP 1.x browser that is running over a secure connection, the Content Download agent typically establishes a new secure connection and leaves the browser’s secure connection in idle while the Content Download is ongoing. Often, the Content Download takes a longer time than the address/port mapping lease time in the NAT or firewall. If so, the address/port mapping originally used with the browser’s secure connection has been lost once the Content Download is over, and the WAP gateway is therefore not able to recognize the client again. Consequently, the secure connection of the browser is lost.

WMLScript Crypto Library

• What size text can be signed in a crypto.signText operation?

• Approximately 200 characters; the exact number depends on the product memory layout and whether or not a certificate has to be included in the result.

• Why can't I sign a text with spaces, ":," "n," or other special characters?

• If you try to do a signature in the following way, in .WML:
  <a href="SignText#signMyText('Share: $(share)\nAmount: $(amount)\n price: $(price)')">Sign your order<\a>

  in SignText.wmls:
  extern function signMyText(signtext) {
  var signature = Crypto.signText(signtext,5,0,'');
  ...;
  }

  the signing process will not start. The reason is that the href attribute in the "a" element of the WML deck requires a well-formed URL. However, ":," "n," and a space are not part of a well-formed URL (at least at the positions where they've been put in the above). Instead, use, for example, HTTP POST to transfer a set of variables to a CGI script, which then returns a dynamically generated WMLScript with the appropriate arguments to Crypto.signText.

• Can WMLScript Crypto.Signtext work with an XHTML browser?

• The Nokia WAP 2.0-compliant browser is dual mode, meaning that besides XHTML Mobile Profile, it supports WML (and WMLScript). Therefore, if the content developer creates a link from an XHTML page to a (binary encoded) WML page (which, in turn, may link to binary encoded WMLScript files), then WMLScript.crypto.signtext is still accessible to the XHTML browser. The Nokia Mobile Internet Toolkit can be used to convert textual WML and WMLScript to binary encoding.

Wireless Identity Module (WIM)

• What is a WIM card and what does it do?

• WIM is the WAP Forum-specified WAP Identity Module. It is intended for mobile Public Key Infrastructure (PKI) use and can be used together with the mobile phone’s browser. WIM is designed for storing private cryptographic keys in a safe way, and for performing the necessary cryptographic operations using the keys, without the key leaving the module. In this way, the key will not be subjected to the risk of being compromised. Additionally, WIM can be used to store user and authority certificates that are needed for security operations in the browser.

• What is the difference between WIM and SWIM cards?

• When WIM is implemented in a smart card, it resides as an application on the card. A smart card is, however, capable of holding more than one application, and thus WIM can be implemented as an additional application residing in a GSM SIM card. When this configuration is used the card is often referred to as a SIM/WIM card, or SWIM for short.

• How will a phone user get a WIM card?

• As current mobile phones only have one smart card slot, which is used for the SIM card, the WIM needs to be a SWIM card. This means that the user typically will get a SWIM card via the mobile operator.

• What do I need to be able to use my WIM card with a PKI?

• To use a service utilizing a PKI, the keys on the card must be certified by a CA that is either part of the PKI in question or related to it. For performing digital signatures to be verified by a server-side PKI, a user certificate associated with a nonrepudiation key must be present on the card. For performing User Authentication towards a server, an Authentication certificate associated with an Authentication key must be present on the card.

• Instead of storing URLs, is it possible to store the user or CA certificates to a WIM?

• Yes, certificates can be saved to both SWIM and the phone itself. However, saving certificates to WIM requires that WPKI is enabled in the device and that there are sufficient privileges and space on the WIM.

• What does Nokia recommend with respect to the use of subjectNameHash and issuerNameHash in a Certificate Directory File (CDF) on WIM?

• Nokia strongly recommends that the subjectNameHash and certHash fields of a CDF of a WIM be used for CA certificates. For user certificates, Nokia recommends that the issuerNameHash and certHash fields be used. In fact, without these fields, many operations involving WIM, for example, Java MIDlet validation, SSL server authentication, and, in the future, DRM content download, will not work as expected. That is, without these fields on the card, the terminal will not be able to use the certificates on the card.

WIM and Java™ Technology

• Can Java MIDlets use WIM?

• Yes and no. Java MIDlets cannot access a WIM. So, from a MIDlet developer point of view, a WIM cannot be used. However, with Java MIDP 2.0, the terminal WIM software uses the CA certificates on a WIM to validate signed MIDlets (or rather, the signature contained in the JAD).

• What certificate should be installed in the terminal in order to verify the signature in a JAD?

• The CA certificate (trust anchor) is always installed in the terminal (or SIM or SWIM card). The JAD itself contains a signature over the JAR as well as the signer certificate corresponding to the private key that was used to generate the signature.

  In order for the signature verification to work, the signer certificate must be issued by a CA for which the CA certificate is installed in the terminal (or on the SIM or SWIM card). If a CA certificate available to the terminal is not a direct issue of the signer certificate, the JAD must include a certificate chain that chains up to a CA certificate available to the terminal.

• How does the terminal tell the difference between the various MIDP 2.0 policy domains, and how is this related to certificates?

• MIDP 2.0 ties the policy domain to the CA certificate that was used to verify a signer certificate in a JAD. That is, if the OperatorCA1 certificate was used to verify the certificate chain in the JAD of some MIDlet, then that MIDlet will be mapped to the policy domain corresponding to the OperatorCA1 certificate.

  The policy domain for a CA certificate, in turn, is determined by an identifier external to the certificate. On a SIM or WIM card, for example, this identifier is stored in the trustedUsage field and must contain the DER encoding of the Oid iso(1)org(3)dod(6)internet(1)private(4)enterprises(1)sun(42)products(2) javaXMLsoftware(110)midp(2)spec(2)gsm-policy(2)operator(1) in order for a CA certificate to map to the GSM Operator domain (see the MIDP 2.0 specification for more information). CA certificates for the GSM trusted third-party domain should either not have the trustedUsage field at all in the CDF or have it contain the DER encoding of the Oid id-kp-codeSigning. For CA certificates stored internally in the terminal, Nokia ensures that the trustedUsage field contains the appropriate value.

  The above means that an operator needs to provide separate CA certificates for the operator and trusted third-party domains.

• Are there any special fields that are needed in the CDF of a SIM/WIM card?

• Yes. For Nokia terminals to support checking of MIDP 2.0 JADs by means of CA certificates on SIM/WIM cards, the CDF must contain the trustedUsage field for a CA certificate corresponding to the operator domain and the identifiers.subjectNameHash for all CA certificates (irrespective of the domain).

• What profile should the CA and signer certificates follow?

• The CA certificate should be a version 3 X.509 certificate with the keyUsage and basicConstraints set correctly (to keyCertSign and TRUE, respectively). Note that Nokia also allows for version 1 X.509 certificates (that is, CA certificates without extensions), although these are deprecated. The signer certificates should be version 3 X.509 certificates and have the extendedKeyUsage extension with id-kp-codeSigning included and the keyUsage extension with the digitalSignature bit set.

  MIDP 2.0-enabled terminals support the RFC3280 path validation algorithm except for policy mapping and name constraints.