Information Security & HIPAA Regulations

Information Security & HIPAA Regulations

PKI Tutorial Model Policy Workshop Ann Geyer - Bill Pankey tunitas @ earthlink.net www.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 Healthcare Requirements 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 way e.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 Healthcare Requirements 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 Healthcare Value 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 Healthcare PKI 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 Healthcare Interoperability 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 Healthcare Workshop 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 Secondary Goals Provide a forum for continuing PKI collaboration Advance the general understanding of PKI issues and healthcares 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) Authentication in Healthcare Test 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 Healthcare Internet 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 Healthcare File 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 Healthcare Form 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 Healthcare EDI 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 Healthcare Communicating 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 Healthcare Communicating 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 purchasers 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 Basics What 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 Cryptography Basics What is cryptography? (cont)

Represents information as numbers where the numbers are the result of some mathematical manipulation Terminology: plaintext encryption ciphertext decryption 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 plaintext

Cryptography Basics What 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 algorithms 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 Basics Secret Key Cryptography 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) secret key (k) plaintext Cryptography Basics

block encryption example Th e quick brown fox wil meet the lazy dog behind the woodshed tonight at midnight. Bring plenty of catnip. plaintext coding 0 0 1 1 1 0 1 0 1 ... 0 1

0 1 8 bit substitution functions derived from the key S1 0 1 0 1 0 1 ... 0 loop for n rounds

0 1 1 1 0 0 1 0 S8 1 1 0 0 64 - bit intermediate permutations possibly

based on the key 64 - bit output ... ciphertext 0 1 1 0 1 0 1 0 A5 73 30 6B 7B 27 E6 7C D4 77 6A 5A 79 F5 68 35 82 0D FF EA F1 0 1

0 0 0 0 1 ... 1 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 insecure channel plaintext

Encryption algorithm public key (k) ciphertext Decryption algorithm private key (k*) reliable channel e.g.. secure directory plaintext Cryptography Basics Public 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 Basics Public 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 Bobs public key 2 Alice transmits cipher text over insecure channel

3 Bob decrypts message using Bobs private key Cryptography Basics Public 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 Basics RSA encryption example m y S e c re tK e y s ta n d a r d e n c o d in g o f m e s s a g e ( P K C S # 1 ) B E R ( b a s ic e n c o d in g r u le s ) D E R ( d is tin g u is h e d e n c o d in g r u le s ) 0 0 1 1 1 0 1 1 0 1 0 1 0 1 1 1 0 0 1 0 1 1 1 0 0 1 0 1 0 0 1 0 1 1 1 0 1 1 1 0 0 1 0 1 0 0 1 0 0 1 1 0 1 0 1 0 0 1 0 1 0 1 1 0 encoded m essage = m (a n u m b e r) num ber c ru n c h e r < k , n > ( a p u b lic k e y )

( e x p o n e n t ia t io n m o d u lo n ) d e c r y p tio n s im ila r ; u s e r e la te d p r iv a t e k e y , k * K* c m od n m km od n = c e x p o n r e n ts a r e v e r y la r g e ( o n th e o r d e r o f 3 5 0 d ig its i.e .1 0 2 4 b its ) ( c ip h e r te x t) = m a 3 d 2 0 5 5 d 1 a 7

8 5 8 2 3 2 9 b e 3 0 0 4 e 0 d d 4 6 6b ff e ba 0e b9

7 a 4 6 0 b 27 f1 2 1 4c a 51 c 2a e6 e d 41 d8 db 7c a 1 0e 21 b6 d 4 7 7 6 a 5 a 7 9 f5 6 8 0 53 68 6a 11 eb 42 bf d5 9c 82 90 4c 1c

ad 52 18 bf a0 d7 ce 79 ef c ip h e r te x t Cryptography Basics Message 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 Basics Public Key Digital Signature Verifies origin & integrity of transmitted message hash Message Digest insecure channel sign Encryption algorithm messages 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) Supports non-repudiation Signature confirms application of signers 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 nonrepudiation Cryptography Basics Exchange of Session Keys 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 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 Basics Computer 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 Basics Computer 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 Basics Basic 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 Scheiers 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 MSFTs CryptoAPI Digital Certificates Module 3 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 Digital Certificates What 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 Certificates What are digital certificates? (cont) controls use > Private Key 1 1 1 Entity / owner 1 signs > 1 Issuer Public Key

