1. 1
The Australian Higher Education
and
Research Sector
Federation Certification Authority
(AHERTF)
PKI implementation issues and case studies
Viviani Paz (AusCERT)
Rodney McDuff (UQ)
James Lever (UQ)
John Zornig (UQ)
pki@auscert.org.au
2. 2
Content
• Introduction to PKI
• AHERTF
– eSecurity Framework
Project
• Objectives
• HE and research
Federation
• Future Steps
• Trust Fabric & Trust
Model
• Identification Process
• Certificate Path
Construction
• Certificate Path Validation
• PKI Testing
Environment
• PKI for Grid Computing
• Monash PKI Case Study
3. 3
Introduction to PKI
• Authentication
• Entity identification
• Data origin identification
• Integrity
• Confidentiality
Services
4. 4
Introduction to PKI
• 1976 Diffie and Hellman
– encryption method that uses a two-part key
• A public key and a private key
– a public key is known to everyone and a private or secret key is
known only to the recipient of the message
Public-key cryptography
Plain
text Encrypt Decrypt
Recipient’s
Encryption
Private Key
Encrypted
text
Plain
text
Recipient’s
Encryption
Public Key
5. 5
Introduction to PKI
• Public Key Infrastructure
– enables users of an insecure public network to securely and
privately exchange data through the use of a public and a
private cryptographic key pair that is obtained and shared
through a trusted authority.
6. 6
Introduction to PKI
• Digital Signature
Digital Signature Verification
Send Message
Digital Signature Creation
Originator’s
Public Key
Original
Message
Digital
Signature
Plain
text
Create Signature Verify Signature
Originator’s
Private Key
Plain
text
Signature
7. 7
Introduction to PKI
• Digital or Public-Key Certificate
– X.509
Bob Info:
Name
Department
Phone Number
Certificate Info:
Expiration Date
Serial Number
Bob's Public Key:
Digital
Certificate
Trusted Authority
Sign Data
9. 9
Introduction to PKI
Bob Info:
Name
Department
Phone Number
Certificate Info:
Expiration Date
Serial Number
Bob's Public Key:
10. 10
eSecurity Framework for Research
• Funded by $649K
• Lead Institution
• Supported by
• http://www.esecurity.edu.au
Council of Australian University Directors of Information Technology
11. 11
eSecurity Framework for Research
Objectives
• Take PKI into Production
– Australian Higher Education and
Research Federation Certification Authority
• Reduce the Systems Cost barriers to entry
for PKI
– Dissemination of information
• Establish PKI/Shibboleth alignment
– Common Trust Federation for Australian HE sector
• Aiding the integration of Grid technologies with
PKI / Shibboleth in the Australian HE sector
12. 12
Collaboration and Interoperation
• Develop the Trust Fabric between Australian Higher
Education and Research Institutions
– Trust Fabric between Institutions and AusCERT will
help
• Develop common policies, practices and standards
• Evolve a PK Infrastructure as a vehicle to enable this
trust fabric
• Avoid retro-fitting other implementations
• Ensure interoperability with other national and
international PKIs and Federations
13. 13Earth image from http://nssdc.gsfc.nasa.gov/image/planetary/earth/gal_australia.jpg
Federation
14. 14
Federation Considerations
• PKI is based on trustworthiness asserted and
enforced by a Policy Authority and expressed
through the credentials issued by Certification
Authorities under a federation.
• Shibboleth is based on trusting participants to
abide by established community standards and
rules. Contracts are required.
• Grid Services accept certificates as valid
credentials if they are signed by trusted
authorities.
HE and Research Context
15. 15Earth image from http://nssdc.gsfc.nasa.gov/image/planetary/earth/gal_australia.jpg
Australian Higher Education and Research Trust Federation
• Federation Management Authority
Transparency
• Members and
ID processes
16. 16
Future Steps
• Further develop the Australian HE Trust Fabric
• Implement the Trust Model that supports the Trust Fabric
• Aid further integration with Shibboleth and Grid Technologies
• Seek Australian HE input
– Application survey results (http://www.esecurity.edu.au/esecurity-framework-
project-overview.data/application_survey_summary.pdf)
– Technical Working Group Mailing list (pkitag@auscert.org.au)
– Wiki
– Test and evaluate available technologies for certificate management systems
– Further develop Interoperability test
– Input into draft CP/CPS
– Revision of Certificate Profile
– Questions/Comments: pki@auscert.org.au
– www.esecurity.edu.au
• Keep PKI uptake costs low
– Share lessons learnt
• Training, disseminate information, guidelines, policies, procedures
18. 18
Trust Fabric & Trust Model
• Need to develop a Trust Fabric
– An exercise in sociology
• Need to develop a Trust Model
– An exercise in technology
Technology can not develop a Trust Fabric.
Technology is an instrument that can enable and
enhance a Trust Fabric.
19. 19
What is Trust?
• Trust between individuals is well known concept to
us.
– Social animals learn how to trust.
• But what about:
– Individuals trusting an external organization.
– Organizations trusting external individuals.
– Organizations trusting other organizations.
• These cases are not so clear to us.
20. 20
What is Trust?
From ITU-T Recommendation X.509/ISO/IEC 9594.
The directory: public-key and attribute certificate
frameworks:
Generally, an entity can be said to “trust” a second
entity when it (the first entity) makes the
assumption that the second entity will behave
exactly as the first entity expects. This trust may
apply only for some specific function. The key role
of trust in this framework is to describe the
relationship between an authenticating entity and a
authority; an entity shall be certain that it can trust
the authority to create only valid and reliable
certificates.
21. 21
What is Trust?
From the Online Ethics Center for Engineering and Science
<http://onlineethics.org>
Trust is confident reliance. We may have confidence in events, people, or
circumstances, or at least in our beliefs and predictions about them, but if we
do not in some way rely on them, our confidence alone does not amount to
trust.
Reliance is a source of risk, and risk differentiates trusting in something from
merely being confident about it. When one is in full control of an outcome or
otherwise immune from disappointment, trust is not necessary. It is, of
course, possible to rely on other people or on circumstances simply because one
lacks other options.
Basis for confidence in relying on some person may not be morally sound. Trust
may be naive or otherwise ill-founded. In that case it is likely to be
disappointed. Trust may also rest on a morally unsound foundation as when,
for example, one party feigns trustworthiness or behaves reliably only
because the other party dominates. Philosopher Annette Baier offers as a test
of the moral soundness of trust relationships that they thrive rather than
wither when the basis for confidence is revealed.
22. 22
What is Trust?
From F. Fukuyama, Trust: The Social Virtues and the Creation of
Prosperity
Trust is the expectation that arises within a community of regular, honest,
and cooperative behavior, based on commonly shared norms, on the part
of other members of that community.
From M. Sako, Prices, Quality, and Trust: Inter-firm Relations in Britain
and Japan
Trust is a state of mind, an expectation held by one trading partner about
another, that the other behaves or responds in a predictable and mutually
expected manner.
From E. Lorenz, Trust, Contract and Economic Cooperation
Trust can be defined as the judgment one makes on the basis of one's past
interactions with others that they will seek to act in ways that favor one's
interests, rather than harm them, in circumstances that remain to be
defined. Trusting judgments inevitably remain tentative, rather than
certain, since they are based on a limited knowledge of others rather than
a precise calculation of their interests."
23. 23
What is Trust?
From WikiPedia
<http://en.wikipedia.org/wiki/Trust_(sociology)>
Trust in sociology is a relationship between people, or
between people and social institutions such as a
corporation or government. It is the belief by one person
that another's motivations towards them are benevolent
and "honest“ ….
The work of Barbara Misztal attempts to combine all
notions of trust together. She points out that there are
three basic things that trust does in the lives of people.
– It makes social life predictable,
– It creates a sense of community
– It makes it easier for people to work together.
24. 24
• Predictable behaviour
– Expectations are understood and agreed
upon
– Institutions follow agreed set of rules
• Beneficial to all Australian HE community
– Institutions work together towards
a common goal
• Confident reliance
– Identification Process
What does Trust mean to us?
25. 25
• Identify Community
– Australian and New Zealand Higher Education and
Research Sector
– 53+ Institutions
• Community must consist of peers
– 1,000,000+ people
Trust Fabric Check List (1)
26. 26
Trust Fabric Check List (2)
• Develop/Identify commonality
– Has to be important to us
• If it is not important to us why bother?
– Has to inspire confident predictability
• The way it works for me is the same as it works for
you
• The way it works today is the same way it will work
tomorrow and after tomorrow
– Has to be transparent
• Has to be auditable
27. 27
• Engineering Issues
– Has to be simple
• Complex things break easily
• Complex things don’t get implemented
– Has to be inclusive
• Must cover full spectrum of possibilities within the
community
– Has to have minimal impact on an institution’s
business process
• Institutions don’t like being told what to do
– Has to be flexible to fit an institution’s particular
“uniqueness”
Trust Fabric Check List (3)
28. 28
• Simple
– Based on Australian Law and Breeder Documents
• Identification Record for a Signatory to an Account
– 100 Point Check
– http://www.austrac.gov.au/guidelines/forms/201.pdf
– Primary Documents
» Proof of identity
– Accrued Points
– IdM an integral part of any institution
• Minimal Impact
– Only measures the strength of an institution’s identification
process. Doesn’t change it
– An Institution can pick and choose what it wants to
implement
Trust Fabric Commonality based on
Strength of Identification Process
29. 29
• Authentication Process Agnostic
• Authorization Process Agnostic
• Independent of Technology
• Auxiliary Processes and Practices need to complete
the whole picture
– For PKI needs CP/CPS
– For Shibboleth needs Federation Participation Agreement
• InCommon (http://www.incommonfederation.org/)
• MAMS Federation (http://federation.org.au)
Trust Fabric Commonality based on
Strength of Identification Process
30. 30
Why concentrate on Identity?
AuthZ
Process.
Access
based on
user’s
attributes
AuthN
Process.
Proof of
Possession of
Credentials
Identification
Process.
Issuance of
Credentials.
Because that is where it all starts going wrong.
32. 32
Certificate
Level
Description
Level 1
No proactive identity check has been provided to the RA. However identity information has
been provided by a body that the RA has a trust relationship.
Example: A student being enrolled in at least one subject is sufficient for the certificate
issuing however identity information has only been supplied by QTAC (or similar state
body).
Level 2
Subject is required to provide proof of identity by an in-person appearance to the RA.
However the individual for what ever reason can not provide the required 100 points of
identification.
Example: A contractor, who is at an institution for a short time but needs access to a system
protected by PKI, may not have enough credentials on her person to meet the 100 points
check but can provide some credentials like a drivers licence and/or credit card.
Level 3
Subject is required to provide proof of identity by an in-person appearance to the RA. That
proof should accrue to at least 100 points of identity.
Example: A foreign staff member that has a valid passport and has a written reference from
an acceptable referee.
Level 4
Subject is required to provide the same information for Level 3 certification in addition to a
positive check to be conducted by an appropriate external agency.
Certification Levels
33. 33
• For our exercise in sociology we need:
– To construct a “sense of trust” between a relying party
and an end entity. IE a Trust Fabric.
• For our exercise in (PKI) technology we need:
– To construct a valid unbroken chain of CAs between a
relying party’s trust anchor and an end entity’s certificate.
• Certificate Path Processing
– Certificate Path Construction.
– Certificate Path Validation.
– A Trust Model.
• Topology of how CAs are order.
Trust Model
34. 34
Relying Party’s Trust Anchor?
• Trust Anchors are self-signed certificates.
– A Relying Party usually chooses its Trust Anchor.
– Typically it’s the Trust Anchor of their Organization.
– Or …
• Trust List.
– CAs trusted by a particular application vendor.
– CAs manually added to a Trust List. (But by who?)
• Sometimes it not obvious who is your Trust Anchor.
– Need to click on the Padlock.
35. 35
Trust Model:
Policy Management Authority
Harmonize polices and practices
across existing PKI inline with
common purpose.
• GRID Model
• CPP by publishing
cert bundle.
36. 36
Trust Model:
Mesh Cross-Certification
• Very flexible for
institutions policies
and procedure wise.
• 53x(53-1) = 2756
cross-certificates.
• CPP distressingly
difficult.
...
Mesh of Cross-Certified CAs at an Institution Level
RA RA
Institution 53
CA
RA RA
Institution 52
CA
RA RA
Institution 2
CA
RA RA
Institution 1
CA
(self-signed) (self-signed) (self-signed)
Commercial
CA
Chain
Each institution has is own CA and RAs and
acts as its own trust anchor. Cross-certification
agreements signed with other institutions.
37. 37
• As with Mesh Cross-
Certification.
• Only 53 cross-
certificates needed.
– Scales linearly.
• Each institution 2
hops away.
• CPP slightly easier.
• Model used to
connect US Uni’s
(HEBCA) and US
Gov. Agencies
(FBCA).
...
AusCERT as the Bridging CA
RA RA
Institution 53
CA
RA RA
Institution 52
CA
RA RA
Institution 2
CA
RA RA
Institution 1
CA
Commercial
CA
Chain
AusCERT
CA
Commercial
CA
Chain
(self-signed) (self-signed) (self-signed)
Each institution has is own CA and RAs and
acts as its own trust anchor. Cross-certification
agreements signed AusCERT.
Trust Model:
Bridge Cross-Certification
38. 38
• Only AusCERT CA
issues and revokes
certificate.
• Good for CPP.
• Less flexible for
institutions.
– Difficult to respond to
institution
customizations.
• Common policies and
practices across 53+
institutions.
• AusCERT needs huge
infrastructure if
CAUDIT PKI gets
large. (1 million +
clients.)
– Revocation problems.
– Much duplication
with help and service
desks.
...
RA RA
Institution 1
RA RA
Institution 53
RA RA
Institution 52
RA RA
Institution 2
AusCERT
CA
Commercial
CA
Chain
AusCERT CA as the only Trust Anchor
Each institution only has RAs which initiates
issuance and certificate management based on
common policies and practices over entire PKI.
Trust Model:
Single CA
39. 39
Australian Higher Education and
Research CA Federation Trust Model
AusCERT will provide:
PMA, Directory of Directories, Single
point Certificate Dissemination, Single
point CRL and OCSP, Virtual CAs.
40. 40
Certificate Path Construction
• Two CAs must have trust relationship to form link. Either
– One must be subordinate to other or
– Must be Cross-Certified. (Unilateral or Bilateral?)
– Relationships should be forged due to common policies or
procedures or interests. Otherwise there is a dilution of
trust.
• Must be able to locate and retrieve candidate CAs for chain
– Don’t need end entity’s certificate. Already have it.
– Some protocols can provide them. SSLv3/TLSv1,
S/MIME.
– Some certificate attributes can hint at where to find them.
• Authority Information Access Extension.
– Some X.500 or LDAP directories can contain them.
• Can’t construct path, can’t construct “sense of trust”.
44. 44
Certificate Path Validation
• Once path is constructed each link of chain must be checked.
– Is integrity of certificate sound? Issuer signature must be verified.
– Is the certificate being used within its validity period?
– Has certificate been revoked?
• Not trivial pursuit. Need external information. CRL. OCSP.
• Where do I find these? Some X.509 extensions hint at
locations.
– Has it been used for its intended purpose?
– Is the candidate path too long?
– Does one of the CA certificates prohibit the candidate path?
– Does one of the CA certificates prohibit the policy of another?
• Can’t validate path, can’t construct “sense of trust”.
• If path doesn’t validate sirens go off.
• If path does validate (suddenly) nothing happens.
– But who does my application think is the trust anchor and how did
it get there? Check the Padlock.
45. 45
The Good, The Bad and The Ugly
• X.509 and RFC3280 imprecise about Certificate Path Processing.
– Has lead to vendor inoperability problems.
– Common applications can’t do dynamic path construction.
• Netscape/Mozilla/Firefox.
– Others do it but with varying degrees of success.
• Microsoft Windows CryptoAPI (IE, Outlook)
• Authority Information Attritbute
– Can get third party CPP engines.
• Entrust Entelligence.
– CPP can be very intensive and untimely for relying party.
• Delegated Path Construction and Validation. (DPP and DPV.)
– Certificate Authority Module. (CAM)
• Freely available.
• Used by HEBCA and FBCA.
– Simple Certificate Validation Protocol (SVCP).
• Coming soon to a RFC near you.
– W3C XML Key Management Specification (XKMS).
• Total refactoring of PKI way from ASN.1
47. 47
eSecurity Framework Project
• eSecurity Framework Project follows on from the CAUDIT PKI and
has the goal to develop a production PKI
– Initial architecture was developed and a proof of concept CA was
designed and built.
– Fully hierarchical CA test environment, now version 0.2 test
environment
– Developed Draft CP/CPS
• www.esecurity.edu.au
• Requested Feedback from
– Technical Activities Group (pkitag)
– HEBCA, FBCA and others
– Issued CA Certificates
• Victoria University
• Monash University
• The University of Queensland
– Participant Universities Issued End User Certificates
48. 48
eSecurity Framework Project
• Preliminary Interoperability tests
– Email interoperability tests including
Mozilla/Thunderbird, Outlook and Mail.app
• Email encryption, signing, signing+encryption
• Certificate revocation validation
• CRL and OCSP validation
– Client Authentication testing between Apache httpd
(Web Server) and Mozilla/Firefox, Internet Explorer
• CRL and OCSP validation
49. 49
OpenCA Test Environment
• OpenCA used for the initial test environment
– 4 CAs on one test infrastructure
– 4 RAs on another test infrastructure
– RootCA on own host
– Both CA hosts are kept entirely off the network
• Difficulties encountered getting them to all work
together on the one host system – testing purposes
• Built a management system tool
– Documented
50. 50
OpenSSL is your friend
• OpenSSL, every PKI/crypto engineer’s Swiss
army knife.
• Basic OpenSSL commands worth knowing for
any PKI Practitioner – x509, req and the PKCS
formats and protocols
• Fundamental requirement to debugging problems
with your PKI Certificates
52. 52
PKCS* - What/when/where/why?
• Public-Key Cryptography Standards were
developed and published by RSA Laboratories.
• Of specific practical interest are:
– PKCS8 (pkcs8) – Key Store
– PKCS10 (req) – The Certificate Signing Request
– PKCS11 (engine) – Communication w/crypto devices
– PKCS12 (pkcs12)– key store and full certificate chain
53. 53
Certificate Signing Request
NAME
req - PKCS#10 certificate request and certificate generating utility.
SYNOPSIS
openssl req [-inform PEM|DER] [-outform PEM|DER] [-in filename]
[-passin arg] [-out filename] [-passout arg] [-text] [-pubkey] [-noout]
[-verify] [-modulus] [-new] [-rand file(s)] [-newkey rsa:bits] [-newkey
dsa:file] [-nodes] [-key filename] [-keyform PEM|DER] [-keyout file-
name] [-[md5|sha1|md2|mdc2]] [-config filename] [-subj arg] [-x509]
[-days n] [-set_serial n] [-asn1-kludge] [-newhdr] [-extensions sec-
tion] [-reqexts section] [-utf8] [-nameopt] [-batch] [-verbose]
[-engine id]
DESCRIPTION
The req command primarily creates and processes certificate requests in
PKCS#10 format. It can additionally create self signed certificates for
use as root CAs for example.
54. 54
CSR 2…
• OK, so that’s a manpage, but how do I do anything?
openssl req -new
• By default, this will expect you to then enter a number of attributes for
the CSR, namely:
% openssl req -new
Generating a 1024 bit RSA private key
...................++++++
..........++++++
writing new private key to 'privkey.pem'
Enter PEM pass phrase:
Verifying - Enter PEM pass phrase:
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
55. 55
CSR 3…
Country Name (2 letter code) [AU]:
State or Province Name (full name) [Some-State]:
Locality Name (eg, city) []:
Organization Name (eg, company) [Internet Widgits Pty Ltd]:
Organizational Unit Name (eg, section) []:
Common Name (eg, YOUR name) []:
Email Address []:
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
-----BEGIN CERTIFICATE REQUEST-----
MIIBhDCB7gIBADBFMQswCQYDVQQGEwJBVTETMBEGA1UECBMKU29tZS1TdGF0ZTEh
MB8GA1UEChMYSW50ZXJuZXQgV2lkZ2l0cyBQdHkgTHRkMIGfMA0GCSqGSIb3DQEB
AQUAA4GNADCBiQKBgQC5r4pU/y6f+WkLhZwPx2dtLYVYBNnsuiSma9Fj5B3L+VU4
ueaSCSdypiFDA9hrlctJKOlRT4HxigcI2gnbif2KicFDoX9SxXfcaAwSQ2zB74T2
g6Z5sH44XRsu+o+KADrNlIas0ugF8Ute6kU5iLzO+weeR5hXeEe7mTznPv23gQID
AQABoAAwDQYJKoZIhvcNAQEEBQADgYEAGVhKddSY2htMkgSliEFJmwHBUpPHWJnk
nRao9WYrkq0o05LhtT5KAUTYQ5VA+rjbtsNjWYM6tcyVcvHz/EfqHqaoWMFCErut
5FC2WNrH08T7NfCSMBk30kvXnVSJPoO5fY5ieXHJY4PkjgEBOnCgGgkfRd6YSH8D
/ndemFYQG8o=
-----END CERTIFICATE REQUEST-----
56. 56
OpenSSL Configuration Files
[ req ]
prompt = no
email_in_dn = no
req_extensions = req_extensions
attributes = req_attributes
encrypt_key = no
default_keyfile = myhost_wooloomooloo_edu_au.pem.key
input_password = test passphrase
output_password = test passphrase
default_bits = 2048
default_md = sha1
distinguished_name = req_DN
[ req_DN ]
countryName = AU
organizationName = The University of Wooloomooloo
organizationalUnitName = Information Technology Services
commonName = myhost.wooloomooloo.edu.au
#emailAddress = root@myhost.wooloomooloo.edu.au
58. 58
New Certificate Request
• Generating the Certificate Signing Request with the new
configuration file
% openssl req -new -config openssl_test_req.cnf -out
myhost_woolloomooloo_edu_au.pem.csr
Generating a 2048 bit RSA private key
.+++
.................+++
writing new private key to 'myhost_woolloomooloo_edu_au.pem.key’
59. 59
Self-Signed Certificate
• CA Extensions to use for the Self-Signed CA
[ v3_ca ]
basicConstraints = CA:true
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid:always,issuer:always
keyUsage = cRLSign, keyCertSign
subjectAltName=email:copy
issuerAltName=issuer:copy
• Actually Signing the Certificate with its private key
% openssl x509 -req
-in myhost_woolloomooloo_edu_au.pem.csr
-extfile openssl_test_v3_ca.cnf
-extensions v3_ca
-signkey myhost_woolloomooloo_edu_au.pem.key
-out myhost_woolloomooloo_edu_au.pem.crt
Signature ok
subject=/C=AU/O=The University of Wooloomooloo/OU=Information Technology
Services/CN=myhost.instutition.edu.au
Getting Private key
60. 60
Inside the Certificate
% openssl -x50 -text -noout -in myhost_wooloomooloo_edu_au.pem.crt
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
d0:64:a8:0b:96:bb:f1:34
Signature Algorithm: md5WithRSAEncryption
Issuer: C=AU, O=The University of Wooloomooloo, OU=Information
Technology Services, CN=myhost.wooloomooloo.edu.au
Validity
Not Before: Aug 22 00:51:55 2006 GMT
Not After : Sep 21 00:51:55 2006 GMT
Subject: C=AU, O=The University of Wooloomooloo, OU=Information
Technology Services, CN=myhost.wooloomooloo.edu.au
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (2048 bit)
Modulus (2048 bit):
[snip]
62. 62
OpenSSL s_server
% openssl s_server -cert myhost_woolloomooloo_edu_au.pem.crt -key
myhost_woolloomooloo_edu_au.pem.key -HTTP -ssl3 -port 12345 -CAfile
myhost_woolloomooloo_edu_au.pem.crt -Verify 2
verify depth is 2, must return a certificate
Using default temp DH parameters
ACCEPT
depth=0 /C=AU/O=The University of Wooloomooloo/OU=Information Technology
Services/CN=myhost.instutition.edu.au
verify return:1
FILE:foo
ACCEPT
63. 63
OpenSSL s_client
% openssl s_client -cert myhost_woolloomooloo_edu_au.pem.crt -key
myhost_woolloomooloo_edu_au.pem.key -ssl3 -connect localhost:12345
CONNECTED(00000003)
depth=0 /C=AU/O=The University of Wooloomooloo/OU=Information Technology
Services/CN=myhost.instutition.edu.au
verify error:num=18:self signed certificate
verify return:1
depth=0 /C=AU/O=The University of Wooloomooloo/OU=Information Technology
Services/CN=myhost.instutition.edu.au
verify error:num=26:unsupported certificate purpose
verify return:1
depth=0 /C=AU/O=The University of Wooloomooloo/OU=Information Technology
Services/CN=myhost.instutition.edu.au
verify return:1
---
Certificate chain
0 s:/C=AU/O=The University of Wooloomooloo/OU=Information Technology
Services/CN=myhost.instutition.edu.au
i:/C=AU/O=The University of Wooloomooloo/OU=Information Technology
Services/CN=myhost.instutition.edu.au
---
64. 64
OpenSSL s_client (2)
Server certificate
-----BEGIN CERTIFICATE-----
[SNIP]
-----END CERTIFICATE-----
subject=/C=AU/O=The University of Wooloomooloo/OU=Information Technology
Services/CN=myhost.instutition.edu.au
issuer=/C=AU/O=The University of Wooloomooloo/OU=Information Technology
Services/CN=myhost.instutition.edu.au
---
Acceptable client certificate CA names
/C=AU/O=The University of Wooloomooloo/OU=Information Technology
Services/CN=myhost.instutition.edu.au
---
SSL handshake has read 1917 bytes and written 1719 bytes
---
65. 65
OpenSSL s_client (3)
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
Server public key is 2048 bit
SSL-Session:
Protocol : SSLv3
Cipher : DHE-RSA-AES256-SHA
Session-ID:
9F90164E6549A8C5215A6FAF05D2C6F180D2D98EB7CDB7F7B7B068FB130F79B0
Session-ID-ctx:
Master-Key:
957101F3793629A588C60EE0D81336A6F214A890C4BEB4C9701207626002C6870EF142D3C
9FD28F6BF26B6BABF90D461
Key-Arg : None
Start Time: 1156209705
Timeout : 7200 (sec)
Verify return code: 26 (unsupported certificate purpose)
---
GET /foo HTTP/1.0
foo
bar
baz
read:errno=0
66. 66
OpenSSL s_client (4)
-----END CERTIFICATE-----
subject=/C=AU/O=The University of Wooloomooloo/OU=Information
Technology Services/CN=myhost.instutition.edu.au
issuer=/C=AU/O=The University of Wooloomooloo/OU=Information
Technology Services/CN=myhost.instutition.edu.au
---
No client certificate CA names sent
---
SSL handshake has read 1767 bytes and written 250 bytes
---
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
Server public key is 2048 bit
SSL-Session:
Protocol : SSLv3
Cipher : DHE-RSA-AES256-SHA
Session-ID:
6FA491AAF9D430D9E6799111449245918DD2184055605DC79ED2A58D93F8C651
Session-ID-ctx:
Master-Key:
A07730E9FF160ED511E9D32D01D112F07C808557CF9BBB0DA4B446E07E2FE3FE
F17E48A82D10767A58324BDE12EFB737
68. 68
OpenCA Internals
• OpenCA
– Wrapper around OpenSSL
– Perl script
– Meta configuration structure
• Useful when creating VO CAs
– Modules
• CA, RA, LDAP, Public User, SCEP (Cisco), OCSP
– HSM integration
% openssl engine
69. 69
OpenCA Internals
• OpenSSL Extension files and customising your
own certificate profile
${openca_root}/openca/etc/openssl/extfiles
• Certificate profile requirements and issues
importing remotely generated CSRs
Certificate Profiles
70. 70
CMS Capability Study
• Certificate Management Systems Capability Study
– Which products member institutions will use?
– What requirements the institutions have?
– Key elements that will determine decisions
• Requirements Matrix
– Active Directory Integration
– Bulk Certificate Generation
– Cross platform support (Linux, Windows, Apple)
• CMS Products on the RADAR
– OpenCA, AIAK, enTrust, Microsoft, Red Hat, RSA
71. 71
Client Interoperability Study
• Client Application Interoperability Study
• Email clients
– Which features are supported between clients?
– Will full CPP and Online Verification work?
• X509 Extensions Support
– AIA attribute handling
– CRL attribute support
– Which extensions should we actually have in our base
certificate profiles
72. 72
Future work being performed…
• Further work with Certificate Management
Systems and client applications
• Smart card and crypto tokens interoperability
• Hardware Security Modules (HSM) testing and
integration with various CMS
• Fine tune Certificate Profile
• More interoperability studies for different clients
and applications
73. 73
Challenges
• Large Project and small core team
• Requirements analysis takes time, and requires
many hands to perform the testing
• Only the end users and administrators know the
critical requirements within their institution
• Community input
– Community service
• Get involved!
– Feedback and requests to pki@auscert.org.au
– Discussion list at pkitag@auscert.org.au
Authentication is the assurance that the entity proves that she, he, or it is who it claims to be. Authentication finds application in two contexts: entity identification and data origin identification. Entity identification serves merely to identify the specific entity involved and is independent from whatever activity the entity wishes to perform. The process of entity identification usually produces a concrete result that can be used to enable other activities or communications. For example: the process of identifying an entity may unlock a symmetric key that can then be used to decrypt a file or to subsequently authenticate the entity to a remote environment. Data origin identification recognises a specific entity as the source of a given piece of data, regardless of any subsequent activities that the entity may engage.
Integrity is the assurance to an entity that data has not been undetectably modified, either intentionally or unintentionally, between here and there or between then and now. PKI provides the means to ensure data integrity in a transparent fashion.
Confidentiality is the assurance of data privacy. No one can read a piece of data except for the intended receiver entity (or entities).
In 1976 Diffie and Hellman developed a new concept known as public-key cryptography[1], also called Diffie-Hellman encryption or asymmetric encryption. Asymmetric encryption uses two keys instead of one key (symmetric encryption[2]).
In public-key cryptography two keys are used, public and private keys. These keys are different but also related in a way that only the corresponding private key can decrypt a message encrypted with the corresponding public key. Theoretically given enough computing power a private key may be derived from a public key. In practice not many organisations have enough resources to attempt this.
[1] W. Diffie and M. Hellman, “New Directions in Cryptography”, IEEE Transactions on Information Theory, Vol 22, No 6, November 1976, pp.644
[2] In Symmetric encryption the same key is used to encrypt and decrypt a piece of data. For example the sender and the receiver ‘share a secret’ in the form of a password which they have exchanged in advance. The message is encrypted with the sender&apos;s key and the recipient decrypts the message using the same key.
The CA vouchsafes for the binding of the entities’ identity and its key par.
Digital Signature is similar to a handwritten signature where one entity can sign some data, but many entities can read the signature and verify its accuracy. In the digital signature process a private-key operation is performed on data in which the resulting value is a signature. This signature can than be verified by using the corresponding public-key.
Digital certificate is similar to an electronic &quot;credit card&quot; that establishes your credentials when doing business or other transactions over unsecured networks.
It is issued by a certification authority (CA). It contains a users name, a serial number, expiration dates, a copy of the certificate holder&apos;s public key (used for encrypting messages and digital signatures), and the digital signature of the certificate-issuing authority so that a recipient can verify that the certificate is real. Some digital certificates conform to the X.509 standard.
X.509 standard defines a standard certificate format for public key certificates and certification validation.
CA: certifies the public key/identity by digitally signing a data structure that contains some representation of the identity and a corresponding public key. A CA is a critical component of many large-scale PKI and is responsible for issuing these public key certificates. A CA can take on a number of different representations depending on the trust model embodied by that CA. This will be discussed in detail later.
RA: support the CA in the end-entity registration requirements. A given RA may perform a number of tasks, such as establishing and confirming the identity of an individual seeking to obtain a public-key certificate, initiating a certification process with a CA on behalf of the end-user, performing certain key/certificate life-cycle management functions.
CP: is a collection of rules that indicate the applicability of a certificate to a particular community or class of application with common security requirements. CP is high-level document that describes requirements and limitations associated with the proposed use of the certificates issued under such a policy.
CPS: a statement of the practices which a certification authority employs in issuing certificates. is a detailed document that describes internal operating procedures of the CA. It often contains very sensitive information about the CA operation.
PMA’s primary responsibility is to manage the CP/CPS documents. The PMA provides points of contact for insiders – relying parties and subscribers in its PKI. The PMA also provides points of contact for external entities – other PKI PMA’s, potential new members or relying parties.
The eSecurity Framework is a follow on project of its predecessor CAUDIT PKI, that aimed at an interoperability and capability study of PKI for the higher education sector. Its main objective was to enable collaboration among universities, while keeping a closer look at infrastructures used elsewhere to maintain interoperability with other PKI initiatives around the world. This pilot developed initial draft policies and a prototype system.
The eSecurity Framework is funded by DEST, The University of Queensland is the lead institution with support from AusCERT, MAMS, CAUDIT, APAC (via VPAC) and Aarnet.
The main objectives of this project include:
Develop a PKI that could be taken into production for the HE and research sector.
Reduce the costs of PKI uptake by producing documentation that can be used by universities, sharing lessons learnt and supporting the community.
Establish a PKI and Shibboleth alignment drawing on the expertise developed by the MAMS project and developing a common trust federation for the sector.
Integrate the GRID community needs with PKI and Shibboleth by working closely with the GridShib project.
A focal point of this project is to further develop the collaboration and interoperation study that was set in motion last year with the CAUDIT PKI project.
We intend to further develop and strengthen the trust fabric between Higher Education sector, Research Institutions and AusCERT.
We are developing a PK Infrastructure which will be the medium to enable this trust fabric.
We are developing a capability study based on the HE needs that will serve as a base to further develop policies, practices and standards which will be made available to the community.
We are also drawing on developments from other successful PKI implementations at national and international levels to avoid retro-fitting and to ensure interoperability with other PKIs.
A Federation is formed by organisations or a community that have common goals and objectives. They agree on a set of rules and follow them.
Depending on the federation institution’s rules can be mapped against the federation rules.
In general there is a body that oversees its management and ensures compliance to these rules by the community.
Trust seems to be a common denominator between implementations such as PKI, Shib or Grid Services.
A vision of the future is that one would be able to put into operation an Australian Higher Education and Research Federation that would support and address the sector needs for cooperation and interoperation. While there are a number of independent initiatives trying to address the HE and Research requirements it would make sense to have one infrastructure encompassing all initiatives and avoid doubling up work. An alternative of what it would look like is shown in this diagram: the AHERCA, the Grid Computing Federation and the MAMS Federation.
In such federation there would be a body to oversee the policies management which would allow anyone in this federation to know who the members of the federation are and what process was used to identify these individuals.
The near future awaits us with a number of challenges to be faced, for this architecture to be refined and adjusted to the HE and Research sector needs we must further develop the trust fabric and implement the trust model.
This can only be done with the support and input from the sector. We have created a mailing list and a wiki to facilitate the dissemination and sharing of information and we would like expressions of interest from institutions that would like to participate in this project.
We are looking into ways to keep the costs minimal for institutions to participate in this federation and we’ll make available guidelines, policies and procedures to be used as a starting point by institutions.
John will now present the second part of this presentation on the tests we’ve been doing with Grid Computing.
There are a few concepts that we need to understand in order to enable the
What is a trust fabric? It is an exercise in understanding human behaviour and how they relate and what makes one individual trust another.
Trust model on the other hand can only enhance an existing Trust Fabric.
Technology cannot develop a trust fabric as it is based on human behavior, rules and relationships.
The next slides explain definitions of trust from diverse view points, they are here for completeness.
According to ITU (International Telecommunication Union)’s recommendation on public key and attribute certificate framework:
An entity trusts a second entity when it believes the second entity will behave exactly as expected by the first entity, and it may apply only for a specific function.
In the case of authentication a relationship between an entity and an authority are created, where the entity expects the authority to create valid and reliable certificates.
The next slides explain definitions of trust from diverse view points, they are here for completeness.
According to ITU (International Telecommunication Union)’s recommendation on public key and attribute certificate framework:
An entity trusts a second entity when it believes the second entity will behave exactly as expected by the first entity, and it may apply only for a specific function.
In the case of authentication a relationship between an entity and an authority are created, where the entity expects the authority to create valid and reliable certificates.
According to the Online Ethics center for engineering and science, trust is defined as confident reliance, one not only believes and expects a predictable behaviour, but also relies on them.
What does trust mean to the HE sector and research community for the purpose of this project?
Basically the community agrees on a set of rules that everyone is comfortable to follow. Everyone benefits from this trust and are willing to work towards a common goal.
We choose to rely on each other as a community and support each other, by choosing to trust the identification process used by the HE sector in general.
What do we need to ‘trust’?
Firstly we identify the community willing to develop the trust fabric. Which in our case is straight forward:
All Australian and New Zealand Higher Education and Research Sectors
About 53+ Institutions formed by peer institutions
About 1,000,000+ people spread within these institutions.
What else do we need?
We must identify and further develop commonality in this community. It has to be relevant to the community otherwise, why bother.
This needs to inspire confident predictability, the way it works for me is the same way it works for you, and the way it works today is the same way it will work tomorrow and after tomorrow and so on.
It has to be transparent and auditable.
We now must consider some engineering issues:
Has to be simple
Complex things break easily
Complex things don’t get implemented
Has to be inclusive
Must cover full spectrum of possibilities within the community
Has to have minimal impact on an institution’s business process
Institutions don’t like being told what to do
Has to be flexible to fit an institution’s particular “uniqueness”.
The trust fabric commonality proposed is based on the strength of the identification process.
It must be simple – it is based on Australian Law and Breeder Documents, such as the ‘Identification Record for a Signatory to an Account ‘ and must support Identity management, as it is part of any institution.
Should cause minimal impact on institutions as it
Only measures the strength of an institution’s identification process. Doesn’t change it
An Institution can pick and choose what it wants to implement
The Authentication Process and Authorization Process are agnostic.
The identification process is independent of Technology and requires support Processes and Practices to complete the whole picture:
For PKI needs CP/CPS
For Shibboleth needs Federation Participation Agreements
InCommon
MAMS Federation (http://federation.org.au)
Why are we focussing on identity? Because it is the base for trust, if you don’t know who you are trusting chances are you will not trust him/her. This is also where all starts going wrong.
We agree that we are trying to protect valuable information for the sector. To reach that information an authorization process is in place and access is granted based on users attributes, before the authorisation takes place a user must authenticate providing evidence of possession of credential.
But before one can authenticate one must proffer ones identity via an identification process, in which a credential is issued.
There are cracks on the identification process, authentication process and authorization process and that is why we must have a reliable way to determine the strength of ones Identity.
Obviously Institutions have their own processes to identify individuals’ identities.
What we would like to do is to be able to apply a metric to the identification process.
For example what are the types of identification that we could use:
No identification process
Use another’s identification process that you trust, for example QTAC
You do the identification process yourself
For this trust fabric no one will opt for the ‘no identification process’ for obvious reasons.
When doing your own identification process it makes sense to base it on the Australian Financial Transaction Record that is unquestionably accepted by anyone in Australia.
We than consider individuals that accrue less than 100 points, 100 points and more than 100 points.
This can easily be mapped into the certification levels as shown on this diagram.
This diagram is an example of how the identity check will be carried on for the different certification levels.
For level 1 there will be no proactive check in the presence of an RA.
For level 2 the subject must provide proof of identity by in-person appearance to an RA. Accrues less than 100 points
For level 3 the subject is required to provide proof of identity by an in-person appearance to the RA. That proof should accrue to at least 100 points of identity.
For level 4 the subject is required to provide the same information for Level 3 certification in addition to a positive check to be conducted by an appropriate external agency.
One of the fundamental issues with any successful PKI implementation centres on the identity of the end user, or entity and how well this identity has been checked and verified. As mentioned previously, one of the main virtues of X.509 certificates is the integrity of the binding of a name to a public key and the vouchsafing of this binding by a trusted third party, namely the CA. However, the identification of end entities is fraught with various problems; especially so in the education arena. Issues such as privacy arise and finding a balance between usability and privacy can be challenging. While it is usually the case that an institution has a good understanding of the identity of its staff (at least staff on its payroll), it may not be so assured about the identity of its students. Also there exists a class of people within a typical institution’s circle that are neither paid staff or fee-paying student but never the less require access to resources that involve PKI or protected by PKI.
This pilot has several levels of identity certification that correspond only to the strength of the identification process of the end entity[1] and not what they are or what they do within the institution. (Each level will also correspond to a different signing private key for the appropriate CA). Moreover we also propose to base the identification process on the Australian 100 points of identity system[2] and have a modified version of Form 201 (http://www.austrac.gov.au/guidelines/forms/201.pdf) which end users are required to fill out and sign in the presence of a RA. It is proposed that four levels of certification be considered for the production of the CAUDIT PKI.
[1] This is a well known technique to address this problem and several well known CA’s employ it.
[2] See Financial Transaction Reports Act 1988 and Financial Transaction Reports Regulations 1990.
AusCERT Root CA plans to cross-certify with national, international and global PKIs, such as HEBCA.
8 CAs on a single host - multiple completely separate installations of OpenCA and a bunch of &lt;Location&gt; directives to identify each of these Certificate Authorities. Given the significant overlap in these, there is a locally developed meta-build system that takes some configuration files which read templates - from these, the installation OpenCA templates are constructed and when OpenCA is configured locally, these templates build the local runtime configuration files for the OpenCA installation(s).
The highlighted commands are ones that I plan to specific mention later.
OCSP - Online Certificate Status Protocol RFC2560
The pkcs8 command processes private keys in PKCS#8 format. It can handle both unencrypted PKCS#8 PrivateKeyInfo format and EncryptedPrivateKeyInfo format with a variety of PKCS#5 (v1.5 and v2.0) and PKCS#12 algorithms.
PKCS#10 files are the certificate signing request - the initial request that is generated to begin the process of obtaining a Public-Key certificate. It contains a signed request with a list of desired attributes. The req command primarily creates and processes certificate requests in PKCS#10 format. It can additionally create self signed certificates for use as root CAs for example.
PKCS#11 is the protocol used to communicate with hardware cryptographic devices such as smartcards and other tokens. OpenSSL provides a mechanism to extend its support of different vendor products via the ‘openssl engine’ cryptographic engine plugin.
PKCS#12 files are typically used to securely transfer full certificate information (key, certificate and full certificate chain) in an encrypted manner. PFX, p12 and pkcs12 files are normally also used in browsers and email clients such as MSIE and MS Outlook, Mozilla/Thunderbird and Firefix and Apple Keychain.
Passphrase (to encrypt the private key) and a whole bunch of entries regarding the certificate identity you are requesting. Country Name, State/Province, Locality/City, Organisation Name, OrgUnit Name, YOUR NAME (or that of the end entity for this certificate) and an Email Address. It will also request a challenge password and an optional company name.
Reducing overhead to entry
Explain what feature we want to support in the clients and what is available.
What are the X509 Extensions available? How they are proven to work? MS CAPI versus other verfication and validation methods.
Authority Information Access
The AIA extension allows the certificate user to obtain a current copy of the CAs current certificate. CA certificates are required when a certificate chain is built. Chain building is performed as part of the certificate verification process.
When you configure AIA extensions, use the same attention to detail that you use when you configure CRL distribution point extensions. See the following example for more information about the AIA extension in a certificate.
