Intel s Common Data Security Architecture

Transcription

1 Intel s Common Data Security Architecture Draft Release 2.0 version 1.0 Presented at TOG Members Meeting PKI-TG Session June 26, 1997 Denise Ecklund, Intel Architecture Labs

2 Today s Agenda History of CDSA and TOG, PKI-TG Certificate and Key Life Cycle Management Key Recovery as an Elective Service Category Portable Credentials CSSM Enhancements Status Update Group Questions and Answers 2

3 History of CDSA, TOG, PKI-WG Intel presented CDSA at PKI Mtg, Dec-96 PKI-TG requested response to PKI Requirements Intel presented PKI-Reqs response, Mar-97 PKI-TG recommended 3 specific extension areas:» Certificate and Key Life Cycle Management» Key Recovery Services» Portable Credentials Support Close review by other TOG members Intel presenting these results today, anticipating PKI-TG recommendation to Technical Managers July-97 TM recommendation to begin Fast Track 3

4 Acknowledgements Intel acknowledges the thorough review and the active contributions of the following companies in evolving CDSA 2.0 Entrust Technologies IBM Netscape Communications Trusted Information Systems Additional, appreciated feedback from Intel Product Groups building appls on CSSM United States NSA 4

5 CDSA - a four layer architecture Supports varied degrees of security-awareness in applications Applications in C++ Applications in C Applications in Java Layered Security Services and Tools Method Wrapper Defines a common API CSSM Security API Common Security Services Manager Service Provider Interfaces Extensible for all types of security services Security Service Add-in Modules 5

6 Summary of Enhancements - 1 Certificate and Key Life Cycle Follows an extended PKIX model» RA, CA, local & remote services New APIs for Trust Policy and Certificate Library operations» create, verify, renew, recover, multisign Supports asynchronous operation completion 6

7 Summary of Enhancements - 2 Key Recovery Defines a secure model for individuals, corporations, and governments to recover encryption keys using a broad range of recovery mechanisms» encapsulation, escrow, hybrid schemes New, independent category of security service Uses new dynamic service manager binding mechanism New APIs and new SPIs Works with any add-in Cryptographic Service Provider 7

8 Summary of Enhancements - 3 Portable Credentials No a priori detailed model from PKI-TG No detailed model defined by working team Intel view includes at least HW tokens Latest evolution of CSSM APIs provide complete support for PKCS#11 and other HW token interfaces 8

9 Summary of Enhancements - 4 Smoothing it out and putting it all together Infrastructure Enhancements Horizontal Extensibility» Dynamic addition of security service categories Multi-service Add-in Modules» Allow add-in vendors to provide any subset of SPIs Support for TOG s PKI Model» Use stronger integrity checks among components» In the specs - clarify required vs optional parameters & behavior 9

10 A Quick Refresher on CDSA Applications in C Applications in C++ Applications in Java System Security Services Layered Services Tools Method Wrapper Middleware Language Interface Adapter CSSM Security API EM-API Common Security Services Manager CSP Manager SPI Integrity Services TP Module Manager TPI CL Module Manager CLI Security Contexts DL Module Manager DLI Elective Module Mgr EMI Security Add-in Modules Cryptographic Service Provider Trust Model Library Certificate Library Data Storage Library New Category of Service Data store 10

11 CSSM Module Managers Define the CSSM APIs and SPIs for a category of security services Base Service Module Managers are always present certificate, trust policy, data store, cryptography Elective Module Managers are transparently loaded on demand key recovery, audit/logging, future services Provide a subset of the CSSM services dispatch APIs to zero, one or more SPIs pre and/or post-process dispatched API calls 11

12 CSSM Core Services Implement architectural extensibility Dynamic attaching of add-in modules (mechanism implementations) Transparent attaching of elective module managers (categories of security service) Standard component management install, register-services, query-registry, etc. Integrity Services Security Context Management parameters required for cryptographic operations 12

13 Certificate and Key Life Cycle Management

14 Supporting Certificate and Key Life Cycle The model is based on PKIX-* and compatible with the PGP keyring model Basic Entities Certification Authority, Client, Registration Authority remote or co-located Basic Services over the life cycle Certificate delivery, verification & mgmt asynchronous operation completion possible 14

15 Certificate and Key Life Cycle Phases Registration of Certificate Bearer Key Generation (and other CA-provided services) Certificate Generation Cert Update Cert Recovery Cert Revocation Active Phase Cert Retrieval Cert Cert Verification MultiSign 15

16 Supporting Certificate Life Cycle in CSSM New APIs for Trust Policy Modules Verification of trust to perform an action (based on certificates) New APIs for Certificate Library Modules Certificate create, renew, recover, multisign 16

