PKI Tutorial Model Policy Workshop Ann Geyer Bill

PKI Tutorial Model Policy Workshop Ann Geyer - Bill Pankey tunitas @ earthlink. net www. tunitas. com 925 -631 -1244

Session Goals l Prepare participants for Workshop – Language and application of public key cryptography – Meaning and use of digital certificates and signatures l mechanics of certificate use l lifecycle of digital certificate l Develop common understanding of PKI – Potential sources of “trust” in a PKI and its use l Introduce the components of a Certificate Authority – Role and substance of Certificate Policy & Practice Statements – Software components and business functions l Introduce relevant standards – From IETF -- PKCS and PKIX – From ABA -- Digital Signature Guidelines – From NACHA -- CARAT Guidelines

Agenda l Authentication in Healthcare – Overview of the problem set l Cryptography Basics – Security foundation in open networks l Digital Certificates – Structure of authentication “credentials” l Certificate Issuance and Management – How certificates are created, maintained, used, and revoked l PKI Trust Models – How trust can be extended to unknown parties l Certificate Policies – Support the use of certificates by third parties.

Authentication in Healthcare Module 1

Authentication in Healthcare Requirements l Authentication is designed to positively corroborate identity of remote user or electronic correspondent – Necessary component of any network security solution l authentication - authorization - access control - audit – Necessary condition for disclosure of patient identifiable data l HIPAA, HCFA Internet Policy, industry good practice l Healthcare authentication has specific requirements – Support unique individual identification as required by HIPAA – Recognize persistent personal roles (e. g. physician) l roles assigned to individuals independent of resource or organization – different organizations respond to a role in a similar way e. g. all plans contract with physicians as providers and so have similar authentication requirements l roles may have presumptive access privileges and disclosure permissions

Authentication in Healthcare Requirements l Healthcare authentication has specific requirements (cont) – Must respond to industry reliance on “proxy” roles l assigned independently of resource by principal, e. g. provider staff l Healthcare context impacts authentication – Multiple affiliations – Mesh Industry – Heterogeneous business relationships – Heterogeneous computing platforms – Cost Avoidance – Regulatory Scrutiny – Risk Avoidance

Authentication in Healthcare Value of PKI l Digital certificates & PKI have gained tentative acceptance as the solution with greatest potential – Can be very secure l if authenticated persons accept personal responsibility for key integrity – Can be highly scalable l if plans and provider institutions can take advantage of common shared CA resources – Can acquire high degree of provider acceptance l 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 l if there is explicit industry recognition of common solutions l if HCFA supports the creation and adoption of defacto standards and solutions (HCFA policy & Internet “trial”) – Can be low cost security solution l unbundles authentication from application and resource

Authentication in Healthcare PKI Collaboration l Several collaborative models that aim to facilitate a common solution – Healthcare specific root. CA l requires significant industry commitment but lacks suitable model – Domain specific policy management l instantiated in the user. Type Management Model – CMA model for a physician PKI proposed by Tunitas Group l involves collaboration specific to classes of persons and organizations l leverages existing professional and trade associations – vision generally lacking within association management – Promulgate defacto standard CA vendor for some user classes (buying coalition) l 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 Healthcare Interoperability Issues l X. 509 Standardization – Defacto implementation standard for digital certificates – Flexibility at the risk of voiding interoperability l uneven support for multiple algorithms – Reliance on imputed semantics at the risk of voiding interoperability l e. g. special interpretation of DN inserting comments as ou= ; l e. g. special use of “serial number” say by inserting Employee ID, l Certificate Extensions – Certificate Profile publishes locally defined fields – Provides semantics not supported by X. 509 standard l e. g. certificate Type or Class – Must be understood within domain or otherwise risk voiding interoperability l Certificate Policies – Policies define appropriate applications of certificate – Meaning and trustworthiness of certificate depends on policy l reliance on certificate is by definition reliance on policy

Authentication in Healthcare Workshop Goals l 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 Secondary Goals l l Provide a forum for continuing PKI collaboration Advance the general understanding of PKI issues and healthcare’s Internet use – Additional Tunitas Group seminars l Healthcare use of Internet Mail (late Q 1 - Q 2) – s/MIME -- locus point for encryption, SMTP alternatives l Access control for health Information (Q 3) – multi-level access control using client certificates, directories, and SSL (technical seminar on the use of SSL in conjunction

Authentication in Healthcare Test Case Applications l 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 l Will use these applications as test cases

Authentication in Healthcare Internet Mail l Internet mail security requirements – Encrypt messages to protect the confidentiality of message content – Provide assurance of correspondent authenticity l needed for both senders and receivers l mail addresses and context are not adequate for authentication – Two potential models l proprietary “mail” - mailboxes hosted on a secure server – implies “secure file transfer” ability – requires partners to support correspondents’ mail processes l SMTP mail – messages must be “cryptographically enveloped” and selfauthenticating l 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) l s/MIME protocol requires authentication using digital certificates

