PKI Tutorial Model Policy Workshop

PKI TutorialModel Policy Workshop

Ann Geyer - Bill Pankey

tunitas @ earthlink.netwww.tunitas.com

925-631-1244

Session Goals

Prepare participants for Workshop– Language and application of public key cryptography – Meaning and use of digital certificates and signatures

mechanics of certificate use lifecycle of digital certificate

Develop common understanding of PKI

– Potential sources of “trust” in a PKI and its use

Introduce the components of a Certificate Authority– Role and substance of Certificate Policy & Practice Statements– Software components and business functions

Introduce relevant standards– From IETF -- PKCS and PKIX– From ABA -- Digital Signature Guidelines– From NACHA -- CARAT Guidelines

Agenda

Authentication in Healthcare

– Overview of the problem set

Cryptography Basics

– Security foundation in open networks

Digital Certificates

– Structure of authentication “credentials”

Certificate Issuance and Management

– How certificates are created, maintained, used, and revoked

PKI Trust Models

– How trust can be extended to unknown parties

Certificate Policies

– Support the use of certificates by third parties.

Authentication in Healthcare

Module 1

Authentication in HealthcareRequirements

Authentication is designed to positively corroborate identity of remote user or electronic correspondent

– Necessary component of any network security solution authentication - authorization - access control - audit

– Necessary condition for disclosure of patient identifiable data HIPAA, HCFA Internet Policy, industry good practice

Healthcare authentication has specific requirements

– Support unique individual identification as required by HIPAA

– Recognize persistent personal roles (e.g. physician) roles assigned to individuals independent of resource or organization

– different organizations respond to a role in a similar waye.g. all plans contract with physicians as providers and so have similar authentication requirements

roles may have presumptive access privileges and disclosure permissions

Authentication in HealthcareRequirements

Healthcare authentication has specific requirements (cont)

– Must respond to industry reliance on “proxy” roles assigned independently of resource by principal, e.g. provider staff

Healthcare context impacts authentication

– Multiple affiliations

– Mesh Industry

– Heterogeneous business relationships

– Heterogeneous computing platforms

– Cost Avoidance

– Regulatory Scrutiny

– Risk Avoidance

Authentication in HealthcareValue of PKI

Digital certificates & PKI have gained tentative acceptance as the solution with greatest potential

– Can be very secure if authenticated persons accept personal responsibility for key integrity

– Can be highly scalable if plans and provider institutions can take advantage of common shared CA

resources– Can acquire high degree of provider acceptance

if solution simplifies provider requirements to authenticate self and staff to a large number of resources

– assumes that plan & institutions will use common CA resources – Can reduce regulatory risk

if there is explicit industry recognition of common solutions if HCFA supports the creation and adoption of defacto standards and solutions

(HCFA policy & Internet “trial”)– Can be low cost security solution

unbundles authentication from application and resource allows cost sharing based on a common industry solution

Authentication in HealthcarePKI Collaboration

Several collaborative models that aim to facilitate a common solution

– Healthcare specific rootCA requires significant industry commitment but lacks suitable model

– Domain specific policy management instantiated in the userType Management Model

– CMA model for a physician PKI proposed by Tunitas Group involves collaboration specific to classes of persons and organizations leverages existing professional and trade associations

– vision generally lacking within association management

– Promulgate defacto standard CA vendor for some user classes (buying coalition) failed model; excluded vendors have no choice but to respond by working to fracture

the coalition or otherwise abandon the market

– Develop and standardize on the common healthcare certificate requirements to have greatest impact on interoperability . . .

Authentication in HealthcareInteroperability Issues X.509 Standardization

– Defacto implementation standard for digital certificates– Flexibility at the risk of voiding interoperability

uneven support for multiple algorithms – Reliance on imputed semantics at the risk of voiding interoperability

e.g. special interpretation of DN inserting comments as ou= ; e.g. special use of “serial number” say by inserting Employee ID,

Certificate Extensions– Certificate Profile publishes locally defined fields– Provides semantics not supported by X.509 standard

e.g. certificate Type or Class– Must be understood within domain or otherwise risk voiding interoperability

Certificate Policies– Policies define appropriate applications of certificate– Meaning and trustworthiness of certificate depends on policy

reliance on certificate is by definition reliance on policy– Interoperability implies common understanding of policy

Authentication in HealthcareWorkshop Goals Build a FRAMEWORK for consistent and potentially

interoperable healthcare PKI implementations by independent certificate authorities

– Common healthcare certificate policies and framework

– a Policy Authority provides a sustainable governance model

Provide a forum for continuing PKI collaboration

Advance the general understanding of PKI issues and healthcare’s Internet use– Additional Tunitas Group seminars

Healthcare use of Internet Mail (late Q1 - Q2)– s/MIME -- locus point for encryption, SMTP alternatives

Access control for health Information (Q3)– multi-level access control using client certificates, directories, and SSL

(technical seminar on the use of SSL in conjunction with authorization DB - includes NSAPI & ISAPI)

Secondary Goals

Authentication in HealthcareTest Case Applications

Workshop solutions will support authentication mechanisms required by:

– Internet Mail

– Exchange of patient data through extranet

– Non-reputiation of electronically submitted forms

– EDI over the Internet (EDIINT)

– Electronic communication with patients/members

Will use these applications as test cases

Authentication in HealthcareInternet Mail

Internet mail security requirements – Encrypt messages to protect the confidentiality of message content– Provide assurance of correspondent authenticity

needed for both senders and receivers mail addresses and context are not adequate for authentication

– Two potential models proprietary “mail” - mailboxes hosted on a secure server

– implies “secure file transfer” ability– requires partners to support correspondents’ mail processes

SMTP mail– messages must be “cryptographically enveloped” and self-authenticating

s/MIME is the defacto secure Internet mail standard– HCFA explicitly acknowledges suitability of this protocol– s/MIME is supported by all browsers ( 3.x and later)

s/MIME protocol requires authentication using digital certificates

Authentication in HealthcareFile transfer across Extranets

Requirements

– Mutually assure client & server authenticity

– Protect file integrity and confidentiality during network transit

– Leverage existing client software (e.g. browsers)

– Support connectivity solutions of trading partners

SSL is the defacto internet standard for secure client server exchange

– Provides authentication and “negotiates” encryption parameters

