Transcript Public Key Infrastructure Tools for trusting electronic records Russ Savage Mike Totherow [email protected] [email protected] Public Key Infrastructure • What is it and What does it do.

Public Key Infrastructure
Tools for trusting electronic records
Russ Savage
Mike Totherow
[email protected]
[email protected]
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…
What we mean by securing the
electronic community • Minimize threats:
– Interception
– Impersonation
– Alteration
– Unauthorized access
– Denial of Service
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
Electronic “community” evolution
•
•
•
•
Access control lists
Network domains
Universal Naming Convention
X.500
– Novell Directory Services
– X.509 certificates
– Microsoft Active Directory
– LDAP
The electronic community
• Establishes the identity of the
elements of the community
– Identification
– Authentication
– Authorization
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!
Expectations of PKI:
•
•
•
•
electronic identity
electronic locations & devices within the e-community
ensuring integrity in documents
Access, authorization and control
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
Elements of
Public Key Infrastructure
• The Key
– Asymmetric cryptographic keys
• The Infrastructure
– Roles, relationships and responsibility
• The Public
– Open design and accessibility
– Interactions with
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)
Sam's
Public
Key
Plaintext
Sam's
Private
Key
Ciphertext
Plaintext
Decrypt
Encrypt
Ciphertext
Plaintext
Encrypt
Ciphertext
Plaintext
Encrypt
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)
Then it was noticed
that switching the order of public/private key use led to identification.
Sam's
Public
Key
Sam's
Private
Key
Plaintext
Ciphertext
Plaintext
Decrypt
Encrypt
Ciphertext
Plaintext
Decrypt
Ciphertext
Plaintext
Decrypt
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)
Light bulb Sam
Betty
(Originator/Signer)
(Recepient/Relying Party)
plaintext
document
plaintext
document
plaintext
Sign
Sam's
Private
Key
Signature
Verify
Verifies?
(yes/no)
Sam's
Public
Key
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).
To solve the risk
of a party between sender and receiver changing the message.
Message
Message
Hash Function
Hash Function
Message
Signature
Digest
Private
Key
Public
Key
Decrypt
Encrypt
Signature
Expected
Digest
Actual
Digest
If these are the same,
the signature is verified
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.
Message
Message
Hash Function
Hash Function
Message
Signature
Digest
Private
Key
Public
Key
Decrypt
Encrypt
Signature
Expected
Digest
Actual
Digest
If these are the same,
the signature is verified
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)
The “infrastructure” in PKI
– “Guidelines for Public Key
Infrastructure” by the American Bar
Association
• Defines Roles
• Defines Responsibilities
• Defines Relationships
• Defines Liability
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
The Roles in Electronic Signature Use
(State of Arizona’s infrastructure model)
(Sec State)
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)
PKI Roles & Responsibilities
• Certification Authority
– Operates mechanisms of PKI
– Registration Authority
• Verify identity of applicants to become subscribers (inperson)
– 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
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
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
Policy Authority
(Secretary of
State)
Certification
Authority
Repository
VISIOCORPORATION
Deposit
Subscriber's Public
Key for Validation
$
Subscribe for
Electronic
Signature
(and receive
Private Key)
Request
validation of
Certificate. Valid?
Yes/No
Agency PKI
Project
Subscriber
E-mail or other
Electronically Signed
Document
Relying
Party
Certificate Policy:
“Signing
Process”
The ‘Certificate Policy’ might be called
the ‘Contract of Process’
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
PKI Certificate Policies
• Depict the communities structure - Authority
CP YZ
PKI cliff notes
CPS
CERTIFICATE AUTHORITY
CP XY
CA Z
Cert
CPS
Corp Y
Cert
Business
X
Cert
Who’s Bob
Bob’s
Cert
Bob’s
Cert
White Pages
Issuer=CA Z
O=Corp Y
OU=Business X
DN=Bob
CP BX
CPS
Repository
Bob’s
Cert
Two Infrastructure pilots using the same CP
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”
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
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 tree
established 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.
OID Schema for the State of Arizona
(2)
[ISO-CCITT root]
(16)
[org-type=country]
(840)
US
(3)
[org-type=State]
(04)
AZ [Arizona]
(nn)
[org-type=intraStateType]
01 = (EB) exec branch
02 = (LB) legislative branch
03 = (JB) judicial branch
04 = (CO) county
05 = (CI) city [and similar subdivisions]
06 = (OP) other public entities
07 = (NP) non-profit entities
08 = (PB) private business (corp., LLC, etc)
09 = (PC) private citizen
10 = (EE) exec branch - educational (college, university)
00 = (SO) state object
(nnn)
intraStateOrg
[division, object]
(nn)
[SubOrg-type=division,
object]
(nnn)
SubOrg [division,
object]
(nn)
[SubOrg-type=section,
object]
(nnn)
SubOrg [section,
object]
(nn)
[SubOrg-type=unit, object]
(nnn)
SubOrg [unit,
object]
OID Schema Reads like an Org Chart
OID Schema for the State of Arizona
2.16.840.3.04
[state OID]
(01)
[org-type=EB
(exec branch)]
(02)
[org-type=LB
(legislative branch)]
(03)
[org-type=JB
(judicial branch)]
(001)
Office of the
Governor
(002)
Secretary of State
(01)
[org-type=EP
(person)]
(01)
[org-type=EP
(person)]
(001)
the
Governor
(001)
the
Secretary of State
(04)
[org-type=CO
(county)]
(nnn)
other Exec Branch
entity
(05)
[org-type=CI
(city)]
(06)
[org-type=OP
(other public
entity)]
(07)
[org-type=NP
(non-profit entity)]
(08)
[org-type=PB
(private business)]
(09)
[org-type=PC
(private citizen)]
(000)
Exec Branch object
(00)
[org-type=OO
(object)]
(02)
[org-type=DO
(division)]
(999)
Policy Authority
(001)
Elections
(00
[org-type=OO
(object)]
(01)
[org-type=EP
(person)]
(000)
Policy Authority
Practices
(002)
Business Division
(000)
SecState Object
(02)
[org-type=DO
(division)]
(01)
State Seal
(001)
Certificate Policy Fundamental
2.16.840.3.04.01.002.02.999.00.001
(02)
Web server
(002)
Certificate Policy Basic
2.16.840.3.04.01.002.02.999.00.002
(10)
[org-type=EE
(educational)]
(00)
[org-type=SO
(state object)]
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.
Arizona a piece of global picture
Arizona
High
Medium
Basic
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
Arizona Communities Grow
High
Medium
Basic
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
Communities Cross Jurisdictions
(Global) Public Infrastructure
takes Shape
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
How do we assure accessibility by all parties?
Interoperability requires common document and signing standards
across 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/
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
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.
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
What is inspected?
Digital
Signature
(or equivalent)
Self-documenting record
Signed Original
Electronic
Document
Signed Electronic
Document
Expert Witness - System Integrity Audit
Shipping
Receiving
unPackaging
Packaging
System documenting record
"signed" database record
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.
Paper Copy
Original Paper Document
Digital Copy (Image)
It is possible to
send an original
digital document
to someone while you keep
the original of it.
Original Digital Document
There is no difference between them!
Original Digital Document
Self-Documenting Records
The validity of a copy of a paper
document depends on the validity of the
original
(and that the copy
hasn’t been altered).
Child
Parent
Paper Copy
Original Paper Document
The validity of a digital
document depends on the
tests it can pass - including
whether it has been altered.
Child
Digital Copy (Image)
Parent
Clone
Since there is no copy,
only a clone, those tests
apply to the clone as well.
Original Digital Document
Digital Document
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).
Child
Parent
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!
signature
Paper Copy
signature
Child
Signed Original Paper
Document
signature
Digital Copy (Image)
Digital Signature
Parent
A digital signature wraps
Signed Original Digital
Document
the document. The validity
of the document depends on how you can test the wrapping
such that its contents were not altered.
Clone
Signed Digital Document
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.
Child
Parent
signature
Paper Copy
signature
Child
Signed Original Paper
Document
signature
Signed Original Digital
Document
Digital Signature
Digital Signature
Parent
Digital Copy (Image)
Clone
Signed Digital Document
Keeping a “legal” digital document requires being able, over time,
to test the signature’s validity and keeping the wrapped contents readable.
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
If an electronically signed record needs to be preserved,
then its trustworthiness over time needs to be assured.
Digital
Signature
(or equivalent)
Self-documenting record
Signed Original
Electronic
Document
Signed Electronic
Document
Expert Witness - System Integrity Audit
Shipping
Receiving
unPackaging
Packaging
System documenting record
"signed" database record
Self Documenting record
Documenting integrity over time
Message
Message
Hash Function
Hash Function
Message
Signature
Digest
Private
Key
CP
Public
Key
Decrypt
Encrypt
Signature
Expected
Digest
Actual
Digest
If these are the same,
the signature is verified
Trust
Chain
System Documented Record
Documenting integrity over time
Trustworthy Records
Reliability - record content can be trusted as a full and accurate representation of
the transactions, activities, or facts to which it attests and can be depended upon in
the course of subsequent transactions or activities.
Authenticity - a record proven to be what it purports to be and to have been created
or sent by the person who purports to have created and sent it.
Usability - a record that can be located, retrieved, presented, and interpreted.
In any subsequent retrieval and use, the record should be capable of being directly connected
to the business activity or transaction which produced it. It should be possible to identify a
record within the context of broader business activities and functions. The links between
records which document a sequence of activities should be maintained. These contextual
linkages of records should carry the information needed for an understanding of the transaction
that created and used them.
Trustworthy Records
(cont.)
Integrity - a record being complete and unaltered.
• protect record against alteration without appropriate permission.
• records management policies and procedures should specify
• what, if any, additions or annotations may be made to a record after it is
created,
• under what circumstances additions or annotations may be authorized, and
• who is authorized to make them.
• Any authorized annotation or addition to a record made after it is complete should
be explicitly indicated as annotations or additions.
• structural integrity of a record - the structure of a record should remain
physically or logically intact - its physical and logical format and the
relationships between the data elements comprising the record. Failure to maintain
the record’s structural integrity may impair its reliability and authenticity.
Preserving Trustworthy Records
For a record to remain reliable, authentic, with its integrity maintained, and useable
over the record life cycle, it is necessary to preserve its content, context, and
sometimes its structure.
A trustworthy record preserves the actual content of the record itself and information
about the record that relates to the context in which it was created and used (e.g.
formatting of presentation).
Specific contextual information will vary depending upon the business, legal, and
regulatory requirements of the business.
It also may be necessary to preserve the structure or arrangement of its parts.
Failure to preserve the structure of the record will impair its structural integrity. That
may undermine the record’s reliability and authenticity (e.g. Linking the parts of the
record together - presentation organizational instructions such as what text with what
graphic).
Preserving Trustworthy Records
Content*
• The electronic signature or signatures in a record are part of the content.
• They indicate who signed a record and whether that person approved the content
of the record.
• Multiple signatures can indicate initial approval and subsequent concurrency.
• Signatures are often accompanied by dates and other identifiers such as
organization or title.
• All of this is part of the content of the record and needs to be preserved.
• Lack of this information seriously affects a document’s reliability and authenticity.
* text largely from
“Records Management Guidance for Agencies Implementing Electronic Signature Technologies”
National Archives and Records Administration, Oct. 18, 2000
Preserving Trustworthy Records
Context*
• Some electronic signature technologies rely on individual identifiers that are not
embedded in the content of the record, trust paths, and other means to create and
verify the validity of an electronic signature. This information is outside of the
content of the record, but is nevertheless important to the context of the record as
it provides additional evidence to support the reliability and authenticity of the
record.
• Lack of these contextual records seriously affects one’s ability to verify the
validity of the signed content.
* text largely from
“Records Management Guidance for Agencies Implementing Electronic Signature Technologies”
National Archives and Records Administration, Oct. 18, 2000
Preserving Trustworthy Records
Structure*
• Preserving the structure of a record means its physical and logical format and the
relationships between the data elements comprising the record remain physically
and logically intact.
• It may be necessary to maintain the structure of the electronic signature. In that
case it is necessary to retain the hardware and software that created the signature
(e.g., chips or encryption algorithms) so that the complete record could be
revalidated at a later time as needed.
* text largely from
“Records Management Guidance for Agencies Implementing Electronic Signature Technologies”
National Archives and Records Administration, Oct. 18, 2000
Preserving Trustworthy Records
All of the checks and balances (the evidentiary proof) in the paper world will
need to be mimicked in the electronic world - the clerk stamps the filing on
receipt, files a self-documenting, signed original paper record, and, when
requested, a copy is stamped as a certified copy.
Some form of technical “non-repudiation” services must be implemented to
protect reliability, authenticity, integrity and usability.
Essential elements:
• Evidence of the origin of the message
• Evidence of sent
• Evidence of receipt
• Timestamp as needed of origin, sent, receipt
• Long-term storage of evidence
• Designated adjudicator of prospective disputes
Remember that you’re not alone, others need access to those documents
and records. And they need assurance that you protected the reliability,
authenticity, integrity and usability of those records..
Intentionally blank
It’s important to remember that you’re not alone,
others need access to those documents & records.
Working Files
Electronic
Communications
(Internal & External
Sources)
Identify Business
Communications
(by agency protocol)
Determine
Agency
E-Records
Policy per
Statute, Regs
& Rules
discard non-business
communications
Provide Access to
Business Records according to
Agency Protocol
Active E-record
Repository
capture business
communications
according to
Agency & State
policy, standards
& procedures
(GITA, SLAPR,
SoS, GAO)
(electronic record/document management systems)
E-records technology refresh as needed
Inactive & Archive E-record Vault
Electronic Records Life Cycle
Simplified Business Process View
Non-Business
E-communications
Provide Access to
Business Records according to
Agency Protocol
External
E-Records Users
destruction of persistent e-records
at end of retention period
Provide Access to
Business Records according to
Agency Protocol
Current Movements to address the inter-relationship of
digital identity & electronic records lifecycle using PKI
For a record/document, we often need to:
• identify & authenticate the source/originator
• identify & authenticate requester –
increasingly we need to manage access to records
(or parts of records) based on the requester’s role
(identity, purpose, etc)
• authorized access management
• encryption and electronic “redacting” for confidentiality
(e.g. HIPPA – Health Information Privacy & Portability Act)
• identify & authenticate signer(s)
• affirm the integrity of record/document
• copy certify – “this is a true and accurate copy of….”
Some of the current national, international and state PKI efforts
• Federal PKI Bridge – link agencies’ PKI systems together
• Federal ACES – common PKI system for federal agencies
• Identrus (international banking industry effort)
• USPS (certified “e-mail”)
• Multi-state Electronic Signatures & Documents Reciprocity
• Electronic Notary (multi-state reciprocity)
Federal Bridge CA (FBCA)
• The Federal Bridge CA is operated by the FPMA.
• Its purpose is to be a bridge of trust that provides trust paths
between the various trust domains of the Federal PKI, as well as
between the Federal PKI and non-Federal trust domains.
• FPMA-approved trust domains designate a principal CA that is
eligible to cross-certify with the Federal FBCA.
• The FBCA is not a root CA because it does not typically begin
certification paths.
Federal PKI Policy Authority
• Voluntary interagency group (is not an agency itself)
Six charter members – DOJ, DOD, OMB, GSA, Treasury and DOC
• Governing body for FBCA interoperability
Responsible for Certificate Policy
Agency FBCA certificate policy mappings
• Oversees operation of FBCA
• Operates under the Federal CIO Council
What is ACES?
Access Certificates for Electronic Services (ACES)
provides the American Public secure electronic
access to privacy related Federal Government
Access Federal
information and services System
through
the use of public key
with ACES
technology.
Authentication
Any Web-based
Access Control
Data Integrity
Citizen
Return Personalized
Government
Benefits/Information
Government
Application
Validate Digital
Signature Certificate
Technical Non-Repudiation
Industry
Partner
(This an OMB slide)
ACES
Certificate Arbitrator Module (CAM)
What is CAM?
The Certificate Arbitrator Module (CAM) is an application-level
router that efficiently and consistently routes certificates from
relying party programs to the issuing certification authorities (CAs)
for validation. By interfacing directly with the CAM, a relying
party application will be able to interact seamlessly with multiple
CAs.
Open Source (with some proprietary parts)
As of August 2001, the CAM source code is now available through
our open source agreement. This web site will continue to be the
sole distribution point for the official CAM used in the ACES
program.
Identrus
an international banking trust initiative
via an interoperable PKI network
IDENTRUS
Financial Institutions
- Certificate Authority
Corporate clients
employees with
certificates
authenticated eCommerce between banking customers
State Electronic Records and Signatures Reciprocity
United States Postal Service (USPS) certified e-mail
PosteCS™ works with Secure Sockets Layer (SSL) enabled browsers.
How it works for the sender
•You establish a PosteCS account before the first file can be sent.
•Next, you simply select the email address to where the document will be sent.
•You can also choose to add several security levels along with delivery
confirmation before sending the document.
•When the document is sent it is uploaded to the PosteCS server, which
generates an email notice to the recipient, containing a unique Web address (a
patented technology) to access the PosteCS document.
How It works for the Recipient
•Following the notification email, the Recipient clicks on the Web address.
•The file is downloaded through the Web connection into a Web browser.
State Electronic Records and Signatures Reciprocity
NECCC E-SIGN Interoperability Workgroup and
State Electronic Records and Signatures Reciprocity and
Interoperability Issues
E-SIGN - Federal Electronic Signatures in Global and National Commerce Act
• E-SIGN was passed and put into effect in 2000.
• UETA (Uniform Electronic Transactions Act) was also passed
by about half the states.
• They
establish a legal foundation for electronic signatures
in commerce. An electronic signature is whatever the parties agree to.
•E-SIGN requires states to be “technology neutral.”
State statutes that aren’t “technology neutral” are preempted.
State Electronic Records and Signatures Reciprocity
Several States:
• Were a “little concerned” about preemption.
• They also recognized
the risk of having to receive any record format,
 the need for legal guidelines for agencies and
 for an interoperability framework for recognizing
