# Hard Disk Encryption with expirable keys possible?

## ChojinDSL

Our office is considering converting to linux. I've been tasked with researching about Harddisk Encryption possibilities.

We want to issue all of our workers with laptops and linux. The idea ist to provide a locked down laptop, so that each employee only has a user password, so they can mess with the installation. 

Another idea was also to encrpyt the entire harddrive, or at least the most important portions of it.

The idea is, should a laptop get stolen, nobody can do anything with the data. 

Pretty straight forward so far.

But what about encryption keys which can expire? Is it even possible or even feasible to encrypt a partition with a key which has a set expiry date?

The basic idea is this. If a employee gets fired and they still have a company laptop in their possession, that they would loose access to their data after a certain time, once the encryption key expires. This would require the admins to regularily update the encryption keys, or at least extend their expiry date.

Is this even possible?

----------

## frostschutz

This is not possible. Even if you find some way to let a key expire, that kind of security can be broken easily by simply making a copy of the data while the key has not yet expired. If you implement such a system you will find that it does not increase security at all but causes a lot of unwanted trouble (keys expiring when they shouldn't).

I suggest you use LUKS for encrypting your hard disks. It comes closest to what you want - you can have several passwords and keys (by default up to 8 in total I believe), and you can change passwords and keys without having to re-encrypt the entire drive. So if an employee leaks a password / key by accident you can pull in all laptops and change passwords / keys for all of them. In terms of security and comfort, LUKS is by far the best solution on the market today. If you need support for Windows/Mac OS as well, you may want to have a look at TrueCrypt instead.

Some pointers and examples for cryptsetup/LUKS:

http://www.gentoo-wiki.com/SECURITY_System_Encryption_DM-Crypt_with_LUKS

http://www.gentoo-wiki.com/Booting_encrypted_system_from_USB_stick

----------

## Akhouk

Encryption of hard disks is done by a block cipher. It is possible that the decryption key for the cipher is protected using a PKI interface that will expire. However, just to note that the expiration only really protects against lost keys. The data is still encrypted in the same way which means that if someone was going to brute force it then whether or not the key has expired won't make any difference.

It is more important to have strong encryption keys and a strong block cipher.

Having said that I personally haven't seen anyone use expireable keys for hard disks. The worry would be that you let the key expire and then can't get back in to your data.

As the previous poster I suggest you use DMCrypt/LUKS. It is easy to setup and...works  :Smile: 

----------

## frostschutz

Regarding strong encryption, it's really hard to make LUKS insecure. This is simply because it comes with it's own password layer. The key that is actually used for encryption is randomly generated (which makes it safer than any safe but memorizable password), and decrypting this key with another key / by using a password uses an extremely SLOW cipher (so slow that you couldn't use it for the entire hard disk as it takes a second to decrypt just a few bytes), but this slowness is what makes a brute force attack unfeasible. Of course you should use a safe password nevertheless. This password layer is also what makes using several passwords / keys possible; they are all used to decrypt the same key from the LUKS header that is then used to actually access the hard disk (i.e. the real key does not change as no one knows it).

The downside of this is that if your LUKS header gets damaged you can't get your data back no matter what you do. But other solutions are even more prone to this kind of failure (you forget the password or lose the key, say byebye to your data - with LUKS you can have a fallback password/key to recover). But in the end all it means is that you shouldn't forget about making backups, with or without encryption.

----------

## deathcon1

Look into Seagate FDE drives which will encrypt the data at a hardware level, freeing up CPU cycles and prolonging battery life, and, afaik, is one of the safest ways to encrypt a drive, as the entire drive would be encrypted (including boot and swap.)  Then, if you wanted to be paranoid, add another layer of encryption and good luck getting into the data on that drive.

----------

## ChojinDSL

Thanks for the replies.

With expirable keys, I was thinking more along the lines of having one root/superuser/admin key, which can be used to generate user keys. The user keys have a expiration date, the root one doesnt. So lets say on an employee's laptop the key expires, then the root user could issue a new key or extend the expiry date of the existing ones.

Our employees are not very technically capable, (most of them are overwhelmed with resizing and compressing an image before sending it as an email attachment.)  so the possibility of bruteforce or some other method of cracking the encryption is slim to none, or at least in this scenario highly unlikely.

The basic idea behind it all is to have an expiry date on the data. Of course, the user could copy all the data before the key expires, however this is only an issue if the person actually remembers to do so. Besides this way, if an employee had to be let go, it could be timed to coincide with the expiration of their encryption key.

We realise of course that its not foolproof by any stretch of the imagination. Of course on the other hand, if a user isn't constantly aware of the fact that their encryption key can expire, they are even less likely to go through the effort of creating backups.

----------

## frostschutz

All ways I can think of have two things in common: They add a lot of complexity to your system, and none of them really work.

Do you really want to make an effort to implement such a system when you know it can be circumvented easily?

----------

## frostschutz

 *deathcon1 wrote:*   

> Look into Seagate FDE drives which will encrypt the data at a hardware level, freeing up CPU cycles and prolonging battery life, and, afaik, is one of the safest ways to encrypt a drive, as the entire drive would be encrypted (including boot and swap.)  Then, if you wanted to be paranoid, add another layer of encryption and good luck getting into the data on that drive.

 

Security within the drive itself is really a dangerous toy to play with. Most hard disks have a password facility nowadays. With some software encryption, if you lose your passphrase / key, you lost your data and you have to reformat. With a password set on the hard disk, you can't use the disk anymore at all. You have to buy a new drive or pay someone to force it open (it can be done by software because one company is offering this as a service online, but I don't know what kind of voodoo they use). Some BIOSes even offer to prevent the setting of such password in the hard drive because it is so dangerous.

Furthermore I just won't trust such a black box system. With a software solution like LUKS, I know exactly what it does and how it works (and what its limitations are), with the hard disk encryption, it may be secure, or it may be completely insecure. A little CPU overhead is a small price to pay.

----------

## ChojinDSL

LUKS seems to be the way to go so far. 

I'm having a hard time finding some good documentation on LUKS, sepcifically about the multiple passphrases and possible revocation of such.

From what I gather LUKS seems to support having a master key and several user passphrases. I just cant seem to find any detailed info if it is possible to set expiry dates for user passphrases.

----------

## frostschutz

It does not have master/user keys; anyone with a valid key is entitled to remove / replace / add other keys. It does not support expiry dates for keys either.

EDIT:

Of course you can still add a 'master' key and a 'user' passphrase so if the user forgets his password you can still use the master key to unlock the drive. But it will work only as long as the user didn't mess with the keys otherwise.

----------

