Rubber hose attack
The rubber hose attack is extracting secrets from people by use of torture or coercion. Other means is governmental and corporate influence over other sub-entities.
The best method of defense is for people to know nothing or as little secrets as possible. The same logic applies to application servers, nodes, email servers, slack servers, etc… Another lesser known and used method for defense are various forms of deniable encryption.
Knowing as little as possible
The first turtle shell is to know as little as possible and keep secrets in the least amount of locations with the least amount of people able to view it. An example is to not allow CA’s or cloud companies such as AWS to create your private keys for you or to store them. If they have them at some point in memory on their server even as a transient operation, then there’s always a chance it can be stored on the file system either through a swap space or log files or audit files, etc… Who knows, they could begin emailing them to other companies in plain text.
Instead, create all secrets and keys locally store them in one and only one location. Preferably the secrets and keys are on closed systems with as little copying and shredding of the file system as possible.
Another turtle shell is to setup your openssl or local non cloud vendor software to automatically generate them for you and keep yourself from seeing them or having access to them easily once created.
Another turtle shell is to use physical mediums which never allow you to see or copy their private contents easily such as smart cards and have counter measures against physical tampering.
Another turtle shell is to use tools to access those tools which will require multiple operators to unlock a secret.
Deniable Encryption
Deniable Encryption is holding a set of keys and handing 1 of n keys to a rubber hose attacker who then decrypts
- less information than you want the attacker to decrypt
- a completely different set of information
- a combination of the two above.
Once done decrypting the contents, the rubber hose attacker also does not have a way of knowing
- If there is more information that can be decrypted. The decryption is not hiding anything, left over values are
null/0. - If any or all of the information is false information. The one-time pad-ness means any message of equal length to the key can be decrypted into any other message of the same length. For smaller messages, left over message bits can be flipped to
null/0. - If the handler of the keys has more keys and if so how many more keys they do have by looking at the encrypted and decrypted values.
It is possible to use various hard drive encryption from vendor software to mask or hide data with multiple sets of keys using this technique.
It is also not difficult to write a toy version with one-time pads to do the same thing. Writing a One Time Pad on my github , I was able to create two different keys from the encryption of hello which becomes the encrypted message of xmckl.
If I hand over a key of eqnvz it will yield the message of hello. If I hand over the key of gqnvz it will yield the message of jello instead.
I can now choose which key to give out to decrypt the message with. If I send a courier or person with a message and a false key through an enviornment in which they are required to hand over their decryption key and the encrypted message and do not tell the courier it is a false key, they have plausible deniability that the fake message decrypted is not the real message.