electronic signatures from other states.

• Met in August, 2000 to discuss the issues.
(hosted by California’s Secretary of State)
• Then met in September to form workgroups
Policy, Legal, Security, and Interoperability
sponsored by National Governors’ Association
coordinated by NECCC
(National Electronic Commerce Coordination Council)
Work will be officially published at NECCC conference this December.
State Electronic Records and Signatures Reciprocity
Using an electronic signature means creating a signed electronic document.
The legality of an electronically signed record requires that it
“remains accessible to all persons who are entitled to access by
statute, regulation, or rule of law, for the period required by such
statute, regulation, or rule of law, in a form that is capable of being
accurately reproduced for later reference, whether by transmission,
printing, or otherwise.” (emphasis added)
•Federal Electronic Signatures in Global and National Commerce Act,
Section101. (d)(1)(B)
(E-SIGN - interstate and international commerce)
State Electronic Records and Signatures Reciprocity
The Interoperability work group asked
“how do we get from technology neutral e-signatures statutes
to agreement about what are
sharable, trustworthy signed electronic documents
(things that are reliable, usable, authentic, and having integrity)?”
State Electronic Records and Signatures Reciprocity
Secure electronic signatures
A signature is a secure electronic signature if, through the
application of a security procedure, it can be demonstrated that the
electronic signature at the time the signature was made was all of
the following:
 Unique to the person using it.
 Capable of verification.
 Under the sole control of the person using it.
 Linked to the electronic record to which it relates in such a
