CS469/569 - Linux and Unix Administration and Networking Spring 2022

Certificates:

The purpose of certificates is to establish a trust relationship with a second party via the use of public/private key signing with identity verification through certificate authorities. The key point is to verify that the person or organization on the remote end (such as your bank) is who they claim to be, then finally establishing a secure encrypted communications channel with them. It is important to note that is not merely to establish secure comms, as there are other protocols that can do that, but is intended to verify identity, i.e. it makes no difference if we can security communicate with a hacker, we want to securely communicate with our bank.

Terms:

Certificate Authority (CA)

• A issuer of certificates that verify the identity of the certificate owner. If we trust the CA, then we may be inclined to trust the certificate owner.

Certificate Signing Request (CSR)

• The protocol for signing a certificate by a CA or intermediate CA. Usually provides the public key of the of the certificate subject (the future owner of the signed certificate,) and identifying information, such as the subjects domain.

X.509

• An ITU-T standard for certificates, specifying among other things, standard formats and contents of certificate files, revocation lists, and a certificate path validation algorithm.

SSL (Secure Sockets Layer)

• Predecessor to TLS, now deprecated.

TLS (Transport Layer Security (supersedes SSL))

• Successor to SSL, defines the protocol for establish a trust relationship via certificates and then establishes an encrypted communications channel.

.pem (Privacy Enhanced Mail?)

• A common format for storing certificates and keys in a ASCII text manner.

.pfx (PKCS #12) Public-Key Cryto Standards

• Alternate format for certs and keys, often used by windows.

Certificate Revocation list (CRL):

• A list of certificate serial numbers for certificates that should no longer be trusted.
• Usually published by the CA and often having a short life-span (a day or less). Signed by the CA to prevent spoofing.
• Requires being on-line to check the CRL

Public key

• One half of a public/private key pair that is used to establish secure communications. Messages to be sent to the owner of the key-pair are encrypted with the public key which can only be decrypted with the private key. The public key can de-crypt messages encrypted with the private key.

Private key

• The other half of a public/private key pair. It should never be shared with anyone. Message sent by the owner of a certificate are encrypted with the private key. Messages encrypted with one key, can only be decrypted with the other.

Format of a certificate:

The following information should be present in a certificate as defined by the X.509 protocol.

Certificate creation, signing and management:

• Reading: man 1 openssl

> openssl command [options]

• OpenSSL command line tool

Example:

> openssl x509 -text -in *certificate-file*

• Display information from a certificate file, use the x509 command set.

Common command sets:

Command	What it is for
x509	X.509 Certificate Data Management.
ca	Certificate Authority (CA) Management.
req	PKCS#10 X.509 Certificate Signing Request (CSR) Management.
s_client	Implements a generic SSL/TLS client which can establish a transparent connection to a remote server speaking SSL/TLS.
s_server	Implements a generic SSL/TLS server which accepts connections from remote clients speaking SSL/TLS. It's intended for testing and provides both an own command line oriented protocol for testing SSL functions and a simple HTTP response facility to emulate an SSL/TLS-aware webserver.

Creating a Certificate Authority:

To create a Certificate Authority for purposes of certificate signing we make a directory for all the files and configurations for our CS, then setup a openssl.cnf configuration file:

mkdir CA
cd CA
cp /etc/ssl/openssl.cnf .

Then we make the changes necessary to the configuration, defining our CA:

Changes to openssl.cnf:

[ CA_default ]
dir             = /path/to/CA           # Where everything is kept (change /path/to)
certificate     = $dir/<CAname>.crt     # The CA certificate
private_key     = $dir/<CAname>.key     # The private key
default_days    = 999                   # how long to certify for
default_md      = sha1                  # which md to use.

[ req ]
default_bits            = 2048      # Required number of bits in the keys

[ req_distinguished_name ]
countryName_default             = <country>
stateOrProvinceName_default     = <state>
localityName_default            = <city>
0.organizationName_default      = <company name>
organizationalUnitName_default  = <Unit in company name>
commonName_default              = <domain>
subjectAltName                  = Alt names
subjectAltName_default      = DNS:<domain>.com,DNS:mail.<domain>.com,DNS:mail.<otherdomain>.com,...
emailAddress_default            = <email address>

[ v3_req ]
# Extensions to add to a certificate request
subjectAltName = DNS:<domain>.com,DNS:mail.<domain>.com,DNS:mail.<otherdomain>.com,...

[ policy_match ]
countryName             = match
stateOrProvinceName     = optional
organizationName        = supplied
organizationalUnitName  = optional
commonName              = supplied
emailAddress            = optional

The req_distinguished_name field defines the name of the Issuer. The Issuer and Subject identity fields are:

Under policy_match the fields define what identity fields of the Subject must either "match" the Issuers identity, are required (supplied) or may be optionally supplied (optional).

The v3_req extensions have to be re-coded for each certificate, so ought to probably be left undefined for any CA you initially create.

Once you have a properly setup CA directory (and all the required sub-directories as define in the openssl.cnf files CA_default section, you can begin creating the keys and signing certificates via the following steps:

Steps to then create the CA:

1) Create a 2048 bit RSA key:

> openssl genrsa -out root-ca.key 2048

This generates the CA's private key, against which all certificates are signed. The key should be stored where the openssl.cnf file says it is located at. This key should be kept private, non-readable and never shared. If the key is released to the wider world, all certificates signed against it are now invalid. An attacker would also then be able to sign invalid certificates as you.

2) Creating a certificate authority:

