Public-Key Infrastructure


Asymmetric cryptosystems are flexible enough to provide data encryption and file signing. However, the weak point of public key cryptography is a problem of trust: a user employing someone's public key to encipher data or verify a digital signature must have a confidence that the key really belongs to his counteragent. One way of establishing the relations of trust is the deployment of a centralized system binding the public key to the entity holding the corresponding private key. The system consists of Certification Authorities - organizations acting as independent third parties and issuing public-key certificates. A certificate can be regarded as a data structure containing an entity's public key and additional information identifying the entity.

The first attempts to standardize procedures related to public-key certification were made in 1988. The primary version of ITU-T X.509 (formerly CCITT X.509) standard adopted as part of the X.500 Directory Recommendations defined the format of public-key certificates and formulated the main principles of the public-key certificate framework. In 1993 X.509 was updated to version 2. The current version of the standard supported by the International Telecommunication Union is 3. In addition, the Internet Engineering Task Force developed a profile aimed at easing the deployment of X.509 certificates in the Internet applications.

A public-key certificate is signed by a Certification Authority and has the following data elements:

  • version;
  • serial number;
  • signature - an identifier designating a cryptographic algorithm applied to sign the certificate;
  • an issuer - a Certification Authority that has issued the certificate;
  • validity - a time interval for which the certificate is considered valid; X.509 certificates have a limited lifetime;
  • a subject - an entity whose public key is certified;
  • the subject's public key information;
  • optional unique identifiers of the issuer and subject;
  • extensions - a sequence of X.509 certificate extensions; a set of extension fields may be defined by any organization or community; however, certificate parsers implemented in software may ignore unknown extensions; an extension can be flagged as critical; unrecognized critical extensions cause the certificate validation to fail.

A self-signed certificate can be generated with the help of one of available cryptographic utilities, e. g., keytool - the JDK key and certificate management instrument. The example below demonstrates keytool options used to create a new keystore. The store contains one entry aliased as rsa_entry. The entry keeps the RSA private key and the corresponding public key wrapped into a self-signed X.509 certificate. The -keyalg option defines the algorithm for the key pair generation. The signature algorithm applied to sign the certificate is SHA1withRSA. The -dname is a distinguished name based on the X.500 naming conventions. The validity of the certificate is 90 days. User will be prompted to enter a password for key protection and a password to block unauthorized access to the keystore:

keytool -genkeypair -alias rsa_entry -keyalg RSA -sigalg SHA1withRSA -dname CN=user -validity 90 -keystore rsakeys.jks

To get the contents of the store entries, the -list command is invoked. Verbose (-v) output will display information about the entry type (PrivateKeyEntry) and details of the self-signed certificate. The subject and the issuer of the certificate is the same entity. Besides, the command displays the serial number of the certificate, its version (3), its lifetime and MD5/SHA-1/SHA-256 fingerprints. The subject key identifier extension expands the generated certificate: it identifies the public key being certified. Any other extensions could be provided by using the -ext option during keys generation. The -rfc option can be fed to the keytool -list: in this case the output shows PEM-encoded certificate representation.

keytool -list -keystore rsakeys.jks -v
keytool -list -keystore rsakeys.jks -rfc

The self-signed certificate can be saved to a file:

keytool -exportcert -alias rsa_entry -file cert.der -keystore rsakeys.jks
keytool -printcert -file cert.der
openssl asn1parse -inform DER -in cert.der

Saving the certificate as a PEM-encoded structure requires -rfc option:

keytool -exportcert -alias rsa_entry -file cert.pem -keystore rsakeys.jks -rfc
keytool -printcert -file cert.pem
openssl asn1parse -in cert.pem

To analyze the exported certificate in PHP, openssl_x509_parse or openssl_x509_read functions can be used:

<?php
 $file=fopen("cert.pem", "r");
 $cert_data=fread($file, filesize("cert.pem"));
 fclose($file);
 $certificate=openssl_x509_parse($cert_data);
 $serial_number=$certificate["serialNumber"];
 echo dechex($serial_number);
?>

Working with the same certificate in Java will require the use of the CertificateFactory class:

FileInputStream certStream=new FileInputStream("cert.pem");
CertificateFactory factory=CertificateFactory.getInstance("X.509");
X509Certificate certificate=(X509Certificate) factory.generateCertificate(certStream);
. . .

Any of PEM-encoded certificates created above can be utilized to create a PKCS #12 data structure:

openssl pkcs12 -export -in cert.pem -nokeys -out cert.p12

PKCS #12 is one of the RSA cryptographic standards describing transfer syntax for personal identity information. Such information can include both private keys and certificates, but in the example above only certificate information was exported. To view the contents of the generated PKCS #12 structures, the -info option of openssl should be used:

openssl pkcs12 -in cert.p12 -info

A self-signed certificate may be adequate if the number of users employing the certificate is limited and there are established relations of trust among them. However, certificates issued and signed by an independent Certification Authority is a more reliable source of trust in security-sensitive scenarios. A person or organization can generate a key pair and then submit a Certificate Signing Request (CSR) to a CA. The CA verifies the identity of the applicant owning the private key and issues an X.509 certificate authenticating the requestor's public key. The CA is responsible not only for checking the identity of the applicant, but also for controlling the validity of the issued certificate. Expired certificates must be revoked. Similarly, if the subject or CA itself have compromised their private keys, the certificate must be revoked immediately. Revocation mechanism can be based on the notion of a Certificate Revocation List (CRL) or utilize any other reliable network protocol allowing relying parties to check the status of a certificate. One of such schemes is OCSP - Online Certificate Status Protocol widely implemented in cryptographic software.