End User Encryption Key Protection Policy

1. Overview

If not done correctly, Encryption Key Management can compromise and disclose private keys used to secure sensitive data and, hence, compromise the data.   While users may understand it’s essential to encrypt certain documents and electronic communications, they may not be familiar with minimum standards for protection encryption keys.

2. Purpose

This policy outlines the requirements for protecting encryption keys that are under the control of end-users. These requirements are designed to prevent unauthorized disclosure and subsequent fraudulent use. The protection methods outlined will include operational and technical controls, such as key backup procedures, encryption under a separate key, and use of tamper-resistant hardware.

3. Scope

This policy applies to any encryption keys listed below and to the person responsible for any encryption key listed below. The encryption keys covered by this policy are:

The public keys contained in digital certificates are specifically exempted from this policy.

4. Policy

All encryption keys covered by this policy must be protected to prevent unauthorized disclosure and subsequent fraudulent use.

4.1  Secret Key Encryption Keys

Keys used for secret key encryption, also called symmetric cryptography, must be protected as they are distributed to all parties that will use them. During distribution, the symmetric encryption keys must be encrypted using a more robust algorithm with a key of the longest key length for that algorithm authorized in eCuras’s Acceptable Encryption Policy. If the keys are for the strongest algorithm, then the key must be split, each portion of the key encrypted with a different key that is the longest key length authorized, and each encrypted portion transmitted using other transmission mechanisms. The goal is to provide more stringent protection to the key than the data that is encrypted with that encryption key.

Symmetric encryption keys, when at rest, must be protected with security measures at least as stringent as the measures used for distribution of that key.

4.2  Public Key Encryption Keys

Public key cryptography, or asymmetric cryptography, uses public-private key pairs. The public key is passed to the certificate authority to be included in the digital certificate issued to the end-user. The digital certificate is available to everyone once it is issued. The private key should only be available to the end-user to whom the corresponding digital certificate is issued.

4.2.1        eCuras’s Public Key Infrastructure (PKI) Keys

The public-private key pairs used by the eCuras’s public key infrastructure (PKI) are generated on the tamper-resistant smart card issued to an individual end-user. The private key associated with an end user’s identity certificate, which is only used for digital signatures, will never leave the smart card. This prevents the Infosec Team from escrowing any private keys associated with identity certificates. The private key associated with any encryption certificates, which are used to encrypt email and other documents, must be escrowed in compliance with

eCuras policies.

Access to the private keys stored on a eCurasissued smart card will be protected by a personal identification number (PIN) known only to the individual to whom the smart card is issued. The smart card software will be configured to require entering the PIN before any private key contained on the smart card being accessed.

4.2.2        Other Public Key Encryption Keys

Other types of keys may be generated in software on the end user’s computer and stored as files on the hard drive or a hardware token. If the public-private key pair is generated on a smartcard, the requirements for protecting the private keys are the same as those for private keys associated with eCuras PKI. If the keys are generated in software, the end-user is required to create at least one backup of these keys and store any backup copies securely. The user is also required to create an escrow copy of any private keys used for encrypting data and deliver the escrow copy to the local Information Security representative for secure storage.

The Infosec Team shall not escrow any private keys associated with identity certificates. All backups, including escrow copies, shall be protected with a password or passphrase compliant with eCuras Password Policy.  Infosec representatives will store and protect the escrowed keys.

4.2.2.1  Commercial or Outside Organization Public Key Infrastructure (PKI) Keys

In working with business partners, the relationship may require the end-users to use public-private key pairs generated in software on the end user’s computer. In these cases, the public-private key pairs are stored in files on the end-users hard drive. The private keys are only protected by the strength of the password or passphrase chosen by the end-user. For example, when an end-user requests a digital certificate from a commercial PKI, such as VeriSign or Thawte, the end user’s web browser will generate the key pair and submit the public key as part of the certificate request to the CA. The private key remains in the browser’s certificate store, where the only protection is the password on the browser’s certificate store. A web browser storing private keys will be configured to require the user to enter the certificate store password anytime a private key is accessed.