Authentication in Healthcare File transfer across Extranets l 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 l 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) l also object communication with IIOP/SSL and telnet/SSL l SSL requires digital certificates for authentication – Supports weaker client authentication using login / pswd (optional)

Authentication in Healthcare Form Signing l Requirements – Provide non refutable assurance of the identity of an electronic form submitter l protect against fraud in Medicare billing; anticipated HCFA requirement – Bind the electronic signature to the electronic document l SSL binds identity to a session and only indirectly to the information submitted – Leverage existing client software and language-level APIs l 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 (Java. Script; Java) and current browser editions

Authentication in Healthcare EDI over the Internet l Requirements from HCFA & HIPAA – Mutual authentication of trading partner EDI processes – Encryption l 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 l EDIINT requires that certificates be issued to trading partner EDI resources

Authentication in Healthcare Communicating with Patients l Benefits – Member/patient satisfaction - JAMA reports increased email communication between physicians and patients l Need guidelines for appropriate use. Without guidelines and true authentication, providers significantly exposed – Support future Privacy Act required patient authorization before disclosure l Requirements – Positively identify unique patient. Requires corroboration of patient identifier beyond just name. l National Patient Identifier ? < not likely > – Positively identify appropriate parents/caretakers – Assurance that patient is using appropriate encryption software – Support very large scale authentication solutions l 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 Healthcare Communicating with Patients l 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 (NT 5, Net. Ware 5) l 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 l smart cards in university environments, UCLA certificate project l Province of Ontario to issue certificates to entire population !!! l Include certificate on “smart card” member enrollment card l Issue member certificates in conjunction with service l Most solutions will requires patient/member directory – Digital certificates for members – Online application to bind patient provided credential to unique patient identifiers

Cryptography Basics Module 2

Cryptography Basics l What is Cryptography? l Secret Key Cryptography l Public Key Cryptography l Message Digest l Digital Signature l Standards l Software Considerations

Cryptography Basics What is cryptography? l l The art of scrambling information into gibberish in a way that allows for a secret method of unscrambling Ancient roots – From the Greek: krupto (secret) + grafh (writing) – substitute letter with one appearing k digits later example: {(d, a) (e, b), etc} l l l 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

Cryptography Basics What is cryptography? (cont) l l Represents information as numbers where the numbers are the result of some mathematical manipulation Terminology: plaintext l encryption ciphertext decryption plaintext Cryptographic schemes usually involve: – Algorithm l usually public but can be secret l knowledge of algorithm alone is insufficient to decrypt ciphertext – Secret value (key) l shared by good guys l analogous to the combination for a combination lock

Cryptography Basics What is cryptography? (cont) l Fundamental Tenets of Cryptography – Algorithms that have successfully withstood continuous scrutiny and challenge are not easily compromised l 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 l set of all possible keys known as the keyspace l Security of strong algorithms depends upon the size of keyspace – Effectively, the only known attacks would be brute force attacks l exhaustively attempt decryption with each possible key until something intelligible is recovered l practical strength of the encryption is a function of: – available computing power – size of key (40 bit, 56 bit, 128 bit)

Cryptography Basics Secret Key Cryptography l Single key for encryption and decryption – typically used for “bulk” encryption – referred to as “symmetric key” cryptography insecure channel plaintext Encryption algorithm ciphertext Decryption algorithm secure channel secret key (k) plaintext

Cryptography Basics block encryption example

Cryptography Basics Secret Key Cryptography (cont) l 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 l Issues – Alice and Bob must agree upon choice of algorithm – Key Management Alice and Bob must securely communicate shared key l out of band via some private method l in band using public key methods

Cryptography Basics Secret Key Cryptography (cont) l Advantages – Relative “simplicity” – Computational efficiency l linear “computational complexity” i. e. proportional to message length l Some Algorithms – DEA (data encryption algorithm) l AKA DES - (Data Encryption Standard ) currently FIPS* encryption l multiple variants 40 bit, 56 bit, triple DES (112 bit, 168 bit) l 56 bit DES current defacto standard for bulk encryption – AES (Advanced Encryption Standard) l once selected will replace DES as the FIPS l candidates include CAST-256, DEAL, RC 6, SAFER+ * Federal information processing standard

