Public Key Infrastructure

1. Public Key Infrastructure Tools for trusting electronic records Russ Savage Mike Totherow rsavage@sos.state.az.us mtotherow@sos.state.az.us

2.  Public Key Infrastructure • What is it and What does it do for us? • Not a new concept • Means to control electronic access • Evolved as networking evolved from the dumb terminal, to networks to the internet traffic of today…

3. What we mean by securing the electronic community - • Minimize threats: • Interception • Impersonation • Alteration • Unauthorized access • Denial of Service 010111011001010110101 100101001110100110101 101010111010010100101

4. Conceptually, how do we do this? • Draw a perimeter • Identify those that can enter • Keep others out • To Protect the contents within the perimeter • control who can change (update) the contents within the perimeter

5. Electronic “community” evolution • Access control lists • Network domains • Universal Naming Convention • X.500 • Novell Directory Services • X.509 certificates • Microsoft Active Directory • LDAP

6. The electronic community • Establishes the identity of the elements of the community • Identification • Authentication • Authorization

7. Enter the electronic signature • Laws now recognize electronic signature • E-Sign • Uniform electronic Transactions Act (state level) • The twist… • Now e-signatures become part of (or related to) the document • Creates an inter-relation of digital identity and record lifecycle • Beyond electronic community, It’s also the product of the community • Electronic records!

8. Expectations of PKI: • electronic identity • electronic locations & devices within the e-community • ensuring integrity in documents • Access, authorization and control

9. Building trust for the electronic community • Define the Trust in the community • Only authorized access to the system (community)? • Do I trust the documents stored in the system (community)? • Don’t allow unauthorized access to my stuff • Don’t allow unauthorized change to my stuff • Don’t let them do it and say they didn’t • Don’t let them stop my work • Create a hierarchal chain of trust that ensures validation of the product and verifies my records

10. Elements ofPublic Key Infrastructure • The Key • Asymmetric cryptographic keys • The Infrastructure • Roles, relationships and responsibility • The Public • Open design and accessibility • Interactions with

11. Behind the “key” in public key infrastructure - the first idea of public/private key use was for encryption. (eliminated the problems with shared secret encryption) Several people can encrypt and send secure messages to Sam.And only Sam can read them. This is “Hi, only you can read this.” (a.k.a. PKC - Public Key Cryptography)

12. Then it was noticed that switching the order of public/private key use led to identification. Sam can encrypt and send unsecured messages to several people.But they know it is from Sam. This is “Hi, it’s really me.” (Internet Caller ID)

13. Light bulb - Sam can send a message to Jean, who will know it is from Sam.This is “Hi, I sent this (but somebody might have changed it).

14. To solve the risk of a party between sender and receiver changing the message. Sam can send a message to Jean. Jean will know it is from Sam and that the message has not been altered.This is “Hi, I sent this and you know whether it was changed.

15. Viola – an electronic signature on an electronic record… • unique to the person using it, • capable of reliable verification and • linked to the record in a manner so that if the record is changed the electronic signature is invalidated. • (Arizona Statute 41-132 B)

16. The “infrastructure” in PKI • “Guidelines for Public Key Infrastructure” by the American Bar Association • Defines Roles • Defines Responsibilities • Defines Relationships • Defines Liability

17. The Four Corner Model How do you know the person is who he says he is? Verified by reputable source - Chain of trust (chain of reputable sources) - Authenticating the person associated with a record is not the same as showing intent to sign or establishing integrity of a signing** • To build an electronic signature infrastructure, the community has: • Policy Authority establishing the planning and zoning for the infrastructure • Certification Authority registering the subscriber & issuing digital certificates • Community, or sub-communities, contracting with the CA for services. • Subscriber getting a certificate to have a digital signature. • (Citizen of the electronic community) • Relying Party verifies the digital signature received from the subscriber. • ** Depending on the policy of the community to which you belong

18. The Roles in Electronic Signature Use (State of Arizona’s infrastructure model) (Sec State)

19. PKI Roles & Responsibilities • Subscriber • “subject”/holder of the signature • Subscriber Agreement (policy, contract) • keep signature private (sole control) • Relying Party • party whose application requires signature validation • Relying Party agreement (policy, contract)