4.2.2.2  PGP Key Pairs

If the business partner requires the use of PGP, the public-private key pairs can be stored in the user’s key ring files on the computer hard drive or a hardware token, for example, a USB drive or a smart card. Since the private keys’ protection is the passphrase on the secret keying, it is preferable that the public-private keys are stored on a hardware token. PGP will be configured to require entering the passphrase for every private key in the secret key ring.

4.3  Hardware Token Storage

Hardware tokens storing encryption keys will be treated as sensitive company equipment, as described in eCuras’s Physical Security policy, when outside company offices. Also, all hardware tokens, smartcards, USB tokens, etc., will not be stored or left connected to any end user’s computer when not in use. For end users traveling with hardware tokens, they will not be stored or carried in the same container or bag as any computer.

4.4  Personal Identification Numbers (PINs), Passwords and Passphrases

All PINs, passwords, or passphrases used to protect encryption keys must meet complexity and length requirements described in eCuras’s Password Policy.

4.5  Loss and Theft

The loss, theft, or potential unauthorized disclosure of any encryption key covered by this policy must be reported immediately to The Infosec Team.  Infosec personnel will direct the end-user in any actions required to revoke certificates or public-private key pairs.

5. Policy Compliance

5.1  Compliance Measurement

The Infosec team will verify compliance with this policy through various methods, including but not limited to periodic walk-thrus, video monitoring, business tool reports, internal and external audits, and feedback to the policy owner.

5.2  Exceptions

The Infosec Team must approve any exception to the policy in advance.

5.3  Non-Compliance

An employee found to have violated this policy may be subject to disciplinary action, up to and including termination of employment.

1. Acceptable Encryption Policy

10. Password Construction Guidelines

11. Password Protection Policy

7. Definitions and Terms

The following definition and terms can be found in the SANS Glossary located at:

https://www.sans.org/security-resources/glossary-of-terms/

Revised: March 14th, 2018

Table of Content

  1. Acceptable Encryption Policy
  2. Acceptable Use Policy
  3. Clean Desc Policy
  4. Data Breach Response Policy
  5. Disaster Recovery Plan Policy
  6. Digital Signature Acceptance Policy
  7. Email Policy
  8. Ethics Policy
  9. Pandemic Response Planning Policy
  10. Password Construction Guidelines
  11. Password Protection Policy
  12. Security Response Plan Policy
  13. End User Encryption Key Protection Policy
  14. Acquisition Assessment Policy
  15. Bluetooth Baseline Requirements Policy
  16. Remote Access Policy
  17. Remote Access Tools Policy
  18. Router and Switch Security Policy
  19. Wireless Communication Policy
  20. Wireless Communication Standard
  21. Database Credentials Policy
  22. Technology Equipment Disposal Policy
  23. Information Logging Standard
  24. Lab Security Policy
  25. Server Security Policy 
  26. Software Installation Policy
  27. Workstation Security (For HIPAA) Policy
  28. Web Application Security Policy
  29.  Analog/ISDN Line Security Policy
  30. Anti-Virus Guidelines
  31. Server Audit Policy
  32. Automatically Forwarded Email Policy
  33. Communications Equipment Policy
  34. Dial In Access Policy
  35. Extranet Policy
  36. Internet DMZ Equipment Policy
  37. Internet Usage Policy
  38. Mobile Device Encryption Policy
  39. Personal Communication Devices and Voicemail Policy
  40. Removable Media Policy
  41. Risk Assessment Policy
  42. Server Malware Protection Policy
  43. Social Engineering Awareness Policy
  44. DMZ Lab Security Policy
  45. Email Retention Policy
  46. Employee Internet Use Monitoring and Filtering Policy
  47. Lab Anti Virus Policy
  48. Mobile Employee Endpoint Responsibility Policy
  49. Remote Access Mobile Computing Storage
  50. Virtual Private Network Policy