In today’s cyber-world there is an ever-present risk of unauthorized access to all forms of data. Most at risk is financial and payment system data that can expose the personal identifying information (PII) or payment card details of customers and clients. Encryption is crucial for protecting PII and mitigating the risks that businesses which conduct payment transactions face every minute of every day.
In this article we will talk about symmetric encryption in banking, its advantages and some challenges of managing the keys.
What is Symmetric Encryption?
Symmetric encryption is a type of encryption where only one key (a secret key) is used to both encrypt and decrypt electronic information. The entities communicating via symmetric encryption must exchange the key so that it can be used in the decryption process. This encryption method differs from asymmetric encryption where a pair of keys, one public and one private, is used to encrypt and decrypt messages.
By using symmetric encryption algorithms, data is converted to a form that cannot be understood by anyone who does not possess the secret key to decrypt it. Once the intended recipient who possesses the key has the message, the algorithm reverses its action so that the message is returned to its original and understandable form. The secret key that the sender and recipient both use could be a specific password/code or it can be random string of letters or numbers that have been generated by a secure random number generator (RNG). For banking-grade encryption, the symmetric keys must be created using an RNG that is certified according to industry standards, such as FIPS 140-2.
There are two types of symmetric encryption algorithms:
Block algorithms. Set lengths of bits are encrypted in blocks of electronic data with the use of a specific secret key. As the data is being encrypted, the system holds the data in its memory as it waits for complete blocks.
Stream algorithms. Data is encrypted as it streams instead of being retained in the system’s memory.
Some examples of symmetric encryption algorithms include:
AES (Advanced Encryption Standard)
DES (Data Encryption Standard)
IDEA (International Data Encryption Algorithm)
Blowfish (Drop-in replacement for DES or IDEA)
RC4 (Rivest Cipher 4)
RC5 (Rivest Cipher 5)
RC6 (Rivest Cipher 6)
AES, DES, IDEA, Blowfish, RC5 and RC6 are block ciphers. RC4 is stream cipher.
In “modern” computing, DES was the first standardized cipher for securing electronic communications, and is used in variations (e.g. 2-key or 3-key 3DES). The original DES is not used anymore as it is considered too “weak”, due to the processing power of modern computers. Even 3DES is not recommended by NIST and PCI DSS 3.2, just like all 64-bit ciphers. However, 3DES is still widely used in EMV chip cards.
The most commonly used symmetric algorithm is the Advanced Encryption Standard (AES), which was originally known as Rijndael. This is the standard set by the U.S. National Institute of Standards and Technology in 2001 for the encryption of electronic data announced in U.S. FIPS PUB 197. This standard supersedes DES, which had been in use since 1977. Under NIST, the AES cipher has a block size of 128 bits, but can have three different key lengths as shown with AES-128, AES-192 and AES-256.
What is Symmetric Encryption Used For?
While symmetric encryption is an older method of encryption, it is faster and more efficient than asymmetric encryption, which takes a toll on networks due to performance issues with data size and heavy CPU use. Due to the better performance and faster speed of symmetric encryption (compared to asymmetric), symmetric cryptography is typically used for bulk encryption / encrypting large amounts of data, e.g. for database encryption. In the case of a database, the secret key might only be available to the database itself to encrypt or decrypt.
Some examples of where symmetric cryptography is used are:
Payment applications, such as card transactions where PII needs to be protected to prevent identity theft or fraudulent charges
Validations to confirm that the sender of a message is who he claims to be
Random number generation or hashing
Key management for symmetric encryption - what we need to consider
Unfortunately, symmetric encryption does come with its own drawbacks. Its weakest point is its aspects of key management, including:
Symmetric Encryption suffers from behavior where every use of a key ‘leaks’ some information that can potentially be used by an attacker to reconstruct the key. The defenses against this behavior include using a key hierarchy to ensure that master or key-encryption keys are not over-used and the appropriate rotation of keys that do encrypt volumes of data. To be tractable, both these solutions require competent key-management strategies as if (for example) a retired encryption key cannot be recovered the data is potentially lost.
Unlike asymmetric (public-key) Certificates, symmetric keys do not have embedded metadata to record information such as expiry date or an Access Control List to indicate the use the key may be put to - to Encrypt but not Decrypt for example.
The latter issue is somewhat addressed by standards such as ANSI X9-31 where a key can be bound to information prescribing its usage. But for full control over what a key can be used for and when it can be used, a key-management system is required.
Key Management at large scale
Where only a few keys are involved in a scheme (tens to low hundreds), the management overhead is modest and can be handled through manual, human activity. However, with a large estate, tracking the expiration and arranging rotation of keys quickly becomes impractical.
Consider an EMV payment card deployment: millions of cards multiplied by several keys-per-card requires a dedicated provision and key-management system.
Maintaining large-scale symmetric encryption systems is a very challenging task. This is especially true when we want to achieve banking-grade security and auditability when the corporate and/or IT architecture is decentralized / geographically distributed.
In order to do this properly, it is recommended to use special software to maintain the proper life-cycle for each key created. In instances of massive key enrollment, it is truly impossible to conduct key management manually. We need specialized key life-cycle management software for it.
Quantum computing is expected to materialize within the next 5-10 years. Already today, NIST advises to replace the widely used 3DES algorithm with algorithms which we consider to be more save, based on today's knowledge.
Not knowing what progress in technology and hence in the evolution malicious decryption-algorithms may be, we strongly advise banks to migrate to a crypto-agile setup. Such a setup will allow to rapidly replace algorithms, when weaknesses are detected, with algorithms which are considered to be more secure. Investment and architecture decisions need to be taken now, to avoid major damage in the forthcoming years.
References and Further Reading
- Buyer’s Guide to Choosing a Crypto Key Management System - Part 1: What is a key management system (2018), by Rob Stubbs
- Buyer's Guide to Choosing a Crypto Key Management System; Part 2: The Requirement for a Key Management System (2018), by Rob Stubbs
- Buyer’s Guide to Choosing a Crypto Key Management System - Part 3: Choosing the Right Key Management System (2018), by Rob Stubbs
NIST SP800-57 Part 1 Revision 4: A Recommendation for Key Management (2016) by Elaine Barker
Selected articles on Key Management (2012-today) by Ashiq JA, Dawn M. Turner, Guillaume Forget, James H. Reinholm, Peter Landrock, Peter Smirnoff, Rob Stubbs, Stefan Hansen and more
CKMS Product Sheet (2016), by Cryptomathic