17 Trust Policy API - Review Access to certificate-based trust models semantics of trust Generic API supports different trust models from hierarchical to introducer Basic categories of operations: verify application-specific action operates on groups of semantically-related certificates 17

18 TP_CertVerify ( ) Verification is based on chain of certificates a set of trusted certificates (cross-certified) a set of specified policies the action to be performed (if the cert verifies) Outputs Yes or No list of evidence from the verification process automatic initiation of specified action 18

19 Cert Management API - Overview Defines memory-based manipulation of certificates and certificate revocation lists (CRL) Generic API so libraries can support different certificate types CSSM_OIDs name cert and CRL fields CSSM_OID structure holds a generic object identifier Examples: ASCII string, enum value, X.509 OID, S-expression Basic categories of operations: create, sign, verify view, get_field_values life cycle mgmt, type_translations 19

20 APIs support Asynchronous Completion of Operations Some operations invoke remote services that may not complete for days Examples: certificate enrollment Two APIs per asynchronous operation initiator function» returns: estimated time to completion, transactionid result retrieval function» returns: result or new estimated time to completion 20

21 Certificate Creation and Certificate Renewal Set-up and initialize» CL_RegistrationFormRequest; CL_CertCreateTemplate CL_CertRequest keypair generation by client or by CA/RA submit request to CA entity» include authorization info and certificate template request additional CA backend services» key backup, cert renewal notice, white pages listing, etc. CL_CertRetrieve retrieve certificate ( and remote keypair ) RA CA CA 21

22 Certificate Recovery - setup CL_CertRecoveryRequest requires authorization data can request a subset of your certificate history CL_CertRecoveryRetrieve cache retrieves a set of certificates and their associated private keys into a local cache certificates and keys in the cache are protected and ready to be recovered also outputs the number of cached items CA CA 22

23 Certificate Recovery - completion CL_Recover Cert recover/look at each cached certificate determine which keys to recover CL_RecoverCertKey recover the I-th private key into a local CSP provide new passphrase to secure recovered key CL_CertAbortRecovery {cert1, key1} {cert2, key2} {cert3, key3} {cert1, key1} {cert2, key2} {cert3, key3} empty cache scrubs the cache and ends the recovery process CSP secured storage 23

24 Certificate MultiSign CL_CertMultiSignRequest request additional signature on a certificate uses a selectable signing scope does not invalidate earlier signature(s) supports notary public functionality CL_CertMultiSignRetrieve retrieve the multiply-signed certificate CA CA 24

25 Key Recovery

26 The Purpose of Key Recovery The primary purpose of a Key Recovery is to recover a key that has been used to ensure the confidentiality of some data Corporations and governments recover a key to decrypt intercepted, cipher data Individuals and corporations recover a key to decrypt stored, cipher data Encrypted Data Data Source Data to Send Interception Point Data Destination Data Received Other Local, Encrypted Data 26

27 Using Key Recovery Key Recovery is useful when a key is lost, corrupted or unavailable Using KR is voluntary or directed by policy Provided as an explicit service if selected, it must be invoked by an application or a layered service 27

28 The Model for Key Recovery (KR) Participants and their Roles in Key Recovery Recovery Agents: a set of trusted, independent systems that work together to recover keys on demand Participating Parties: users or systems that enable key recovery by generating the key recovery information that is required by their recovery agents Authorized Parties: users or systems that are authorized to recover their keys or someone else s keys from a set of recovery agents 28

29 Key Recovery Concepts (KR) Objects and their Purpose in Key Recovery Key Recovery Fields: information that enables specified key recovery agends to recover a referenced key Key Recovery Policy: a statement defining who must use key recovery, when it must be used, what mechanism must be used, and what KR agents can be used Key Recovery Mechanism: a set of functions that generate and process key recovery fields and recover keys on request 29

30 Phases of the KR Process 0) KR Policy Definition Policy: Encrypt:.. 1) Key Recovery Registration (optional) KR Registration Application Registration Messages Key Recovery Agent(s)/Server 2) Key Recovery Enablement KR-enabled Cryptographic Application A Key_Exch, KRFields, CipherText KR-enabled Cryptographic Application B 3) Key Recovery Request KR Request Application Authorization data, KRFields Key Recovery Server KR Agent-1 KR Agent-2 Decryption Key KR Agent-N 30

31 Key Recovery In CDSA Applications in C Applications in C++ Applications in Java Layered Security Services SSL Method Wrapper Protocol Handlers EDI SMIME IPSEC Common Security Services Manager TPM Mgr CSSM Security API Integrity Context Mgmt CSP Mgr DLM Mgr CLM Mgr KR-API KRM Mgr TPI SPI DLI CLI KR-SPI Security Add-in Modules TP Lib CSP Lib DL Lib CL Lib Key Recovery Service Provider 31

