Encryption Key Management
Encryption keys and encryption key management are an important consideration when you are looking at implementing an encryption strategy. I will provide an overview of public key infrastructure (PKI) and pretty good privacy (PGP) key management.
1.1 PKI Key Management
PKI is a centrally managed encryption strategy. The advantage to a PKI is that it is trusted because users generally have to prove their identity before the certificate will be issued to them. The disadvantage is that a PKI can be complex to set up and maintain. There are a number of PKI solutions such as Microsoft Certificate Services (on-premise) and Symantec’s Managed PKI (hosted).
High-Level PKI Key Management Steps
- Import certificate authority’s root certificate.
- Create a private key and certificate signing request.
- Submit certificate signing request to a certificate authority.
- Import certificate from certificate authority.
- Encrypt files and emails.
- The sender retrieves the recipient’s certificate from Active Directory for example.
- The public key is extracted from the certificate.
- The sender’s application creates a new one-time encryption key and encrypts a file.
- The public key is used to encrypt the one time use encryption key.
- Optionally: Sender can sign the encrypted file or email with their private key.
- The encrypted file and the encrypted one time use encryption key are sent to the recipient.
- The recipient decrypts the one time use encryption key and then uses the one time use encryption key to decrypt the encrypted file.
- If signed, the recipient can confirm the sender’s signature with a copy of the sender’s public key.
Then the central piece of the infrastructure is called the certificate authority (CA). To ensure that you trust the certificates issued by the CA you may have to add the CA’s root certificate into the Trusted Root Certification Authorities node of your Certificate utility.
The CA is responsible for issuing public-key certificates, or simply “certificates”, for users. When a user wants to use PKI for encryption they use a utility such as Microsoft Windows’ Certificates to generate a private key and a certificate signing request(CSR). The CSR is submitted to the CA. If the CSR is accepted by the CA it will create and issue a certificate for the user. A certificate is the user’s public key which has been signed by the CA. The certificate is trusted because it has been signed by the CA. The private key and certificates are managed on the local computer by the Certificates utility.
Once a certificate has been issued it can be used for file and email encryption. The encryption application creates a one time use encryption key which is used to encrypt the file. The recipient’s public key is extracted from their certificate and used to encrypt the one time use encryption key. The encrypted file and encrypted one time use encryption key is sent to the recipient. The recipient decrypts the encrypted one time use encryption key with their private key and the one time use encryption key is then used to decrypt the file.
Senders can also sign encrypted files and emails. By signing the email or file it proves the sender was the creator of the file and that it was not tampered with, enroute to the recipient. The encryption application creates a one time use encryption key which is used to sign the file. The sender’s private key is used to sign the one time use encryption key. The signed file and encrypted one time use encryption key is sent to the recipient. The recipient decrypts the encrypted one time use encryption key with the sender’s public key and the one time use encryption key is then used to verify the signature of the file.
1.2 PGP Key Management
PGP is generally not centrally managed. The advantage is that is it quick to set up and easy to use. The disadvantage is that it can be a challenge to manage the keys and it may hard to establish trust.
High-Level PGP Key Management Steps
- Create a public and private key pair.
- Save a copy of your key pair.
- Exchange public keys with your friends.
- You and your friends confirm the fingerprints of the public keys and assign trust using the fingerprint of the keys.
- Your friends encrypt files or emails with your public key and send them to you.
- Optionally: Friends can sign the encrypted file or email with their private key.
- You decrypt encrypted files you receive with your private key and password.
- If signed, you can confirm your friend’s signature with a copy of the sender’s public key.
PGP keys can be created using utilities such as Cryptophane and Kleopatra for file encryption, Enigmail (mail encryption) or a full-function utility such as Symantec Encryption Desktop (email, file, file share and whole disk encryption).
With all of the utilities mentioned above, you can create a public and private key pair. The private key will need a password and will need to be kept secure by the user. The private key should not be distributed to other people. The public key, on the other hand, is meant to be distributed to other people. For instance, you can email the public key to a friend or you can host it on a key server such as https://keyserver.pgp.com. When it is hosted on the key server anyone one can do a key lookup and send you an encrypted file.
When I save my PGP keys to a folder I try to be as obvious as possible which will aid key management. On Microsoft Windows my folder structure looks something like:
When I save the private and public keys I use the following nomenclature:
UserName@domain.com (0x03C93169) pub.asc
UserName@domain.com (0x03C93169) pub-sec.asc
Where, UserName@domain.com is my email address, (0x03C93169) is the fingerprint of the key, “pub” indicates that the key is the public key and “pub-sec” indicates that the key is the public and private key pair. Including the fingerprint is important because there is nothing stopping you from having more than one key pair. The easiest way to tell them apart is by adding the fingerprint into the file name.
You can distribute UserName@domain.com (0x03C93169) pub.asc to your friends. They can then use your public key to automatically encrypt files and emails for you without the need of assigning a password.
You can import your private key, UserName@domain.com (0x03C93169) pub-sec.asc, into all of your PGP compatible applications so that you can decrypt encrypted files using your private key’s password.
As mentioned before there is a matter of trust. How can your friends trust that a public key belongs to you? When they import your public key into their PGP utility they will be asked by the utility if they trust the key. Normally they will confirm with you what the fingerprint of the key is. If the fingerprint they have on the public key that they are importing is the same as the fingerprint that you tell them they can assign trust to the key. Once they assign trust to the key it is a good idea for them to sign your public key with their private key.
Your friends can now encrypt files for you using your public key and you can decrypt them with your private key and password.
As with PKI encryption, users can sign encrypted files and emails. To sign a file or email they sign it with their private key. If you have a copy of their public key the signature will be verified and appear as a “good” signature.
Symantec has a solution to centrally manage PGP keys called Symantec Encryption Management (SEM) server. The SEM server can be used to apply encryption policies to groups users who use the Symantec Encryption Desktop client.
As you can see there are a couple of key options when it comes to file and email encryption. It is a good idea to spend some time to analyse your requirements and then talk to a consultant to deliver a solution that meets those requirements.
Join the Insentra Community with the Insentragram Newsletter
Hungry for more?
The Secure Workplace Story Part 2: Why and How Do You Implement a SWP?
By [Lee Foster]
The secure workplace has evolved rapidly over the past 24 months with more and more integration and continuous development to stay ahead of the bad guys.
Azure Information Protection - Deployment - Part 4
By [Hugh Roberts]
In part 4 of the series we take our implemented environment and ensure it is expanded, governed and monitored correctly.