Cryptography Basics Public Key Cryptography l 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 insecure channel plaintext Encryption ciphertext algorithm public key (k) Decryption algorithm private key (k*) reliable channel e. g. . secure directory plaintext

Cryptography Basics Public Key Cryptography (cont) l 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 l deriving the private key from the value of a public key is involves solving what is known as a hard problem l 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 Basics Public Key Cryptography (cont) l 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 l 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 Basics Public Key Cryptography (cont) l RSA: example of public key algorithm – First practical public key algorithm l widely implemented; defacto international standard for signatures – Public keys are very large prime numbers, typically 1024 bits (~350 digits) or larger l density of primes decreases with size, require very large primes to assure an effectively large key space – Encryption / decryption involves exponentiation with keys l computational requirement limits practical use to small plaintext l Other Public Key Examples – Digital Signature Standard (DSS) l digital signature only – Diffie-Hellman Key Exchange l used with DSS for key exchange – Elliptic Curve Cryptosystem (ECC) l order of magnitude more complicated and stronger than RSA l implemented in chips for niche markets l high performance / more efficient use of key space than RSA

Cryptograhy Basics RSA encryption example

Cryptography Basics Message Digest l Summarizes content of message – Aka “one-way hash” – Maps variable length message into fixed length digest l Fundamental properties of message digest – “One way” function l message determines digest; l digest does not uniquely determine message – Easy to compute, hard to invert l Digest verifies message integrity – Compute message digest – Compare with a digest transmitted with the message l requires secure channel or “signature” l Examples – MD 5 (Message Digest 5) - 128 bit digest – SHA (Secure Hash Algorithm) - 160 bit digest

Cryptography Basics Public Key Digital Signature l Verifies origin & integrity of transmitted message hash Message Digest insecure channel sign Encryption algorithm message’s digital signature private key (k) reliable channel e. g. secure directory verify Recompute digest and compare w/ transmitted signature Decryption algorithm public key (k*)

Cryptography Basics Public Key Digital Signature (cont) l Supports non-repudiation – Signature confirms application of signer’s private key l only holder of private key can generate identical signature – Requires protection against invalid public key l PKI or secure directory provides that protection l Can be combined with encryption to support both confidentiality and non-repudiation

Cryptography Basics Exchange of Session Keys l Using public key encryption to exchange a symmetric (session or message) encryption key generate key and sign Encryption algorithm insecure channel encrypted session key Alice Bob's public key (k) reliable channel e. g. secure directory extract key and verify signature Decryption algorithm bob Bob's private key (k*)

Cryptography Basics Standards l Symmetric key standards from NIST – DES – AES – Federal Information Processing Standard (FIPS) l Public Key Cryptography Standards (PKCS) – Promulgated by RSA – Multiple parts supporting different aspects of public key crypto l some PKCS standards are superceded by PKIX – Examples l PKCS #1 (Public Key Standard) signing and encrypting with RSA l PKCS #7 (cryptographic message syntax) l PKCS #11 (crypto standard for smart cards, PCMCIA devices) l PKCS #13 (elliptic curve cryptosystem) signing and encrypting with ECC

Cryptography Basics Computer Issues l Sources of transparent (to the app) support for cryptography – Operating system l NT, Novell Net. Ware – omnipresent in next generation OS – Application Server Platforms l session layer encryption – e. g. Netscape Suite. Spot or other SSL compliant l Security Frameworks to embed cryptography services into applications – Does not require extensive cryptography knowledge l may be appropriate for enabling legacy applications – RSA PKI Framework – Netscape Security Services – IBM Key. Works

Cryptography Basics Computer Issues l Major Cryptographic APIs (CAPI) – Use requires knowledge of cryptography basics l to manage cryptography functions l requires modules that support low level cryptography functions – CDSA (Common Data Security Architecture) l applications can be written as algorithm independent l supports “pluggable” crypto – Microsoft Crypto. API l proprietary version of pluggable crypto – GSS (Generic Security Service) l distributed protocols, e. g. peer entity (object) authentication l IETF developed and supported – JAVA Security API l “Cryptographic Service Providers” (toolkits) – code modules that implement cryptography algorithms l RSA, Microsoft CSP, Cyclink, Certicom …

Cryptography Basics Basic References l Good Textbooks – Network Security, Private Communication in a Public World l Charlie Kaufman et al (mathematical introduction) – Applied Cryptography: Protocols, Algorithms and Source l Bruce Schneier (classic text) – Email Security l Bruce Schneier (informal introduction) l Cryptography resources on the Internet – RSA Laboratories; http: //www. rsa. com l leading crypto vendor; links – Counter. Pane Systems; http: //www. counterpane. com/ l Bruce Scheier’s company l includes an online crypto course and critical analyses of current events – Microsoft http: //www. microsoft. com/security/tech/cryptoapi/default. asp? ID=22&Par ent=4

