Public Key Infrastructure

We cannot properly understand and implement secure technologies without understanding the principles behind them.  So to continue I this vain we’ll take a deeper look into the principles of public and private keys, and how we use them in our security.

There are a number of different protocols in use today to generate key-pairs:

•    RSA – primarily used for authentication
•    DH – Whilst the algorithm is asymmetric, it generates symmetric keys, and we typically use this in conjunction with 3DES and AES.
•    ElGamal – used with DH
•    DSA – Digital Signature Algorithm
•    ECC – Elliptical Curve Cryptography

Public Keys in use

Both parties who want to communicate will have a public and private key pair.  They are both enrolled with a Certificate Authority (CA), which used the public keys of both and created their digital certificates.  To communicate, we now send our digital certificate to the other party.  The receiving party will verify that the certificate was issued by a trusted CA.  Now that both parties have each other’s public keys, they can communicate securely. 

Certificate Authorities

We briefly mentioned Certificate Authorities (CA) above, so let’s talk a bit more about the role they play for us.  They are an entity which has the ability to create and issue digital certificates.  These certificates include the Fully Qualified Domain Name (FQDN) of the device along with its IP address and public key, and also contain validity dates to ensure that the certificate has no expired.  Most web browsers come with a list of CAs which are trusted, thus relieving us of the problem of being able to verify the identity of these CAs
A root certificate is the certificate associated with the CA and contains the CAs public key.  An identity certificate is similar, but it describes a client and contains that client’s public key.

Digital certificates will contain either all or most of the following:
•    Serial number of the certificate
•    Subject
•    Signature algorithm
•    Signature
•    Issuer
•    Valid from
•    Valid to
•    Key usage
•    Public key
•    Thumbprint algorithm
•    Thumbprint
•    Certificate revocation list location

Public Key Standards

•    PKCS 1 – RSA
•    PKCS 3 – Diffie-Hellman
•    PKCS 7 – format of a response to a PKCS 10 request
•    PKCS 10 – format of a certificate request sent to a CA.
•    PKCS 12 – format for storing public and private keys using a symmetric password

Implementing PKI

Single Root CA

A typical solution for a small environment is to have one single CA server handling all requests; however there is no fault tolerance in this case.

Hierarchical CA with Subordinate CAs

Here we have a root CA which delegates the authority to subordinate CAs to create and assign identity certificates. 

Cross-certifying CAs

In this situation we have multiple CAs acting at the same level.  Clients of either CA will trust the signatures of the other CA.

Configuring certificates on an ASA:

ciscoasa(config)# crypto key generate rsa label TestPair modulus 2048 noconfirm
INFO: The name for the keys will be: TestPair
Keypair generation process begin. Please wait...

ciscoasa(config)# crypto ca trustpoint TestCA
ciscoasa(config-ca-trustpoint)# keypair TestPair
ciscoasa(config-ca-trustpoint)# id-usage ssl-ipsec
ciscoasa(config-ca-trustpoint)# no fqdn
ciscoasa(config-ca-trustpoint)# subject-name CN=ciscoasa
ciscoasa(config-ca-trustpoint)# enrollment url http://192.168.1.1
ciscoasa(config-ca-trustpoint)# exit
ciscoasa(config)# crypto ca authenticate TestCA nointeractive
ciscoasa(config)# crypto ca enroll TestCA noconfirm