PKI Tutorial Model Policy Workshop

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

2. 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

3. 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.

4. Authentication in Healthcare Module 1

5. 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

6. 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

7. 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

8. 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 . . .

9. 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

10. Authentication in HealthcareWorkshop Goals • Build a FRAMEWORKfor 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

11. 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

12. 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

13. 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)

14. 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

15. 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

16. 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

17. 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

18. Cryptography Basics Module 2

19. Cryptography Basics • What is Cryptography? • Secret Key Cryptography • Public Key Cryptography • Message Digest • Digital Signature • Standards • Software Considerations

20. 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: krupto (secret) + grafh(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

21. encryption decryption plaintext ciphertext plaintext Cryptography BasicsWhat is cryptography? (cont) • 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

22. 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)

23. Encryption algorithm Decryption algorithm ciphertext plaintext plaintext secure channel Cryptography BasicsSecret Key Cryptography • Single key for encryption and decryption • typically used for “bulk” encryption • referred to as “symmetric key” cryptography insecure channel secretkey (k) secretkey (k)

24. Cryptography Basicsblock encryption example

25. Cryptography Basics Secret Key Cryptography (cont) • Example • Alice encrypts message using key, K • Alice securely shares K with Bob • Alice transmits ciphertext to Bob over insecure channel • 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

26. 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

27. ciphertext plaintext plaintext 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 insecure channel Encryption algorithm Decryption algorithm privatekey (k*) publickey (k) reliable channel e.g.. secure directory

28. 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

29. 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 • Alice encrypts message using Bob’s public key • Alice transmits cipher text over insecure channel • Bob decrypts message using Bob’s private key

30. 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

31. Cryptograhy BasicsRSA encryption example

32. 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

33. insecure channel Cryptography BasicsPublic Key Digital Signature • Verifies origin & integrity of transmitted message verify hash Message Digest Recompute digest and compare w/ transmitted signature sign message’s digital signature Encryption algorithm Decryption algorithm privatekey (k) reliable channel e.g. secure directory publickey (k*)

34. 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

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

36. 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

37. 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

38. 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 …

39. 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

40. Digital Certificates Module 3

41. Digital Certificates • 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

42. 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

43. Digital CertificatesWhat are digital certificates? (cont)

44. 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

45. 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

46. 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

47. Digital CertificatesCMA MediPass example See last page for readable version

48. Digital CertificatesArchitecture - Subject DN • Subject Distinguished Name (DN) • Name for the public key owner • Follows the X.500 distinguished name format • e.g.. cn=commonname, 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

49. 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, JohnDoe2solutions 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

50. 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