Esecurity framework-camp-final

289 views

Published on

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
289
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
4
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide
  • 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'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 "credit card" 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'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 <Location> 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.
  • Esecurity framework-camp-final

    1. 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. 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. 3 Introduction to PKI • Authentication • Entity identification • Data origin identification • Integrity • Confidentiality Services
    4. 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. 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. 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. 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
    8. 8. 8 Introduction to PKI • Certification Authority (CA) • Registration Authority (RA) • Certificate Policy (CP) • Certification Practice Statement (CPS) • Policy Management Authority (PMA) Definitions
    9. 9. 9 Introduction to PKI Bob Info: Name Department Phone Number Certificate Info: Expiration Date Serial Number Bob's Public Key:
    10. 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. 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. 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. 13. 13Earth image from http://nssdc.gsfc.nasa.gov/image/planetary/earth/gal_australia.jpg Federation
    14. 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. 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. 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
    17. 17. 17 AHERFCA Architecture
    18. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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.
    31. 31. 31 Identification Process Metric NoIdentificationProcess Another’sIdentificationProcess Whichyou“trust”. Your Identification Process < 100 Points 100 Points > 100 Points Level 1 Level 2 Level 3 Level 4 Birth Certificate=70pt Passport=70pt Drivers License=40pt Known customer (>= 12 month) = 40pt Credit Card=25pt
    32. 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. 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. 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. 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. 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. 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. 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. 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. 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”.
    41. 41. 41 Realistic example of Certificate Path 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
    42. 42. 42 Realistic example of Certificate Path 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
    43. 43. 43 Certificate Path Construction: Bridge CA Cross-Certification From http://pkidev.internet2.edu/bridge/
    44. 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. 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
    46. 46. 46 AHERFCA Testing Environment
    47. 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. 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. 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. 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
    51. 51. 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
    52. 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. 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. 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. 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. 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
    57. 57. 57 OpenSSL Conf Files cont… [ req_extensions ] subjectAltName=@alt_section [ alt_section ] email.1=pki_admin@its.woolloomooloo.edu.au IP.2=10.0.0.1 DNS.3=myhost2.woolloomooloo.edu.au [ req_attributes ] challengePassword = A challenge password challengePassword_min = 4 challengePassword_max = 20
    58. 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. 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. 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]
    61. 61. 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]
    62. 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. 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. 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. 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. 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
    67. 67. 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
    68. 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. 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. 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. 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. 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. 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
    74. 74. 74 PKI for Grid Computing
    75. 75. 75 Thank You! pki@auscert.org.au

    ×