PKI Basics

Due to the fact that “the bad guys” appeared quickly on the web and in networks, generally speaking, some things had to be done to make the web a safer place. One of this things is SSL – Secure Socket Layer.

What is SSL?

SSL is a security protocol, that works on a TCP/IP data stream. Used with HTTP at application level, the result is HTTPS – that is HTTP secure. SSL is used to secure the communication between to entities, such as a client and a server, by encrypting the data send between them. Usually, only the server needs to authenticate, so the client is sure to whom is is communicating. To get even more secure, both entities must authenticate. At this point A Public Key Infrastructure – or PKI – is required, unless the client uses TLS-PKS or Secure Remove Password protocols. So SSL ensures secure communication accross Internet.

SSL phases

Usually, when a client and a server communicate using SSL, some steps must be followed:

1. negotiate the encryption details – the “handshake” – such as the cipher or authentication codes
   
2. exchange keys and authentication – usually using public key algorithms
   
3. exchange data using the already agreed on encryption algorithm

So at phase two the server and the client must authenticate each other. If, for example, the client receives the server’s authentication details, how can it establish that the server really is who it claims it is? Well, this is done using PKI.

What is PKI ans how it works?

PKI is a hierarchical organization of the web. The purpose is to confirm that a given entity on the web is who it claims it is. The same model used on the Web can be applied at a proper scale on all kind of networks.

To approach the problem bottom up, consider that a client and a server begin communicate using SSL. At some point the server sends the client its authentication data – a digital certificate. How can the client can verify that the server is who is claims it is? Well, the client can question the certification authority wich released the server’s certificate. But how can the certification authority’s identity can be check? Simply, by advancing one step furter. How far can this go on? Until the client reaches a certification authority it trust.
At top level there are several major certification authorities. These server do not release individual certifications, but they release certificates for other certification authorities. To provide hierachical compatibily, some commom standards must be used. Currently, one of the must popular certificate format is X.509. The general format of an X.509 certificate is the following:

• Certificate
  • Version
  • Serial Number
  • Algorithm ID
  • Issuer
  • Validity
    • Not Before
    • Not After
  • Subject
  • Subject Public Key Info
    • Public Key Algorithm
    • Subject Public Key
  • Issuer Unique Identifier (Optional)
  • Subject Unique Identifier (Optional)
  • Extensions (Optional)
    • …
• Certificate Signature Algorithm
• Certificate Signature

Make your own PKI using X.509 certificates

It is possible to create small scale PKI using OpenSSL – this is an open source implementation for SSL and TLS (Transport Layer Security) protocols. This library is available for Unix-like operating systems, but also for Microsoft Windows. To create a PKI-like structure, first it must be established the trusted certification authority – by launching a request for a certificate. In the following example it is used a RSA encriptyion algorithm, with a 1024 bytes key. The result is a private key for the certification authority stored in CA_key.key and a certification request, stored in CA_certificate_request.

openssl req -new -newkey rsa:1024 -nodes
        -out CA_certificate_request.csr
        -keyout CA_key.key -batch

Because the certification authority is at the top of the hierachy, it’s certificate must be signed by itself. The following command signes a certificate using the request and the key generated at the previous step. The result is an X.509 certificate for the certification authority:

openssl x509 -trustout -signkey CA_key.key
        -days 365 -req
        -in CA_certificate_request.csr 
        -out CA.pem

Next, the certification authority can emit a certificate for the authorization server. The following command created a request for a certificate using the rsa algorithm. The authorization server can be described by an alias. It uses the AS_pass password. The certificate will be stored in a keystore – the authorization server’s certificate collection. To access the keystore, it is provided a password – AS_store_pass. The result will be a certificate request: AS_certificate_request.

keytool -certreq -keyalg rsa -alias AS_alias
        -keypass AS_pass -keystore AS_kyestore
        -storepass AS_store_pass
        -file AS_certificate_request

After lauching the certificate request, the certification authority must sign the server’s certificate. To create the certificate, we must provide the certification authority ow certificate – CA_certificate, its key – CA_key, its given serial number: CA_serial, the request for the authorization server’s cerficicate: AS_certificate_request. The result will be a an authorization certificate for the authorization server, available for 365 days.

openssl x509 -CA CA_certificate -CAkey CA_key
        -CAserial CA_serial -req
        -in AS_certificate_request -out AS_certificate
        -days 365

Finally, the authorization server’s certificate must be imported into its keystore.

keytool -import -alias AS_alias -keypass AS_pass
        -keystore AS_ks -storepass AS_store_pass
        -trustcacerts -file AS_certificate.

So we have a certification authority witch created an authorization certificate for an authorization server. The authorization server also has a keystore, which contains both the server’s certicate and the certification authority’s.

Advertisement