About Certificates

The purpose of this page is to give the reader a short introduction into certificates from the grid user’s point of view. It aims to explain the main principles in a simple manner without going too much into technical details.

Cryptography

About Certificates

About CA, RA and CRL

About Certificates and Grids

Further Reading

  • C.Kaufmann et al. Network Security: Private Communication in a Public World, Prentise Hall and references therein


Cryptography

1. What is cryptography?


Cryptography is the mathematical manipulation of data for the purpose of reversible or irreversible transformation. A piece of data, called cleartext or plaintext, is transformed into a piece of data called ciphertext. This process is called encyption, the reverse process decryption.

The transformation typically needs another piece of information, called secret or key, as input data in order to properly function

 


2. What is public key cryptography?


One speaks of public key cryptography (or asymmetric cryptography) if the two keys used during  encryption and decryption are different. The key used to transform the cleartext into cyphertext is called public key and the key used for the decryption is called the private key. Of course the two keys have to be related and a mathematical operation is used to generated them. The two keys are called key pair.

This mechanism can be used as follows: Imagine two persons: Alice and Bob. Alice generates  such a key pair and gives the public key to all her friends (including Bob). She keeps the private key for herself and doesn’t give it to anybody. Bob now uses Alice’s public key to transform a message from cleartext into ciphertext and gives the cipertext to Alice, who is the only person to read the message using the private key (as long as nobody else owns it).  In other words, Bob can communicate with Alice in a secret way. Of course the communication is no longer secret if someone obtains a copy Alice’s private key. In that case one says that the private key is compromised.


 

One can use the key pair also in another way: If Alice uses her private key to transform the message, then Bob (and everybody else owning the public key of Alice) can read it and know for sure that Alice has generated this message (as long as Alice is the sole owner of her private key). The process of transforming the cleartext into cyphertext using the private key is called signing and the corresponding cypertext is called signed message.




Of course this mechanism works only if Bob has Alice’s public key. However, the question arises how Bob can be sure that the public key of which he thinks is Alice’s public key is really Alice’s public key. Imagine what happens if say Trudy gives Bob her public key and
tells him that this is Alice’s key. So Bob starts to exchange secrets with Trudy thinking only Alice can read his secret messages.

 

About Certificates

3. What is a certificate?

The public key cryptography is based on the distribution of public keys as explained above. E.g. Alice owns her private key and the public keys of all her friends. However, she must be sure that the public key of Bob is really Bob’s public key (and not Trudy’s). This is where the certificate comes in.
A certificate is a message from a trusted authority that binds a public key to a name (i.e. the guarantee that  this public key is really Alice’s public key). This trusted authority is called Certificate Authority (CA) and the CA signs the certificate using its own private key. All recipients of a certificate must trust the issuing CA and own its public key in order to read its certificates.

In order to use the certificates in the real world, their data format have to be standardized. X.509 is the standard that is most widely used today. In the following sections we only talk about X.509 certificate.


4.  Which fields of a certificate are important for the user?

As described above,  a certificate simply binds a name to a public key. Thus the following fields are important:
  • The name, called Subject or distinguished name (DN)
  • The public key
  • When the certificate was issued (issuing date) and when it will expire  (expiration date). This time span is called validity.
  • The issuing Certificate Authority (CA)  (issuer)

The standard also sets the format of the Subject and Issuer to follow a certain naming standard, called X.500. X.500 names looks like this:
C=<country>, O=<organization>,OU=<organizational unit>,CN=<a name>,
whereas not all fields have to be present, e.g.
C=CH,O=Switch, CN=Alice
A description of X.500 is beyond the scope of this note.

