About PKI Key Stores Dartmouth College PKI Lab

Key Store Defined Protected “vault” to hold user’s private key with their copy of their x.509 certificate A function of their client computer and software Should be locally password protected Should be encrypted and/or protected by specialized hardware May be provided by OS or by application(s) May hold the only copy of a private key

Key Store Anatomy (first look before we launch into details)

Key Store Interfaces Microsoft Windows CAPI RSA PKCS#11 Application specific

Browsers and Key Stores Browsers provide one of the most common ways to access key stores GUI for key generation and certificate enrollment Viewing and manipulating certificates and keys Import/export Mozilla/Netscape does PKCS#11 Internet Explorer/Windows does CAPI

Key Store Types “Software” –Keys encrypted in a file “Hardware” –Keys stored on specialized hardware tokens

OS Key Stores CAPI: Microsoft Windows CryptoAPI “Keychain” from Apple Many Windows applications use CAPI; others have their own key store.

“Software” Key Store Stores certificates and encrypted keys on the local computer’s file system Encryption is password protected Relatively vulnerable to key theft (depending on implementation) Requires exporting and importing to use the key on another computer or in a different key store on the same computer All PKI applications support this type of key store – for some it is the only type supported.

“Hardware” Key Store Stores certificates and keys in special purpose hardware (typically USB token or smart card and reader) Much higher assurance - the key cannot be used without the user’s password, but still not unbreakable Allows easy private key mobility between computers and applications Two-factor security (need token plus password to do anything) makes hardware key stores much more secure than software key stores

PKCS#11 Standard developed by RSA to provide applications with a key store and PKI cryptographic functions Used by Mozilla on all OSes (even Windows) Has a lower-level API for plugging in different implementations (enables hardware tokens) Open source implementations available Similar to MS CAPI – unfortunately MS opted to not support PKCS#11

Microsoft CAPI (AKA CryptoAPI) Microsoft Windows “standard” API for providing PKI functionality to applications Provides: – Key store function –Cryptographic operations using the key store and certificate –GUI for managing certificates and keys –Facilities to create, import, and export certificates and keys Cryptographic Service Provider (CSP) layer allows 3 rd party software, token, and smartcard solutions Microsoft’s software key store CSP has some issues

Key Store Anatomy (revisited now that we are familiar with the pieces)

Application Key Stores Some applications don’t use either CAPI or PKCS#11 Adds undesirable complexity Incompatible with hardware keys (since they can only support PKCS#11 and CAPI/CSP interfaces) Require exporting and importing certificates/keys AOL AIM has its own key store

How PKI Uses Passwords Passwords protect local key stores Stored and managed locally by the user Never stored on servers (an important feature – passwords on servers and traversing a network are more vulnerable) User provides the password to “unlock” their private key – all other operations use asymmetric key cryptography

User Accounts Windows CAPI stores software keys in each user’s profile If user accounts are secure, then CAPI keys are protected by the Windows logon security

PKCS#7 and PKCS#12 More RSA standards No awards for imaginative names… PKCS#7 is general syntax for data that may have cryptography applied to it PKCS#12 specifies secure containers for transporting PKI certificates with private keys