> openssl req -new -x509 -days 3650 -key root-ca.key -out root-ca.crt -config openssl.cnf

This creates the root certificate authority certificate root-ca.crt, using the root key. You'll need to change the paths to the correct file locations.

3) Creating a certificate request:

Create a private key:
> openssl genrsa -out domain.key 2048

This is done by the subject, not the CA. This is the subjects private key.

Create certificate request:
> openssl req -new -sha256 -key domain.key -out domain.csr

The certificate signing request is then signed against the private key. The domain.csr is then sent to the CA to be signed.

4) Signing a certificate request:

> openssl ca -in domain.csr -out newcert.pem -config ./openssl.cnf

The CA then signs the CSR (using the information in the config file,) the output in newcert.pem is a PEM formatted certificate which is then sent back to the subject.

Quick self-signed certs:

> openssl req -new -newkey rsa:2048 -x509 -nodes -keyout server.key -out server.crt -days 9999

This will create a private key (server.key) and a self-signed certificate (server.crt). Often useful for quickly setting up some certificates for testing purposes.

Convert between pkcs12 and pem formats:

> openssl pkcs12 -in input.pfx -out output.pem

Converts from the Windows standard pkcs12 format to Linux's pem format standard.

> openssl pkcs12 -export -in input.pem -out output.pfx

Converts from the Linux pem (includes both private key and cert) format to Windows standard pkcs12 format.

Test server/client:

> openssl s_server -port port -cert public-key -key private key -www

Creates a "web server" on port using a certificate and private key. Useful for testing purposes.

> openssl s_client -connect hostname:443

Connects to hostname:port, displaying any certificate information from the host.

The SSL/TLS handshake:

1. Client connects to server and sends a list of supported cipher suites (ciphers and hash functions)

2. Server picks a cipher and hash it also supports and tells client.

3. Server sends it's digital certificate, which includes its server name, Certificate Authority (CA) and public key.

4. Client may verify the certificate with the CA.

5. Client generates session keys by encrypting random numbers using the servers public key and sends the encrypted keys to the server.

6. Server can then decrypt the sessions keys using it's private key.

7. The session key(s) are used to initialize a hash or stream cipher to the same state on both ends, which are then used to encrypt the traffic.

Encryption:

Public Key exchange is used to securely share a secret key: A seed to a stream cipher or Pseudo-Random Number Generator (PRNG), or a key to a block cipher. The use of signed certificates is used to facilitate trust in the exchange of these keys -- that we're trading keys with the entity we want and not some man in the middle. The certificate contains the public key of the person or organization to which we want to communicate, which we can use to begin encryption with them by encrypting the above mentioned seed.

In public/private key exchange, the public key unlocks an item encrypted by the private key and vice-versa. By way of an over-simplified example, imagine that a public key was the number 20, and the private key was the multiplicative inverse, i.e. 1/20 A number, our seed, is enciphered by the subject using the public key. Suppose the seed was 33. The message sent to the holder of the private key is then 33*20 or 660. Some imagination is required to imagine that it is impossible to deduce the seed number from the public key, which is normally the case. The owner of the private key can however recover the seed value by multiplying the 660 by 1/20 to get the original 33. You can maybe imagine how it can also work in the other direction.

Stream ciphers (RC4, et.al.)

RC4 is an example of a stream cipher which is really a cryptographically secure Pseudo Random Number Generator (PRNG). A PRNG will always produce the same sequence of seemingly random numbers when seeded with the same seed number. Both ends of a connection seed their PRNGs with the same seed number.

Once the shared seed is used to initialize the PRNG, the data to be shared it XOR'ed (Exclusive OR'ed) with the stream of random bits from the PRNG on the sending side.

The receiver XOR's the received data with its PRNG data, resulting in the original un-encrypted data.

XOR operation:
0 ⊕ 0 = 0
0 ⊕ 1 = 1
1 ⊕ 0 = 1
1 ⊕ 1 = 0
Di ⊕ PRNGi = Ei
Ei ⊕ PRNGi = Di

Where D_i is Data byte i and E_i is the Encrypted data for data byte i. Using the same random value from the PRNG reverse the encryption.

Good PRNG's have:

• Good distribution of random data (should not favor certain numbers or bits)

• Large period between repeating data. Where:
  PRNG_i = PRNG_i+k for all 0 <= i < k. k should be large, for all input seeds.

• Good PRNGs tend to be more computationally expensive (slower.)

Block ciphers (DES, AES, Blowfish)

• Permute blocks of data (usually of a fixed size) based on a reverable function, permuted by a specific key.

• Sender takes a block of data, applies the permutation function to the data, then send to the reciver.

• Reciver uses the inverse of the permutation function to decode the orginal data. The operation of the permutations is contingent upon the key being used.