THE SQL Server Blog Spot on the Web

Welcome to - The SQL Server blog spot on the web Sign in | |
in Search

Buck Woody

Carpe Datum!

Should All Data Be Encrypted By Default?

Recently several IT industry information outlets have reported that there has been a 10-year concentrated, organized effort on breaking through computer security at some of the largest companies in the world. Government sites have also been attacked in multiple countries. Add to this the regular loss of data by banking and other industries, and the fear of “the cloud” as a storage location, and it seems to beg the question asked in the title in this post: “should all data, everywhere, be encrypted by default?”

If you’re new to encryption, there’s an excellent video and overview here: 

If all data were encrypted, the break-in to websites would still continue, but the value would be lessened for some types of “orthogonal” attacks that only seek the pure stream of data.

Data States

Computing has two major components - static program elements and data. The program doesn’t change (until it is updated, of course) over the course of a transaction between a user and the ultimate data store. Data is classified as anything that is manipulated by the program. That implies three states of the data interchange: Creation, Transmission, and Storage. In on-premise systems, many times none of these states are encrypted. The entire system from user to data store is viewed as “secure”, which of course evidence has proved it is not. In some cases, even laptops are viewed as part of an on-premise system, and so is left unprotected. If all data were treated as “publicly viewable”, that mindset would lead to encrypting the data at all states, even for on-premise systems.


In this phase, a user, device or other input program creates data to send to the program. This can be entries on a web form, input from a weather sensor, or one service (program) sending information to another service. There are multiple ways to encrypt data at this state, most notably using client-side libraries such as the Windows Crypto API, hardware encryption and others. The reference for the Crypto API is here:


After the data is created, it needs to be transmitted to the processing and storage system. the references above explain how to secure the communications channel between the client systems and the various components used within the system. In the case of Windows Azure, the session can be protected with a secure session, and all communications within the Azure datacenters are encrypted. The key is that the transmission of data, regardless of method, should be considered to be “in the clear”, and treated as such. Without the decryption algorithm, it’s much harder to get to the ultimate goal.

Storage (data at rest)

It follows that f the data is encrypted at the source, and the decryption method is retained only with the code that processes the data, then the data “at rest” if obtained is less accessible. If the data is not encrypted at the source, then this step should be put into place at a minimum. In many cloud systems, including Windows and SQL Azure, the data is not encrypted at rest. There are various reasons for this, including performance, physical and logical security already in place, and the fact that the encryption process would expose customer data to the provider while it is being encrypted. In this case, the key is to encrypt the data before it is transmitted and stored, so that it is encrypted ahead of time.


Encrypting data is a separate process, and must be factored into the original codebase. This means additional effort, and more CPU power for the encryption process (although many systems have security hardware included which help with this) and of course protecting the keys. If the keys are accessed, the data is considered unencrypted from then on, and all previous encryption with that particular key is now vulnerable. Key rotation and protection is essential. Even so, the benefits of treating all data as being at risk outweighs the efforts.

You can learn more about general encryption here:

Published Tuesday, August 09, 2011 7:45 AM by BuckWoody


No Comments
New Comments to this post are disabled

About BuckWoody

This Blog


Privacy Statement