32 Attaching Add-in Modules and Elective Module Managers CSSM Core Service Actions: If cateory is Elective then (1) transparently load module manager (2) perform the attach operation for the add-in module CSP MMgr TP MMgr CSSM CL MMgr Application Hdl = attach( KeyRecov1 ); DL MMgr Mgr for Elective KR Module 1 Mgr for Elective KR Module Installed CSP Modules Installed TP Modules CSP1 TP2 CL1 DL1 Installed CL Modules Installed DL Modules KR Module 2 Installed KR Modules 32

33 Key Recovery APIs - categories Registration - optinal register with KR agents/server Context - create security context for KR enablement Enablement - create KR fields Request - request a recovery by a set of KR agents 33

34 KR and CSP Module Managers Work Together All Module Managers can share state and work together KR Module Manager (KRMM) is a sophisticated module manager understands CSSM security context structure shares state with the Cryptographic MM makes policy decisions 34

35 Portable Credentials One Piece of the Puzzle: PKCS#11 and other HW Tokens

36 Cryptographic Services API APIs appropriate for hardware tokens, software modules, & hybrids CSSM Cryptographic APIs subsume legacy APIs» GCS-API, PKCS#11, Fortezza Cryptoki, etc. Basic Categories of Operations sign/verify digest/hash encrypt/decrypt key operations random number generation GCS-API CSSM API PKCS#11 Help manage parameters and their state 36

37 Enhancements to Fully Support PKCS#11 Service Model New APIs for login/logout, sessions, optional password/pin Extended structures for key formats: reference, wrapped, raw each device slot is one subservice Features Dynamic description of capabilities A-Card B-Card Multi-service add-ins for (CSP + DL) APIs Reader 37

38 Multi-Service Add-in Modules Application Actions: Attach one service module Receive one Handle Use the handle for CSP ops and for DL ops Add-in Module: (1) Implements functions from multiple service categories (2) Registers multiple sets of functions with CSSM TP MMgr Common Security Services Manager TP2 Application: Hdl = CSSM_Attach(pkcs11_guid) CSSM_Encrypt(Hdl, ) CSSM_DL_DataGetFirst(Hdl, ) CSP MMgr CSP1 DL MMgr DL1 CL MMgr CL1 Elective MMgr New Service PKCS#11 Add-in Module 38

39 Adaptation Layers in CDSA CSSM API CSP Manager TPM Mgr CLM Mgr DLM Mgr SPI TPI CLI DLI SPI to SPI Adaptation Layer Native CSP TP Lib C Lib D Lib Legacy Cryptographic Service Provider Example legacy CSPs: BSAFE PKCS#11 HW tokens Fortezza token Data store 39

40 Intel s PKCS#11 Adaptation Layer One implementation of PKCS#11 adapter Inter-operating devices in Intel Labs (today) Rainbow (CryptoSwift, add-in card) DataKey (Smart card) Litronic (ME2000, CryptOS) Fischer (Smart disk) Chrysalis (Luna) New devices under test GemPlus Sign Data S-Card Data Reader A Verify Data Signature S-Card Data Reader B 40

41 CSSM Enhancements Putting it all together, with integrity

42 Integrity Requirements In a dynamic environment, components must authenticate themselves prove identity prove integrity Components must have signed credentials certificate manifest CSSM Module Mgr Attach Who are you? Module Are you the CSSM? Component object modules must be signed 42

43 The Model for Credentials Certificate chain represents trust in a vendor used to prove identity supported by real world licenses Manifest describes the integrity of the module s functional capabilities the module s object code (this is the module) Acknowledgements to Netscape and Javasoft for early work on Manifests (W3C effort w/ Intel) review of Intel s Enhanced Manifests 43

44 An Add-in Module s Certificate A hierarchical chain of three certificates CSSM vendor owns the root certificate Add-in module vendor owns the middle certificate The module owns the leaf certificate Certificate File CSSM Vendor s Certificate (self-signed) Add-in Module Vendor s Certificate (signed by CSSM Vendor) Product Certificate (signed by Add-in Module Vendor) 44

45 A Manifest Manifest File Manifest Sections SectionName: MD5-Digest: Capabilities Object Reference SectionName: MD5-Digest: Capabilities Object Reference 45

46 CSSM Integrity Services Built on an Embedded Integrity Services Library (EISL) EISL Use self_check to establish a trust perimeter CSSM base Use credential-based bilateral authentication procedure to extend trust perimeter to dynamically CSSM base EISL attaching components EISL Module EISL 46

47 Status and Summary

