trusted networks & applications icn isa tna © siemens ag 2001. icn isa tna. dr. oliver pfaff....

Trusted Networks & ApplicationsICN ISA TNA

© S

iem

ens

AG

20

01.

IC

N I

SA

TN

A.

Dr.

Oliv

er P

faff.

Ju

ne,

20

01

Wireless CertificatesPKI Forum, TWG, Munich 2001 Meeting

Trusted Networks & Applications - E-Business Security

© S

iem

ens

AG

20

01.

IC

N I

SA

TN

A.

Dr.

Oliv

er P

faff.

Ju

ne,

20

01

2

Contents

M-Business

Wireless PKI

Conclusions


© S

iem

ens

AG

20

01.

IC

N I

SA

TN

A.

Dr.

Oliv

er P

faff.

Ju

ne,

20

01

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


© S

iem

ens

AG

20

01.

IC

N I

SA

TN

A.

Dr.

Oliv

er P

faff.

Ju

ne,

20

01

4

Servicefrontend

Mobile business span

E-/M-Business serviceCustomer

PSTN

IP network

E-/M-Business Model

PSTN

Intranet

Network operator

Home,hotel,...

Office

Mobile

Mobile networkspan

Businesslogic

Servicebackend

Service portals

Wireless PKIfocus


© S

iem

ens

AG

20

01.

IC

N I

SA

TN

A.

Dr.

Oliv

er P

faff.

Ju

ne,

20

01

5

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.

Current approaches to deliver Internet contents/services to wireless devices: iMode

Based 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.


© S

iem

ens

AG

20

01.

IC

N I

SA

TN

A.

Dr.

Oliv

er P

faff.

Ju

ne,

20

01

6

Contents

M-Business

Wireless PKI

Conclusions


© S

iem

ens

AG

20

01.

IC

N I

SA

TN

A.

Dr.

Oliv

er P

faff.

Ju

ne,

20

01

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)


© S

iem

ens

AG

20

01.

IC

N I

SA

TN

A.

Dr.

Oliv

er P

faff.

Ju

ne,

20

01

8

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.

Endentity

RA

CARepository

PKI portal


© S

iem

ens

AG

20

01.

IC

N I

SA

TN

A.

Dr.

Oliv

er P

faff.

Ju

ne,

20

01

9

WPKI Applications

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 generation at client-site (via WMLScript

‘signText’, since WAP 1.2). Under development (not covered by the current ‘WAP PKI Definition’):

Information-bound security services:Signature validation at client-site (e.g. signed scripts

or active contents such as WTA - Wireless Telephony Application objects)

Encryption at client-site (i.e. wrapping symmetric keys)Decryption at client-site (i.e. unwrapping symmetric keys)

Remark: WAP security applications are optionally accompanied by a WIM - Wireless Identification Module; WAP includes a WIM specification.


© S

iem

ens

AG

20

01.

IC

N I

SA

TN

A.

Dr.

Oliv

er P

faff.

Ju

ne,

20

01

10

WPKI Certificate Taxonomy (WAP 1.n)

Certificatetype

Refers to Applies to

Server

certificates

Client

certificates

Certificates stored upon clients or sent over-the-air

X.509-WAPCert Client andissuing authority certificates

X.509-PKIX Certificates not stored upon clients and not sent over-the-air

Client andissuing authority certificates

WTLS certificate WTLS server andissuing authority certificates

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.


© S

iem

ens

AG

20

01.

IC

N I

SA

TN

A.

Dr.

Oliv

er P

faff.

Ju

ne,

20

01

11

WTLS vs. X.509v3 Certificate Formats

version

serialNumber

signature

issuer

validity

subject

subjectPublicKeyInfo

issuerUniqueID

subjectUniqueID

extensions

signatureAlgorithm

signatureValue

ASN.1 encoded

X.509v3 certificate format

certificate_version

signature_algorithm

issuer

valid_not_before

valid_not_after

subject

public_key_type

parameter_specifier

public_key

signature

Ad-hoc, not ASN.1 encoded

WTLS certificate format


© S

iem

ens

AG

20

01.

IC

N I

SA

TN

A.

Dr.

Oliv

er P

faff.

Ju

ne,

20

01

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


© S

iem

ens

AG

20

01.

IC

N I

SA

TN

A.

Dr.

Oliv

er P

faff.

Ju

ne,

20

01

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 issuance

Performed 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.


© S

iem

ens

AG

20

01.

IC

N I

SA

TN

A.

Dr.

Oliv

er P

faff.

Ju

ne,

20

01

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).


© S

iem

ens

AG

20

01.

IC

N I

SA

TN

A.

Dr.

Oliv

er P

faff.

Ju

ne,

20

01

15

RA/CA service

WAPclient

0: CA certificate provisioning

4: Transmit signed data with client certificate-ID

Repositoryservice

1: Provide private key and client certificate-

ID upon WIM

6: Validate client

certificate

E-/M-Businessservice

2: Request client

certificatevia ID

5: Retrieve certificatevia 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.

3: Publish client certificate


© S

iem

ens

AG

20

01.

IC

N I

SA

TN

A.

Dr.

Oliv

er P

faff.

Ju

ne,

20

01

16

Infrastructure Core vs. Boundary

(W)PKI portal

WPKI service consumers

(W)PKI service providers

RA

CARepository

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.


© S

iem

ens

AG

20

01.

IC

N I

SA

TN

A.

Dr.

Oliv

er P

faff.

Ju

ne,

20

01

17

Outlook: XKMS as Potential WPKI Enabler

(W)PKI service providers

WPKI service consumers

Deploy: Basic asymmetric services XKMS services integration

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 handlingfrom 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.

XKMS services

RA

CARepository

Provide: ASN.1 parsing Key recovery Object retrieval Path construction and processing PKI/attribute registration Status checking Trust model processing


© S

iem

ens

AG

20

01.

IC

N I

SA

TN

A.

Dr.

Oliv

er P

faff.

Ju

ne,

20

01

18

Contents

M-Business

Wireless PKI

Conclusions


© S

iem

ens

AG

20

01.

IC

N I

SA

TN

A.

Dr.

Oliv

er P

faff.

Ju

ne,

20

01

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.


© S

iem

ens

AG

20

01.

IC

N I

SA

TN

A.

Dr.

Oliv

er P

faff.

Ju

ne,

20

01

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: [email protected]

trusted networks & applications icn isa tna © siemens ag 2001. icn isa tna. dr. oliver pfaff....

Documents