manner that if the record were changed the electronic
signature would be invalidated.
State Electronic Records and Signatures Reciprocity
Secure electronic records
If, through the ongoing application of a security procedure, it can
be demonstrated that an electronic record signed by a secure
electronic signature has remained unaltered since a specified time,
the record is a secure electronic record from that time of signing
forward.
State Electronic Records and Signatures Reciprocity
Proposed Process leading to Electronic Signature Reciprocity between States
Recognize NEC3
definitions for Secure
Electronic Signatures and
Secure Electronic Record
Determine whether to
centralize electronic
signature policy
Centralized
Electronic Signature Policy
Management Authority (ESPMA)
[NEC3 ESR Framework whitepaper]
While the Electronic Signature Policy
Management Authority (ESPMA)
provides a general framework for
centralized electronic signature
management, there may be particular
additions needed for specifc
technologies
(e.g. a PKI based Policy Management
Authority (PKI PMA) might be formed
with a wider view of PKI use and the
ESPMA and the PKI PMA policies would
need to be harmonized).
PKI Signing Process
(with Certificate Policy
ala NEC3 Model PKI CP)
Decentralized Electronic
Signature Practices
[NEC3 ? whitepaper]
Develop Electronic Signing processes conforming to the
NEC3 Framework for Electronic Signature Reciprocity
(and appropriate policy)
Determine Electronic Signing
Process(es) to be used
(and appropriate Electronic
Signature Policies)
PGP signing
process
(with appropriate
policy)
Shared Secret signing
process
(PIN/password)
(with appropriate policy)
Negotiate Reciprocity
with other states based
on the Framework
? Signing Process
(with appropriate
policy)
State Electronic Records and Signatures Reciprocity
Framework for Electronic Signature Reciprocity
The Framework identifies appropriate implementations for basic, medium, and high
trust levels as far as how the:
• Signer is identified.
• Signer is linked to the signature.
• Signature is linked to the integrity of the record.
The trust levels are:
• Basic - provides a basic level of assurance relevant to transactions where there are
risks and consequences of data compromise, but they are not considered to be of
major significance. This may include access to private information where the
likelihood of malicious access is not high. It is assumed at this security level that
users are not likely to be malicious.
• Medium - is relevant to environments where risks and consequences of data
compromise are moderate. This may include transactions having substantial
monetary value or risk of fraud, or involving access to private information where the
likelihood of malicious access is substantial.
• High - is appropriate for use where the threats to data are high, or the
consequences of the failure of security services are high. This may include very
high value transactions or high levels of fraud risk.
State Electronic Records and Signatures Reciprocity
Proposed Process leading to Electronic Signature Reciprocity between States
Recognize NEC3
definitions for Secure
Electronic Signatures and
Secure Electronic Record
Determine whether to
centralize electronic
signature policy
Centralized
Electronic Signature Policy
Management Authority (ESPMA)
[NEC3 ESR Framework whitepaper]
While the Electronic Signature Policy
Management Authority (ESPMA)
provides a general framework for
centralized electronic signature
management, there may be particular
additions needed for specifc
technologies
(e.g. a PKI based Policy Management
Authority (PKI PMA) might be formed
with a wider view of PKI use and the
ESPMA and the PKI PMA policies would
need to be harmonized).
PKI Signing Process
(with Certificate Policy
ala NEC3 Model PKI CP)
Decentralized Electronic
Signature Practices
[NEC3 ? whitepaper]
Develop Electronic Signing processes conforming to the
NEC3 Framework for Electronic Signature Reciprocity
(and appropriate policy)
Determine Electronic Signing
Process(es) to be used
(and appropriate Electronic
Signature Policies)
PGP signing
process
(with appropriate
policy)
Shared Secret signing
process
(PIN/password)
(with appropriate policy)
Negotiate Reciprocity
with other states based
on the Framework
? Signing Process
(with appropriate
policy)
State Electronic Records and Signatures Reciprocity
Now some of mine can migrate to your place and
some of yours can migrate to my place.
Still, they will need to be readable at both places.
Copy certification & electronic notary will evolve in the near future.
Interoperability
getting from here to over there
Working Files
Working Files
Electronic
Communications
Electronic
Communications
(Internal & External
Sources)
(Internal & External
Sources)
Identify Business
Communications
(by agency protocol)
Determine
Agency
E-Records
Policy per
Statute, Regs
& Rules
discard non-business
communications
Provide Access to
Business Records according to
Agency Protocol
Active E-record
Repository
capture business
communications
according to
Agency & State
policy, standards
& procedures
(GITA, SLAPR,
SoS, GAO)
(electronic record/document management systems)
E-records technology refresh as needed
Non-Business
E-communications
Identify Business
Communications
(by agency protocol)
Determine
Agency
E-Records
Policy per
Statute, Regs
& Rules
discard non-business
communications
Provide Access to
Business Records according to
Agency Protocol
Provide Access to
Business Records according to
Agency Protocol
Active E-record
Repository
capture business
communications
according to
Agency & State
policy, standards
& procedures
(GITA, SLAPR,
SoS, GAO)
(electronic record/document management systems)
E-records technology refresh as needed
Inactive & Archive E-record Vault
Inactive & Archive E-record Vault
Electronic Records Life Cycle
Simplified Business Process View
External
E-Records Users
destruction of persistent e-records
at end of retention period
Provide Access to
Business Records according to
Agency Protocol
Electronic Records Life Cycle
Simplified Business Process View
Non-Business
E-communications
Provide Access to
Business Records according to
Agency Protocol
External
E-Records Users
destruction of persistent e-records
at end of retention period
Provide Access to
Business Records according to
Agency Protocol
Thank you
• Please visit us on the web…
http://www.sos.state.az.us/pa
Russ Savage
Mike Totherow
[email protected]
[email protected]
For those more interested
• Following slides contain examples of
what a digital certificate looks like
Digital Signatures (PKI)
• uses a certificate issued within a PKI
– here’s what a certificate looks like
– elements of a certificate
• uses encryption algorithms
– publicly known algorithms
– very high levels of assurance
• Bits equates stronger protection, but encryption still
decays with age
PKI signature example
1. Policy Authority defines the Certificate Policy for trusted network description
2. Department as a relying party defines community of interest
a. Decision: electronic signatures needed? - Digital Signature
b. Chooses Certificate Policy
c. Chooses Vendor off Approved Certification Authority List
i Department will act as RA
ii Department (or community?) will archive certificates
iii Vendor sells tool sets to subscribers
d. Department creates application for community
3. Subscriber visits Registration Authority (potentially Gov through contract) to register
a. Subscriber verifies identity to RA
b. CA issues digital signature to Subscriber
c. Subscriber gets training from Vendor
d. Subscriber installs tool set with Vendor support
4. CA publishes public digital signature in Repository
5. Subscriber uses application to commit transaction
a. Signs document with issued digital signature
6. Relying party receives document
a. Verify integrity of transaction
i Verify signature against repository
ii Check Certificate Revocation List (CRL)
b. Updates database and stores transaction
I Information parsed and saved in db
ii “document” stored for evidence
c. Receipt sent to subscriber
d. Relying party verifies receipt received
The Roles in Electronic Signature Use
(State of Arizona’s infrastructure model)
Policy Authority
(Secretary of State)
Certification
Authority
Repository
VISIO CORPORATION
Deposit
Subscriber's Public
Key for Validation
$
Subscribe for
Electronic
Signature
(and receive
Private Key)
Request
validation of
Certificate. Valid?
Yes/No
Agency PKI Project
E-mail or other
Electronically Signed Document
Subscriber
Relying Party
New
Applicant
Apply for
Digital
Signature
Applicatio
n
approved
Life Cycle
Certificate
Issued
Accepted
by
Subscriber
Apply to
Renew
(about to
expire)
Subscriber
Uses
Revoked
(Compromised,
critical information change
or expired)
Digital Certificate Life Cycle
While this describes PKI certificates, the need for application and
renewal occurs for any identification process - you have to identify the
applicant and periodically renew them
PKI Risk evaluation
• Uniqueness
– In-person registration assures uniqueness
• Verifiable
– provides non-refutable verification
• Repudiation based on handling, not technology
• Sole control
– Combination something person knows with have =
Medium
– Smart card could be next to perfect (with biometric)
• depends on implementation
• Linked to the record
– Implementation inherent by design
Electronic Document by DS
<xml version=1.0>
<document>
<title>An Electronic Document</title>
SAMPLE SIGNING BLOCK
[s01] <Signature Id="MyFirstSignature"
xmlns="http://www.w3.org/2000/09/xmldsig#">
[s02] <SignedInfo>
[s03] <CanonicalizationMethod
Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
[s04] <SignatureMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1"/>
[s05] <Reference URI="http://www.w3.org/TR/2000/REC-xhtml1-20000126/">
[s06] <Transforms>
[s07]
<Transform
Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
[s08] </Transforms>
[s09] <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
[s10] <DigestValue>j6lwx3rvEPO0vKtMup4NbeVu8nk=</DigestValue>
[s11] </Reference> [s12] </SignedInfo>
[s13] <SignatureValue>MC0CFFrVLtRlk=...</SignatureValue>
[s14] <KeyInfo>
[s15a] <KeyValue>
[s15b]
<DSAKeyValue>
[s15c]
<P>...</P><Q>...</Q><G>...</G><Y>...</Y>
[s15d]
</DSAKeyValue>
[s15e] </KeyValue>
[s16] </KeyInfo>
[s17] </Signature>
<Section style=paragraph>This is an example of a document.</Section>
<Section style=paragrahp>Everything within the document tag is passed to the
hash algorithm to create the hash. The hash is stored in the document under the
signing block, and the digital signature certificate information is inserted to
designate who “signed” the document.</Section>
</document>
<Signature Id=“Mike Totherow” xmlns=“http://repository.verisign.com/clm#1”>
<SignedInfo>
<CanonicalizationMethod
Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
<SignatureMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1"/>
<Reference URI="http://www.w3.org/TR/2000/REC-xhtml1-20000126/">
<Transforms>
<Transform Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n20010315"/>
</Transforms>
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<DigestValue>j6lwx3rvEPO0vKtMup4NbeVu8nk=</DigestValue>
</Reference> [s12] </SignedInfo>
<SignatureValue>MC0CFFrVLtRlk=...</SignatureValue>
<KeyInfo>
<KeyValue>
<DSAKeyValue>
<P>...</P><Q>...</Q><G>...</G><Y>...</Y>
</DSAKeyValue>
</KeyValue>
</KeyInfo>
</Signature>
</xml>
Email Digital Signature
Received: from femail18.sdc1.sfba.home.com ([24.0.95.145]) by extra.sosaz.com with SMTP (Microsoft
Exchange Internet Mail Service Version 5.5.2650.21)
id JFJH9NQG; Sat, 28 Apr 2001 13:39:06 -0700
Received: from cx74747a ([24.1.194.228]) by femail18.sdc1.sfba.home.com
(InterMail vM.4.01.03.20 201-229-121-120-20010223) with SMTP
id <20010428204109.YZEE937.femail18.sdc1.sfba.home.com@cx74747a>
for <[email protected]>; Sat, 28 Apr 2001 13:41:09 -0700
Message-ID: <[email protected]>
From: "Michael Totherow" <[email protected]>
To: "Michael Totherow" <[email protected]>
Subject: This is a Signed Email
Date: Sat, 28 Apr 2001 13:38:20 -0700
MIME-Version: 1.0
Content-Type: multipart/signed;
protocol="application/x-pkcs7-signature";
micalg=SHA1;
boundary="----=_NextPart_000_005C_01C0CFE8.7DBBDD00"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2615.200
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
This is a multi-part message in MIME format.
------=_NextPart_000_005C_01C0CFE8.7DBBDD00
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
------=_NextPart_000_005C_01C0CFE8.7DBBDD00
Content-Type: application/x-pkcs7-signature;
name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="smime.p7s"
------=_NextPart_000_005C_01C0CFE8.7DBBDD00--
Enveloping
<DOCUMENT>
<PARAGRAPH>
BLAH BLAH BLAH
</PARAGRAPH>
</DOCUMENT>
<SIGNATURE>
<SIGNATURE_BLOCK ID=1>
SIGN HERE
</SIGNATURE_BLOCK ID=1>
<SIGNATURE_BLOCK ID=2>
SIGN HERE
</SIGNATURE_BLOCK ID=2>
<SIGNATURE_BLOCK ID=3>
SIGN HERE
</SIGNATURE_BLOCK ID=3>
</SIGNATURE>