Faults in Crypto-systems

Written by: Mario Sist

April 19, 2016 - Why do faults in crypto-systems occur and what can done to overcome this?

At UL, we review crypto-systems on a daily basis. These crypto-systems are used in chip-enabled credit cards, ATMs, card-acceptance devices, communication devices, mobile phone applications, smartcards and computer chips. The number and types of faults we find in the design and/or implementation of crypto-systems compared to other systems always amazes me – so I’ve started to think about why this happens and what can be done.

That is not to say that as part of UL’s functional testing we do not also find faults – we do. Most people are familiar with functional faults: unexpected behaviour, unusual results, crashing applications – frustration. Manufacturers understand how this impacts on sales of the product and the perception of their brand, so to minimise functional faults, testing is undertaken. Functional testing involves assessing the product with known inputs and known outputs. The known inputs are applied to the product and the actual outputs are captured and then compared to the known outputs to confirm if the product has functioned ‘correctly’.

Crypto-systems are different! Crypto-systems scramble or ‘encrypt’ input data so only authorised people can read it – unscrambling of the encrypted data is known as decryption and requires the decryption cryptographic key. The functions used to encrypt and decrypt data are related to each other and combined are known as a cryptographic algorithm (or algorithm for short) – common algorithms are TDEA, AES, RSA and ECC. In modern crypto-systems, the method the algorithm uses to encrypt and decrypt data does not need to be secret; typically, it is public information that can be found in standards. Indeed, we have found commercial and well analysed public algorithms are more secure than proprietor non-public algorithms. The secrecy of modern crypto-systems is (in theory) tied to the secrecy of the cryptographic keys that are used to drive the algorithm.

In practice, to gain a high level of assurance that the data is truly private, you need to check:

  • The algorithm and strength of the associated cryptographic keys (i.e. key length)
  • The cryptographic keys used to decrypt data are only in the possession of authorised people and unauthorised copies have NEVER been made
  • The data that needs to be kept private has not been exposed in either the encryption environment or decryption environment

Unfortunately, many crypto-system implementations are not tested by people who are knowledgeable of cryptography. Most coders are happy if they just get their crypto-system working and the data looks scrambled to the naked eye – even if it does not provide privacy. An example of this is the use of default cryptographic keys in production implementations. Suppliers of crypto-systems will provide the developer with ‘test’ cryptographic keys to speed up the process; however, some developers who are not knowledgeable on cryptography will use the default test cryptographic keys in production implementations – this allows unauthorised people who know the default decryption keys (in theory, everyone) to read the encrypted data!

The following is a checklist of common faults in crypto-systems:

  • The algorithm is not or is no longer considered ‘strong’ – use only approved algorithms
  • The associated cryptographic key length is no longer considered ‘strong’, i.e. it is too short – use only approved key lengths
  • The processes and system to keep a cryptographic key private across its full lifecycle are not in place; this includes key management (i.e. generation, transport, use, storage, archive and destruction)
  • Weak security in the encryption or decryption environments which allow either the data to be copied or information on the keys to be leaked

For high-assurance environments, you should also:

  • Understand the crypto-system may break and you should have information to assist incident response, i.e. decryption logs, logs that detail access to the system(s) that hold the decryption keys
  • Processes to change the cryptographic keys in use

I have thought long and hard as to why I see so many faults in crypto-systems. In my opinion, the main cause is twofold:

  • Most people implementing crypto-systems have little understanding of crypto-systems; they are coders who just follow an example they find on the internet and cut and paste calls to crypto libraries without understanding crypto basics.
  • A crypto-system looks like it is working even if it is not; it is impossible to detect weak encryption by visual inspection alone.

So, a list of best practices for entities using crypto-systems:

  • People designing and implementing crypto-systems need crypto-awareness.
  • Document the crypto-system algorithm(s) and key lengths and how the keys are used and stored. Also document the cryptographic key lifecycle – how and when cryptographic keys are generated, transferred, loaded, used, suspended and destroyed – and look at how they are stored in each stage.
  • Review the design at least annually to confirm advances in attack methods have not rendered them ineffective or at-risk.
  • Review if the actual processes used to handle keys matches the documented processes at least annually. Look for signs of possible key exposure, i.e. the key has not been kept secure. If keys have been ‘leaked’ to an unauthorised person then the whole system is at risk and may not be offering any protection of data at all!
  • Detailed instructions are needed for successful implementation and operation.
  • Secure the encryption and decryption environments to the level of security required. Ensure the level of security is reviewed at least on an annual basis, as cybercrime is quickly escalating.
  • Ensure key generation uses an approved Random Number Generator (RNG) and that default and weak keys are not used.
  • Ensure decryption keys are only ever accessible to people authorised to decrypt data. This includes leakage during use, transport and storage. It is very easy to make a copy of a cryptographic key on a digital system with a low chance of detection.

If you need help with crypto-systems – reach out.

Disclaimer

These are the personal opinions of UL’s employees and its guests and should not be misunderstood as representing the opinion of UL's clients, suppliers or other relations.