Whenever I see a web site or hear a commercial touting how my personal information is secure because “we use encryption,” I just have to chuckle.
I guarantee you that Target did — and does — encrypt your personal information at rest. In fact, I strongly suspect they were doing a better job of protecting personal information than the average retail company.
Look what happened to them and the personal information of many of their customers!
You may have thought that encrypted data is much harder to steal than unencrypted data. However, even data encrypted with industry-standard algorithms and very strong keys (i.e. relatively long key lengths of relatively random data) can be just as susceptible to theft as unencrypted data. This is caused by a number of factors, most of which are mistakes and oversights of the business collecting and storing your data.
So what’s my point? It’s actually twofold.
- Encryption is not a panacea — even when done correctly.
- The knowledge that information is encrypted tells you exactly nothing about whether or not your data is adequately protected.
A Chain is as Strong as its Weakest Link
Encryption is not a panacea. You have probably been told more than once that there is no such thing as 100% security. And that is absolutely true. Encryption, when implemented correctly to meet the requirements of each individual scenario, can significantly reduce the risk of data being stolen. However, if other aspects of security are not being managed correctly, the actual amount of risk reduction can be negligible.
You Need More than Application-Level Access Control
For example, many companies I have worked with over the years have implemented access control functions only at the application level. If you can access a system outside of their applications, or if you can directly call programs within their applications, you bypass all of their access control!
Further, these companies also tend to implement the decryption process such that if you are running a program that manipulates data that is encrypted, the program automatically decrypts it. These implementations of encryption may make it harder to directly access data outside of the application. But as long as an attacker can compromise the user account of a person who is able to run a program that decrypts encrypted data, encryption provides little additional security (i.e. risk reduction). In this example, poor access control implementation negated most of the security value of encryption.
Protect Sensitive Data on the Move
The Target breach is another example of encryption not being a panacea. To my knowledge, the attackers didn’t compromise data at rest. They attacked devices where credit card data was only present for a short period of time. It didn’t matter how good Target’s encryption of data at rest was. They didn’t have to worry about encrypted data.
Disk-Level Encryption is Plain Lazy
Then there are the companies who decide to encrypt data at the disk level. Rather than having to change existing software or purchase third-party plug-ins for database level encryption, they decide that they’ll encrypt all data at a much lower level – the disk write operation level. This is available for many operating system environments. They believe doing so requires much less disruptive change. And they are right. Unfortunately, this approach means that access to clear text data is still controlled by the existing access control methodology and implementation.
The only risk mitigated by this approach to encryption is if someone steals the disk drives. Stealing entire disk drives nowadays constitutes a miniscule portion of the successful security attacks. Drives on stolen PCs rarely contain 10s of millions of accounts.
To clarify, I’m not arguing that encryption is useless. I am arguing that encryption does not improve security where other aspects of security are poorly managed. Therefore, encryption is not a panacea.
Look Behind the Curtain
The other half of the point of this article is “knowing that a web site or company encrypts data tells you exactly nothing about how well that company protects its data.” In other words, claims like “You can trust us because we encrypt your data” are absolutely meaningless. The examples above also support this point. Without knowing how a site or company has implemented the encryption/decryption process, you cannot possible know if their implementation provides any real additional protection.
But it goes deeper than this. Even if you are convinced that the organization follows the best practices for access control, authentication, accountability, and auditing, there are still a number of questions that need to be answered before you can adequately ascertain whether the encryption process employed by a company provides any real additional protection.
The first thing to understand about encryption is that doing it right is hard. It’s complicated. Not only are the encryption algorithms themselves complicated, but the processes surrounding the encryption and decryption functions can also obviate any benefit of encryption.
Encryption Algorithms
One of the first things you need to know is which encryption algorithms are used in which scenarios. AES encryption is generally considered the best encryption algorithm currently available. Triple-DES with appropriate key lengths may also still be acceptable for certain types of data.
Not only is the algorithm important, but you also want to know if the implementation of that algorithm has been certified with any legitimate organization. It’s possible to implement an algorithm that will encrypt and decrypt data such that it can be exchanged with a different implementation of the same algorithm, but to do so in a way that the level of protection is significantly less than a certified implementation. The National Institute of Standards (NIST) is the primary organization for certifying encryption algorithm implementations in the U.S. If a company uses a non-certified or home grown algorithm implementation, then your level of comfort in safety of data encrypted by that implementation is significantly less.
Key Strength
Key strength is also an important aspect of encryption. In general (but not 100% true for all algorithms), the shorter the length of the key for a given algorithm, the less the level of protection afforded to data encrypted by that key. So why doesn’t everyone use the longest possible keys? Because the longer the key, the longer it will take to encrypt and decrypt data. For a web site accepting tens of thousands of transaction per second, each of which contain data that must be decrypted coming off of the wire and re-encrypted before being stored in a database, key length is crucial decision. Currently, 2048-bit RSA keys are recommended with 128- or 256-bit keys being the norm for AES. (Note: a problem with AES using 256-bit keys was identified back in 2009. Bruce Schneier, the encryption expert, advised using AES-128 rather than AES-256 in new applications. The nature of the issue, in his opinion, was that there was no need to change existing applications using AES-256. Increasing the “number of rounds” of the algorithm was the fix for the problem).
Key Management
There are a number of questions to ask about how keys are managed in the encryption and decryption process. Why is this important?
Consider a bank that has the best bank vault money can buy. To get into the vault, you have to know the key combination. It would take a thief 8 hours to break into it. (I don’t believe one of these really exists. Vaults are normally rated in the number of minutes it would require an attacker to break into!) How safe is your money in the vault? Well for our fictitious bank, not very. You see, everyone that works at the bank knows the combination!
One of the first questions to ask is how keys are managed. That is, how are keys generated and stored? Are they rotated? If a key becomes lost, can it be recovered and if so, how? The answers to all of these are important because they provide insight into how well keys are managed.
Key Generation and Storage
Key generation is important. If not done correctly, it may be relatively easy to guess which key either has been used or will be used. This is not something that you want to build in your own shop.
How keys are stored is also very important. They have the same value to the organization as the data they encrypt. Encryption keys should be more highly protected than anything else. If everyone knows (or can learn!) the encryption key, then the data encrypted with that key has no additional protection.
Access to Keys
Who has access to the keys is another important question to answer. Assuming that keys are properly generated and properly stored and protected, you then need to know who is authorized and able to access encryption keys. Is the key available only to the owner of the data? Are system administrators able to access the keys? How many system administrators are able to access the keys? Is the keystore appropriately audited so those able to access keys know that access can be traced back to them?
Dropbox.com, the cloud-based storage company, touts its encryption of data. I have no reason to suspect they don’t implement it very well. However, it is known that Dropbox.com generates and stores the encryption keys. This means that, at a minimum, system administrators of the Dropbox systems on which the keys are stored have the capability of seeing all customer data encrypted with those keys. Dropbox was taken to task for making a claim that only people relatively well versed in encryption would understand correctly.
Key Rotation
Key rotation is another critical aspect that is sometimes overlooked. The longer an encryption key is used, the less protection provided by that key. If you use the same encryption key for ten years, an attacker has ten years to figure out what it is. Once they do, they have access to all of your encrypted data. If you rotate keys on a regular basis – say once a year – you generate a new key and re-encrypt everything on the system with that key. Attackers have, at most, only one year to get everything currently stored on the system.
Decryption Control
Another very important question to get answered is “Under what conditions is data decrypted?”
Because of the architecture and functionality of most databases, authorization is typically done at the database file or the database row level. In most applications, however, there are users that need to see some fields in a particular row but shouldn’t be able to see the clear-text version of encrypted fields in those rows.
Oftentimes, the display of the data is controlled by an application. The encrypted data is decrypted, but not displayed through the application. This opens the door for folks to access clear-text data using a different program or system level interface. Many times the development team isn’t even aware of this decryption!
Another aspect to this is the backup process. Does data get backed up in its encrypted or decrypted form? If the encrypted form is backed up, how are the encryption keys backed up? Hopefully, they aren’t stored on the same media! If the decrypted form is backed up, how is the media protected? Who is authorized and able to restore that data?
The Bottom Line
As I have — hopefully — showed, claims of data being protected because it’s encrypted are meaningless without a lot of extra information. Whenever you see or hear claims like these, take them with a grain of salt….. and maybe some ibuprofen. Personally, I find suspect any company making these types of claims. I worry that they don’t understand information security as well as they should and that they very likely may be doing a poor job with other aspects of security. Encryption is not a panacea, and the benefits of it can be mitigated by making mistakes in implementation or by poorly managing other aspects of information security.
Just an additional thought: When someone asks which encryption algorithm is used, does that person receive the name of the algorithm ?
Yet another weak link. By knowing the algorithm someone then only needs to work on the encryption key.
Mr. E., Encryption algorthims are “rated” in terms of the amount of time required to mount a brute force attack (i.e. trying all possible keys). These values are calculated based on the assumption that the algorithm is known. So if these values are sufficiently large, it won’t matter if the attacker knows the algorithm and key size.
From the EE times (http://www.eetimes.com/document.asp?doc_id=1279619)
This assumes that there are no weaknesses inherent in the algorithm. That’s why you should always use (or demand) that a well known algorithm, generally accepted by the encryption community, appropriate for the requirements of the specific usage, be used.
What I mean by “requirements of the specific usage?” Well, lets take an authentication mechanism that uses randomly generate, one-time use token, that is only valid for a short period of time. In this case AES is probably overkill. It might make sensse to use a less computationally expensive algorithm such as RC4. So just because AES is pretty much the current gold standard for symetric encryption, that doesn’t mean that it’s the right choice in every situation.
I use the line “it’s not rocket science” in lots of situations. With respect to encryption, I really think it is as complicated — perhaps even more complicated — than rocket science. That’s why I would not trust an algorithm that the encryption communicated had not yet vetted and/or approved.