– HCFA explicitly acknowledges its suitability

– Software support found in all browsers (3.x and later)

– “Session layer” protocol which supports HTTP& FTP (among others) also object communication with IIOP/SSL and telnet/SSL

SSL requires digital certificates for authentication

– Supports weaker client authentication using login / pswd (optional)

Authentication in HealthcareForm Signing

Requirements

– Provide non refutable assurance of the identity of an electronic form submitter protect against fraud in Medicare billing; anticipated HCFA requirement

– Bind the electronic signature to the electronic document SSL binds identity to a session and only indirectly to the information submitted

– Leverage existing client software and language-level APIs

Digital Signature is the defacto standard for electronic signature

– HIPAA mandates that healthcare electronic signature will be a digital signature

– Supported by existing language-level API (JavaScript; Java) and current browser editions

Digital signatures require digital certificates of signers

Authentication in HealthcareEDI over the Internet

Requirements from HCFA & HIPAA

– Mutual authentication of trading partner EDI processes

– Encryption

EDIINT is the established protocol for exchanging structured messages (EDI) over the Internet

– Place structured messages in s/MIME envelope

– Use transport protocol of choice (FTP, HTTP, SMTP )to communicate enveloped EDI

– EDIINT recommendations include message disposition notification to support receipt and delivery guarantee

EDIINT requires that certificates be issued to trading partner EDI resources

Authentication in HealthcareCommunicating with Patients Benefits

– Member/patient satisfaction - JAMA reports increased email communication between physicians and patients

Need guidelines for appropriate use. Without guidelines and true authentication, providers significantly exposed

– Support future Privacy Act required patient authorization before disclosure

Requirements– Positively identify unique patient. Requires corroboration of patient identifier beyond

just name. National Patient Identifier ? < not likely >

– Positively identify appropriate parents/caretakers– Assurance that patient is using appropriate encryption software – Support very large scale authentication solutions

Digital certificates can support required authentication– Can be used to bind person identifiers to patient / member ID– Portability across computing platforms– Large scale deployments anticipated

Authentication in HealthcareCommunicating with Patients Digital certificates support the requirements and are expected to be deployed into

consumer markets– Certificate based security used for corporate intranets and next generation network OS (NT5,

NetWare 5) potential to leverage authentication solutions used for the purchaser’s intranet to support

member communication with health plans and providers, e.g. Netscape employee communications with Prudential Health Plan

– Financial services SET (electronic bank card) initiatives– Some other drivers

smart cards in university environments, UCLA certificate project Province of Ontario to issue certificates to entire population !!!

Include certificate on “smart card” member enrollment card

Issue member certificates in conjunction with service

Most solutions will requires patient/member directory– Digital certificates for members– Online application to bind patient provided credential to unique patient identifiers– Publish to providers and staff

Cryptography Basics

Module 2

Cryptography Basics

What is Cryptography?

Secret Key Cryptography

Public Key Cryptography

Message Digest

Digital Signature

Standards

Software Considerations

Cryptography BasicsWhat is cryptography?

The art of scrambling information into gibberish in a way that allows for a secret method of unscrambling

Ancient roots

– From the Greek: (secret) + (writing)

– substitute letter with one appearing k digits later

example: {(d,a) (e,b), etc} Earliest documented use attributed to Julius Caesar Most popular use in Captain Midnight Secret Decoder Rings

Provides for multiple services

– Confidentiality - controlling who can read and correctly interpret messages

– Integrity checking - assure that message is unaltered

– Authentication - verifying identity

Represents information as numbers where the numbers are the result of some mathematical manipulation

Terminology:

Cryptographic schemes usually involve:

– Algorithm usually public but can be secret knowledge of algorithm alone is insufficient to decrypt ciphertext

– Secret value (key) shared by good guys analogous to the combination for a combination lock

Cryptography BasicsWhat is cryptography? (cont)

plaintext ciphertext plaintextencryption decryption

Cryptography BasicsWhat is cryptography? (cont)

Fundamental Tenets of Cryptography– Algorithms that have successfully withstood continuous scrutiny and challenge are not

easily compromised algorithm “owners” encourage attacks by offering rewards to those who successfully

challenge the algorithm’s strength– Cryptographic algorithms are efficient to compute– The number of potential keys is extraordinarily large

set of all possible keys known as the keyspace

Security of strong algorithms depends upon the size of keyspace– Effectively, the only known attacks would be brute force attacks

exhaustively attempt decryption with each possible key until something intelligible is recovered

practical strength of the encryption is a function of:– available computing power– size of key (40 bit, 56 bit, 128 bit)

Cryptography BasicsSecret Key Cryptography

Single key for encryption and decryption– typically used for “bulk” encryption– referred to as “symmetric key” cryptography

Encryption algorithm

Decryption algorithmciphertextplaintext plaintext

secret key (k) secret key (k)

secure channel

insecure channel

Cryptography Basicsblock encryption example

Th e quick brown fox will meet the lazy dog behind the woodshed tonight at midnight.Bring plenty of catnip.

0 1 0 1 0 1 1 10 0 1 1 1 0 1 1 . . .S1

1 1 0 0 0 0 1 00 1 0 0 1 0 1 0 . . .S8

8 bit substitution functions derivedfrom the key

64 - bit intermediate

64 - bit output

permutations possiblybased on the key

loop for nrounds

0 1 0 0 0 0 1 10 1 1 0 1 0 1 0 . . .ciphertext

A5 73 30 6B 7B 27 E6 7C D4 77 6A 5A 79 F5 68 35 82 0D FF EA F1 ...

plaintext coding

Cryptography Basics Secret Key Cryptography (cont)

Example

1 Alice encrypts message using key, K

2 Alice securely shares K with Bob

3 Alice transmits ciphertext to Bob over insecure channel

4 Bob decrypts ciphertext using K

Issues

– Alice and Bob must agree upon choice of algorithm

– Key Management - Alice and Bob must securely communicate shared key

out of band via some private method in band using public key methods

Cryptography Basics Secret Key Cryptography (cont) Advantages

– Relative “simplicity”

– Computational efficiency linear “computational complexity” i.e. proportional to message length

Some Algorithms