1 * binds > Name Certificate Name Public Key Attestation * Digital Certificates Architecture - 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 issuers private key Digital Certificates Architecture - 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 CAs practice statement prior to certificate use Digital Certificates Architecture - 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 Certificates CMA MediPass example t s a l e e

S e g pa r o f a e r e l b a d r e v n o si

Digital Certificates Architecture - 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 DNs will be globally unique uniqueness defined and enforced within a domain

Digital Certificates Architecture - 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 subjects peers

Digital Certificates Architecture - 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 Certificates

Architecture - 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 dont parse and display Digital Certificates Implementation - 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 proxys use of subjects private key by a client application requires high degree of trust in proxy & special liability model Digital Certificates Implementation - 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 Certificates Issues - 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 Certificates Smart (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 Certificates Standards 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 Certificates Standards 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 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 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 C e r t if ic a t e A u th o r it y R e g is tr a tio n A u th o r ity R e q u e s t R e g is tr a tio n F o r m H T M L fo r m c o n ta in in g < k e y g e n > F o rm m a y c o m e fro m "a n y s o u rc e " R A , C A o r o th e r C o m p le t e F o r m G e n e r a te K e y P a ir S u b je c t In fo p lu s P u b lic K e y ty p ic a lly S S L R e q u e s t C o n f ir m a t io n a g e n t's d ilig e n c e p r o c e s s S S L o r b e tte r A p p ro v e R e q u e s t

C e r tific a te C re a te a n d S Ig n C e r tific a te C e r t if ic a t e D ir e c to r y o r o th e r P u b lic a tio n Certificate Management Certificate Creation - Netscape Current Netscape Model HTML form element 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 agents 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 Certificates

Key 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 Certificates Key Recovery Technical Approaches Subject back up model

PKCS #12 protocol support to backup end users 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 agents 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 Models Why 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 Models Basic 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 subjects 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 Model Basic Obligations < a u th e n tic a te s p ro te c t > in s p e c t >

P r iv a te K e y R e ly in g P a rty S u b je c t C e r tific a te < v e r ify s ig n a tu r e S u b je c t P u b lic K e y < < r e s tr ic tio n s > > p o lic y v a lid ity p e r io d C u rre n t C e r tific a te S ta tu s CRL / OCSP < v a lid a te s u b je c t - k e y in fo n o tify o f s ta tu s c h a n g e > p u b lis h > Is s u e r

PKI Trust Models Basic 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 CAs (AICPA) Technology Protect keys for the enterprise in a central registry & control subject key access Assumes that certificate subjects cant 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 Models

Certificate Verification Certificate verification requires having issuers public key ( the CAs 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 signers 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 subject Appropriate for managing domains and private PKI PKI Trust Models Certificate Verification (cont) Verification mechanisms for Signer (CA) certificates

2 Signed by a CA superior in a hierarchy Acceptance of the CAs 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 Models Certification Paths - Example CA c e r tific a te c h a in ro o t a lic e CA CA 1

2 CA CA 11 C A - r o o t s ig n s C A - 1 c e r t C A - 1 s ig n s C A - 1 1 c e r t C A - 1 1 s ig n s c c e r t C A - r o o t s ig n s C A -1 c e rt b 22 c A lic e c a n v e r ify c e r t if ic a t e s c a n d b a f t e r v e r if y in g a c h a in o f c e r tif ic a t e s f r o m t h e C A - r o o t ( w h o s e p u b lic k e y s h e k n o w s ) th ro u g h C A -1 to C A -1 1 to c a n d th ro u g h C A -2 to b PKI Trust Models

Certification Paths - Example p r in c ip a l C A - c a p a b le o f " b r id g in g " w ith o th e r d o m a in s . T y p ic a lly w ill h a v e s o m e g o v e r n in g a u t h o r ity H ie r a r c h ic D o m a in M e s h D o m a in p e e r C A - s e lf s ig n s d is t r ib u t e s t o it s c e r t h o ld e r s - c r o s s - lic e n s e s w it h in d o m a in PKI Trust Models Certification Path Constraints 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 Models Browser 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 Models Basis 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 Models Types 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 rootCAs 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 Models Types 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 Models Some 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 Models Proposal 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 CAs 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 CAs stated objectives Equivalent to inclusion on the States 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 Models Proposal 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 CAs 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 Certificate Policies Module 6 Certificate Policies Role of Certificate Policy Structure of Certificate Policy Statement Policy Enforcement

Role of Certificate Practice Statements Next Steps Certificate Policies Defined 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 CAs 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 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 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 . Note that the last two statements in 2) are really conditions on the certificate profile of a providerPerson certificate Certificate Policies Scope 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 Policies Composition 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 Policies Policy 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 CAs 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 Policies Practice 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 Policies Next 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

Recently Viewed Presentations

  • Learning types activities , V- Visible learning A

    Learning types activities , V- Visible learning A

    Online role play (forum, virtual classroom) Reflective tasks - group or individual (forum) V/A. Case studies (forum, lesson) V/A. Rapid-fire exam questions (forum) V/A. Advanced role play - you are the consultant etc. V; Acquisition. Guided readings (library resources) OER...
  • Algorithmic Techniques for Massive Data (COMS 6998-9)

    Algorithmic Techniques for Massive Data (COMS 6998-9)

    Algorithmic Techniques for Massive Data (COMS 6998-9) AlexAndoni. Left to the title, a presenter can insert his/her own image pertinent to the presentation.
  • Management of UC

    Management of UC

    Unmet Needs in UC: Expert Group Consensus (cont) Treatment Options for UC. Efficacy of Anti-TNF Therapy in UC. VARSITY: First Head-to-Head Superiority Trial Comparing 2 Biologics in UC. VARSITY: Efficacy and Safety of Vedolizumab in UC.
  • Presentation Title Goes Here - WordPress.com

    Presentation Title Goes Here - WordPress.com

    Cheminformatics for Computational Chemistry and Computer-Aided Molecular Discovery * NW requirements revealed by motives for adoption need to enumerate the set of proto-stereomeric structures which a compound can adopt (2D-MetaStructure) and the set of proto-stereo-conformers (3D-MetaStructure) subject to user specifications...
  • Diapositive 1 - jam.bouguechal.free.fr

    Diapositive 1 - jam.bouguechal.free.fr

    L'atome d'hydrogène étant sphérique, on utilise les coordonnées sphériques r, θ et φ pour décrire la position de l'électron autour du noyau, pris comme origine.
  • Learning outcomes - msmt

    Learning outcomes - msmt

    * * Which should come first - Programme or Module Learning Outcomes? Matrix of Learning Outcomes Program L.Os Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 1 x 2 x x x 3 4 x x...
  • How to Create a New Guardianship Program

    How to Create a New Guardianship Program

    HOW TO CREATE A NEW GUARDIANSHIP PROGRAM Monica Mitchell Judicial Staff Counsel San Bernardino Superior Court STEP ONE DETERMINE THE MODEL OF THE PROGRAM STEP ONE: PICK A MODEL Facilitation (passive, one on one) Direct (active, one on one) Workshop...
  • Plasma Diagnostics - C-DEN

    Plasma Diagnostics - C-DEN

    Plasma Diagnostics ... QMS signal for CH4 is measured for a known pressure of the gas in the plasma chamber under plasma-off condition CH4 calibration must be done right after the O concentration measurements to avoid the effect of drifts...