We'll see here explained simply the essence of Public-key cryptography, and its use for encryption, authentication, certificates and PKIs.
VPN technologies requiring a lot of security, one mean to provide it is through the simple, usual passwords. The other way, more evolved and secure, is through certificates. We'll be seeing here the theory and the functioning of Public-key cryptography.
Last edited July 27 2014
1. Symetric-key encryption
The most basic form of cryptography is symetric cryptography. It is a basic system, where a message is encrypted using a secret key K. Then, the encrypted message can be unencrypted using the same secret key K.
An historical exemple is the Ceasar code, which is a simple letter shift of +n, where n is the key :
message : HELLO ------------------> encrypted message = KHOOR
key : +3
The un-encryption is performed using the same key, in a minus way.
The obvious problem of symetric crypto is the key, which has to stay secret at all costs. Historically, 2 seperate messengers where sent by horse on two seperate path : one with the encrypted message, one with the key. So that the the message wouldn't be found with its un-encryption key.
This key exchange / integrity problem is obviously furthermore crutial in an IT context : How to send the secret key on the internet in a safe way ?
Modern symetric keys algorithms are : RC4, 3DES, Twofish, Blowfish, Serpent, AES (Rijndael), CAST5, and IDEA.
Symetric-key encryption is also named secret-key, single-key, shared-key, one-key, and private-key encryption ( the last term leads to ambuguity with assymetric encryption )
2. Assymetric-key encryption
Assymetric cryptography slowly emerged through the 20th century. It relies on a particularity of asymetric keys algorithms :
A key pair is generated : Key1 and Key2.
If a message is encrypted with Key1, it can only be unencrypted by Key2.
this message CANNOT be unencrypted by Key1, and Key2 can't be guessed from Key1.
If a message is encrypted with Key2, it can only be unencrypted by Key1.
this message CANNOT be unencrypted by Key2, and Key1 can't be guessed from Key2.
Modern asymetric keys algorithms are : Diffie–Hellman key exchange protocol, RSA encryption algorithm (PKCS#1), Various elliptic curve techniques.
Assymetric-key encryption is also named public-key cryptography.
3. Assymetric-key encryption usages
The main usages of assymetric cryptography are Public-key encryption and Digital signatures ( ie certificates ). Let's see these
1. Public-key encryption
Let's imagine Bob and Alice want to communicate over an open ( ie insecure ) channel, like a WEP Wifi network.
Bob creates an assymetric-encryption keypair. He keeps one of the keys ( the private key ) secret and makes the other key ( the public key ) available to anyone.
Alice gets the public-key, chooses a secret password : abcd , and encrypts the following message with Bob public key :
" I'm Alice. My password is abcd. OK ? "
The message is then sent to Bob over the insecure channel.
Nobody but Bob can decrypt this message, as Bob's secret private key is needed. Now Bob and Alice have securely exchanged a secret key : abcd. The basic problem of key-exchange has been solved.
Now they'll continue the conversation, using symetric-encryption, using abcd as the secret key ( Because Assymetric-encryption is too CPU-intensive and time-consuming to keep on using it past the abcd key exchange )
This is Public-key encryption. An example of use if HTTPS, where Bob is the HTTPS server, and Alice si a Client Browser. Another example is SSH, where Bob is the SSH server and Alice the SSH client.
2. Digital signatures
Now let's imagine Bob wants to send a message to Alice, so that Alice can be sure the message really is from Bob ( Authenticity ) and hasn't been altered ( integrity ).
This is how we can do this :
Bob first computes a Hash ( MD5 ) of the message. ( A Hash is like a fingerprint ).
Bob then encrypts the message's Hash with his private key : The result is the Digital Signature.
The message is then sent by Bob to Alice appended with the Digital Signature.
Alice now unencrypts the Digital Signature with Bob's public key, computes the MD5 Hash of the received message, and compares these two values : If they are equal, it means that :
1. The message hasn't been altered ( Integrity )
2. The message is really from Bob ( Authenticity )
3. Bob isn't able to refute that message ( Non-Repudiation )
4. Practical example : SSH server
How SSH works
When the SSH server is installed, it generates a private/public key-pair.
When a client wants to connect, he receives the server public-key. The client creates a symetric-key, encrypts it with the SSH-server public-key, and sends this result to the SSH-server.
The SSH server unencrypts the received message with its private-key. Now a private, symetric-key has been securely exchanged between the SSH server and the client.
All following communication will be encrypted with that symetric key.
The client is now able to authenticate securely using that encrypted channel.
This is ( simplified ) how SSH works
One note : When receiving the SSH Server's public-key, the Client will raise a warning if this public-key is not already known ( present on /home/[user]/.ssh/known_hosts file ). If the user accepts the key, it is added to the known_hosts file, and no more warning will be raised. This is a basic way for the client to check who it is connecting to ( Althought not 100% spoof-proof ).
SSH with Public Key authentication
Once the secure encrypted channel has been created, the client has different options to authenticate. One is simple password authentication, using a login name + password. Another one is using a Public-key. Let's see how this authentication works.
This is how we do it :
1. We generate an assymetric-encryption key-pair : a private key and a public key
2. We place the private key in the client and have the SSH server register the public key
Now, once the secure encrypted channel has been created, the client will authenticate by proving it can un-encrypt a challenge encrypted by the SSH server with the client's public-key.
This is ( simplified ) how SSH with Public Key authentication works.
note: for some extra security, we can have the client 's private-key password-encrypted on the client's HDD.
See next Blogpost ( VPN 11 : SSH with Public-Key Authentication ) for a Debian tutorial
5. Practical example : PPTP server with EAP-TLS
This next practical example is to secure a PPTP server with a Public Key Infrastructure
This is how we do it :
1. We create a personnal Certificate Authority ( CA ) with its own Public-key/Private-key pair
2. We have this CA Sign Public-key/Private-key pairs for the PPTP Server and any PPTP client
3. We place the CA certificate + the Server's key-pair in the Server
4. We place in each Client the CA certificate + the Client's keypair
Do note that the CA have the Server and Client certificates signed using its Private-key, which will remain secret. The CA will only make publicly available its Public-key.
Here is how the Server-Client exchange works :
1. Each peer ( the Server and the Client ) will verify that the other peer's certificate has been rightfully signed by the CA.
2. If the certificate is authenticated ( ie. Authenticated and Unaltered ), each peer now checks the Certificate headers, for informations like :
. Common Name ( CN ) : It's the name written on the certificate
. Certificate type : Client or Server ( if Server, nsCertType=server )
The Server can now verify if a Client certificate has been rightfully signed by the CA.
We don't need to maintain a Client's list at the Server's level. We just issue ( sign ) certificates for the clients.
If wished, a client's certificate can be revoked at the CA's level : This is the Certificate Revocation List ( CRL ).
We just have to be sure the Server checks the CA's CRL.
See VPN 12/13 for a tutorial on Debian PPTP Server with EAP-TLS
notes : nsCertType si a deprecated Netscape Certificate Type Exttention. This is a multi-valued extensions which consists of a list of flags to be included. It was used to indicate the purposes for which a certificate could be used. The basicConstraints, keyUsage and extended key usage extensions are now used instead.
Acceptable values for nsCertType are: client, server, email, objsign, reserved, sslCA, emailCA, objCA.
( source : x509v3 / https://www.openssl.org/docs/apps/x509v3_config.html )