– DEA (data encryption algorithm) AKA DES - (Data Encryption Standard ) currently FIPS* encryption multiple variants 40 bit, 56bit, triple DES (112bit,168 bit) 56 bit DES current defacto standard for bulk encryption

– AES (Advanced Encryption Standard) once selected will replace DES as the FIPS candidates include CAST-256, DEAL, RC6, SAFER+

* Federal information processing standard

Cryptography Basics Public Key Cryptography

Different but related keys for encryption and decryption– typically used for “signature” and key exchange

– aka, “symmetric key” cryptography

– related keys called key pair - private key & public key


Decryption algorithm

ciphertextplaintext plaintext

public key (k) private key (k*)

insecure channel

reliable channele.g.. secure directory

Cryptography BasicsPublic Key Cryptography (cont)

Fundamental Tenets of Public Key Cryptography

– What the public key encrypts, the private key decrypts, and

what the private key encrypts, the public key decrypt

– As a practical matter, security is based on the non-feasibility of computing one key from knowledge of other key

deriving the private key from the value of a public key is involves solving what is known as a hard problem

In RSA this is equivalent to finding prime factors of very large numbers– all known solutions are computationally very complex – computational effort grows exponentially with size of number

– In practice, security depends upon keeping the association of public and private key secure

Cryptography BasicsPublic Key Cryptography (cont)

Ownership

– Public key pairs are “owned” and identified with persons or other entities

– Ownership of public key is published and widely known; the related private key kept under strict control of owner

Example

1 Alice encrypts message using Bob’s public key

2 Alice transmits cipher text over insecure channel

3 Bob decrypts message using Bob’s private key

Cryptography BasicsPublic Key Cryptography (cont) RSA: example of public key algorithm

– First practical public key algorithm widely implemented; defacto international standard for signatures

– Public keys are very large prime numbers, typically 1024 bits (~350 digits) or larger density of primes decreases with size, require very large primes to assure an effectively

large key space– Encryption / decryption involves exponentiation with keys

computational requirement limits practical use to small plaintext

Other Public Key Examples– Digital Signature Standard (DSS)

digital signature only– Diffie-Hellman Key Exchange

used with DSS for key exchange– Elliptic Curve Cryptosystem (ECC)

order of magnitude more complicated and stronger than RSA implemented in chips for niche markets high performance / more efficient use of key space than RSA

Cryptograhy BasicsRSA encryption example

num bercruncher

0 1 0 1 0 1 1 10 0 1 1 1 0 1 1 0 1 0 1 0 0 1 00 0 1 0 1 1 1 0 0 1 0 1 0 0 1 01 1 1 0 1 1 1 0 0 1 0 1 0 1 1 00 1 1 0 1 0 1 0

mySecretKey

encoded m essage = m (a num ber)

<k,n> (a pub lic key)

mk

(exponentia tion m odulo n )

a5 73 30 6b 7b 27 e6 7c d4 77 6a 5a 79 f5 6835 82 0d ff ea f1 2e da 10 53 68 6a 11 eb 42dd 59 0d ba 41 4c 41 0e b f d5 9c 82 90 4c 1c21 8b 44 0e 6a 51 d8 21 ad 52 18 b f a0 d7 ce0a 2e e6 b9 0c 2a db b6 79 e f

ciphertext

exponren ts a re ve ry la rge (on the o rde r o f350 d ig its i.e .1024 b its )decryp tion s im ila r;

use re la tedpriva te key, k*

