Wireless Certificates PKI Forum, TWG, Munich 2001 Meeting

1. Wireless Certificates PKI Forum, TWG, Munich 2001 Meeting

2. Contents • M-Business • Wireless PKI • Conclusions

3. M-Business • Considered as variant of E-Business that is accommodating mobile users: “M-Business = Internet + E-Business + Mobility” [Siemens I&C] • Intends to supply ubiquitous access to digitally represented business processes. • Classical security requirements occur: • Integrity • Authentication • Non-repudiation • Confidentiality • Classical security solutions apply: • Security infrastructure • Information- and/or transport-bound security services • Security token

4. PSTN Wireless PKI focus Mobile network span Mobile business span E-/M-Business Model Network operator E-/M-Business service Customer Service portals Business logic Home, hotel,... PSTN IP network Office Intranet Mobile Service backend Service frontend

5. Current approaches to deliver Internet contents/services to wireless devices: • iModeBased on HTTP as well as a HTML subset (cHTML - compact HTML). Services are provided via HTTP proxies. Solution is being developed by NTT DoCoMo (www.nttdocomo.com). • WAP - Wireless Application ProtocolVersion 1.n specifications are based on an own protocol suite and XML. Services are provided via WAP gateways. Specifications are being developed by the WAP Forum (www.wapforum.org), a global industry consortium. M-Business Solutions: Constraints and Approaches • Limitations of wireless devices/networks constraint M-Business solutions: • Devices are restricted with respect to battery, display, keyboard, memory, or processor capacity. • Networks are based on narrow-band bearers with high latency. • These limitations apply to mobile security architectures, in particular. But, they are becoming less significant with new device and network generations.

6. Contents • M-Business • Wireless PKI • Conclusions

7. WPKI - Wireless PKI: Overview • Public key infrastructure that is designed to support automated identification, authentication, and authorization services in mobile environments. • Work item of the WAP Forum Security Working Group (WSG). Following PKI specifications are currently available: • WTLS certificate: part of the WTLS specification (status: ‘approved’). Provides a simple, non-ASN.1 certificate format. • WAPCert: ‘WAP Certificate and CRL Profile’ (status: ‘proposed’). Provides a compact certificate profile on base of PKIX. • WPKI: ‘WAP PKI Definition’ (status: ‘proposed’). Supports WTLS, X.509-WAPCert, and X.509-PKIX certificates. • Basis for efforts of other industry consortiums, including: • MeT (Mobile Electronic Transactions; www.mobiletransaction.org) • Mobey (promoter of mobile financial services; www.mobeyforum.org) • MoSign (Mobile Signature, a German trial effort; www.mosign.de) • Radicchio (promoter of wireless PKI; www.radicchio.org)

8. End entity Repository RA CA WPKI Entities • End entityEntity that is using (e.g. validating) certificates or is a subject of certificates. • Registration authority (RA)Entity that is authorized to make requests to issue/revoke/update certificates to a CA. • Certification authority (CA)Issues/updates/revokes public key certificates in response to authenticated requests from legitimate RAs. • PKI portalEntity that provides services to WAP end entities and performs RA and/or CA functions. It is required to be both WAP and PKI aware. • RepositorySystem(s) that support(s) the distribution of certificates and CRLs. PKI portal

9. Already specified (and covered by the current ‘WAP PKI Definition’): • Transport-bound security services: • Server authentication (aka: WTLS class 2/3, since WAP 1.0) • Client authentication (aka: WTLS class 3, since WAP 1.0) • Information-bound security services: • Signature generationat client-site (via WMLScript ‘signText’, since WAP 1.2). • Under development (not covered by the current ‘WAP PKI Definition’): • Information-bound security services: • Signature validationat client-site (e.g. signed scripts or active contents such as WTA - Wireless Telephony Application objects) • Encryptionat client-site (i.e. wrapping symmetric keys) • Decryptionat client-site (i.e. unwrapping symmetric keys) WPKI Applications • Remark: WAP security applications are optionally accompanied by a WIM - Wireless Identification Module; WAP includes a WIM specification.

10. Certificate type Client and issuing authority certificates Certificates stored upon clients or sent over-the-air X.509-WAPCert Server certificates X.509-PKIX Certificates not stored upon clients and not sent over-the-air Client and issuing authority certificates Client certificates WTLS certificate WTLS server and issuing authority certificates WPKI Certificate Taxonomy (WAP 1.n) Applies to Refers to Remark: The WTLS certificate format is going to be deprecated when migrating from WTLS to TLS with WAP-NG. It is going to be substituted by the WAPCert profile.

11. WTLS certificate format X.509v3 certificate format certificate_version signature_algorithm issuer valid_not_before valid_not_after subject public_key_type parameter_specifier public_key signature version serialNumber signature issuer validity subject subjectPublicKeyInfo issuerUniqueID subjectUniqueID extensions signatureAlgorithm signatureValue ASN.1 encoded Ad-hoc, not ASN.1 encoded WTLS vs. X.509v3 Certificate Formats

12. WAPCert Certificate Profile on Base of PKIX-X.509v3 The WAPCert profile is based upon the PKIX profile (RFC 2459; certificate versions: v1/v3). It applies to client certificates stored in WAP devices and transmitted in WAP protocols. WAPCert requirements beyond RFC 2459: • SerialNumber: limited to 8 bytes. • Signature: sha1WithRSAEncryption or ecdsa-with-sha1. • Issuer/subject: recommends the serialNumber (X.520) attribute for short and locally unique distinguished names. • SubjectPublicKeyInfo: rsaEncryption or id-ecPublicKey • Extensions: provides additional domainInformation attribute to enforce OCSP and/or link non-critical extensions not contained in the certificate (extension URL and hash value are included). version serialNumber signature issuer validity subject subjectPublicKeyInfo extensions signatureAlgorithm signatureValue

