X

Jeff Victor's Blog

Encryption Everywhere

Jeff Victor
Principal Systems Engineer

Introduction


Until recently you chose between security and performance. Now you can have both, all the time. Encryption everywhere.



Generally speaking, data resides in three types of locations: long-term storage (e.g. disks), short-term memory (RAM), and in flight, on the network. Encrypting your data in all three types of locations minimizes the chances that your data can be misused even if it is stolen.


Many data protection mechanisms focus on preventing thieves from getting access to your data. Preventing access is a good goal, and worthy of the effort. However, recent history has shown us that eventually, the "bad guys" will get through these defenses. One straightforward method to protect your data from misuse is encryption. Even if villains can make a copy of the encrypted data, they can't use it.


A primary goal of data thieves is copying data. They can use this data directly, or they can sell it. But they can only do so if the data is readable. They cannot use encrypted data.


Many people use data encryption to protect data in transit over the Web. This was the first area of data encryption, and that's not surprising. As your data travels the Internet, it passes through many pieces of network equipment. A determined attacker may be able to gain control of such equipment and copy your data as it passes by.
Unencrypted data could be used for nefarious purposes. To prevent this, developers of web browsers and web server software added the ability to communicate via encrypted data, protecting your information while in the Internet. This is already used uniformly to protect financial purchases including online shopping.


Of course, every computer operation has a price. With encryption, the price has been reduced performance: software algorithms that encrypt data slow down data processing. So for years, encryption was only performed when it was judged "necessary."


Recent advances in Oracle SPARC processors have addressed this, reducing the performance penalty to an almost negligible amount. This opens up other possibilities: regular encryption of storage, and even memory. And so, with SPARC CPUs, it is no longer necessary to choose between data protection and industry-leading performance. You can have both with current-generation SPARC servers.


Today I'll focus specifically on protection of your data from misuse after theft, through the use of encryption. This blog entry discusses the features that you can use to protect your data, using SPARC servers based on the SPARC M7 and SPARC S7 processors, Oracle Solaris, and Oracle Database software.


Background


I'll use the phrase "encryption domain" to mean any location or path of data that has been encrypted. For example, if you encrypt a letter you have written to someone, and mail the encrypted version to someone who can decrypt it, its "encryption domain" is the piece of paper with encrypted text. During its whole voyage, its content is protected from anyone who might see it. If you copy the encrypted text without decrypting it, the copy is also in the encryption domain of the message. A decrypted copy would, of course, not be in that message's encryption domain.




This is similar in some ways to airport security. After you have passed through security screening,
you are in a secure area, often called "airside." This includes parts of the original airport, the airplane, runways, etc. You can extend this to include the airplane while in flight, and the secure areas of the destination airport. You are in this secure area from the moment you pass through the screening area of your originating airport until you walk past the screening area of your destination. All of the other people in these spaces have also been "secured." This is your "security domain." (See Figure 1.)


Encryption Everywhere



The rest of this blog entry portrays the multiple locations where encryption is possible. To distinguish them, I use a diagram that becomes progressively more secure by using encryption in more computer components. I will also name features that you can use for this purpose, in the description that accompanies the diagrams.




First let's look at the whole path of data, from a user, through the Web and associated network equipment, a web server, an application server, a database server, and finally to persistent storage. Figure 2 depicts this path as a logical diagram, which you can click to see a larger version. As the data flows from user to database, it passes through the user's PC, a network adapter (labeled "Net" in the diagram), and so on. Note the labels "Swap Disk" off to the side. They represent the potential for data to be swapped out to disk if the server has insufficient RAM.


All of these shapes are highlighted in red to indicate that their data is not encrypted.




Protecting Data in Motion





The first use of encryption in this diagram will be SSL: the
Secure Sockets Layer.
This encryption, shown in Figure 3, protects data from people who have control of Internet infrastructure equipment such as network routers. After the user enters some text such as a password, the user's PC encrypts the data before sending it over the web. This is indicated by green rectangles: a green Firewall shows that the data is encrypted while it flows through the firewall. The data is not decrypted until it arrives at the web server. This type of encryption has been common for a few years: you are using it whenever your web browser begins a URL with "https:".


Most common operating systems, including Oracle Solaris, and web server software packages, such as Apache, include SSL features.


Less common, but also shown in Figure 3, is the use of encryption between the web and application tiers, and between the app and database tiers. These are less common because their traffic does not typically flow over the public Internt, and for the reason mentioned early in this article: traditionally encryption has slowed performance too much. But with current generation SPARC servers, there is no longer a reason to not encrypt this traffic.




Protecting Data at Rest





Figure 4 adds encrypted storage to protect the "data at rest." Two effective methods that protect storage are Oracle TDE
(Transparent Data Encryption) and
ZFS. So whether you store your databases in flat files - on ZFS - or in ASM, you can protect your data from prying eyes while it sits on storage.



Solaris 11 added encryption to ZFS. You can easily
create an encrypted file system with the following command:

# zfs create -o encryption=on tank/home/jeffv

Oracle SPARC processors offer excellent encryption performance.
A comparison performed a year ago demonstrated negligible performance overhead for encryption on SPARC CPUs, but a significant decrease in performance on x86 CPUs.











Encryption has become common for network traffic, because the value of data protection is large, and the additional processing needed to implement encryption takes much less time than the transmission and receipt of a network packet. Encryption processing has little effect on network performance.
Similarly, encryption is slowly becoming common for persistent storage. The effect on overall performance can be larger than network performance, depending on the type of storage and the implementation of encryption algorithms in the CPU.


Memory accesses, on the other hand, have traditionally been far faster than encryption operations, and the implementation of encryption of data while in memory has lagged behind. However, this is changing.


Oracle TDE can enrypt data, either per column, or for a whole table, while it is in RAM. Encryption of a tablespace occurs at the block layer: a block is encrypted and written to disk, and the block is decrypted when it's read back in.


Column encryption and decryption occurs in PGA user session memory, which means that the data is encrypted while it is in the SGA, as shown in Figure 5.


Benchmark engineers have found that TDE encryption is

much faster on current SPARC CPUs than current x86 CPUs
.
The performance overhead when using a SPARC computer was about 2%, while the x86 system suffered 25% overhead.












Finally, Figure 6 shows an under-appreciated feature: the ability of Oracle Solaris to
encrypt data before it is saved in the swap disk. Without this protection, sensitive data that has been "temporarily" paged out could be copied by a successful attacker. Further, data that has been paged out is not erased when it is no longer needed. The data may remain on deallocated disk blocks until further paging activity overwrites it.


Conclusion


You can now encrypt all of your data, whether it's in motion or at rest. If you use Oracle Solaris on SPARC computers, you can do so without sacrificing performance.

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.Captcha