s tandard encod ing o f m essage (P K C S #1) B E R (bas ic encod ing ru les ) D E R (d is tingu ished encod ing ru les )

m od n = c (c iphe rtex t)

cK*m od n = m

Cryptography BasicsMessage Digest

Summarizes content of message– Aka “one-way hash”– Maps variable length message into fixed length digest

Fundamental properties of message digest– “One way” function

message determines digest; digest does not uniquely determine message

– Easy to compute, hard to invert Digest verifies message integrity

– Compute message digest – Compare with a digest transmitted with the message

requires secure channel or “signature” Examples

– MD5 (Message Digest 5) - 128 bit digest– SHA (Secure Hash Algorithm) - 160 bit digest

Cryptography BasicsPublic Key Digital Signature


private key (k)


public key (k*)

insecure channelMessage Digest

message’s digital signature

hash

sign

Recompute digest and compare w/ transmittedsignature

verify

reliable channele.g. secure directory

Verifies origin & integrity of transmitted message

Cryptography BasicsPublic Key Digital Signature (cont)

Supports non-repudiation

– Signature confirms application of signer’s private key only holder of private key can generate identical signature

– Requires protection against invalid public key PKI or secure directory provides that protection

Can be combined with encryption to support both confidentiality and non-repudiation

insecure channelgenerate key and sign

Cryptography BasicsExchange of Session Keys


Bob's public key (k)


Bob's private key (k*)

encrypted session key

reliable channele.g. secure directory

Using public key encryption to exchange a symmetric (session or message) encryption key

Alice

bob

extract key and verify signature

Cryptography BasicsStandards

Symmetric key standards from NIST

– DES

– AES

– Federal Information Processing Standard (FIPS)

Public Key Cryptography Standards (PKCS)– Promulgated by RSA– Multiple parts supporting different aspects of public key crypto

some PKCS standards are superceded by PKIX– Examples

PKCS #1 (Public Key Standard) signing and encrypting with RSA PKCS #7 (cryptographic message syntax) PKCS #11 (crypto standard for smart cards, PCMCIA devices) PKCS #13 (elliptic curve cryptosystem) signing and encrypting with ECC

Cryptography BasicsComputer Issues

Sources of transparent (to the app) support for cryptography

– Operating system NT, Novell NetWare

– omnipresent in next generation OS

– Application Server Platforms session layer encryption

– e.g. Netscape SuiteSpot or other SSL compliant

Security Frameworks to embed cryptography services into applications

– Does not require extensive cryptography knowledge may be appropriate for enabling legacy applications

– RSA PKI Framework

– Netscape Security Services

– IBM KeyWorks

Cryptography BasicsComputer Issues

Major Cryptographic APIs (CAPI)– Use requires knowledge of cryptography basics

to manage cryptography functions requires modules that support low level cryptography functions

– CDSA (Common Data Security Architecture) applications can be written as algorithm independent supports “pluggable” crypto

– Microsoft CryptoAPI proprietary version of pluggable crypto

– GSS (Generic Security Service) distributed protocols, e.g. peer entity (object) authentication IETF developed and supported

– JAVA Security API

“Cryptographic Service Providers” (toolkits)– code modules that implement cryptography algorithms

RSA, Microsoft CSP, Cyclink, Certicom …

Cryptography BasicsBasic References Good Textbooks

– Network Security, Private Communication in a Public World Charlie Kaufman et al (mathematical introduction)

– Applied Cryptography: Protocols, Algorithms and Source Bruce Schneier (classic text)

– Email Security Bruce Schneier (informal introduction)

Cryptography resources on the Internet– RSA Laboratories; http://www.rsa.com

leading crypto vendor; links– CounterPane Systems; http://www.counterpane.com/

Bruce Scheier’s company includes an online crypto course and critical analyses of current events

– Microsoft http://www.microsoft.com/security/tech/cryptoapi/default.asp?ID=22&Parent=4

FAQ, links and information on MSFT’s CryptoAPI


Module 3


What are digital certificates?

Architecture

– Subject identification

– Algorithms and attestations

– Extensions

– Form and format

Implementation

– Ownership assumptions

– Software considerations and models

– Hardware devices

Relevant Standards

Digital CertificatesWhat are digital certificates?

A “credential” that identifies a person, resource or “entity”

Formally, a signed data structure

– Specifies that a specific public key is owned by a specific named entity

– Generally, ownership of public key implies “exclusive” control of related private key

– Named entity can be person, server, software agent or other object

– Signature “binds” the public key to its named owner (subject)

Support attribution of private key use to the subject

– Allows for encrypt messages for specific individual without prior key exchange

– Non reputation of digital signature

Used extensively in Internet security protocols

– s/MIME, TLS / SSL, IPsec

Digital CertificatesWhat are digital certificates? (cont)

NamePublic KeyAttestation

Certificate

Name

EntityPublic Key

Private Keycontrols use >

/ owner

1

1

1

1

Issuer

1 *

signs >

bind

s >

1

*

Digital CertificatesArchitecture - Required Info

Certificate Information

– Serial Number - unique to certificate authority

– Validity period date first valid / date expired

– Signature algorithm

Authority Information

– Unique name of issuer

Subject Information

– Unique name of subject

– Subject public key

– Subject public key algorithm (usually RSA)

Digital Signature

– Using issuer’s private key

Digital CertificatesArchitecture - Optional Info Standard Extensions support additional CA attestation

– Subject and Issuer Attributes e.g. altNameExtension Used to further identify certificate actors

– Key Use e.g. certificateType Defines intended use by class of application

(s/MIME, SSL. …)– Certificate Constraints

e.g. pathLengthConstraint Limits certification chain, i.e who can use the cert e.g. nameConstraint Restricts signing ability to specific X.500 subtree

– Policy Extensions Identify policies of CA used to issue this certificate

Extensions may or may not be “critical”– Relying party must be able to meaningfully process extensions. If not, then the certificate can not

be used for authentication and must be rejected Reliance on certificates forces prior recognition of the CA’s practice statement prior to

certificate use

Digital CertificatesArchitecture - Customization

Custom Extensions support additional requirements imposed by a CA or user community

– Support added semantics of user community e.g. Specialization e.g. nationalProvbiderIdentifier e.g. authorizedDelegateFor

– Attribute values will be attested to by CA CA must leave unspecified if unknown

– Standard syntax for definition (ASN and BER)

“Certificate Profile” includes

– Definition of all custom extensions

– Standard extensions

– Algorithms

Digital CertificatesCMA MediPass example

See la

st pag

e for r

eadab

le vers

ion

Digital CertificatesArchitecture - Subject DN

Subject Distinguished Name (DN)

– Name for the public key owner

– Follows the X.500 distinguished name format e.g.. cn=common name, ou=department name, o= organization, c=country X.500 provides standard “components of DN” can use other DN components

– e.g. uid=userID, e=email address, l=locality– vendor support sometimes uneven for other than c=, o=, ou=, c=, e=

– X.500 presumes unique DN for every individual based on subordination and location

– X.509 anticipates but does not require assigned DN’s will be “globally” unique uniqueness defined and enforced within a domain

Digital CertificatesArchitecture - Subject DN (cont) Namespace design is a critical cost factor

– Robustness of certificate solution is dependent on the stability of DN change in DN requires reissue of certificates benefit of stable name assignment

– Require simple solutions to avoid name “collisions” arbitrary jDoe, JohnDoe, JohnDoe1, JohnDoe2

solutions are costly to create and support

Namespace design is a critical interoperability factor– Interoperability implies cross domain recognition & meaning

problematic for providers with multiple affiliation problematic for providers known in different contexts

– cn=DrBobJones, ou=HillPhysicians, o=BlueShieldHMO– cn=DrBobJones, ou=DrBobJonesPA, o=BlueCrossPPO– are these the same person?

AXIOM: Names that may be simple for the issuer may be complex for the subject and unrecognizable by the subject’s peers

Digital CertificatesArchitecture - Subject DN (cont)

Namespace design considerations

– Subject “distinguished name” (DN) should be meaningful unique in some well defined context

– reflect real world ways in distinguishing real world entities simplifies certificate management

– Robustness requires simplicity and stability across multiple affiliations for typical providerPersons organizational restructuring

– e.g.. cn=DrBobJones, ou=FriendlyHills, o=TakeCare

– Interoperability requires mutual understanding of namespace root names in broadest context

– Flatter structures are more stable but uniqueness bigger issue e.g. e=emailAddr, cn= common name, ou=Physician, o=CMA.org eg. uid=MedLicense#, l=state, o=physicianPersons

Digital CertificatesArchitecture - Alternate Names

subjectAltName used for optional name attribute

– Allows additional (1 or more) identities to be bound to certificate

– Options include: electronic mail addresses DN names, e.g.

– subjectAltName=4567829.PP0.BlueShield IP addresses URI (uniform resource identifiers) other X.500 names !!! locally definition

– Issuer must confirm each subjectAltName

– Not well supported in client software browsers generally don’t parse and display

Digital CertificatesImplementation - Ownership

Digital certificates contain only PUBLIC information

Public key & certificate “owned” through control over the related private key

– Private key maintained in some sort of persistent store, for example: desktop “key rings” protected by owner selected/maintained passphrase

– browsers and mail clients– PKCS #12 provides specification

hardware devices under physical control of owner– PCMCIA (fortezza) cards, JAVA crypto rings, chip cards

– Model does not imply that use control must be direct for example, model can support “proxy management” by subject

– proxy maintains private key, subject control's proxy’s use of subject’s private key by a client application

– requires high degree of trust in proxy & special liability model

Digital CertificatesImplementation - Netscape

Private Key Management in Netscape 4.x

– Client certificates are maintained in certificate DB on the desktop (cert.db)

– When first issued a certificate, subject assign passphrase to protect key ring

– Owners can assign a variety of security levels to key ring, e.g.: prompt for password once a session prompt for password every time a certificate requested

– Netscape also supports interface to external key storage, e.g. smart cards through PKCS #11 interface

Demo

Digital CertificatesIssues - Portability Private keys are typically installed on PCs, but users want workstation

independence

Two approaches:

– Export key ring to portable media (floppy) and reinstall on other devices as needed, i.e. “backup to disk”

PKCS #12 defines similar procedure for key backup

– Install private key to portable device such as smart cards, PCMCIA devices, crypto rings

PKCS #11 provides Crypto API for these devices– Netscape support

device manufacturers provide interfaces to browsers and mail clients 2 factor authentication model

– insert device (e.g. smart card)– respond to password prompt to “unlock” key ring

Digital CertificatesSmart (Chip) Cards Anticipated to be principal store for client certificates

– Standards are complete

– Microsoft & Intel include smart capability in 1999 PC manufacturers guide as a “Recommendation” to support smart card readers

Changes to “Required” status in 2000. Adherence to guide necessary for “Windows Compatible” labels

– Windows 2000 (NT 5) supports smart card authentication natively

Two factor authentication

– Smart card is PIN (4-8 digits) protected 3 unsuccessful tries results in card lockdown requiring card reissue

Digital CertificatesStandards

X.509 Standard– Created to provide credentials for X.500 directory objects– V1 published as part of X.500 directory recommendations

V1 (1988) - V2 (1993) V1 & V2 inadequate for PEM (privacy enhanced mail) applications

– V3 (1996) added much flexibility added provisions for “extension” fields (“V3 extensions”)

– V3 use pretty much universal for Internet applications supports mail, c/s, IPsec alternatives limited to special purposes, e.g PGP certificates

PKIX IETF standards and drafts – Intended to provide Internet with components missing from X.509

X.509 rewrite according to IETF specs– Protocols for certificate creation and management

e.g. certificate requests, revocation lists added profile and policy definitions

Digital CertificatesStandards

X.509 defined to support a high degree of inter-operability

– Independent of application, language, platform & vendor supports wide range of applications and environments e.g. interoperability between Japanese issued certificates stored on a Java ring

with Internet kiosk in a New York library e.g. SET (secure electronic transactions) designed to support electronic

commerce worldwide

– Significant issues in coding certificates uses ASN.1 (Abstract Syntax Notation) and BER requires self describing data

– data which includes the format for interpreting data very robust but has significant overhead costs

– very verbose– parsing issues; must parse string before an awareness of the type of string -

with deeply nested structures this can be very difficult

Certificate Issuance &

Management

Module 4

Certificate Management

Certificate Actors and Basic Transactions

Certificate LifeCycle

Role of Directories

Costs and Business Models

Certificate Management Actors Principal Actors in the life of certificate

– Subject owner of public key

– Certificate Authority (CA) Issuer of certificate - signs certificate

– Registration Authority (RA, sometimes ORA or LRA) assumes some administrative functions typically vouches for binding between public keys and certificate holders

– Relying Parties (Acceptors) validate digital signatures

– Repositories that store certificates and revocation lists internal to CA published network directories local certificate dB

– Key Recovery Authority

Certificate Management Lifecycle

Creation of Key Pair

Certification

Transport

Use

Revocation

Recovery

Certificate Management Key Generation RSA keys are generated as a key PAIR

– key pair is computable; but deriving one key from the other is not

Locus of pair generation is important– by Certificate Subject

private key never need be communicated best understood and model supported by PKCS model well supported in browsers

– HTML <keygen> tag triggers key pair generation– by Certificate Authority

then must securely communicate private key to subject requires high degree of trust between subject and CA may be appropriate when corporate ownership of keys

– simplifies key escrow model supported by NetWare 5 and some Entrust products value probably limited to intranet

Certificate Management Certification

CA must collect Subject Information and Public Key– Usually obtained from subject's Certificate Request

There are standards for request form and format HTTP request using <keygen> form element

• appropriate to web browser models but limited– PKCS#10 - usually for server requests– CRMF (Certificate Request Message Format”) PKIX standard

• overcomes limitations of keygen, more robust as it includes subject signing of public key; supports key escrow (.ie. supports secure communication of private key to escrow authority)

CA must confirm validity of Subject Info and request

– Role of “(local) Registration Agent” or (L)RA

– No real standards for “proof” system “point” systems (NACHA), but applicability to healthcare unclear

CA signs certificate to attest to Subject Info - Public Key binding

Certificate Management Certificate Request w/ Browser

SUBJECT Certificate Authority Registration Authority

C om p le te F o rmG enera te K ey P a ir

R eques t R eg is tra tion F orm

H T M L fo rm con ta in ing < keygen>Form m ay com efrom "any source"R A, C A or o ther

S ub jec t In fo p lus P ub lic K ey

agen t'sd iligence p rocess

R eques t C on firm a tion

A pprove R eques t

C rea te and S IgnC ertifica te

C ertifica te

Directory orother

Publication

typ ica lly SSL

C ertifica te

SSL or better

Certificate Management Certificate Creation - Netscape

Current Netscape Model

– HTML form element <keygen> submitted over HTTPs

– Certificate approval either by Auto verification by comparing subject info against database RA logging onto a CA process

Demo

– Simple certificate request / approval / creation using Netscape server

Netscape futures (Certificate Server 4.0 - March ‘99)

– CRMF with more flexibility for request submission

– Distribution of RA and CA functions

Certificate Management Certificate Server Products Software Sales Model

– All functions owned and managed by enterprise

– Leading vendors Netscape Entrust Baltimore (Zergo) RSA ( at a toolkit level)

Service & Software Model

– Distribute registration and other functions to enterprise while certificate manufacture occurs at vendor center

– Leading vendors VeriSign GTE CyberTrust

Certificate Management Certificate & Key Transport

Certificates contain only public information– User certificates are self-proving & may be communicated as cleartext (PKCS #7) – Source of signer certificates is an issue

“Bootstrap” problem - discussed in the next module At some point, relying party must obtain signer certificate from a “trusted” source

“Portability” of Private Keys

– Required to support multiple workstation use Physicians in particular certificate portability for seamless access from home, office(s) and

hospital

– Two approaches Export to “media” (floppy) and “import” to another workstations

– PKCS #12 mechanism similarly used for key backup Use portable devices such as smart cards, PCMCIA devices, crypto rings

– PKCS #11 provides Crypto API for these devices– 2 -factor authentication uses password prompt to “unlock” key ring

Certificate Management Certificate Use Certificate use protocol driven

– SSL /TLS and s/MIME in particular

Basic authentication model binds current user (message sender) to certificate

– typically with subject signing of authentication message which includes the digital certificate

in s/MIME , signed message includes symmetric key used for bulk encryption in SSL/TLS , signed message includes a one time nonce to prevent replay of

authentication by third party object signing similar

– in general, certificate supports use of the private key

Certificate Management Certificate Revocation

Certificates must be “revoked” when the subject - key binding is no longer true or reliable

– When “exclusive control of private key” provisions are compromised– When the subject information no longer true

e.g. change in employment or professional status or address

CA must support publication of revocation– Certificate Revocation List (CRL)

CA publishes list of all revoked certificates; “delta” lists provide “changes”. The Relying party periodically updates its local copy of list. Checks to see if target certificate is included in list.

– Ambiguity in how often Relying Party should “check revocation” alternatives: CRL distribution points; cretificate revocation trees

– Online Certificate Status Protocol (OCSP) CA provides server that responds to status request for specific certificates with “good”,

“revoked” or unknown– Alternatives based on LDAP directories

“userCertificate” is a standard LDAP person attribute

Certificate Management Certificate Revocation Revocation Processes

– No standard “revocation request” message Revocation request is subject to similar diligence as for a certificate request

– Revocation in case of compromise generally involves action by subject Must inform the RA / CA when private key compromised (say by theft of

computer) Governed by terms of user agreement

– Registration agent’s diligence required to revoke certificate when subject information no longer true

e.g. subject information contained certificate to which the CA has made an attestation is no longer true,

e.g. left employment; lost license; terminated PPO affiliation

– s/MIME certificates problematic Certificate profile contains an email address New certificate is required with every change of email address

Digital CertificatesKey Recovery

Without private key, encrypted data unavailable– Particularly problematic in case of clinical data with potential impact on care

Archiving of private key is critical, 2 models:

– Self-escrow - owner maintains secure copy of private key

– Third-party escrow rely on “Key Recovery Authority” Subject to Third Party Rule

1977 Supreme Court ruling created Third Party Rule - There is no expectation of privacy for information given to third party. Escrowed keys will be available to government agency upon “mere request” and can be subpoenaed for civil litigation. Third party rule overrides any contract between cert owner and authority. Some financial data is exempt by statute; healthcare data may become exempt with passage of Pivacy legislation; mere HCFA regulation is not sufficient

Digital CertificatesKey Recovery Technical Approaches

Subject “back up” model– PKCS #12 protocol support to “backup” end user’s key ring

“Export” to floppy or other device; exported PKCS12 file protected by pass phrase. enterprise requires added processes to recover the key in case of non-availability of

user, eg termination, illness

Enterprise repository– Server based key recovery

Requires that private key is securely communicate from subject to repository Special challenge to store recoverable copy of private key without compromising

“non-reputiation” of digital signature– less problematic in enterprise environment

– Generally includes a “split-key” model where archived private key protected by combination of two keys to guard against administrator misuse

– protocols with appropriate crypto under development– general solutions will appear in next generation certificate server management

systems, eg Netscape Cert Server 4.0 (March ‘99)

Certificate Management Directories

Directories may store certificates along with other subject information

– userCertificate is a standard LDAP attribute

Certificate publication required to support broad email use

– Certificates required to send secure mail

– How do correspondents acquire certificates Desire to minimize “negotiation” prior to secure use

Required for role based access control

– Generally transient roles are not included on a certificate

– Use directory to bind role and other authorization information to certificate subject

– Support distribution of role assignment to trading partners e.g. physician office administrator billing clerk

Certificate Management Cost and Business Models Three models for Certificate Authorities

– Enterprise Issue certificates to subordinate employees and resources CA owner controls resources to which certificate will authenticate

– CA and PKI become part of network administration, eg Netware 5 Enterprise ultimately assumes responsibility for misuse

– Public CA is fully independent of the certificate subjects and the protected resources

– Hybrid Multiple user classes imply different liability (e.g. employee; trading partner) Multiple information resources

– Authenticate staff to resources of trading partner(eg. secure email or access to eligibility data)

Certificate Management Cost and Business Models Costs

– Relatively small software cost $800 (MSFT) up to $10K + $/cert

– Registration agent’s due diligence costs Minimal in case of Enterprise model where merely attesting to existing knowledge

of employee May be significant for public CA to verify the subject information included on

certificate– Liability costs and insurance

May be limited (somewhat) by user agreements Tradeoffs between liability & due diligence costs

– Operations cost for highly secure certificate servers– Operations costs for high availability revocation publication– End user support– Many hidden costs;

e.g. loss of data with non-availability of private key e.g. reduced ability to audit information flows

Certificate Management Cost and Business Models Highly variable total cost estimates

– Annual costs anywhere from $2/ cert to $600/ cert !!!– Aberdeen Study

http://www.versign.com/library/reports/Aberdeen/cost/index.html

– Giga Information Corporation http://www.entrust.com/news/1998/gigatco.htm

Critical cost factors– Special requirements of vertical markets or enterprises

Increased RA due diligence & liability costs Increased integration costs for Relying Parties

– depth of certificate “chains”– End user support

Multiplicity and criticality of applications– Integration with enterprise systems

PKI Trust Models

Module 5

PKI Trust Models

Basic Concepts

Certification Paths

– Types

– Constraints

Trust Models

– Direct

– Hierarchical

– Mesh

Browser / Email Client Support

Significant Issues and Alternatives

– “Straw Dog” Alternative

PKI Trust ModelsWhy Trust?

Advantages of “trusting” certificates issued by others

– Reach Can extend communications to previously unknown parties

– Potential for improved reliability In the whole, fewer certificates for end users and relying parties

– Efficiency Communities can be served by different CAs

(e.g. healthplan can better certify its employees than a public CA)

– Economy Cost sharing

Questions

– What is being trusted?

– What is the basis for trust?

– What are the enforcement mechanisms?

PKI Trust ModelsBasic Concepts

Fundamental principle of certificate use and acceptance

– The certificate subject is accountable for any use of the private key If non-repudiation is not required, this principle can be

How is the principle supported?

– Issuer (CA) has responsibility to assure appropriateness of subject - key binding “Proof” appropriate to certificate scope Maintain current status and publish revocation

– Subject has responsibility to guard private key Protect private key using tools appropriate to subject’s environment Notify CA as required if private key compromised

– Relying Party Responsibilities Check certificate validity

– Verify signature and revocation status Accept restrictions of scope of certificate

PKI Trust ModelBasic Obligations

Subject

Issuer

RelyingParty

S ub jec tP ub lic K ey

< < res tric tions> >po licyva lid ity pe riod

Certificate

Private Keypro tec t >

< au then tica tes

< verify s igna tu re

CurrentCertificate Status

CRL / OCSP

< va lida te sub jec t - key in fo

pub lish >

inspec t >

no tify o f s ta tus change >

PKI Trust ModelsBasic Concepts (cont)

How is the fundamental principle enforced?

– Contract User agreements set responsibilities and remedies

– Legislation, (e.g. State of Calif. digital signature law) By statute, presumptive responsibility for key use place

on certificate owner /subject– Has limited application & is not applicable to “proxy” environments

– Regulation HIPAA & healthcare accreditation audits Independent audits for public CA’s (AICPA)

– Technology Protect keys for the enterprise in a central registry & control subject key access

– Assumes that certificate subjects can’t be relied upon to protect their keys This approach not generally appropriate for a healthcare extranet

– Contrary to business and other relationships– Cost

PKI Trust ModelsCertificate Verification

Certificate verification requires having issuer’s public key( the CA’s Signer Certificate)

– Implies confidence in accuracy of signer certificate

– How is such confidence established? Bootstrap problem

Verification mechanisms for signer (CA) certificates

1 Self signed using signer’s own key Appropriate for rootCA Requires that truth of CA identity - key binding be independently established

– Browser manufacturer support by “pre-installing” public CA keys(ATT Certificate Services, GTE CyberTrust Global Root)

– CA provides signer certificate when CA issues key to subjectAppropriate for managing domains and private PKI

PKI Trust ModelsCertificate Verification (cont)

Verification mechanisms for Signer (CA) certificates

2 Signed by a CA superior in a hierarchy Acceptance of the CA’s certificate is derived from acceptance of rootCA Appropriate for corporate structures with hierarchical administration

– The rootCA is typically corporate “global” key where divisions, departments have subordinate keys

– Used for administrative convenience

3 Signed by CA from an independent domain with cross-certification Acceptance of one CA derived from acceptance by another (peer) CA Cross-licensing may be reciprocal or one way May be appropriate for trading partners and well-defined communities of interest

PKI Trust ModelsCertification Paths - Example

2

11 22

1

CA

CA

CA CA

CA

roo t

c

b

alice

A lice can verify certifica tes cand b after verify ing a cha in o fcertifica tes from the CA-root(w hose pub lic key she know s)through CA-1 to CA-11 to cand through CA-2 to b

certificatechain

CA-root signs CA-1 certCA-1 s igns CA-11 cert

CA-11 s igns c cert

CA-root s ignsCA-1 cert

PKI Trust ModelsCertification Paths - Example

Mesh Domain

Hierarchic Domain

peer C A - se lf s ignsd istribu tes to its certho lders - cross-licensesw ith in dom ain

principa l C A - capab le o f"b ridg ing" w ith o ther dom ains.Typ ica lly w ill have som egovern ing au thority

Trust is not unbounded

Certificate authority may want to limit “signing” capability of certificates that it issues

– To limit depth of a “certificate chain” Control complexity of certificate hierarchy under CA

– To limit CA liability

– To distinguish between “end user” and other certificates” e.g. may provide IPA with signing capability so that the IPA can issue certs to

affiliated practices under its authority; end user” certificates to health plan staff.

– Limitations are supported by digital certificate extensions

– Trust may not be transitive use nameConstraints on cross-licensing to prevent the following: US Canada Cuba ; but US does not trust Cuba

PKI Trust ModelsCertification Path Constraints

PKI Trust ModelsBrowser support

Local file with rootCA self signed certificates– Managed by end user

further determine when cert will be trusted– May import certificates and trust as a root CA– Shipped with some rootCA certificates pre-installed

implicit “defacto” accreditation by browser manufacture Verisign, CyperTrust, Thawte. . .

– Support ordered certificate chains from sender to root stored in local file

Can import certificates from trusted directory

Limitations– Limited support for finding certification paths– No direct support for cross-certificate pairs– No support for policy extensions, name constraints, path constraints– Limited ability to centrally manage dB of trusted certificates

PKI Trust ModelsBasis for Trust

Expectations of trust differ depending on relationships

– Subject and Issuer Subject is the issuer Subject is subordinate to issuer (employee) Subject and issuer have independent business relationship Public CA - issuer and subject otherwise independent

– Public CA issues certificates to any qualified subject on a fee basis

– Relying Party and Issuer Issuer is the Relying Party Issuer is a trading or practice partner of relying party Public CA - issuer and relying party otherwise independent

– Issuer may or may not be known by relying party

PKI Trust ModelsTypes

Direct Trust

– Relying party independently verifies each subject - key binding Usually by contract - agreement to terms of certificate use Role of CA is limited to coding the certificate

– e.g. Verisign or Entrust limited liability certificates used for authentication purposes

Maintenance is an issue, contract must address revocation & other terms

Hierarchical Trust

– Relying party trusts rootCA and consequently the rootCA’s certificates as well as those issued by a subordinate CA

Principal CA “owns” domain Subordinate CA following guidelines of Principal CA (presumably) Basic corporate model

– X.509 supports certPathLength and use restrictions

PKI Trust ModelsTypes Peer Trust

– CA self signs and cross-licenses with trading partners Extends the reach of PKI available to each in reciprocal fashion Requires extensive cooperation

– Examples Certificates issued by hospital for its staff are accepted by health plan Physician certificates issued by one health plan are accepted by second health

plan

PKI Trust ModelsSome Criticisms

Emphasis on the “who” rather than the “what” of trust– e.g. “Approved CA(s)”, but for what purpose?– Difficult business models

may wish to limit applicability of cross-licensed certificate assumptions of liability differ with respect to different relying parties

No enforcement mechanism for breach of trust– Particularly problematic with cross-certificate chains

Lack of domain definition– Appropriate CA for many subjects with multiple affiliations is confusing

eg for physician: - healthplan, hospital, MG, IPA, state agency, ... Trust in hierarchical model may not be asymmetric

– Certificate holders in hierarchy may have limited trust of root physicians and health plans

Overly complex– Limited software support for cross-certification– Especially problematic for certificate revocation

PKI Trust ModelsProposal for a Policy Authority

Policy Authority issues certificate to any healthcare CA(s)

– Results in a single rootCA for a healthcare PKI binding “subordinate” CA to healthcare certificate policies it supports

– Policy Authority CA supports publication of the CA’s supported policies assumes common semantics, i.e. this workshop

Each registered CA is trusted to faithfully implement CA chosen policies

– Subject to audit according to AICPA standards to assure consistency of certificate practices and the CA’s stated objectives

– Equivalent to inclusion on the State’s “Approved List of Certificate Authorities”

Policy Authority

– Publishes a profile for each registered CA

– Publishes CRL for CA certificates probably more proactive - push notification of certificate revocation to Mediator CA

subscribers as the revocation occurs

PKI Trust ModelsProposal for a Policy Authority Governance

– Policy Authority can be operated as independent agency probably, in conjunction with industry CA (for cost savings)

– management responsible to an industry board– Business model– Limited functionality and costs

only a few certs issued; only signer certificates to CA’s publish revocation lists (probably OCSP) publish healthcare policy definition publish “audit” and CA profiles

– Simple revenue model to cover costs CA subscriptions

Precedents

– NACHA financial industry trial

– FED PKI will implement something similar


Module 6


Role of Certificate Policy

Structure of Certificate Policy Statement

Policy Enforcement

Role of Certificate Practice Statements

Next Steps

Certificate PoliciesDefined From X.509 (v3) specification

“A named set of rules that indicates the applicability of a certificate to a particular community and / or class of application with common security requirements”

Policies are named with an OID (“object identifier”) that assures global uniqueness

For a given CA, “appropriate use” questions are answered by referring to the CA’s certificate Policy, e.g.

– Who is being issued certificates, i.e. userType

– What is the basis for issuing these certificates, ie general “proof” requirements

– Characterization of user agreements

– Any special user requirements

– What is the intended use (what applications owned by whom)

Certificate PoliciesPolicy Example

1. A healthcare organization is an organization which is either a payer or provider as defined by HIPAA (pg. #). Healthcare PKI certificates may be issued only by a healthcare organization or its agent.

2. A healthcare providerPerson certificate may be issued only to a person who either has a NPI (national provider identifier) or is employed by a person or organization that has an NPI. Every healthcare providerPerson certificate will include the qualifying NPI. That NPI will be included in a ‘providerIdentifer’ extension <citing an OID> .

Note that the last two statements in 2) are really conditions on the certificate profile of a providerPerson certificate

Certificate PoliciesScope Certificate policies created by Relying Parties represent requirements for

certificate practices and profiles

– Conditions under which certificates are “acceptable” for Relying Party applications

Policies for a given CA are supported by:

– Certificate Practice Statements Details specific activity that CA & RA undergo to issue certificates consistent with

policy statement

– Certificate Profile Name space architecture, extensions, etc How information supporting policy is displayed on certificate

Policies are implemented on a certificate basis

– A given CA can issue classes of certificates under different policies

Certificate PoliciesComposition

A CA can implement several consistent policies simultaneously

– Policies required by a number of organizations e.g. health plans, local hospital and lab

– Policies required to support different kinds of applications e.g. “read” versus “read / write” privileges e.g. differential sensitivity of data

– General and specific policies e.g. policy required by any Federal Government Agency; e.g. policy to support a HCFA requirement

A given certificate can reflect several independent policies

– Certificate policy extension records the OID of all policies under which the certificate can be issued

Certificate PoliciesPolicy Enforcement Policies represent an implied contract that CA faithfully implements the

policies– Places a limitation on the strength of any contract having cross-certificates and longer

certification chains relying parties may not be party to a contract with issuing CA potential for many intermediaries with different contractual obligations

– Uncertain test of “faithful compliance”

Independent audits record CA’s compliance with its policy– AICPA (Amer. Inst. of CPA) standards for audits

same standards applicable to any “service” contract basis for acceptance by State of California (per digital signature law)

Potential for state and federal licensing ( Utah )– In principle, judgements should be made relative to policy, otherwise licensing will not

be sensitive to vertical market requirements

Certificate PoliciesPractice Statements

Describe specific activities that CA/RA will undertake to support certificate

– Issuance -- i.e. diligence process to confirm subject-key binding and subject info

– Revocation -- e.g. frequency of updates

Measure practice statements relative to policy

– Constitutes clearer obligation of CA than does policy statement

– Want close fit between practice and policy

– Some potential to hold CA accountable for implementing practices under E&O insurance

Example of a practice statement

Prior to issuing a physicianProviderPerson certificate, the applicant will sign and return to the CA a user agreement that was sent to applicant at the address of record maintained by the State Medical Board.

Certificate PoliciesNext Steps Participant response

– PKI Readiness Survey

– Authentication Requirements Survey

Straw Dog Presentation

– Policy Criteria

– Healthcare Policy Framework

– Specific Healthcare CA Policies

Tunitas Internet Site

– FAQ

Documents

PKI Tutorial Model Policy Workshop