20. PKI Roles & Responsibilities • Certification Authority • Operates mechanisms of PKI • Registration Authority • Verify identity of applicants to become subscribers (in-person) • Issuance • Manufacture and issue electronic signatures • Ensure subscriber possession of electronic signature • Frequent Compliance Audits • Liability / Contract intensive function • Repository • Maintain electronic signatures integrity • secure facilities, with public access

21. Certificate Policy is the zoning for construction Outlines the roles Describes the responsibilities and liabilities Limits the scope of application Determines location within Infrastructure Establishes the trust amongst the community

22. The Structure is formulated into Policy Certificate Policy is the zoning plan Zoning for Infrastructure is Summarized in CP Policy Issuance of Technology Subscriber Party Repository Control for access & maintenance Relying Party • The ‘Certificate Policy’ might be called the ‘Contract of Process’ Certificate Policy: “Signing Process”

23. Public Key Infrastructure • Description of a trust through Certificate Policies & Certificate Practice Statements • hierarchy of organizational units and end nodes • uses x.509v3 certificates as protocol specification • responsibilities and liabilities of the members of the network • governs the operational aspect (tech and process) of Infrastructure • uses a public / private key for unique identifiers • Identity • Hierarchy • Encryption

24. PKI Certificate Policies • Depict the communities structure - Authority

25. Corp Y Cert Business X Cert Bob’s Cert Bob’s Cert Bob’s Cert CP YZ CPS PKI cliff notes CERTIFICATE AUTHORITY CA Z Cert CP XY CPS Repository White Pages Issuer=CA Z O=Corp Y OU=Business X DN=Bob CP BX CPS Who’s Bob

26. Two Infrastructure pilots using the same CP

27. One size does not fit all ESI for CP “A” The Arizona Electronic Signature Infrastructure (AESI) consists of several collections of pilots (ESIs) organized around different Certificate Policies (CPs). ESI for CP “B”

28. The “public” in PKI • PKI meant to be open infrastructure • Distinguished Names and Object Identifiers • External LDAP (Lightweight Directory Access Protocol) interfaces • Little infrastructures connected are big infrastructures

29. DN (distinguished names) and OID (object identifiers) • OID uniquely defines Distinguished Names and Object Identifiers. • Under the joint-iso-ccitt arc in the registration tree, the US-JRA has registered sub-authorities, including states. • Arizona’s schema builds on the US arc of the registration treeestablished according to CCITT X.660 Recommendation and ISO/IEC 9834-1 Standard. • The state arcs are defined by FIPS PUB 5-2. • The registration sub-authority for Arizona is the Secretary of State • The root Arizona arc is 2-16-840-3-04 • The first numeric assignment after 2-16-840-3-04 identifies the type of entity within the state.

31. OID Schema Reads like an Org Chart

32. Lightweight Directory Access Protocol LDAP relies on DN and RDN (Relative Distinguished Name) to define unique entries in the directory schema. The common elements for mapping between LDAP DN and OID alphanumeric assignments are: (LDAP element = OID element) • cn=CommonName • sn=Surname • l=LocalityName • st=StateName • o=OrganizationName • ou=OrganizationUnitName • c=CountryName • street=StreetAddress • uid=UserIdentifier The proposed policy in Arizona is that the registered OID alphanumeric arc is the LDAP DN.

33. Arizona a piece of global picture

34. High Medium Basic Arizona Access Authorization Encryption Digital Signatures

35. Communities of Interest • Based on interest, not jurisdiction • Need within community for electronic signing • Reduce time constraints • Reduce location restraints • Automate the operation of the Community • Jurisdictions serving community • Must be interested in participation • Resources for participation • Willing to collaborate with other jurisdictions • Agree to level of assurance required for community enrollment

36. Arizona Communities Grow High Medium Basic

37. Reliance (Community Evidence) • Within the community • agreement of community enrollment • agreement of jurisdictions governing community • common understanding of evidence • Outside the community • What are you missing? • Who else relies upon evidence created in community • What other jurisdictions must the evidence be presented • How will the evidence be communicated • Tool set / application “exportable” • How will evidence be proven • Self evidencing documentation • Jurisdiction (perhaps community wide) system security

