Dipl.-Ing. Stephan Grill Hewlett-Packard Österreichmembers.aon.at/~sgrill/downloads/19980128 PKI im Unternehmen.pdf© HP Austria / Stephan Grill / 9/15/2003 PKI im UuW.ppt / Page

© HP Austria / Stephan Grill / 9/15/2003PKI im UuW.ppt / Page 1

Public Key Infrastructureim Unternehmen

Dipl.-Ing. Stephan GrillHewlett-Packard Österreich


Cryptography 101

• Secret Key Algorithms– one shared secret key– e.g. DES, RC4, IDEA, Blowfish, CAST, …..– Problem - Key Management

• Public Key Algorithms– one private (secret) key and one matching public key– e.g. DSS, RSA, ECC, Rabin, ElGamal, …..– Problem - Certificate Management

• Certificates - means to trustfully manage public keys


Use-Cases

• E-Mail Encryption and Signing - S/MIME, PGP• E-Commerce - SET• Session-Encryption - SSL, TLS• IP-Encryption - IPSec, ISAKMP/Oakley, SKIP• Secure DNS - DNSSEC• Authentication of Pictures


Certificates

• A certificate is a digitally signed binding of a public key and additional information.

• In most cases, the additional information indicates the identity and affiliation of the public key and matching private key's owner.

• Signing is done by a trusted Certificate Authority using it's private key.

• Verification of the CA's signature on the certificate is done with the CA's widely distributed public key.

Subject's Information: Name, Organization, Address

Subject's Public Key

Certificate Validity Dates

Certificate Serial Number

Certificate Issuer's Name and SignatureCA


X.509 v3 Certificates

Type Criticality Value

Version (of Certificate Format)

Certificate Serial Number

Signature Algorithm Identifier(for Certificate Issuer's Signature)

Issuer (Certification Authority)X.500 Name

Validity Period(Start and Expiry Dates/Times)

Subject X.500 Name

Subject Public KeyInformation

Issuer Unique Identifier

Subject Unique Identifier

Extensions

Certification Authority'sDigital Signature

Algorithm IdentifierPublic Key Value

} version 2

version 3{optional

GenerateDigital

Signature

Certification Authority'sPrivate Key


Certificate Extensions

• Type– e.g. simple text string, numerical value, date, graphic,

or complex data structure– to promote interoperability, all extension types should

be registered with an internationally-recognized standards organization.




• Criticality– single-bit flag; indicates that the associated extension

value contains information of such importance that an application cannot ignore the information.

– if a particular certificate-using application cannot process a critical extension, the application should reject the certificate.




• Value– contains the actual data for the extension.– the format of the data is reflected in the extension type

field.



Certificate Standard Extensions

• Extensions for– Key Information (e.g. Key Usage)– Policy Information (e.g. Certificate Policies)– User and CA Attributes (e.g. Subject Alternative Name)– Certification Path Constraints (e.g. Basic Constraints)


Keys and Certificatesneed to be managed

• Generation of Key-Pair(s)• Private Keys– Storage of the Private Key– Key Recovery/Escrow– Expiration or Renewal

• Public Keys– Creation of Certificate– Storage and Publication of Certificate– Renewal, Revocation and Expiration of the Certificate


RegistrationDeregistration

A Simple PKI

End-Entity EE (User)

Registration Authority RA

Certification Authority CA

Repository Certs/CRLs

Cert RequestCert Issuance

Cert/CRL Publish

Cert Validation


End-Entity / UserPrimary Tasks

• Generates Keys• Stores private keys securely• Applies private keys to– sign “outgoing” messages– decrypt “incoming” messages

• Uses public keys from certificates to– verify signatures of “incoming” messages – encrypt “outgoing” messages

• Validates certificates using CRLs in a repository


Certification AuthorityPrimary Tasks

• accept initial certificate requests from RA• accept certificate renewal requests from RA• issue certificate• publish certificate (to directory service)• accept certificate revocation request from RA• revoke certificate• publish CRL (to directory service)• accept cross-certificate request from another CA• issue cross-certificate• publish cross-certificate• define and enforce Certificate Practice Statement CPS


Registration AuthorityPrimary Tasks

• authenticate users (on-line or out-of-band procedure)• submit initial certificate request for end-entity to CA• submit certificate renewal request for end-entity to CA• submit revocation request for end-entity to CA• key generation for end-entity (optional)• submit private key archival request (optional)


Directory Service (LDAP)Primary Tasks

• Publishes Certificates• Publishes Certificate Revocation Lists CRL

• Issues and Considerations– Problems with CRL latency (time granularity)– The security of certificates and CRLs is self-contained– The information in the directory, in particular

certificates, may contain information which could be considered somewhat private.


Additional ServicesTime Stamping Authority TSA

• Associate a message with a gve point in time to provide a “proof of existence”

• Verify only the time; the TSA does not examine or verify the data being time stamped or the requesting entities in any way.

• Only time stamp a hash representation of the message.

• Important service but rarely implemented.


Additional ServicesNotary Authority NA

• Validate the correctness of the enclosed digital signatureusing all appropriate status information and public key certificates and produce a signed notary token attesting to the validity of the signature, if asked by the requester.

• Validate, according to PKIX part 1, the enclosed certificate and its revocation status at the specified time using all appropriate status information and public key certificates and produce a signed notary token attesting to the validity and revocation status of the certificate, if asked by the requester.


Trust Model for CAs

• Hierarchical– ultimate point of trust is the

root CA– certificate path goes from

root CA to EE– e.g. SET, PEM

• Network (Cross-Certification)– EE trusts ist own immediate

CA– certificate path goes from

one EE to the other EE– e.g. PGP


Risks of this Architecture

• Private Key of CA is compromised– all certificates and CRL signed by that CA are

compromised– protect against read access

• Public Key of CA is „modified“– malicious Certs/CRLs can be generated with matching

private key– protect against write access

• Private key of EE is compromised


ConsiderationsHow many key pairs are required for an EE ?

• One key pair for encryption and signature (e.g. SSL, PGP)• One key pair for encryption and another key pair for

signature (e.g. SET)• Administration requirements for encryption and signature

key pairs are different– key generation (at EE, RA, CA)– key backup– dual key pair approach is preferred


ConsiderationsApplikation Integration

• How many applications are integrated with the PKI ?– E-Mail, NW-Encryption, VPN, …

• How can applications be integrated with the PKI ?– Is a toolkit available ?– Does the toolkit conform to a standard ?

• Certificates currently hardly interoperate acrosss applications.


ConsiderationsWhat‘s in a Certificate

• What does the certifiacte actually state ?• How is the semantics enforced and managed ?• How are different meanings dealt with when using cross

certifying CAs ?• Management of the required policies.


PKI Architecture

CertificationAuthority

KeyArchive

EventManager

PKI KernelApplication

PKI Client

Toolkit(s)

Crypto-Libraries

PSE

SmartCard

Adm

inistration

RegistrationAuthority

Repository

SCMS

DigitalTimestamp

Service

NotaryService Audit Trail


Requirements for an Enterprise PKI

• Transparent operation for users - existence of certificates should be invisible to the user– one button for encryption– one button for digital signature– automatic renewal of keys and certificates

• Possibly key backup and recovery for encryption key• Key used for signature should be kept only by the EE• Support for hierarchical and cross-certification• Toolkit to integrate client applications• UI to match the security organisation of a company


Standards for a PKIProtocol Level

• ITU/OSI based• RFC 1422 ff - targeted for PEM• PKIX - Public Key Infrastructure for the Internet• SPKI - Simple PKI– Carl Ellison/CyberCash et al. for IETF

• SDSI - Simple Distributed Security Infrastructure– Ronald Rivest/RSA, Butler Lampson/MS

• SPKM


PKIX

• Strong support from the industry (except MS ?)• Part 1: X.509 Certificate and CRL Profile– profiles format and semantics of certificates and CRL

• Part 2: Operational Protocols LDAP v2– addresses requirements to provide access to Public

Key Infrastructure (PKI) repositories – based on the Lightweight Directory Access Protocol

(LDAP) v2, defined in RFC 1777) defining a profile of that protocol for use within the IPKI.