48 Summary of our Response to PKI-TG Evolution new APIs for Cert Life Cycle and Key Recovery modified CSSM APIs based on experience Future enhancements - layered technologies continued work on Object-oriented i/f: e.g., Java, support high level APIs, e.g., GSS, SSPI, etc. provide packagable protocols, e.g., PKCS#12 Documents/Specifications available 13 documents: Arch, APIs, SPIs, Special Srvs 48

49 Categorization of CDSA Documentation Normative Informative Apps Developers CSSM-API, EISL, KR-API 3 CDSA, Signed-Mfests CSSM Developers Add-in Module Developers CSSM-API, EISL, CSSM-EMMI, CSSM-AMmgmt (1 of) {TPI, CLI, DLI, SPI, KRI } CSSM-AMmgmt, EISL 4 3+ CDSA,API, Signed-Mfests CSSM Policy CDSA, Signed-Mfests 49

50 Status of CDSA Reference Implementation Release 1.1.a on the Intel Web site ( for Windows* 95 and Windows NT* statically linked, exportable CSP used in two Intel applications Release 1.2 will be on web site Sept-97 same as release 2.0 minus some APIs Release 2.0 before Dec-97 50

51 Status of CDSA for TOG Fast Track Process Intel is a specification member of the TOG PKI-TG has signed TOG Fast Track Agreement is prepared to present specs for TOG Technical Managers Review in July 1997 is preparing for the normal Fast Track process during August and September 1997 is committed to carefully consider all feedback resulting from Fast Track review 51

52 CDSA Questions for the Panel

53 Example - Limited Strength Encryption or Failure without KR 1. Create Key Handle (side A) Communication Protocol 2. Context Handle HA1 CSSM 3. EncryptData (HA1, msg) KeyExch, Enc(msg) 4. Obtain Key Handle (side B) Communication Protocol 5. Context Handle HB1 CSSM 6. DecryptData (HB1, Enc(msg)) Policy: Encrypt: <= 56 bits or >56 bits + KR Short key encryption or the EncryptData call fails 53

54 Example - KR-enabled Communication 3. Generate Recovery Fields 4. Handle HA2, KRFields 1. Create Key Handle (side A) Communication Protocol 2. Key Handle HA1 CSSM-KRMM 5. EncryptData (HA2, msg) KeyExch KRFields, Enc(msg) Intercept Point 6. Obtain Key Handle (side B) Communication Protocol 7. Key Handle HB1 10. DecryptData (HB2, Enc(msg)) CSSM-KRMM 8. Process Recovery Fields 9. Handle HB2 KR and CSPs are separate, but they work together via the KRMM and the CSP MM Policy: Encrypt: <= 56 bits or >56 bits + KR 54

55 MS CAPI 2.0 as a Multi-Service Add-in Module MS CAPI 2.0 is a multi-service provider cryptographic operations certificate store certificate encode/decode CSSM API CSP Manager DLM Mgr CLM Mgr TPM Mgr SPI DLI CLI TPI Adaptation Layer TP Lib MS CAPI 2.0 Implementation Data store 55

56 A Signed Manifest All signing is performed using the module s certificate Manifest File Signer Information File Signature Block File Manifest Sections SectionName: Name: MD5-Digest: Capabilities SectionName: Name: MD5-Digest: Capabilities Relative File Name Digest of object refenced by Name URL Digest of object refenced by Name Signer Info File SectionName: Name: MD5-Digest: Capabilities Manifest Section Identifier Hash of Manifest Section Hash of Signature Info File PKCS#7 Signature Block SectionName: Name: MD5-Digest: Capabilities In Memory Digest of object refenced by Name Digest value Signature Block Encrypted Hash Value 56

57 System-wide Policy Compliance A system-wide policy can be defined constrains the use of security services» restrict certificate creation or cryptographic opers specified by a certificate and signed manifest CSSM can provide generic mechanisms to record and test for policy compliance record and protect system-wide policy at CSSM install check service provider s capabilities at service provider install and attach check function calls against system-wide contraints 57

58 Credential Verification Procedure A six step procedure packaged as two functions in the EISL 1. Verify the certificate chain 2. Verify the signature on the manifest 3. Verify the digest values for each of the manifest sections 4. For each manifest section, verify the digest value on each referenced object code file 5. Verify secure linkage» verified object code is the code you are about to invoke» or the code that invoked you 58

59 Bilateral Authentication Performed as the first phase of ModuleAttach processing Six step procedure 1. CSSM performed a self integrity check 2. CSSM performs an integrity check of the attaching module 3. CSSM verifies secure linkage by checking that the initiation point is within the verified module 4. The add-in module performs a self integrity check CSSM Module Mgr Attach 5. The add-in module performs an integrity check of CSSM Who are you? Module Are you the CSSM? 6. The add-in module verifies secure linkage by checking that the function call originated from the verified CSSM Use EISL functions 59