esecurity framework-camp-final
DESCRIPTION
TRANSCRIPT
Copyright © 2006 AusCERT 2006 Middleware Forum and CAMP 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)
Copyright © 2006 AusCERT 2006 Middleware Forum and CAMP 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
Copyright © 2006 AusCERT 2006 Middleware Forum and CAMP 3
Introduction to PKI
• Authentication• Entity identification
• Data origin identification
• Integrity
• Confidentiality
Services
Copyright © 2006 AusCERT 2006 Middleware Forum and CAMP 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 EncryptionPrivate Key
Encryptedtext
Plain text
Recipient’s EncryptionPublic Key
Copyright © 2006 AusCERT 2006 Middleware Forum and CAMP 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.
CA
IssuesCertificates
Copyright © 2006 AusCERT 2006 Middleware Forum and CAMP 6
Introduction to PKI
• Digital Signature
Digital Signature VerificationSend Message
Digital Signature Creation
Originator’s Public Key
Original
Message
DigitalSignature
Plain text
Create Signature Verify Signature
Originator’s Private Key
Plain text
Signature
Copyright © 2006 AusCERT 2006 Middleware Forum and CAMP 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
CA
Trusted Authority
Sign Data
Copyright © 2006 AusCERT 2006 Middleware Forum and CAMP 8
Introduction to PKI
• Certification Authority (CA)
• Registration Authority (RA)
• Certificate Policy (CP)
• Certification Practice Statement (CPS)
• Policy Management Authority (PMA)
Definitions
Copyright © 2006 AusCERT 2006 Middleware Forum and CAMP 9
Introduction to PKI
CARA
SendCertificate SigningRequest (CSR)User information
AcceptPolicy
Request Certificate
Send Certificate
IssueCertificate
ComplyCP / CPS
PublishInformation
aboutCertificates
PMA
Basic PKIBob Info: Name Department Phone Number Certificate Info: Expiration Date Serial Number Bob's Public Key:
Copyright © 2006 AusCERT 2006 Middleware Forum and CAMP 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
Copyright © 2006 AusCERT 2006 Middleware Forum and CAMP 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
Copyright © 2006 AusCERT 2006 Middleware Forum and CAMP 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
Copyright © 2006 AusCERT 2006 Middleware Forum and CAMP 13Earth image from http://nssdc.gsfc.nasa.gov/image/planetary/earth/gal_australia.jpg
Ma
p R
ule
sM
ap
Ru
les
Institution1
Institution2
Institution3
Institution4
Institutionn
Set of rulesCommunity agrees to abide by rules
Community with common goals
Oversee and Ensure Compliance
Federation
Copyright © 2006 AusCERT 2006 Middleware Forum and CAMP 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
Copyright © 2006 AusCERT 2006 Middleware Forum and CAMP 15Earth image from http://nssdc.gsfc.nasa.gov/image/planetary/earth/gal_australia.jpg
Australian Higher Education and Research Trust Federation
• Federation Management Authority
1….n 1….n
AusCERTCA Level 1
AusCERTCA Level 2
AusCERTCA Level 3
AusCERTCA Level 4
GRID CALevel 3
VO CALevel 4
VO CALevel 3
VO CALevel 2
VO CALevel 1
InstitutionsCA Level 4
InstitutionsCA Level 3
InstitutionsCA Level 2
InstitutionsCA Level 1
VO ShibCA Level 3
VO MyProxyCA Level 3
RA RA RARARA
AusCERTRoot CA
Policy ManagementAuthority (PMA)
OldCA
RA RA
Australian Higher Education and Research Federation CA
Transparency
• Members and
ID processes
Grid Computing Federation
Diag
ram fro
m Jo
hn
O’C
allagh
an’s P
resentatio
nB
ased o
n S
id K
arin, S
DS
C/N
PA
ServiceIdentity
ProviderProvider
MAMS
Copyright © 2006 AusCERT 2006 Middleware Forum and CAMP 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 ([email protected])– 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: [email protected]– www.esecurity.edu.au
• Keep PKI uptake costs low– Share lessons learnt
• Training, disseminate information, guidelines, policies, procedures
Copyright © 2006 AusCERT 2006 Middleware Forum and CAMP 17
AHERFCA Architecture
Copyright © 2006 AusCERT 2006 Middleware Forum and CAMP 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.
Copyright © 2006 AusCERT 2006 Middleware Forum and CAMP 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.
Copyright © 2006 AusCERT 2006 Middleware Forum and CAMP 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.
Copyright © 2006 AusCERT 2006 Middleware Forum and CAMP 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.
Copyright © 2006 AusCERT 2006 Middleware Forum and CAMP 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 CooperationTrust 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."
Copyright © 2006 AusCERT 2006 Middleware Forum and CAMP 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.
Copyright © 2006 AusCERT 2006 Middleware Forum and CAMP 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?
Copyright © 2006 AusCERT 2006 Middleware Forum and CAMP 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)
Copyright © 2006 AusCERT 2006 Middleware Forum and CAMP 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
Copyright © 2006 AusCERT 2006 Middleware Forum and CAMP 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)
Copyright © 2006 AusCERT 2006 Middleware Forum and CAMP 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
Copyright © 2006 AusCERT 2006 Middleware Forum and CAMP 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
Copyright © 2006 AusCERT 2006 Middleware Forum and CAMP 30
Why concentrate on Identity?
AuthZProcess.Access
based on user’s
attributes
AuthNProcess.Proof of
Possession ofCredentials
IdentificationProcess.
Issuance ofCredentials.
Because that is where it all starts going wrong.
Copyright © 2006 AusCERT 2006 Middleware Forum and CAMP 31
Identification Process Metric
No Identification P
rocess
Another’s Identification P
rocessW
hich you “trust”.
Your Identification Process
< 100 Points 100 Points > 100 Points
Level 1 Level 2 Level 3 Level 4
Birth Certificate=70ptPassport=70ptDrivers License=40ptKnown customer (>= 12 month) = 40ptCredit Card=25pt
Copyright © 2006 AusCERT 2006 Middleware Forum and CAMP 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 4Subject 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
Copyright © 2006 AusCERT 2006 Middleware Forum and CAMP 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
Copyright © 2006 AusCERT 2006 Middleware Forum and CAMP 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.
Copyright © 2006 AusCERT 2006 Middleware Forum and CAMP 35
Trust Model:Policy Management Authority
Harmonize polices and practices across existing PKI inline with common purpose.
• GRID Model• CPP by publishing
cert bundle.
Copyright © 2006 AusCERT 2006 Middleware Forum and CAMP 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)
CommercialCA
Chain
Each institution has is own CA and RAs and acts as its own trust anchor. Cross-certificationagreements signed with other institutions.
Copyright © 2006 AusCERT 2006 Middleware Forum and CAMP 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
CommercialCA
Chain
AusCERTCA
CommercialCA
Chain
(self-signed) (self-signed) (self-signed)
Each institution has is own CA and RAs and acts as its own trust anchor. Cross-certificationagreements signed AusCERT.
Trust Model:Bridge Cross-Certification
Copyright © 2006 AusCERT 2006 Middleware Forum and CAMP 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
AusCERTCA
CommercialCA
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
Copyright © 2006 AusCERT 2006 Middleware Forum and CAMP 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.
Copyright © 2006 AusCERT 2006 Middleware Forum and CAMP 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”.
Copyright © 2006 AusCERT 2006 Middleware Forum and CAMP 41
Realistic example of CertificatePath Construction
Issuer: CA1
Subject: EE1
Issuer: CA2
Subject: CA1
Issuer: CA2
Subject: CA2
Issuer: CA2
Subject: CA3
Issuer: CA3
Subject: EE2
Issuer: CA4
Subject: CA4
Issuer: CA2
Subject: CA4
Issuer: CA4
Subject: CA2
Issuer: CA4
Subject: EE4
Issuer: CA4
Subject: CA5
Issuer: CA5
Subject: EE3
Issuer: CA3
Subject: CA5
Issuer: CA5
Subject: CA3
Issuer: CA7 (Trust Lst)
Subject: CA6
Issuer: CA6
Subject: EE5
Issuer: CA7 (Trust Lst)
Subject: CA7 (Trust Lst)
Issuer: CA4
Subject: CA6
Issuer: CA6
Subject: CA4
Certificate Path Construction:Mesh CA Cross-Certification
Copyright © 2006 AusCERT 2006 Middleware Forum and CAMP 42
Realistic example of CertificatePath Construction
Issuer: CA1
Subject: EE1
Issuer: CA2
Subject: CA1
Issuer: CA2
Subject: CA2
Issuer: CA2
Subject: CA3
Issuer: CA3
Subject: EE2
Issuer: CA4
Subject: CA4
Issuer: CA2
Subject: CA4
Issuer: CA4
Subject: CA2
Issuer: CA4
Subject: EE4
Issuer: CA4
Subject: CA5
Issuer: CA5
Subject: EE3
Issuer: CA3
Subject: CA5
Issuer: CA5
Subject: CA3
Issuer: CA7 (Trust Lst)
Subject: CA6
Issuer: CA6
Subject: EE5
Issuer: CA7 (Trust Lst)
Subject: CA7 (Trust Lst)
Issuer: CA4
Subject: CA6
Issuer: CA6
Subject: CA4
Mesh CA Cross-Certification
Copyright © 2006 AusCERT 2006 Middleware Forum and CAMP 43
Certificate Path Construction:Bridge CA Cross-Certification
From http://pkidev.internet2.edu/bridge/
Copyright © 2006 AusCERT 2006 Middleware Forum and CAMP 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.
Copyright © 2006 AusCERT 2006 Middleware Forum and CAMP 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
Copyright © 2006 AusCERT 2006 Middleware Forum and CAMP 46
AHERFCATesting Environment
Copyright © 2006 AusCERT 2006 Middleware Forum and CAMP 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
Copyright © 2006 AusCERT 2006 Middleware Forum and CAMP 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
Copyright © 2006 AusCERT 2006 Middleware Forum and CAMP 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
Copyright © 2006 AusCERT 2006 Middleware Forum and CAMP 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
Copyright © 2006 AusCERT 2006 Middleware Forum and CAMP 51
OpenSSL Commands
Standard commands
asn1parse ca ciphers crl crl2pkcs7
dgst dh dhparam dsa dsaparam
enc engine errstr gendh gendsa
genrsa nseq ocsp passwd pkcs12
pkcs7 pkcs8 prime rand req
rsa rsautil s_client s_server s_time
sess_id smime speed spkac verify
version x509
Copyright © 2006 AusCERT 2006 Middleware Forum and CAMP 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
Copyright © 2006 AusCERT 2006 Middleware Forum and CAMP 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.
Copyright © 2006 AusCERT 2006 Middleware Forum and CAMP 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 -newGenerating 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 incorporatedinto 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 blankFor some fields there will be a default value,If you enter '.', the field will be left blank.-----
Copyright © 2006 AusCERT 2006 Middleware Forum and CAMP 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' attributesto be sent with your certificate requestA challenge password []:An optional company name []:-----BEGIN CERTIFICATE REQUEST-----MIIBhDCB7gIBADBFMQswCQYDVQQGEwJBVTETMBEGA1UECBMKU29tZS1TdGF0ZTEhMB8GA1UEChMYSW50ZXJuZXQgV2lkZ2l0cyBQdHkgTHRkMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC5r4pU/y6f+WkLhZwPx2dtLYVYBNnsuiSma9Fj5B3L+VU4ueaSCSdypiFDA9hrlctJKOlRT4HxigcI2gnbif2KicFDoX9SxXfcaAwSQ2zB74T2g6Z5sH44XRsu+o+KADrNlIas0ugF8Ute6kU5iLzO+weeR5hXeEe7mTznPv23gQIDAQABoAAwDQYJKoZIhvcNAQEEBQADgYEAGVhKddSY2htMkgSliEFJmwHBUpPHWJnknRao9WYrkq0o05LhtT5KAUTYQ5VA+rjbtsNjWYM6tcyVcvHz/EfqHqaoWMFCErut5FC2WNrH08T7NfCSMBk30kvXnVSJPoO5fY5ieXHJY4PkjgEBOnCgGgkfRd6YSH8D/ndemFYQG8o=-----END CERTIFICATE REQUEST-----
Copyright © 2006 AusCERT 2006 Middleware Forum and CAMP 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 = [email protected]
Copyright © 2006 AusCERT 2006 Middleware Forum and CAMP 57
OpenSSL Conf Files cont…
[ req_extensions ]
subjectAltName=@alt_section
[ alt_section ]
IP.2=10.0.0.1
DNS.3=myhost2.woolloomooloo.edu.au
[ req_attributes ]
challengePassword = A challenge password
challengePassword_min = 4
challengePassword_max = 20
Copyright © 2006 AusCERT 2006 Middleware Forum and CAMP 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’
Copyright © 2006 AusCERT 2006 Middleware Forum and CAMP 59
Self-Signed Certificate
• CA Extensions to use for the Self-Signed CA [ v3_ca ] basicConstraints = CA:truesubjectKeyIdentifier=hashauthorityKeyIdentifier=keyid:always,issuer:alwayskeyUsage = cRLSign, keyCertSignsubjectAltName=email:copyissuerAltName=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.crtSignature oksubject=/C=AU/O=The University of Wooloomooloo/OU=Information Technology
Services/CN=myhost.instutition.edu.auGetting Private key
Copyright © 2006 AusCERT 2006 Middleware Forum and CAMP 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]
Copyright © 2006 AusCERT 2006 Middleware Forum and CAMP 61
Certificate (2) Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Basic Constraints: CA:TRUE X509v3 Subject Key Identifier: A8:DB:74:0A:CA:BC:62:C8:AA:B4:1A:ED:28:D8:58:EC:19:88:B1:1E X509v3 Authority Key Identifier:
keyid:A8:DB:74:0A:CA:BC:62:C8:AA:B4:1A:ED:28:D8:58:EC:19:88:B1:1E DirName:/C=AU/O=The University of
Wooloomooloo/OU=Information Technology Services/CN=myhost.instutition.edu.au
serial:D0:64:A8:0B:96:BB:F1:34
X509v3 Key Usage: Certificate Sign, CRL Sign X509v3 Subject Alternative Name: <EMPTY> X509v3 Issuer Alternative Name: <EMPTY>Signature Algorithm: md5WithRSAEncryption[snip]
Copyright © 2006 AusCERT 2006 Middleware Forum and CAMP 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
Copyright © 2006 AusCERT 2006 Middleware Forum and CAMP 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
---
Copyright © 2006 AusCERT 2006 Middleware Forum and CAMP 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.auissuer=/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---
Copyright © 2006 AusCERT 2006 Middleware Forum and CAMP 65
OpenSSL s_client (3)
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHAServer public key is 2048 bitSSL-Session: Protocol : SSLv3 Cipher : DHE-RSA-AES256-SHA Session-ID:
9F90164E6549A8C5215A6FAF05D2C6F180D2D98EB7CDB7F7B7B068FB130F79B0 Session-ID-ctx:
Master-Key: 957101F3793629A588C60EE0D81336A6F214A890C4BEB4C9701207626002C6870EF142D3C9FD28F6BF26B6BABF90D461
Key-Arg : None Start Time: 1156209705 Timeout : 7200 (sec) Verify return code: 26 (unsupported certificate purpose)---GET /foo HTTP/1.0foobarbazread:errno=0
Copyright © 2006 AusCERT 2006 Middleware Forum and CAMP 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: A07730E9FF160ED511E9D32D01D112F07C808557CF9BBB0DA4B446E07E2FE3FEF17E48A82D10767A58324BDE12EFB737
Copyright © 2006 AusCERT 2006 Middleware Forum and CAMP 67
OpenSSL s_client (5)
Key-Arg : None
Start Time: 1156208569
Timeout : 7200 (sec)
Verify return code: 26 (unsupported certificate purpose)
---GET /foo HTTP/1.0
foo
bar
baz
read:errno=0
Copyright © 2006 AusCERT 2006 Middleware Forum and CAMP 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
Copyright © 2006 AusCERT 2006 Middleware Forum and CAMP 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
Copyright © 2006 AusCERT 2006 Middleware Forum and CAMP 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
Copyright © 2006 AusCERT 2006 Middleware Forum and CAMP 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
Copyright © 2006 AusCERT 2006 Middleware Forum and CAMP 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
Copyright © 2006 AusCERT 2006 Middleware Forum and CAMP 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 [email protected]– Discussion list at [email protected]
Copyright © 2006 AusCERT 2006 Middleware Forum and CAMP 74
PKI for Grid Computing