Digital Certificates Module 3

Digital Certificates l What are digital certificates? l Architecture – Subject identification – Algorithms and attestations – Extensions – Form and format l Implementation – Ownership assumptions – Software considerations and models – Hardware devices l Relevant Standards

Digital Certificates What are digital certificates? l A “credential” that identifies a person, resource or “entity” l 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) l 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 l Used extensively in Internet security protocols – s/MIME, TLS / SSL, IPsec

Digital Certificates What are digital certificates? (cont)

Digital Certificates Architecture - Required Info l Certificate Information – Serial Number - unique to certificate authority – Validity period l date first valid / date expired – Signature algorithm l Authority Information – Unique name of issuer l Subject Information – Unique name of subject – Subject public key algorithm (usually RSA) l Digital Signature – Using issuer’s private key

Digital Certificates Architecture - Optional Info l Standard Extensions support additional CA attestation – Subject and Issuer Attributes l e. g. alt. Name. Extension Used to further identify certificate actors – Key Use l e. g. certificate. Type Defines intended use by class of application (s/MIME, SSL. …) – Certificate Constraints l e. g. path. Length. Constraint Limits certification chain, i. e who can use the cert l e. g. name. Constraint Restricts signing ability to specific X. 500 subtree – Policy Extensions l Identify policies of CA used to issue this certificate l 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

Digital Certificates Architecture - Customization l Custom Extensions support additional requirements imposed by a CA or user community – Support added semantics of user community l e. g. Specialization l e. g. national. Provbider. Identifier l e. g. authorized. Delegate. For – Attribute values will be attested to by CA l CA must leave unspecified if unknown – Standard syntax for definition (ASN and BER) l “Certificate Profile” includes – Definition of all custom extensions – Standard extensions – Algorithms

Digital Certificates CMA Medi. Pass example n o si e g a e e S p t s a l r o f e l b a d a re r e v

Digital Certificates Architecture - Subject DN l Subject Distinguished Name (DN) – Name for the public key owner – Follows the X. 500 distinguished name format l e. g. . cn=common name, ou=department name, o= organization, c=country l X. 500 provides standard “components of DN” l can use other DN components – e. g. uid=user. ID, e=email address, l=locality – vendor support sometimes uneven for other than c=, ou=, c=, e= – X. 500 presumes unique DN for every individual l based on subordination and location – X. 509 anticipates but does not require assigned DN’s will be “globally” unique l uniqueness defined and enforced within a domain

Digital Certificates Architecture - Subject DN (cont) l Namespace design is a critical cost factor – Robustness of certificate solution is dependent on the stability of DN l change in DN requires reissue of certificates l benefit of stable name assignment – Require simple solutions to avoid name “collisions” l arbitrary j. Doe, John. Doe 1, John. Doe 2 solutions are costly to create and support l Namespace design is a critical interoperability factor – Interoperability implies cross domain recognition & meaning l problematic for providers with multiple affiliation l problematic for providers known in different contexts – cn=Dr. Bob. Jones, ou=Hill. Physicians, o=Blue. Shield. HMO – cn=Dr. Bob. Jones, ou=Dr. Bob. Jones. PA, o=Blue. Cross. PPO – 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 Certificates Architecture - Subject DN (cont) l Namespace design considerations – Subject “distinguished name” (DN) should be meaningful l unique in some well defined context – reflect real world ways in distinguishing real world entities l simplifies certificate management – Robustness requires simplicity and stability across l multiple affiliations for typical provider. Persons l organizational restructuring – e. g. . cn=Dr. Bob. Jones, ou=Friendly. Hills, o=Take. Care – Interoperability requires mutual understanding of namespace l root names in broadest context – Flatter structures are more stable but uniqueness bigger issue l e. g. e=email. Addr, cn= common name, ou=Physician, o=CMA. org l eg. uid=Med. License#, l=state, o=physician. Persons

Digital Certificates Architecture - Alternate Names l subject. Alt. Name used for optional name attribute – Allows additional (1 or more) identities to be bound to certificate – Options include: l electronic mail addresses l DN names, e. g. – subject. Alt. Name=4567829. PP 0. Blue. Shield l IP addresses l URI (uniform resource identifiers) l other X. 500 names !!! l locally definition – Issuer must confirm each subject. Alt. Name – Not well supported in client software l browsers generally don’t parse and display

