In the creation, operation, and maintenance of software systems, data can be stored in many places: on physical or virtual disks, files, databases, and backups (which can take various forms as well). I discuss each one of these below, but the concept is relatively straightforward:
- Choose an appropriate algorithm and key
- Apply the encryption to the data
- Store the key in a safe place for use when you need to decrypt the data
Block vs. Stream Ciphers
For data at rest, the encrypt and decrypt key is one and the same. This is called symmetric encryption, and there are two varieties of algorithm used: block ciphers and stream ciphers.
Block ciphers encrypt data in fixed-size chunks. A common option is AES (Advanced Encryption Standard), and it comes in various encryption chunk sizes (known as block length), e.g., 128 bits.
Stream ciphers encrypt data one bit at a time. This is a highly secure method; however, it is quite impractical because of the large amounts of key data it needs to work (one for every bit). Variations have been used with a pseudo-random number generator, and some have become popular in Wi-Fi security implementations like WEP and WPA. These have some known vulnerabilities, so investigate carefully before using them.
Choosing the right symmetric cryptosystem may also depend on how/where your software application is used. Check industry regulations, privacy requirements, and other requirements as you design, implement, and deploy your application.
Whole Disk Encryption
Cryptography is often used to encrypt storage media. Whole disk encryption, also called "full disk encryption," is most common. Most whole disk encryption schemes encrypt every sector of the disk using symmetric encryption. The key is usually protected by encrypting it with the user's credentials as a passphrase. The user must enter the credentials at boot time to unlock the drive. This passphrase is a de facto crypto key so store it in a safe place, ideally not on the very same drive you are encrypting.
Whole disk encryption is often used to protect information on laptops. However, it is often misused. In theory, if used correctly, whole disk encryption renders the contents of the laptop's storage media unreadable if the laptop is lost or stolen. However, for whole disk encryption to be effective, the laptop must be powered off when not in use.
If the laptop is lost or stolen when in sleep or hibernation, the disk drive can be unlocked, or the encryption key can be recovered from memory, and then the disk drive can be unlocked.
In most cases, the user is the greatest weakness in deploying whole disk encryption. Many users write passwords down and store them with their laptop; if the laptop is stolen, the user's credentials are stolen with it. They might also store a two-factor authentication (2FA) device, such as an RSA SecureID token, in the same bag as their laptop. This completely negates the value of both data encryption and 2FA.
File Encryption
It's important to encrypt individual sensitive files on all virtual or physical devices. Failure to do so can allow an attacker to copy information onto insecure media or send it through insecure communication channels, rendering the sensitive info insecure. Several popular tools are available to encrypt/decrypt specific files – PGP and Zip. PGP uses both symmetric and asymmetric crypto keys (we cover asymmetric crypto in blog 2 of our crypto series), and there is an open-source version available, OpenPGP. Zip uses AES as described above and is available for all major operating systems. You will find numerous implementations of zip available; take note of the strength of the encryption key used. The larger the key, the more secure, but larger key sizes create larger zip files. If storage space is at a premium in your system, this trade-off must be carefully considered.
Many applications also allow files to be signed with a key, reducing the risk of undiscovered tampering of sensitive information. You sign a file for the same reason you might sign a paper document with a pen - to let readers know that you created the document or that the document has your approval. Everyone who recognizes your signature can confirm that you wrote the letter. Similarly, when you sign a file digitally, anyone who "recognizes" your digital signature knows that the file came from you. The process of recognizing signatures is called verification. You can design your application only to use approved (signed) files for specific functions.
Database Encryption
Information in databases presents one of the most challenging data security issues. There are many approaches to securing databases, and a method that works best for one Database Management System (DBMS) might not work for all.
Sensitive information in databases must be encrypted, but the correct approach varies with the DBMS and the requirements of the applications processing that information. While encrypting databases solves some problems, it can create new ones.
| Encryption Type | How it Works | Risks |
| Hardware-Based | Database resides on raw partitions, separate from the boot, file, and operating systems. | Backup and restore need to happen for both the DB and the files on the non-DB partition. |
| Whole Disk | Databases residing as part of the formatted file system. | Can leave backups and exported data unsecured because only the media itself is secured, not the information in the database. |
| DBMS-based encryption | Multiple techniques, e.g., - Transparent data encryption (TDE) - Column-level encryption - Field-level encryption |
Solves the problem of backup and export data being unsecured but often leaves data exposed to queries. If an attacker issues Structured Query Language (SQL) commands against the DB, the encrypted data in the DB is no longer secure. |
| Server-side application-based | Sensitive data is encrypted by the application querying the DB, and the DB has no knowledge that the info is encrypted. | Might expose information in memory or over the networks and can limit the ability to perform ad-hoc queries on encrypted data. |
| Client-side application-based | Sensitive data is encrypted by the client application, and neither the server nor the DB has any knowledge that the data is encrypted. | Can create key-management issues, especially in systems with numerous client access points. Also, any client-side processing is susceptible to attack, hijacking, and spoofing. |
Backups are often among the most significant holes in an organization's information protection processes. They almost always contain unencrypted sensitive information unless it is encrypted at the file level. For example, backups of encrypted disks produce unencrypted archives when using whole disk encryption because the unencrypted files are being backed up, not the encrypted raw disk sectors. Similarly, backups of database transaction records and database archives themselves are unencrypted unless the records in the database itself are encrypted.
If you first encrypt your data before backup, the primary risks are related to key management. If keys are not managed in an "isolated system," system administrators with malicious intent may have the ability to decrypt sensitive data using keys they have access to. The fundamental principle of keys also gives rise to a potentially devastating risk. If keys are lost, the encrypted data is essentially lost, considering decryption without keys is nearly impossible. Store your keys as carefully as you store your backup – and keep them segregated from the backed-up data the key(s) unlock.
Finally, "off-site" backups are often out of your physical control, rendering them vulnerable to unauthorized access. Theft of backups is a common means of obtaining a path into an organization – mainly for the reason stated above, i.e., most backed-up data is unencrypted. There is no substitute for encrypting every backup.
About Ed Adams, CEO
Ed Adams is a software quality and security expert with over 20 years of experience in the field. He served as a member of the Security Innovation Board of Directors since 2002 and as CEO since 2003. Ed has held senior management positions at Rational Software, Lionbridge, Ipswitch, and MathSoft. He was also an engineer for the US Army and Foster-Miller earlier in his career.
Ed is a Ponemon Institute Research Fellow, Privacy by Design Ambassador by the Information & Privacy Commissioner of Canada, Forbes Technology Council Member, and recipient of multiple SC Magazine’s Reboot Leadership Awards. He sits on the board of Cyversity, a non-profit committed to advancing minorities in the field of cyber security, and is a BoSTEM Advisory Committee member.
