Part III-a
Contents Part III-a Public-Key Infrastructure (PKI) Definition of a PKI and PKI components PKI Trust Models Digital Certificate, X.509 Certificate Management and Life Cycle
Public Key Infrastructure (PKI) Definition [Adam, Lloyd] PKI is a common, pervasive security infrastructure with services offered that are based upon public-key concepts and asymmetric cryptography encompassing of components and services like: K K K K K K certification authority, certificate directory, key management (revocation, key backup and revocation, key update, key history), cross certification, support for non-repudiation, time stamping, client software A PKI is used to securely provision public-keys (within certificates) and other services.
PKI Components User Registration authority Certification authority Private key Check of identity... certificate certificate Key generation... Application Server Repository Public key Certificate revocation list Trust Center
PKI Components (1) A certification authority (CA) is a trusted entity that certifies public-keys and issues certificates. Certification means that the identity of the key owner and the corresponding public-key are tied together and authorized by the digital signature of the CA. The CA may receive the public key from the subscriber or may generate the public/private key pair itself. A registration authority (RA) is an entity that users contact during certificate subscription (enrolment). The RA authenticates the user or the data which the user submits, performs an authorization check and initiates the certificate generation at the CA. Further tasks of a RA include certificate revocation. When the subscriber is required to authenticate by direct physical presence, the RA is often called a local RA (LRA), when physically or organizationally separate from the CA.
PKI Components (2) A certificate repository is a database to which the CA stores all issued and revoked certificates (certificate revocation lists, CRLs), except perhaps those that belong to a closed user group. Usually, the certificate repository is publicly readable. Trust center (TC) is a term that is usually applied when not further distinguishing its components. Thus, a TC subsumes a CA and may include an RA or a repository if available. A monolithic TC consists of both the RA and the CA, whereas a split TC out-sources the RA to another organization.
PKI Trust models PKI fundamentally assumes and requires trust of all involved entities in the Certification Authority. There are 3 major trust models for a CA: K K K Hierarchical Distributed mesh-based with cross-certification Hybrid/Bridge
Hierarchical PKI Trust Model strict tree architecture with a single root CA (according to initial X.509 philosophy) Root CA suitable for hierarchical organizations CA CA CA CA CA CA CA CA End entity End entity End entity End entity End entity End entity End entity End entity
Certificate Chain Self-signed root Certificate for R s public key signed by R Root CA R Certificate for S s public key signed by R Root CA s public key is distributed by independent reliable means to relying party Intermediate CA S Certificate for T s public key signed by S Intermediate CA T Certificate for U s public key signed by T End User, Subscriber U
Virtual root CA in a WWW-browser Currently, there is no established worldwide spanning root CA WWW-browser is configured with certificates from several root CAs. virtual root CA in browser This is not equivalent to a true root CA. VeriSign GlobalSign The root certificates must be installed from an authorized source (masquerade attack!) TeleSec
Distributed mesh-based with cross-certification Cross Certificate for S s public key signed by R Root CA R Trusted relation-ship Root CA S Cross Certificate for R s public key signed by S Independent root CAs interconnect trust islands and establish a meshed network of trusted CA domains for increased interoperability. The trust-relationship can be unilateral or mutual. The trust relation-ships can get complex in fully meshed networks; O(n 2 ) security policies to maintain and evaluate.
Hybrid CA, Bridge CA Root Certificate of R CA R Bridge-CA Certificate of B Cert R Cert S Cert T Root Certificate of T Bridge CA B CA T Root Certificate of S CA S A novel approach to overcome the complexity problem and achieve interoperability among CAs. Only n bilateral security policy agreements are necessary. Member CAs can trust each other. The bridge-ca is not a hierarchical root CA.
Digital Certificate A certificate is used to (cryptographically) bind an identity to the corresponding public-key (identity-based digital certificate). A trustworthy certification authority issues certificates: 1. everyone can verify the CA as source of the certificate, 2. no one else can issue the same certificate without being detected, 3. any one can obtain the public-key from the certificate and 4. only the identified person can read or sign messages with his/her private key. Before issuing a certificate, the CA/LRA has to authorize the requesting entity.
Example of a Digital Certificate Subject Name: Mr. A. Mustermann Valid until: 23.4.2003 Certification Authority: VeriSign CA Serial Number: 1234567890 Public Key: 0D12A79FDE7E
Remark Certificates are means to gain trust in that the certificate owner is indeed who he claims to be. A certificate does not give any hint as to whether the certificate owner can be trusted in any sense or whether he is liable, credit worthy or possesses other similar attributes. The local registration authority (LRA) checks subscriber identity data only during certificate subscription but not at any time later on. It is the responsibility of an entity to decide whether to trust another entity upon a received certificate.
X.509 Version 3 Certificate Structure Signed by CA Version (v2/v3) Serial Number of certificate Signature Name of Alg OID certificate Issuer Validity (not before/ not after) Distinguished Name of Owner/ Subject Public Key Issuer of subject ID with Alg OID Subject ID Signature Alg OID V3 Extensions Signature of CA Mandatory X.509 non-critical or critical extension Depreciated field RFC 2459 mandatory Optional X.509v3 extensions non-critical extension or recommended flagged noncritical critical extension or recommended flagged critical Authority Key ID Subject Key ID Key Usage Extended key usage OIDs Certificate Policy Subject Alternative Name Subject Directory attribute Basic constraints Name constraints CRL Distribution Point Private key Usage Period Policy mapping Issuer Alternative Name Policy constraints Freshed CRL Inhibit any Policy
X.509 X.509v3 is the standard for digital certificates. X.509 offers many features for entity certificates, CA certificates, CRL certificates, cross certificates, and attribute certificates. There are many extension fields in the X.509 data structure with complex inter-relationship. this flexibility and freedom concerns interoperability. IETF PKIX profiles and interoperability specifications try to solve the problem.
Typical Classes of Certificates Class 0 certificates are only intended for testing purposes; they are usually free of charge and have a very short period of validity. Class 1 certificates provide confirmation just on proper email address without actually authenticating the subscriber s identity. They are intended only for client usage in non-commercial environments. Class 2 certificates provide some elementary authentication of the subscriber, based on some information in data-bases. The subscriber must not necessarily be physical present during an automated on-line process authentication. Such certificates may provide a reasonable, but not foolproof assurance of the subscriber s identity applicable e.g. in online subscriptions, password replacement. Class 3 certificates require physical presence of subscribers along with some additional authentication and authorization means. Applications are secure e- commerce, strong encryption, membership-based on-line services, LRA administrator authentication. Hardware storage for private-keys is recommended or necessary.
Certificate Revocation List (CRL) Digital certificates sooner or later become invalid (compromise of the private key, change of name,...) An issued certificate has to be revoked. A regularly updated revocation list holds all revoked certificates. The CA issues authorized revocation lists, they are signed with the CA private key. Using the X.509v3 extension, very powerful revocation methods can be built. Revocation lists have an inherent performance and security issue (size of CRLs, revocation vs. publishing time). On-line certificate status checking (OCSP, RFC 2560) may be an alternative.
CRL Techniques Authority CRL (ARL) are specific CRLs restricted just on revoked CA certificates. Partitioned CRLs with CRL distribution points to split huge CRLs into smaller pieces allowing far better scalability. Delta CRLs show the difference against an older version of the list help reduce size and allow for more frequent transmission. Indirect CRLs effectively combine multiple CRLs from several CAs within a domain into one CRL. Other non-standardized techniques.
X.509 CRL Version (v2) Signature Alg OID Name of CRL Issuer Signed by CA Timestamp (issued CRL) Time of next update Revoked certificates CRL Extensions Signature Alg OID Signature of CA non-critical extension or recommended flagged noncritical critical extension or recommended flagged critical Optional X.509v3 extensions non-critical or critical extension Mandatory X.509 Serial Revocation CRL entry number Serial Revocation date extensions CRL entry number Serial Revocation date extensions CRL entry number Serial Revocation date extensions CRL entry number date extensions CRL reason code CRL hold instruction code CRL certificate issuer CRL invalidity date Authority Key ID Issuer Alternative Name CRL number CRL Scope CRL status referral CRL stream CRL ordered CRL delta identifier list Info Issuing Distribution Point Delta CRL indicator CRL base update
Attribute Certificates Remember: X.509 ID-certificates are like passports, attribute certificate are like visas. An attribute certificate certifies certain permissions (attributes) to a subject. Using privilege management allows to realize flexible rolebased access control schemes. Attribute certificates are not widely in-use today.
X.509 Attribute Certificate Signed by AA Version (v2) Holder Issuer Signature Alg OID Serial number Validity (not before/ not after) Attributes Issuer Attributes ID Attributes Attribute Extension Signature Alg OID Signature of AA Mandatory X.509 Optional X.509v3 extensions non-critical extension or recommended flagged noncritical non-critical or critical extension critical extension or recommended flagged critical Time Targeting Specification information No Revocation information SOA identifier User notice Attribute descriptor Role specification certificate identifier Basic attribute constraints Delegated name constraints Acceptable certificate policies Acceptable priviledges policies Authority attribute identifier
PKI enabled Applications (1) Secure email (S/MIME, PEM, PGP), Secure web access (SSL/TLS), WTLS, E/TLS (ECC TLS), initially only with server certificates, PKI-enabled directories (LDAP, X.500), Virtual Private Networks (IPSEC/IKE), secure Extranets, SSL with client certificates, electronic payment (SET) and electronic commerce with secured business transactions; secure Electronic Data Interchange (EDI), secure transaction processing, PKI enabled legacy applications (SAP R3, ERP, CRM, SCM,..),
PKI enabled Applications (2) strong user authentication, single sign-on user authentication (for remote login, for PKI-based authentication for accounting, charging, billing e.g.), secure corporate Intranets, secure server access, secure remote access, secure mobile teleworking, IPSEC enabled device, (legally binding) document signing, contracting, Code-signing (J/JS/ActiveX), Mobile PKI-enabled applications (WAP), PKI-enabled IP-Telephony, intercarrier settlement, clearing house, PKI-enabled XML applications, Media & content distribution, Set-top box with PKI techniques, ASP-hosted applications with PKI, Voice-ASP,
Certificate Management Certificate publish End entity Out-of-band loading Certificate/ CRL repository Certificate publish RA Initial registration,/certification, key pair recovery, key pair update, certificate update, revocation request Certificate/ CRL publish CA Out-of-band publication Cross-certification cross-certificate update CA-2
Certificate Lifecycle (1) 1. (Registration): Initially, the subscriber has to apply for a certificate. The subscriber fills out a form (paper or web) with some identification data and other relevant information. For decentralized key generation, the browser generates a public/private key pair. The public-key is sent along with the registration form as a certificate request to the RA. As part of the registration the subscriber also agrees to and signs a contract with the trust center which often includes the AGBs, the certificate practice statement (CPS) and sometimes also the certificate policy. 2. (Authentication): The RA receives the certificate request. Using the data conveyed form, or other authentication technique, the RA checks the identity and the authorization of the subscriber. The RA may issue PINs for subsequent transaction verification or may check PINs for authentication. 3. (Key generation): In centralized key generation, the CA generates a private/public key pair upon indication form the RA.
Certificate Lifecycle (2) 4. (Certification): The CA creates a certificate with all provided information and other information due to its security policy and also the public-key. The CA digitally signs the certificate with its own private key. 5. (Certificate distribution): The CA sends the new certificate to the subscriber. If the CA has generated also private keys and possibly personalized smartcards, then these items are securely sent to the subscriber as well. The certificate is also published in a (global) repository; the certificate may be send to other application specific directories. 6. (Usage): Issued certificates are used by the subscribers or assigned entities. The certificates are applied to verify digital signatures, establish trust among the parties, certificates are being looked up in directories or repositories, or are being distributed among the parties.
Certificate Lifecycle (3) 7. (Revocation): At some point in time, there may be necessity to revoke the actual, legitimate certificate and prevent its further use; e.g. certificate is no longer to be used. This could be due to the assertion that the private key is considered no longer secure. Typically, the subscriber would revoke the certificate when there is evidence that the private-key has become public somehow or has lost its confidentiality or is somehow unavailable. The registration authority or an authorized entity of the RA may revoke a certificate as well, if the subscriber can no longer be considered trusted (employee left the company or data in certificate are no longer valid). Some trust centers even allow revocation upon request from a 3rd party (see CPS, AGBs). In case the root key has been compromised, the CA would revoke all issued certificates. For subscriber revocation, the subscriber requests revocation of his certificate at the RA through some authenticated certificate revocation request; this might be accomplished by the initial subscription PIN (when the certificate and private-key are no longer available) or with a signed revocation request issued or through phone call with pass phrase. The CA removes the particular certificate from the repository and adds it to a certificate revocation list (CRL). The CRLs are periodically distributed to the other subscribers. The subscriber may request another certificate anew.
Certificate Lifecycle (4) 8. (Expiration and Renewal): When the time passes beyond the validity date, the certificate expires. The CA may issue a renewed certificate according to step 4. The subscriber may also decide to update the certificate with a new certificate request submitted to the RA.