38. Communities Cross Jurisdictions

39. (Global) Public Infrastructure takes Shape

40. So what does this do for e-records? • Just network domains and access control? • Fancy encryption to determine source of document? • Policy overwhelming, community complicated. • Put the pieces together

41. How do we assure accessibility by all parties?Interoperability requires common document and signing standardsacross different communities Documents may be “self-documenting” or “system documented records” -we’ll need a range of standards. “This initial study led to a detailed description of the electronic record. We determined that an electronic record had to be a fully self-documenting object. We chose to describe these objects in eXtensible Markup Language (XML), a text based standard. We determined that an electronic record was made up of one or more documents, contextual information relating this record with other records, and evidential integrity checks.” Victorian Electronic Records Strategy Final Report One Interoperability example is LegalXML which is establishing court document standards.http://www.legalxml.org/

42. Example of System Documented Records What is EDI? Electronic Data Interchange (EDI) is the computer-to-computer exchange of business-related documents in a structured, machine process able format.These documents may be purchase orders, invoices, payment remittances and shipping notices between the State of Ohio and its "trading partners." A trading partner, in EDI parlance, is a supplier, customer, subsidiary or any other organization with which the state of Ohio does business. EDI differs from e-mail and fax. Although both of these methods of transferring documents are electronic, both are unstructured and free-form in the way they are presented. This means that information received via e-mail or fax must be re-keyed and reinterpreted before it can be processed by a computer application. EDI, on the other hand, requires that the information be organized in a structured format which can be easily interpreted and processed by a computer application. Ohio -http://www.state.oh.us/ecedi/welcome.htm

43. Example of System Documented Records How EDI Works - Briefly (Ohio continued) EDI involves taking a standard computer flat file and reformatting the file into a structured EDI format. This format complies with specific industry standards. This reformatting process is performed by a specialized software program called an EDI translator. Once the file has been put into a structured format, it is transmitted over telephone lines to a third party network. The third-party network called a Value Added Network (VAN) provides a service much like a post office. The VAN receives the transmitted documents and places these documents into an electronic mailbox for the receiving party to pick up. By dialing into the network, the receiving party can access its mailbox and retrieve the transmitted documents. Once the electronic documents have been accessed by the receiving party, the documents once again can be processed through an EDI translator. The translator takes the documents, which are still in EDI format, and translates them into a standard computer flat file. This flat file then can be formatted into a report and printed out or sent directly into a company's computer application for processing.

44. What does it take for system documented records? • Breaches • Vulnerability • Integrity • System documentation: • Audit logs, user authorization, trustworthiness tested • From creation of to present of document in question

45. What is inspected?

46. Paper is self documenting, so electronic self-documenting is the same. Right?A copy of a paper document is a copy, whether it is another paper document or a digital image. It is possible to send an original digital document to someone -while you keep the original of it.There is no difference between them!

47. Self-Documenting Records The validity of a copy of a paper document depends on the validity of the original (and that the copyhasn’t been altered). The validity of a digital document depends on thetests it can pass - includingwhether it has been altered.Since there is no copy, only a clone, those testsapply to the clone as well.

48. Self-Documenting Records The validity of a copy of a signed paper document still depends on the validity of the original (and that the copy hasn’t been altered). There is the extra complication that you could sign a copy which would add “legal standing” to the copy.You could even make it a clone! A digital signature wraps the document. The validity of the document depends on how you can test the wrapping such that its contents were not altered.

49. Self-Documenting Records Keeping a “legal” digital image of a paper original usually requires an affidavit or oath that it is a true, unaltered copy. Keeping a “legal” digital document requires being able, over time, to test the signature’s validity and keeping the wrapped contents readable.

50. Records Management Guidance for Implementing Electronic Signature Technologies • Electronic signature records need to be retained based on their operational needs and perceptions of risk. • If an electronically signed record needs to be preserved, whether for a finite period of time or permanently, then its trustworthiness over time needs to be assured. • Use of a records retention schedule needs to include • designating the disposition authority to dispose of records • the means to dispose of records at the end of the scheduled retention