Practical Data Security for Travelers (to/via the UK)
The Problem: Secure Data Transport through Insecure Channels
You need to transport secrets with you as you travel from one location to another. You can’t guarantee that your data store won’t be copied, or confiscated (or lost) while in transit. You can encrypt it, but how can you ensure that the local authorities can’t force you to decrypt it under duress?
Strong encryption is enough to protect your data, but only if the keys to decrypt it are secure against seizure, brute force attack and compulsion under duress. A TrueCrypt volume is not a completely secure option because the key to decrypt the data is stored inside the volume header and protected only by your passphrase. This weakness is shared by all Full Disk Encryption solutions (BitLocker, LUKS dm-crypt, etc).
So, what can you do to protect your data such that even duress is not enough to gain access?
The Solution, In Theory
Ideally what you want is an encrypted storage container that can only be decrypted with the explicit approval of more than one person. Even if the person carrying the data is placed under duress, their cooperation is insufficient to decrypt the data. Other people, hopefully not under duress, are required to cooperate as well. The idea being that someone remote has veto power over the decryption.
Fortunately for us, crypto nerds have already solved this problem!
The Practical Solution (part 1): Shamir Secret Sharing
Shamir Secret Sharing
SSSS allows data to be encrypted with M keys such that you need at least N keys to decrypt it. This allows multiple people to be involved in the decryption of data, removing the ability of any one person to compromise the data. This mitigates against duress.
An OSS implementation is available here.
Now we need an encryption solution that enables us to use
ssss to protect the key.
The Practical Solution, part two: Tomb
Tomb is a wrapper around the Linux encrypted data power duo:
dm-crypt. Tomb allows mere mortals to access some of the awesome power of
cryptsetup, while encouraging a safer data securing standard operating procedure.
One of Tomb's core strengths is the separation of the encrypted data (the
tomb) from the decryption key (the
.key). This allows the key to be stored and transported separately from the encrypted data itself, which is potentially much more secure. There are downsides: it is a lot more risky re: data loss (do not lose the
The Practical Solution: Tomb + SSSS = Duress This
Since Tomb allows us to have an encrypted data store and a separate decryption key, all that we need to do is encrypt the
ssss. Decrypting the
.key and accessing the data requires the cooperating of more than one holder of the
ssss passphrases, so it is secure against duress (in theory).