Cryptography is at the core of any PKI and the security that it delivers hinges on how the cryptographic keys are protected and how they are used. The following ten ‘standards of due care’ can be applied to any cryptographic system but are particularly critical practices when it comes to building a secure PKI, one that supports the trust models that depend upon it.
Know the origin and quality of your keys: Keys start out life as random numbers but ensuring true randomness is harder than it sounds. Any degree of predictability when generating keys makes the life of the attacker considerably easier and weakens the system. Truly random data can only come from the natural characteristics of hardware, software is inherently predictable.
Know exactly where your keys are and who/what systems can access them at all times. Storing and using keys in software based systems, and in particular virtualized systems can result in the propogation of copies, snapshots, back-ups that increase the risk of key theft or substitution. Segregating keys in dedicated hardware allows explicit processes to be defined for key management.
Ensure each key is only used for one purpose. Critical applications should be governed by distinct and specific key management and usage policies. Different applications use keys in different ways and any one application can potentially leak information that could lead to the corruption of another.
Formalise a plan to rotate, refresh, retain and destroy keys. Overworked keys are a liability and obsolete keys are an unnecessary risk. Keys have a lifecycle and need to be managed from phase to phase. Hardware Security Modules are purpose-built to safeguard and securely manage sensitive keys throughout their lifecycle.
Only use globally accepted and proven algorithms and key lengths. Few areas of IT security are static. As cryptanalysis tools evolve so must the crypto systems they seek to crack. Many government and industry groups publish and update recommendations for algorithm selection and key length policies. Nobody wants to be the last person on earth using Triple DES or SHA-1!
Adopt independently certified products wherever possible. If you’re tempted to write cryptographic software yourself, you may be jeopardising your security. Writing secure code is difficult and testing it is even harder and crypto code is the hardest of all. Formal product certifications such as FIPS 140-2 and Common Criteria exist to back up the claims of vendors and serve as a benchmark for security.
Implement dual control with strong separation for all sensitive operations. Even when keys are protected and can’t be stolen the risk that they will be misused is ever present. Targeted attacks, social engineering and disgruntled insiders can exploit ‘super user’ privileges and single points of weakness.
Ensure your keys are securely backed up and available to your redundant systems. It’s natural to focus on key security but don’t forget that if a critical key becomes unavailable it can take a system off line and bring business to a standstill. Worse still, if a key is lost it can cause the data it is protecting to be irretrievable – for ever.
Control access to cryptographic functions and systems using strong authentication. Security relies on consistency; strong keys should not be able to be accessed by weak means. Password protected access to cryptographic systems should be a security red flag. Two factor authentication and strong authorization for critical operations are essential.
Never allow anyone or any ‘open’ system to come into possession of the full plaintext of a private or secret key. Theft of these keys can enable attackers to access past and future data without detection. Moving keys around and backing up key material is unavoidable in any scalable or mission critical system but it should always be performed only after key material has been made safe – neutralized by encryption. Encryption of keys is essential whenever they leave a trusted system such as an HSM.
More posts in this series:
Part 1: What is a PKI and why is it important?
Part 2: Security considerations of a PKI