Sunday, June 28, 2015

Guide for building an Encryption Policy: Encryption Implementations - part 3

16th century French cypher machine
As you can see in the image above, encryption means nothing if you don't actually implement it. The French cypher machine in the shape of a book dates from the 16th century and was owned by King Henri II which implemented a version of cryptography (Wikipedia source).

But what are the common practices today? In the first two blog-posts I have set out a baseline for the policies concerning hashing and encryption. I have described the various algorithms and stated which ones should be used and which ones shouldn't.

In this part I will look at the variety of different implementations and I will focus on the ones that are common today (and hopefully tomorrow).

The series of posts are divided over the following topics.

Encryption mapped on OSI-model

First I want to take a look in which phases of a data in transit and at rest encryption can takes place. This is important to know, but yet often overlooked. Management pressure often beholds comments like: "we need to do encryption" or "encrypt every network connection". The truth is that most likely your network is a complex network and applying encryption technique is nowhere as easy as like your management stating that you have to implement it.

For the purpose of this post I created a model that gives an overview on which places encryption can take place and in what form. After this model I will briefly explain the variety of options shown in the image. For the record, the image is released under the Creative Commons Attribution-NoDerivatives 4.0 International License, so please share it in every way you like.

Model of Encryption techniques in context to data in transit, in process and at rest
Model of Encryption techniques in context to data in transit, in process and at rest
Data has 3 stages it can be in. It can be in transit between two information systems, it can be in process within an information system and it can be stored (at rest) in an information system. All three stages have a different approach towards encryption. I will talk about the different stages of data from the OSI-model perspective.

If you want to know more about the OSI-model, click here. In the model above I have added three additional layers (after a debate with a colleague of mine) to the OSI-stack. Those are layer 8 Message, layer 9 Transaction and layer 10 Process. These layers represent the layers that are needed to actually submit a message to the Application layer. A process can contain multiple transactions, and a transaction can contain multiple messages.

A message is the actual data itself. Although (meta-)data in and of the transaction and process layer can be sensitive too. In this post I will focus on the actual message that is going to be transmitted to another node.

Data in Transit

Encryption of data in transit happens on the 3rd, 5th, 6th and 7th layer of the OSI-model. Where as layer 3 is information system independent (at least, it should be), layer 5 through 7 are more depended on what mechanism is chosen in the application layer. Important here is to know that they are different.

When applying IPSec for IPv4 or IPv6 in your network configuration you will encrypt the payload of every IP-packet. The header of every IP-packet is, for obvious reasons of delivery of the payload, not encrypted. There are also two modus of operandi here. One is host-to-host and the other one is gateway-to-gateway. I tend to say to go for host-to-host whenever possible as the route of encryption is the longest there. IPSec secures your data against unauthorized access on the wire. But anyone that is authorized to the network can see the data (makes sense I guess).

Transport Layer Security (TLS) is probably the best known protocol to encrypt data on the wire. It takes residence in the presentation and application layer. It is used in HTTP connections (the best known are the web-browsers), known as HTTPS and it is used for FTPS. Do not mistake this with sFTP which uses Secure Shell (SSH) to encrypt the data. SSH has some weaknesses prior to version 2. Secure Socket Layer (SSL) and every version of it is considered insecure, just as TLS 1.0 and 1.1 are. Do not use those protocols anymore!

In summary, TLS version 1.2 and SSH version 2 are safe to use. Therefore, HTTPS, FTPS and sFTP and other protocols based on TLS and SSH are also safe to use.

There is also the phenomenon of VPN (Virtual Private Network) Tunneling on layer 2, 3 and 7. In general every VPN tunnel is insecure when additional security measures are not taken. If you do not trust the underlying network of the VPN tunnel (for instance, the Internet), then you will have to take security measures in the VPN tunnel itself. These measures can be protocols like IPSec in conjunction to Layer 2 Tunneling Protocol (L2TP) or the use of TLS and SSH.

Data in Process

Data in process is the data that is processed by the information system (or business application if you like). It is everything between data-at-rest and data-in-transit. As far as I can see, there is hardly any configurable encryption in this stage. Although it is possible that when the information system reads the data it also encrypts it in memory.

Although this approach seems to me highly CPU and memory intensive and I doubt its usefulness for common business-practices here. And it is something the developers of such an application or the operating system it runs on needs to implement.

Data at Rest

Data at rest has a filesystem centric approach towards encryption, and a data centric approach. Let's start with the first one.

Filesystem centric approach is not about the data itself, but the storage it is stored in. It is about encrypting disks, partitions and volumes (that span multiple disks or partitions). It is also about an encrypted file in which the actual data is stored in the form of files and folders. And also your temporary files in the hibernation and swap space (pagefile) can be encrypted. These last two are especially important if you want to secure your environment for forensic analyses.

The data-centric approach is the encryption of the data itself. Storing passwords is probably the most common known variant of it. But it is also possible to encrypt entire databases or specific records and/or attributes in a database. The focus here is the data it self, and not the filesystem it is stored on.

There are tons of examples for implementation here to choose from. There is an extensive list of disk encryption software on Wikipedia. When selecting your tool for the job, consider your policy towards hashing and encryption. There might be also other corporate policies that state whether you should or should not use open source tools. There is no right or wrong here, other then it is not wise to use software which uses outdated algorithms.

Implementation and testing

Do not ever trust an implementation without testing. TLS, SSH, IPSec, and the others might be secure by itself, but these algorithms and protocols are implemented by software (and hardware in some cases). And software implementations might have (or probably have) weaknesses also.

Therefore, always perform proper testing before and after implementation and keep testing it at regular intervals as new vulnerabilities might be discovered and exploited.


I hope I gave a clear view on the variety of implementations of encryption algorithms without either going to deep or staying to shallow on this topic. In the last blog-post in this series I will summary all three other posts into one policy on how you can handle your encryption and hashing practices.

Did you see anything incorrect, or do you disagree for other reasons? Or do you want to share how you handle topics such as these? Please share your thoughts and opinions in the comments below.

This post has the tag: update, meaning it will be updated when new information becomes available and/or relevant.


Post a Comment