Digital Certificates Implementation - Ownership l l 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: l desktop “key rings” protected by owner selected/maintained passphrase – browsers and mail clients – PKCS #12 provides specification l 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 l 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 Certificates Implementation - Netscape l 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. : l prompt for password once a session l prompt for password every time a certificate requested – Netscape also supports interface to external key storage, e. g. smart cards through PKCS #11 interface l Demo

Digital Certificates Issues - Portability l l 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” l PKCS #12 defines similar procedure for key backup – Install private key to portable device such as smart cards, PCMCIA devices, crypto rings l PKCS #11 provides Crypto API for these devices – Netscape support l device manufacturers provide interfaces to browsers and mail clients l 2 factor authentication model – insert device (e. g. smart card) – respond to password prompt to “unlock” key ring

Digital Certificates Smart (Chip) Cards l 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 l Changes to “Required” status in 2000. l Adherence to guide necessary for “Windows Compatible” labels – Windows 2000 (NT 5) supports smart card authentication natively l Two factor authentication – Smart card is PIN (4 -8 digits) protected l 3 unsuccessful tries results in card lockdown requiring card reissue

Digital Certificates Standards l X. 509 Standard – Created to provide credentials for X. 500 directory objects – V 1 published as part of X. 500 directory recommendations l V 1 (1988) - V 2 (1993) l V 1 & V 2 inadequate for PEM (privacy enhanced mail) applications – V 3 (1996) added much flexibility l added provisions for “extension” fields (“V 3 extensions”) – V 3 use pretty much universal for Internet applications l supports mail, c/s, IPsec l alternatives limited to special purposes, e. g PGP certificates l PKIX IETF standards and drafts – Intended to provide Internet with components missing from X. 509 l X. 509 rewrite according to IETF specs – Protocols for certificate creation and management l e. g. certificate requests, revocation lists l added profile and policy definitions

Digital Certificates Standards l X. 509 defined to support a high degree of inter-operability – Independent of application, language, platform & vendor l supports wide range of applications and environments l e. g. interoperability between Japanese issued certificates stored on a Java ring with Internet kiosk in a New York library l e. g. SET (secure electronic transactions) designed to support electronic commerce worldwide – Significant issues in coding certificates l uses ASN. 1 (Abstract Syntax Notation) and BER l requires self describing data – data which includes the format for interpreting data l 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 l Certificate Actors and Basic Transactions l Certificate Life. Cycle l Role of Directories l Costs and Business Models

Certificate Management Actors l Principal Actors in the life of certificate – Subject l owner of public key – Certificate Authority (CA) l Issuer of certificate - signs certificate – Registration Authority (RA, sometimes ORA or LRA) l assumes some administrative functions l typically vouches for binding between public keys and certificate holders – Relying Parties (Acceptors) l validate digital signatures – Repositories that store certificates and revocation lists l internal to CA l published network directories l local certificate d. B

Certificate Management Lifecycle l Creation of Key Pair l Certification l Transport l Use l Revocation l Recovery

Certificate Management Key Generation l RSA keys are generated as a key PAIR – key pair is computable; but deriving one key from the other is not l Locus of pair generation is important – by Certificate Subject l private key never need be communicated l best understood and model supported by PKCS l model well supported in browsers – HTML <keygen> tag triggers key pair generation – by Certificate Authority l then must securely communicate private key to subject l requires high degree of trust between subject and CA l may be appropriate when corporate ownership of keys – simplifies key escrow l model supported by Net. Ware 5 and some Entrust products l value probably limited to intranet

Certificate Management Certification l CA must collect Subject Information and Public Key – Usually obtained from subject's Certificate Request l There are standards for request form and format l 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) l CA must confirm validity of Subject Info and request – Role of “(local) Registration Agent” or (L)RA – No real standards for “proof” system l “point” systems (NACHA), but applicability to healthcare unclear l CA signs certificate to attest to Subject Info - Public Key binding

Certificate Management Certificate Request w/ Browser

Certificate Management Certificate Creation - Netscape l Current Netscape Model – HTML form element <keygen> submitted over HTTPs – Certificate approval either by l Auto verification by comparing subject info against database l RA logging onto a CA process PDemo – Simple certificate request / approval / creation using Netscape server l 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 l Software Sales Model – All functions owned and managed by enterprise – Leading vendors l Netscape l Entrust l Baltimore (Zergo) l RSA ( at a toolkit level) l Service & Software Model – Distribute registration and other functions to enterprise while certificate manufacture occurs at vendor center – Leading vendors l Veri. Sign l GTE Cyber. Trust