In order to make certificates more useful, additional fields were added of which the following are most important for the average user:
  • SubjectAltName: An alternative name for the subject. Often a readable name is chosen as the Subject name follows the (from the user’s point of view) rather clumsy X.500 naming syntax. Often the SubjectAltName field contains the email address for persons or the DNS name for machines (who can also be identified by certificates, so called server certificates).
  • SerialNumber: The CA gives every certificate a unique serial number.
  • Version: There are several versions of the X.509 certificate standard. The most common used one is version 3 (which is identified by the number 2 in the version field). These certificates are labeled X.509v3.
  • Extensions: These are only present in X.509v3 certificates and contain additional information about the certificate. The most important fields are:
    • KeyUsage: A bit string, where every bit specifies something for which this certificate can be used (e.g. signatures, key encipherment, data encipherment, signing X.509 certificates etc.
    • cRLDistributionPoints: Describes how to find the CRL  associated with this certificate (see below).


5. What is revocation?

Imagine Alice’s private key gets compromised and Trudy owns a copy. In that case Alice would like to inform her friends to no longer use the corresponding public key the certificate that she gave them. In order to do that Alice contacts the Certificate Authority (CA) that issued her certificate and asks it to revoke her certificate.
Every CA publishes a list of certificates, which should now longer be used. This list is called certificate revocation list (CRL).


6. What certificate formats are there?

X.509 certificates can be decoded in several data formats. As a matter of fact there is another standard, called public key cryptography standard (PKCS), which describes more generally how signed or encrypted information is encoded. PKCS is actually a set of 15 standards, labeled PKCS#1 through PKCS#15.

The following ones are the most useful ones for the user of a certificate:
  • PKCS#12: Format commonly used to store private keys with accompanying certificate in a file. The file is protected use a password-based symmetric key. The user may receive the certificate in this format from the CA. If you view this file with a text editor, it is full of “funny” characters.
  • DER: Distinguished Encoding Rules: Certificate in encoded form and digitally signed by the CA. 
  • PEM or base64 format. This format can be viewed with a text editor and the data is enclosed with the statements  “-----BEGIN FOO BAR KEY-----“ and “-----END FOO BAR KEY-----“. 

7. How can I convert certificates between different formats?


About CA, RA and CRL

8. What is a CA?

A Certification Authority (CA) is the authority that binds the public key to a given name by issuing a certificate.  The CA thus asserts that the public key in the certificate belongs to the subject of the certificate.
If someone receives a certificate, then it must trust the CA that this binding is correct and has been properly done. The recipient of a certificate is called a relying party.

Often CAs are organized in tree-like hierarchies, where a root CA (top level) issues certificates to so-called subordinate CAs, which in turn sign can sign other CAs or issue certificates.


9. What is an RA?

The issuance of a certificate involves checking that the owner of the certificate to be issued is really the person who claims he is. E.g. if Alice presents a public key and wants to have it tied to the name Alice, then she has to prove that she is really Alice, e.g. by presenting a passport.
A CA can either perform this test (called identity validation) itself or it can have an agreement with a so called registration authority (RA) to do it.


10. How are certificates issues / how can a user obtain a certificate?

The issuance of a certificate involves typically the following steps:
  1. The user generates a key pair
  2. The user generates a certificate signing request (CSR) which contains the public key as well as other information about the user
  3. The user presents the CSR and additional information to an RA. This may involve presenting the identification papers, such as a passport, and a personal visit to an RA.
  4. The RA verifies the request and sends it to the CA.
  5. The CA issues the certificate to the user.

11. What is the CP/CPS?

Every CA operates according to its own rules, which it publishes in a document called CP/CPS (Certificate Policy / Certificate Practise Statement). There it is specified among other things how the Subject name was derived, how the identity of the owner of the certificate was checked, what the intended use of the certificate is as well as how the CA is being operated


10. What CAs exist in Switzerland?

SWITCH certificates are based on the following CAs:
  • SWITCHpki: The SWITCH PKI infrastructure for the Swiss Higher Education Sector. SWITCH and its partners operate as RAs and SwissSign is used as CA.
  • SWITCHgrid: A root CA, which issues only certificates to CAs.
  • SWITCHslcs: A CA which issues so called SLCS certificates, which have a validity of 1 mio seconds (approx. 11 days).

About Certificates and Grids

11. Why do grid infrastructures use certificates?

Good question! When people started to get involved in grids, an authentication method was needed. PKI at that time was the state of the art, so it was natural to take it. It offers stronger authentication than just username/password, which is important when resources are shared. In addition, an elegant way to handle delegation (see below) is offered by certificates.


12. How does authentication and authorization work in grid infrastructures?

Different grid architectures have different security solutions. We describe here the so-called Globus Security Infrastructure (GSI), on which most grid infrastructures are based (Globus, gLite etc).

In grids, the user is identified through his certificate. However, he does not present this certificate to the grid services as it is long lived (up to one year). Instead the user generates a key pair and issues himself a new, short-lived (typically less than one day) certificate, by signing it with the private key of his long-lived certificate. Thus the user acts as a CA. These self-signed certificates are called proxy certificates and they contain besides the certificate the entire chain of certificates of all CAs, that were involved in issuing the user’s certificate. Note this includes the user’s certificate as well (as the user acts as CA, when he generates the proxy).

The subject of the proxy certificate is the subject of the user’s certificate with the string “/cn=proxy” added. When the user accesses a grid service, he presents this proxy certificate. The grid service validates the proxy by evaluating the entire chain of CAs and checks that all issuing CAs are trustworthy.  Then most grid services simply take the subject name of the user’s certificate and authorize the user based on this string.

Note that this mechanism tightly couples authentication and authorization.

It should be mentioned that sometimes additional information is embedded in the user’s proxy, which can also be used to authorize the user. An example are the user’s attributes as they are maintained by the virtual organization (e.g. by using the VOMS service [virtual organization membership service]). The description of this mechanism is beyond the scope of this note, but the main principles as described above are still valid.


13. What is delegation and how does it work in grid infrastructures?

Delegation in this context means that a grid service acts on behalf of the user. We explain it using the example of a user’s job, which is forwarded by a resource broker to a remote note (called computing element [CE]).

The user submits the job to a resource broker and presents besides the job description also his proxy certificate. The resource broker now finds a node, which is able to execute the user’s job. However, for security reasons the job should run in the remote node associated with the user and not with the resource broker. Thus, the broker should act on behalf of the user. How is this achieved?

The resource broker generates a key pair and sends a CSR (see above) containing this public key to the user's host, where the job submitting service issues a certificate back to the resource broker. This certificate is signed by the private key of the user's proxy and contains the corresponding subject name (i.e. the user's subject name followed by the string "/CN=proxy/CN=proxy"). Again , this proxy-proxy certificate contains the certificates of all issuing CAs involved. The job broker then presents this "proxy-proxy" certificate to the CE, which validates the entire certificate chain and (normally) authorizes the user based on his subject name.

Note that
  • the private keys of the proxy certificates always stay on the host, where they were generated.
  • The private keys of the proxy certificates are not protected by a passphrase, such that the user does not have to enter manually passphrases.

What happens if a hacker gets access to a grid node and obtains copies of these proxy certificates. Then the hacker can impersonate the user on all grid nodes. In order to limit the associated security risk, the lifetime of every proxy should be kept very short (typically 12 or 24 hours).  Jobs, running more than the lifetime of a proxy certificate, must renew the proxy certificate in order to able to complete successfully. How this is done is beyond the scope of this note.