PKIX

• Part 3: Certificate Management Protocols• Part 4: Certificate Policy and Certification Practices

Framework• Part 5: Time Stamp Protocols• Part 6: Notary Protocols


SPKI/SDSI 2.0

• just emerging• avoids ASN.1 complexity• Lisp oriented syntax• convenient Naming Concept• does not support revocation of certificates


Emerging Standards for a PKIOn the API Level

• Common Data Security Architecture CDSA– by Intel Corporation– DRAFT Release 2.0, June 16, 1997– now part of The Open Group activities– supported by Netscape, IBM, HP, ….– quite some attention on recent RSA conference

• MS Crypto API• GSS-API, IDUP GSS-API


Common Data Security ArchitectureApplications

Layered ServicesTools

MiddlewareLanguage Interface Adapter

CSSM Security API E1 API

SystemSecurityServices

CommonSecurityServicesManager

SecurityAdd-inModules

CSSM Core ServicesIntegrityServices

Security ContextManagement

TPM Mgr CSP Mgr DLM Mgr CLM Mgr E1 Mgr

TPI E1-SPISPI DLI CLI

TPLib

CSPLib

E1Lib

DLLib

DLLib


CDSASystem Security Services

• Define high-level security abstractions(e.g. secure electronic mail services)

• Provide transparent security services(e.g. secure file systems or private communication)

• Make CSSM security services accessible to applications developed in languages other than the C language

• Provide tools to manage the security infrastructure


CDSACommon Security Services ManagerCSSM Security API E1 API

Security ContextMgmt

General ModuleMgmt

IntegrityServices

Elective MM Services

Core Services

DLITPI SPI E1-SPICLI

dispatch

TPM Mgr

dispatch

CSP Mgrdispatch

CLM Mgr

dispatch

CSP Mgrdispatch

E1 Mgr

TPLib

CSPLib

DLLib

CLLib

E1Lib

dispatch

DLM Mgr


CSSM - Categories of Services

• CSSM defines four basic categories of service and their corresponding managers:– Cryptographic Services Manager– Trust Policy Services Manager– Certificate Services Manager– Data Store Services Manager

• Two additional CSSM core services include:– integrity services– security context management


Summary of Current Status

• PKI is a useful tool for secure authentication and protection of privacy

• Very versatile tool• Many products (of varying quality) available and

emerging• The maturity of a PKI can be measured by how many

applications have been integrated• Very good tools available to increase Enterprise security

considerable


H Seminar

Einführung in die Verschlüsselungstechnik

Donnerstag, 19. Februar 1998

Documents

Dipl.-Ing. Stephan Grill Hewlett-Packard Österreichmembers.aon.at/~sgrill/downloads/19980128 PKI im Unternehmen.pdf© HP Austria / Stephan Grill / 9/15/2003 PKI im UuW.ppt / Page