13. WPKI Operations • Key generation • May be upon devices (such as WIM) or externally; may be local or central. • Required are different keys with respect to different PKI applications (esp. for client authentication and digitally signing). • Certification requestProcessed by a RA. PKI registration may be part of device/service provisioning or performed upon user request. Formats/protocols to transfer public keys and to provide proof of private key possession (POP): • Server certificates: PKCS#10 • Client certificates (authentication): WTLS • Client certificates (digital signature): signText format PKI registration may be assisted by devices delivered with initial key pairs and pre-installed ‘device certificates’ (allowing manufacturers to make statements regarding key quality, device properties, and related procedures). • Certificate issuancePerformed by a CA upon legitimate request by a RA. Binding of a specific key usage (e.g. client authentication and digitally signing) is recommended. Due to storage limitations, multiple certificates may be issued per client key pair.

14. WPKI Operations (cont’d) • Certificate delivery/distribution • CA certificates: may be provisioned as part of device/service supply as well as downloaded. Authentication of self-signed CA certificates may be provided out-of-band by a fingerprint mechanism or in-band by an additional signature (verification key certified by another CA instance). • End entity certificates: client-certificate IDs allow to avoid client-site storage as well as over-the-air distribution of client certificates. Such client certificates are provided by repository services. • Certificate validationPerformed by end entities. It is intended to mark trusted certificates upon clients (e.g. ‘telephony service provider root’) in order to be able to control certain applications such as download of WTA objects. • Certificate revocationIn order to obviate revocation services upon clients, short-lived WTLS server certificates are suggested (CAs simply stop issuance). • Certificate updateCurrently specified for CA certificates: employs the signature variant for the distribution of self-signed certificates (cf. above).

15. 3: Publish client certificate 0: CA certificate provisioning 1: Provide private key and client certificate-ID upon WIM 5: Retrieve certificate via client certificate- ID 2: Request client certificate via ID 4: Transmit signed data with client certificate-ID Certificate Distribution via Client Certificate-IDs (here: key generation upon WIM as an infrastructure service) • Allows to: • Offload client certificate handling from mobiles. • Save over-the-air distribution of client certificates. • Support identity establishment with or without ‘writing’ onto security token after device provisioning. • Current application scenarios: • WTLS client authentication • Digitally signing via WMLScript ‘signText’ • Identification options: • Key hash • Issuer and serial number • Retrieval may be based on HTTP or LDAP URLs. RA/CA service Repository service 6: Validate client certificate E-/M-Business service WAP client

16. WPKI service consumers Repository CA RA (W)PKI portal (W)PKI service providers Infrastructure Core vs. Boundary WPKI specific processing: • Client certificates • POP during PKI registration based upon WAP security mechanisms. • WAP in-band distribution requires X.509-WAPCert certificates. WAP out-of-band distribution is based on IDs; certificates comply to PKIX. • Server certificatesCurrently based upon proprietary WTLS certificate format which is going to be deprecated with WAP-NG. • Trusted certificatesProvisioning and update are based upon WPKI structures delivered with specific MIME types. Thus, wireless PKI constraints may largely be accommodated at infrastructure border.

17. Deploy: • Basic asymmetric services • XKMS services integration Repository CA RA Provide: • ASN.1 parsing • Key recovery • Object retrieval • Path construction and processing • PKI/attribute registration • Status checking • Trust model processing Outlook: XKMS as Potential WPKI Enabler XKMS - XML Key Management Specification: • Provides XML-based interfaces to PKI: • Supports clients in accessing and using public keys. • Shields clients from syntax, semantic, as well as trust model issues of engaged PKI domains. Thus, XKMS would allow to offload (client and server) certificate handling from mobiles. • XKMS responders may be part of network operator services. • Remark: XKMS assumes clients to be XML and XMLDSig aware (e.g. <KeyInfo> handling) to an extend currently not supported by WAP. Thus, the sketched scenario addresses long term opportunities. WPKI service consumers XKMS services (W)PKI service providers

18. Contents • M-Business • Wireless PKI • Conclusions

19. Conclusions • Technical aspects: • Compared to classical (i.e. originally wired) PKI efforts, WPKI is no new solution approach; it essentially resembles X.509v3 and PKIX ideas. • In part, WPKI documents define formats, protocols, and procedures that deviate from classical approaches. • Business development aspects: • Wireless PKI may see truly large consumer PKI domains rapidly due to existing business processes (e.g. device provisioning), available local infrastructure (e.g. network provider outlets), and product properties (e.g. smart card capabilities in GSM/GPRS phones). • Best-of-both-worlds / how to? • Avoid multiple infrastructures when offering E-/M-Business services via multiple distribution channels such as Web and WAP: • Unify infrastructure core. • Accommodate necessary deviations at infrastructure boundary, i.e. as part of service provisioning. • Emerging XKMS services promise adequate support for wireless needs (lean clients) and are becoming a matter of WAP-NG considerations.

20. Author Information Siemens AG Information and Communication Networks Postal Address: Siemens AG - ICN ISA TNA D-81370 Munich Office Address: Charles-de-Gaulle-Str. 2 Tel. +49.89.722.53227 Dr. Oliver Pfaff Fax: +49.89.722.53249 Technology Area Manager Mobile: +49.172.8250805 E-Business Security E-Mail: oliver.pfaff@icn.siemens.de