Lisa Pretty
Executive Director

Speakers
 Overview & Interoperability – Lisa Pretty,
PKI Forum
 Hardware Security Modules – Bill Franklin, nCipher
 Tokens – Bill Wehrmacher, DataKey

Certificate Lifecycle
Certificate
Revocation
Certificate
Publication
Directory
Services
Certificate
Generation
CA Certificate
Expiration
RA
End
Entity
Certificate
Archiving
Verification of Applicant

PKI Interoperability
 Three different aspects to PKI interoperability
– Component interoperability
– Enterprise interoperability
– Application interoperability

PKI Component
Interoperability


Ability to mix and match COTS PKI products
CA
Depends upon specification-based messages exchanged between components to support:
– Certificate requests
– Certificate renewal
– Certificate revocation
Repository
Client
RA

Factors For Component
Interoperability
 Algorithm suite
 Certificate management protocols
– Certificate issuance
– Certificate revocation
 Transport mechanisms

Enterprise Interoperability
 The ability to connect two enterprise PKIs into a larger functional
PKI
– More than just crosscertification
– Clients must be able to find and validate meaningful certification paths
Enterprise A PKI
CA RA
Repository A
Client
Client
CA
Repository B
RA
Enterprise B PKI

Factors for Enterprise
Interoperability
 Algorithm suite
 Certificate format and extension set
 Certificate policies
 Certificate status information formats
 Path building and validation across PKIs

Application Interoperability
 The ability of PKI-aware applications to:
– Share PKI certificates, key-pairs, and processing modules
– Rely on different PKI environments to implement security services
Enterprise A PKI
CA RA
Repository A
Client
Client
CA
Repository B
RA
Enterprise B PKI

Factors for Application
Interoperability
 Ability to share cryptographic modules OR export/import cryptographic materials
– Cryptographic application programming interfaces (APIs)
 Access to path validation and path building utilities
 Consistency of processing
 Feature sets

Bill Franklin
Dir. of Technology, nCipher

Hardware Security Modules
 Hardware security modules (HSM) perform cryptographic operations, protected by hardware
(PCI boards, SCSI boxes, smart cards, etc.)
 These operations include:
– Random number generation
– Key generation (asymmetric and symmetric)
– Private key hiding (security) from attack (no unencrypted private keys in software or memory)
• Private keys used for signing and decryption
• Private keys used in PKI for storing Root Keys

About Public Key, ---?
 We assume you understand something about public key technology:
– Public-private key pairs; generation and life cycle
– Asymmetric encryption
– Symmetric encryption
– Use of asymmetric encryption to establish keys for subsequent symmetric encryption
– Criticality of private keys (and root keys)

Why Use HSMs?
 A number of public key operations require the use of private keys as part of various processes:
– Cryptographically or digitally signing an object, a file, etc.
– Decrypting an encrypted object or file
 These processes happen in active memory, which is vulnerable to attack and copying of a private key in open use, unencrypted

HSM – Immediate Needs
 SSL predominates in e-commerce:
– Allows secure electronic transactions
 Effect on servers:
– SSL negotiation (asymmetric) creates heavy overhead – increasingly a bottleneck
– Private keys have to be brought into decryption and signing processes, interactively
 So, SSL can drive:
– Insecurity if private keys not protected fully
– Bottlenecks in processing, even bringing servers down

HSM Basics
 HSMs generally hook directly to the server , providing a protected area for the private key to be generated and reside , as well as to participate in a protected manner in critical processes , such as signing and decryption -- such that the private key is never in active memory or software in an unencrypted state.

PKI Implications
 If you have just spent $15M implementing a global PKI – and your root is compromised, or some other important signing key…
 What will it cost you to refit all new certificates – as well as inspecting and changing all the operations associate with the compromised key(s)?
 It will be more than you spent setting up initially!
 Or, transactions are suddenly 8000% over design expectations – how will you scale?

Desirable Characteristics
 HSMs should:
– Resist physical and programming attacks of all types
(our catechism is: NO Private keys unencrypted in software or memory – any time); generate random numbers and keys in HSM
– Make private keys securely available to transaction processes in real time, securely – particularly CAs
– Allow “k of n” security for access to HSMs with security “in depth”
– Accelerate cryptographic processing
– Be scalable and support failover
– Operate with load balancing schemas
– Work with PKCS#11, MS CAPI and other APIs

Need Further Information
 Check with the PKI Forum site for members which have HSMs (www.pkiforum.org)
 Work with your integrator or consultants to identify the best solutions for your implementations and operations
 Work with your PKI vendor concerning solutions for HSM
 But: Use HSM to assure your security!

HSM Example: nCipher HW slide 20
PCI
SCSI

Example: nCipher Hardware
RISC Processor Array
Each CPU can perform - 37 1/2
1024 bit decryptions per second
Secure Memory

Example: nCipher Hardware slide 22
The master processor performs crypto operations and parsing to other chips
“Master” Processor
Other CPU’s perform only crypto operations

The smart token’s role in
PKI interoperability.
W.H.(Bill) Wehrmacher
Datakey, Inc.

Just what is a Smart Token?
 Physical Device
– Potential for two Factor Authentication
– Potential for secure portable Credentials
 Computing Device