Certificate Management Certificate & Key Transport l Certificates contain only public information – User certificates are self-proving & may be communicated as cleartext (PKCS #7) – Source of signer certificates is an issue l “Bootstrap” problem - discussed in the next module l At some point, relying party must obtain signer certificate from a “trusted” source l “Portability” of Private Keys – Required to support multiple workstation use l Physicians in particular certificate portability for seamless access from home, office(s) and hospital – Two approaches l Export to “media” (floppy) and “import” to another workstations – PKCS #12 mechanism similarly used for key backup l Use portable devices such as smart cards, PCMCIA devices, crypto rings

Certificate Management Certificate Use l Certificate use protocol driven – SSL /TLS and s/MIME in particular l Basic authentication model binds current user (message sender) to certificate – typically with subject signing of authentication message which includes the digital certificate l in s/MIME , signed message includes symmetric key used for bulk encryption l in SSL/TLS , signed message includes a one time nonce to prevent replay of authentication by third party l object signing similar – in general, certificate supports use of the private key

Certificate Management Certificate Revocation l 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 l e. g. change in employment or professional status or address l CA must support publication of revocation – Certificate Revocation List (CRL) l 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” l alternatives: CRL distribution points; cretificate revocation trees – Online Certificate Status Protocol (OCSP) l CA provides server that responds to status request for specific certificates with “good”, “revoked” or unknown – Alternatives based on LDAP directories l “user. Certificate” is a standard LDAP person attribute

Certificate Management Certificate Revocation l Revocation Processes – No standard “revocation request” message l Revocation request is subject to similar diligence as for a certificate request – Revocation in case of compromise generally involves action by subject l Must inform the RA / CA when private key compromised (say by theft of computer) l Governed by terms of user agreement – Registration agent’s diligence required to revoke certificate when subject information no longer true l e. g. subject information contained certificate to which the CA has made an attestation is no longer true, l e. g. left employment; lost license; terminated PPO affiliation – s/MIME certificates problematic l Certificate profile contains an email address l New certificate is required with every change of email address

Digital Certificates Key Recovery l Without private key, encrypted data unavailable – Particularly problematic in case of clinical data with potential impact on care l Archiving of private key is critical, 2 models: – Self-escrow l owner maintains secure copy of private key – Third-party escrow l rely on “Key Recovery Authority” l 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 Certificates Key Recovery Technical Approaches l Subject “back up” model – PKCS #12 protocol support to “backup” end user’s key ring l “Export” to floppy or other device; exported PKCS 12 file protected by pass phrase. l enterprise requires added processes to recover the key in case of non-availability of user, eg termination, illness l Enterprise repository – Server based key recovery l Requires that private key is securely communicate from subject to repository l 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

Certificate Management Directories l Directories may store certificates along with other subject information – user. Certificate is a standard LDAP attribute l Certificate publication required to support broad email use – Certificates required to send secure mail – How do correspondents acquire certificates l Desire to minimize “negotiation” prior to secure use l 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 l e. g. physician office administrator billing clerk

Certificate Management Cost and Business Models l Three models for Certificate Authorities – Enterprise l Issue certificates to subordinate employees and resources l CA owner controls resources to which certificate will authenticate – CA and PKI become part of network administration, eg Netware 5 l Enterprise ultimately assumes responsibility for misuse – Public l CA is fully independent of the certificate subjects and the protected resources – Hybrid l Multiple user classes imply different liability (e. g. employee; trading partner) l Multiple information resources – Authenticate staff to resources of trading partner (eg. secure email or access to eligibility data)

Certificate Management Cost and Business Models l Costs – Relatively small software cost l $800 (MSFT) up to $10 K + $/cert – Registration agent’s due diligence costs l Minimal in case of Enterprise model where merely attesting to existing knowledge of employee l May be significant for public CA to verify the subject information included on certificate – Liability costs and insurance l May be limited (somewhat) by user agreements l 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; l e. g. loss of data with non-availability of private key l e. g. reduced ability to audit information flows

Certificate Management Cost and Business Models l Highly variable total cost estimates – Annual costs anywhere from $2/ cert to $600/ cert !!! – Aberdeen Study l http: //www. versign. com/library/reports/Aberdeen/cost/index. html – Giga Information Corporation l http: //www. entrust. com/news/1998/gigatco. htm l Critical cost factors – Special requirements of vertical markets or enterprises l Increased RA due diligence & liability costs l Increased integration costs for Relying Parties – depth of certificate “chains” – End user support l Multiplicity and criticality of applications – Integration with enterprise systems

PKI Trust Models Module 5

PKI Trust Models l Basic Concepts l Certification Paths – Types – Constraints l Trust Models – Direct – Hierarchical – Mesh l Browser / Email Client Support l Significant Issues and Alternatives – “Straw Dog” Alternative

PKI Trust Models Why Trust? l Advantages of “trusting” certificates issued by others – Reach l Can extend communications to previously unknown parties – Potential for improved reliability l In the whole, fewer certificates for end users and relying parties – Efficiency l Communities can be served by different CAs (e. g. healthplan can better certify its employees than a public CA) – Economy l Cost sharing l Questions – What is being trusted? – What is the basis for trust? – What are the enforcement mechanisms?

PKI Trust Models Basic Concepts l Fundamental principle of certificate use and acceptance – The certificate subject is accountable for any use of the private key l If non-repudiation is not required, this principle can be l How is the principle supported? – Issuer (CA) has responsibility to assure appropriateness of subject - key binding l “Proof” appropriate to certificate scope l Maintain current status and publish revocation – Subject has responsibility to guard private key l Protect private key using tools appropriate to subject’s environment l Notify CA as required if private key compromised – Relying Party Responsibilities l Check certificate validity – Verify signature and revocation status l Accept restrictions of scope of certificate

PKI Trust Model Basic Obligations

PKI Trust Models Basic Concepts (cont) l How is the fundamental principle enforced? – Contract l User agreements set responsibilities and remedies – Legislation, (e. g. State of Calif. digital signature law) l By statute, presumptive responsibility for key use place on certificate owner /subject – Has limited application & is not applicable to “proxy” environments – Regulation l HIPAA & healthcare accreditation audits l Independent audits for public CA’s (AICPA) – Technology l 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 l This approach not generally appropriate for a healthcare extranet – Contrary to business and other relationships

PKI Trust Models Certificate Verification l 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? l Bootstrap problem l Verification mechanisms for signer (CA) certificates 1 Self signed using signer’s own key 1 Appropriate for root. CA 1 Requires that truth of CA identity - key binding be independently established – Browser manufacturer support by “pre-installing” public CA keys (ATT Certificate Services, GTE Cyber. Trust Global Root) – CA provides signer certificate when CA issues key to subject Appropriate for managing domains and private PKI

PKI Trust Models Certificate Verification (cont) l Verification mechanisms for Signer (CA) certificates 2 Signed by a CA superior in a hierarchy l Acceptance of the CA’s certificate is derived from acceptance of root. CA l Appropriate for corporate structures with hierarchical administration – The root. CA 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 l Acceptance of one CA derived from acceptance by another (peer) CA l Cross-licensing may be reciprocal or one way l May be appropriate for trading partners and well-defined communities of interest

PKI Trust Models Certification Paths - Example

PKI Trust Models Certification Paths - Example

PKI Trust Models Certification Path Constraints l l Trust is not unbounded Certificate authority may want to limit “signing” capability of certificates that it issues – To limit depth of a “certificate chain” l Control complexity of certificate hierarchy under CA – To limit CA liability – To distinguish between “end user” and other certificates” l e. g. may provide IPA with signing capability so that the IPA can issue certs to affiliated practices under its authority; l end user” certificates to health plan staff. – Limitations are supported by digital certificate extensions – Trust may not be transitive l use name. Constraints on cross-licensing to prevent the following: l US Canada Cuba ; but US does not trust Cuba

PKI Trust Models Browser support l Local file with root. CA self signed certificates – Managed by end user l further determine when cert will be trusted – May import certificates and trust as a root CA – Shipped with some root. CA certificates pre-installed l implicit “defacto” accreditation by browser manufacture l Verisign, Cyper. Trust, Thawte. . . – Support ordered certificate chains from sender to root stored in local file l Can import certificates from trusted directory l 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 d. B of trusted certificates

PKI Trust Models Basis for Trust l Expectations of trust differ depending on relationships – Subject and Issuer l Subject is the issuer l Subject is subordinate to issuer (employee) l Subject and issuer have independent business relationship l Public CA - issuer and subject otherwise independent – Public CA issues certificates to any qualified subject on a fee basis – Relying Party and Issuer l Issuer is the Relying Party l Issuer is a trading or practice partner of relying party l Public CA - issuer and relying party otherwise independent – Issuer may or may not be known by relying party

PKI Trust Models Types l Direct Trust – Relying party independently verifies each subject - key binding l Usually by contract - agreement to terms of certificate use l Role of CA is limited to coding the certificate – e. g. Verisign or Entrust limited liability certificates used for authentication purposes l Maintenance is an issue, contract must address revocation & other terms l Hierarchical Trust – Relying party trusts root. CA and consequently the root. CA’s certificates as well as those issued by a subordinate CA l Principal CA “owns” domain l Subordinate CA following guidelines of Principal CA (presumably) l Basic corporate model – X. 509 supports cert. Path. Length and use restrictions

PKI Trust Models Types l Peer Trust – CA self signs and cross-licenses with trading partners l Extends the reach of PKI available to each in reciprocal fashion l Requires extensive cooperation – Examples l Certificates issued by hospital for its staff are accepted by health plan l Physician certificates issued by one health plan are accepted by second health plan

PKI Trust Models Some Criticisms l Emphasis on the “who” rather than the “what” of trust – e. g. “Approved CA(s)”, but for what purpose? – Difficult business models l may wish to limit applicability of cross-licensed certificate l assumptions of liability differ with respect to different relying parties l No enforcement mechanism for breach of trust – Particularly problematic with cross-certificate chains l Lack of domain definition – Appropriate CA for many subjects with multiple affiliations is confusing l eg for physician: - healthplan, hospital, MG, IPA, state agency, . . . l Trust in hierarchical model may not be asymmetric – Certificate holders in hierarchy may have limited trust of root l physicians and health plans l Overly complex – Limited software support for cross-certification – Especially problematic for certificate revocation

PKI Trust Models Proposal for a Policy Authority l Policy Authority issues certificate to any healthcare CA(s) – Results in a single root. CA for a healthcare PKI binding “subordinate” CA to healthcare certificate policies it supports – Policy Authority CA supports publication of the CA’s supported policies l assumes common semantics, i. e. this workshop l 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” l Policy Authority – Publishes a profile for each registered CA – Publishes CRL for CA certificates l probably more proactive - push notification of certificate revocation to

PKI Trust Models Proposal for a Policy Authority l Governance – Policy Authority can be operated as independent agency l probably, in conjunction with industry CA (for cost savings) – management responsible to an industry board – Business model – Limited functionality and costs l only a few certs issued; only signer certificates to CA’s l publish revocation lists (probably OCSP) l publish healthcare policy definition l publish “audit” and CA profiles – Simple revenue model to cover costs l CA subscriptions l Precedents – NACHA financial industry trial – FED PKI will implement something similar

Certificate Policies Module 6

Certificate Policies l Role of Certificate Policy l Structure of Certificate Policy Statement l Policy Enforcement l Role of Certificate Practice Statements l Next Steps

Certificate Policies Defined l From X. 509 (v 3) 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” l l 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. user. Type – 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 Policies Policy 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 provider. Person 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 provider. Person certificate will include the qualifying NPI. That NPI will be included in a ‘provider. Identifer’ extension <citing an OID>. Note that the last two statements in 2) are really conditions on the certificate profile of a provider. Person certificate

