This chapter is from the book
This chapter is from the book
This chapter is from the book
2.7 Transparent Encryption
Several products on the market advertise transparent encryption. The name itself should raise a few questions: what kind of security does transparent encryption provide? The assumption is, of course, that the cryptography is transparent to the legitimate, authorized user but not to attackers. The security in such a system depends not only on the cryptosystem and key storage, but also on how well legitimate users can be distinguished from attackers.
Attackers are notoriously good at looking like legitimate users. Internal attackers typically are legitimate users. Many of the attacks discussed in the previous chapter are not stopped by transparent encryption, including SQL injection and "sanctioned" backdoors. The threat model must be considered carefully to see if transparent encryption offers the necessary protection.
For instance, triggers and views (features of some databases) can offer automatic encryption and decryption for authorized users. The trigger in this case is a program embedded in the database that runs every time a row is inserted and encrypts the necessary data. The view is a "virtual" table that decrypts the data before returning it to the requester. A select against the view (by an authorized user) returns decrypted data.
Which threats does this system protect against? Assuming that the keys are secured on another machine,7 the risk posed by thievery of the database or backups is mitigated. Of course, if an attacker can steal the database file, it is not too much of a stretch to assume that he can attack the transparent encryption system itself or the database’s authorization mechanism.
Also, threats from legitimate users with direct access to the database via an account that allows them to select against the encrypted table but not against the auto-decrypting view are reduced. However, such users are rare. Development staff engaged in troubleshooting is perhaps the most likely scenario, but, depending on the problem, they may need access to the auto-decrypting view. Most other users will access the data through an application that typically uses its own account, so they will not directly access the database. This is a rather minimal gain.
Most of our other threats still pose a risk for the database. Administrators can easily don the "authorized" user role and have the cryptosystem happily decrypt the data. Application crackers have the option of attacking the application or the database. If either succeeds, the attacker will be well on the way to accessing the encrypted data.8 Application subversion attacks, such as SQL injection, will also likely remain viable since such attacks generally leverage the application’s access privileges, and the application will likely access the database through an account that is authorized to view the decrypted data.
In a nutshell, the trigger and view solution described here reduces the data’s online security to the security level of the passwords to the accounts that are authorized to select against the auto-decrypting view. Should any of those accounts be compromised, the cryptography is circumvented. In terms of online threats, if this level of security were acceptable, cryptography in the database wouldn’t be necessary in the first place.
If the local threat model consists of only offline attacks, transparent encryption, such as the scheme just discussed, might be sufficient.9The threat model considered in this book, though, is more extensive. To mitigate online threats, we can, at the very least, require that an attacker gain access to both the database for the encrypted data and a cryptography service to decrypt it. The cryptography service can then be protected with much better security controls. We can better limit which machines may communicate with it, monitor it more closely, significantly strengthen its access credentials, increase the frequency with which the credentials are changed, and better protect the handling of those credentials.
When considering a transparent encryption solution, an organization’s security analysts must carefully compare the threat model the solution targets with the organization’s threat model. In addition, key storage must be considered. Ideally, the solution will support the use of a dedicated cryptographic hardware module for protecting the key and performing cryptographic operations. At the very least, the keys should be kept and used on a different machine.
A final word of caution. As you’ll see later, using a good algorithm is not enough. How it is used is of equal importance. This how is captured in the mode, and selecting the right mode depends on many conditions. While no single mode is correct in every situation, some modes are very rarely the right choice. Always ask which mode is used, and be very suspicious if a vendor indicates that no mode was used or if electronic code book (ECB) mode was used. In either case, the system is likely to be vulnerable to chosen-plaintext attacks, as described earlier in this chapter. This is covered in more detail in Chapter 4.