– Potential for Strong Authentication
– Potential for Non Repudiation
 Convenient Form Factors
– Potential for regular use

What do you mean by interoperate?
 The definitions for tokens are the same definitions about PKI in general.
– I want my PKI trust system interoperate with others’
PKI trust systems
– I want my PKI credentials to work across applications
 There is more with Tokens
– “OK, now I have have keys and Certificates on my token, I should be able to plug it into any PKI enabled application, in any workstation and have it just work.”

What does the user mean by interoperate?

“OK, you’ve convinced me, I need tokens.
– Now I can work anywhere,
– any time,
– on any computer,
– with any application,
– and on and on and on…”
“OK, now I have have keys and Certificates on my token, I should be able to plug it into any PKI enabled application, in any workstation and just have it work… Right?”

Define where you want interoperability
 At card edge...
 At Card Operating System ...
 At card terminal ...
 At connection API ...
 At Cryptographic API ...
 Across desktop platforms ...
 Across PKI Systems ...

Token Interoperability Stack
ISO 7816
Applications: Secure and non-secure
Security Mechanisms and protocols
Token Connectivity APIs
Security Support
Services
Crypto Modules and Algorithms
PKI functions:
Key & Certificate
Management
Auditing etc.
CAPI/CSP,
Cryptoki
PC/SC,
OCF etc.
Token Connectivity hardware
Tokens

At Card Edge with ISO 7816?
A little like saying RS232 Compatible
– Card will fit in slot
– Contacts will line up
– Power and signals will go to right place
– Card will identify itself with
A nswer T o R eset
– Many low level commands will work
– Most functional commands won’t
Probably not core definition of interoperability, but will be part of the equation

Token Interoperability Stack
ISO 7816
Applications: Secure and non-secure
Security Mechanisms and protocols
Token Connectivity APIs
Security Support
Services
Crypto Modules and Algorithms
PKI functions:
Key & Certificate
Management
Auditing etc.
CAPI/CSP,
Cryptoki
PC/SC,
OCF etc.
Token Connectivity hardware
Tokens

At Card Edge Operating
System:
 CARDOS
 DKCCOS
 EMV
 JavaCard
 Multos
 SEIS
 SpyCOS
 Windows for Smart
Cards
Not really practical to interoperate here…

At Operating System
Algorithm Suite:
 RSA
 DSA
 ECC
 PGP
 Others, new and old
 DES and derivatives
 RCx
 IDEA
 CAST
 Others, new and old
Necessary to support wide range of applications

Token Interoperability Stack
ISO 7816
Applications: Secure and non-secure
Security Mechanisms and protocols
Token Connectivity APIs
Security Support
Services
Crypto Modules and Algorithms
PKI functions:
Key & Certificate
Management
Auditing etc.
CAPI/CSP,
Cryptoki
PC/SC,
OCF etc.
Token Connectivity hardware
Tokens

At Token Terminal
 Platform Dependent
– PC/SC
• WinTel 32 Platforms only
• Limited performance with Cryptographic Smart
Cards
– OpenCardFramework
• Java oriented

Token Interoperability Stack
ISO 7816
Applications: Secure and non-secure
Security Mechanisms and protocols
Token Connectivity APIs
Security Support
Services
Crypto Modules and Algorithms
PKI functions:
Key & Certificate
Management
Auditing etc.
CAPI/CSP,
Cryptoki
PC/SC,
OCF etc.
Token Connectivity hardware
Tokens

At Cryptographic or other API
 Cryptoki (PKCS#11): Lowest Level of popular
APIs
 CAPI (Microsoft Cryptographic API)
 Both supported by existing products
ActivCard: ActivCard Gold Litronic: NetSign
Datakey: SignaSURE CIP
GemPLUS: GemSafe
Schlumberger
Others
 Both Supported by PKI products
For a list, see the PKI Forum Member list and there are others

Token Interoperability Stack
ISO 7816
Applications: Secure and non-secure
Security Mechanisms and protocols
Token Connectivity APIs
Security Support
Services
Crypto Modules and Algorithms
PKI functions:
Key & Certificate
Management
Auditing etc.
CAPI/CSP,
Cryptoki
PC/SC,
OCF etc.
Token Connectivity hardware
Tokens

Perhaps now you have token hooked up. What next?
Rule #1: Do no harm
 Share PKI data across platforms
– If PKI can operate in multiple environments, a smart token should not prevent it
 All Cryptoki applications are not created equal
– Cryptoki recommends, does not specify.
– Applications can store data on tokens in incompatible formats.
– PKI data can be PKI specific or PKI general

Token Vendors
 Smart Card tokens
– ActivCard
– Bull
– Datakey
– GemPlus
– Giesecke & Devrient
– Litronic
– Oberthur
– Schlumberger
– Many others
 Other Smart Tokens
– ActivCard
– CryptoCard
– Security Dynamics
– Many others
These are not “recommended” vendors, just those who came to mind. There are many others and you should search out the ones that best fit your needs.

Please feel free to contact me
W.H.(Bill) Wehrmacher
Director of Technical Services
Datakey, Inc.
bill.wehrmacher@datakey.com
+1 952 808-2337
407 West travelers Trail
Burnsville Minnesota 55337

www.PKIForum.org