Certificate Policies Scope l Certificate policies created by Relying Parties represent requirements for certificate practices and profiles – Conditions under which certificates are “acceptable” for Relying Party applications l Policies for a given CA are supported by: – Certificate Practice Statements l Details specific activity that CA & RA undergo to issue certificates consistent with policy statement – Certificate Profile l Name space architecture, extensions, etc l How information supporting policy is displayed on certificate l Policies are implemented on a certificate basis – A given CA can issue classes of certificates under different policies

Certificate Policies Composition l A CA can implement several consistent policies simultaneously – Policies required by a number of organizations l e. g. health plans, local hospital and lab – Policies required to support different kinds of applications l e. g. “read” versus “read / write” privileges l e. g. differential sensitivity of data – General and specific policies l e. g. policy required by any Federal Government Agency; l e. g. policy to support a HCFA requirement l 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 Policies Policy Enforcement l Policies represent an implied contract that CA faithfully implements the policies – Places a limitation on the strength of any contract having crosscertificates and longer certification chains l relying parties may not be party to a contract with issuing CA l potential for many intermediaries with different contractual obligations – Uncertain test of “faithful compliance” l Independent audits record CA’s compliance with its policy – AICPA (Amer. Inst. of CPA) standards for audits l same standards applicable to any “service” contract l basis for acceptance by State of California (per digital signature law) l 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 Policies Practice Statements l 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 l 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 l Example of a practice statement Prior to issuing a physician. Provider. Person 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 Policies Next Steps l Participant response – PKI Readiness Survey – Authentication Requirements Survey l Straw Dog Presentation – Policy Criteria – Healthcare Policy Framework – Specific Healthcare CA Policies l Tunitas Internet Site – FAQ