| title | permalink |
|---|---|
Concepts and design |
/concepts-design |
- Approach
- Environmental threats
- Active threats and mitigations
- Additional goals
- About multiple identities
- About secrets
- About credentials and passphrases
- About passphrases
What makes a system more secure than another is the care and the solutions taken to mitigate the impact of threats affecting a specific environment.
The environment matters a lot and it must be taken in account when designing any system.
This is the main reason why there isn't an absolutely secure system and why each system must be customized for each unique situation.
A journalist who pisses off 3 letter-agencies and governments, like Assange or Snowden did and do, deals with a very capable enemy. This is a very high risk scenario which requires a patient and focused analysis of the threats involved. Snowden spent months waiting for journalists to be technically ready before talking to them. He wouldn't be out of jail or alive now if he hadn't enough patience and a deep understanding of the risks he was facing.
So, environment analysis first, mitigation then.
These are the threats and the adopted mitigations in R.I.S.K.S.:
| THREAT | MITIGATION |
|---|---|
| complexity leads to mistakes and misbehavior | I keep things simple, I use few tools, I define clear procedures |
| user's behavior is the weakest point of the system | I try to make the system as comfortable as I can |
| humans memory is unreliable | I use few mnemonic passphrases and I keep the mnemonic effort low |
| media loss or theft | I encrypt everything, I hide keys and I use an auto-locking systems |
| media corruption | I design disaster recovery techniques and procedures |
Clearly, I focus on quite common environmental facts affecting almost everyone to a certain extent before considering active forms of attack.
Considering the current development of crypto-currency and its wide adoption, secrecy and security become key points also for the average user. Secrets must be preserved and, eventually, sharable with specific people. Considering the heritage matter, they should also be transferable to specific people.
For these reasons I particularly stress on comfort and memory unreliability.
Also, given that security and its solutions can't be simple, I see no point in a complex system which pushes me to misbehave because the workflow is too uncomfortable and annoying. It doesn't matter how secure the system is.
On this topic check out this beautiful post. I copy here the interesting part in case it disappears:
The question
Let us say I have a volume encrypted under LUKS with a 512-bit key. That would mean there are 2 ^ 512 possible values which the key may be.
Now I need a passphrase which is at least as resistant to brute force as the actual 512-bit volume encryption key. Correct me if my assumptions below are wrong, all numeric values are used for mathematical example only:
Let's say my passphrase is generated by base64 encoding random input and therefore the keyspace for my passphrase is 64 characters. So in order for my passphrase to be at least as strong as the volume encryption key then there need to be at least 2 ^ 512 possible combinations within the length of the passphrase. This can be expressed as:
(size_of_keyspace) ^ number_of_characters >= 2 ^ (size_of_key)
So for this example of a volume key size of 512 and a passphrase keyspace of 64 then the minimum number of characters my passphrase should be in order to be at least as secure as the volume key would be 86.
Is this logic correct or is there some drawbacks I should be aware of? Any other recommendations which can be offered along the lines of this question?
My reasoning for this is that there is no inherent benefit of having a passphrase which is stronger than the actual payload key itself -- someone brute forcing my drive is ultimately trying to crack my encryption key, not my passphrase. If my passphrase is stronger than the encryption key then an attacker can brute force the encryption key faster than they can the passphrase. Is this correct or is there some benefit to having a passphrase which is stronger than the encryption key, maybe as a resource drain for an attacker who doesn't diversify their methods well enough?
The answer
In the context of security, everything is a trade off. More on that in a second....
What are the attack options for breaking into your encrypted volume? They are, basically:
Brute force search of the keyspace for the key utilized by the symmetric encryption primitive.
Brute force the passphrase by trying every possible password utilizing your volume's specific salt and key derivation parameters.
Evil maid, rubber hose, key logger, or other "non crypto" means of securing your keymat.
You should worry about number 3. Because its the obvious attack vector.
No one is going to succeed in brute forcing the key used for the block encryption primitive.
From a basic security perspective, I remain convinced that even 128 bit keys are fully secure if the implementation is not broken. A brute force search in that case has to exhaust on average half of a key space that has 340,282,366,920,938,463,463,374,607,431,768,211,456 possibilities.
For a 256 bit keyed primitive, you're talking about 115,792,089,237,316,195,423,570,985,008,687,907,853,269,984,665,640,564,039,457,584,007,913,129,639,936 possibilities.
So even with 256 bits of key security you're already reaching numbers that approach the number of atoms in the known universe.
So that's out.
What you're worried about is someone trying every possible pass phrase.
Now, remember that LUKS uses some salt + PBKDF2 to stretch your pass phrase to the size of the key space. What this means is that even a password of "a" can map to any possible spot in the entire key space. So attackers aren't going to have a rainbow table that will help here.
If they're going to brute force the pass phrase, they will have try all the possible inputs, running each through the key derivation function with the parameters used on your volume (salt & iterations). That takes time. And, if memory serves, LUKS actually sets the iterations to take a specific amount of time per "try."
What this means is that you simply need a pass phrase length that has enough entropy to make it unfeasible for an attacker to try a sufficient number of possible phrases to locate your phrase. The attacker can of course use GPUs or specialized ASIC hardware to speed this process up (its why folks are experimenting with things like Scrypt to make that harder), but you will be more than protected with 20 to 30 characters containing lowercase, uppercase, numbers and keyboard symbols (including symbols from shifted numbers and other symbols on the keyboard).
This brings me back to my initial comment. Its important to keep in mind the trade offs. You can try to come up with a pass phrase that is equivalent to the difficulty of your 512 bit key space, but it will IMPACT your behavior. You might find yourself not dismounting / logging off when you get up to get a cup of coffee because its such a pain to get that pass phrase right when its time to log back in. You might store the long pass phrase on a phone or piece of paper. If you store it in a password manager, you will be limited by the security of the password manager and not the security of the length of your pass phrase.
Meanwhile, once an attacker has to try 20 to 30 characters of pass phrase utilizing 93 possible characters, the attacker is facing (effectively) 95 to 150 bits of entropy which puts it outside of the reasonable range of brute force.
And, all of which leads back to that third possibility of getting into your volume. Compared to brute forcing the key to the encryption primitive or trying all the possible pass phrases, the third scenario "COMPROMISE" is really what you should be worrying about. An attacker that gets you to point a compromised web browser at an exploit that gives escalated privileges on your running system can scan the memory for your password. An attacker that gets a rootkit on your system can do the same. If you plug in a compromised USB or firewire device, you're potentially compromising security. And these are all much easier for the attacker than brute forcing the keyspace or pass phrase space.
Obviously there are many more threats than those described above: active attacks.
I only slightly mention some here:
| THREAT | MITIGATION |
|---|---|
| remote attacks are hard to identify and fight back | I delegate this to Qubes Os, frequent updates and compartmentalization. |
| online activity analysis shows user's real identity | I use multiple identities, Whonix Qubes AVM and TOR. |
| family and friends leaking information | I shut up. I don't carry on any sensitive activity at home. |
| camera control catching keystrokes | External keyboard with blank caps and customized keyboard layout |
Other threats I'm still working on:
| THREAT | MITIGATION |
|---|---|
| evil maid attack (snitch attack) | Qubes OS mitigates this but its implementation makes my life hard |
| face recognition | Until anonymity protects me, there should be no problem |
R.I.S.K.S. is designed with these additional goals:
- all the software in use must be open source
- passwords and secrets must be managed via terminal
- no database involved, everything must be stored in text files
User's tracking, profiling and, then, artificially intelligence are abused against internet users. This is a proven fact.
One mitigation for this scenario is to use multiple identities: tools isolation (like different browsers and different email clients), different internet connections and different human behavior among identities.
I compartmentalize my prismatic interests. I group my needs in isolated environments. Each group is represented by an ad-hoc digital identity which materializes in a set of qubes.
Metaphorically speaking it's like a company hiring a worker for a specific task: each worker is an identity. Each worker uses a tool-set: each tool-set is a qube-set. Each qube has a different trust-level accordingly to the tasks performed in that qube.
The multiple-identities approach gives several advantages:
- efficiency. I choose what I want to do and this defines which identity to use. Then I start just the qubes I need for the job. More focus and less distractions.
- less harmful type casting. For an adversary it's harder to profile me. For ex. Youtube suggestions or social platform ads totally differ among identities.
- minimalism. I keep my tool-set lean. This reduces the attack surface and I'm surprised of how little amount of software I need.
- freedom. It's hard to admit but being identifiable brings in biases and concerns like "I'm afraid to discuss this topic" or "am I exposing myself to unnecessary troubles?". Hiding gives freedom.
Multiple identities are very good as long as they are isolated.
When the isolation breaks the identities merge back to one person with name, surname and physical address. This can be a big deal.
Isolation can be broken in many ways but mainly because of (in order of importance):
- user's misbehavior
- internet activity analysis
- buggy software
- adversary's investigation
User's misbehavior is by far where most fall, even experienced ones. There is no absolute solution for this and the only mitigation is learning.
Freedom is really valuable and it's obviously targeted by many adversaries therefore protecting it takes a lot of efforts. There isn't any shortcut.
A good start for this long journey is Gary T. Marx's publications and, more specifically, his aged but not old essay on identity and anonymity
When I refer to identity I mean Marx's identity #4. Bad isolation degrades it to identity #3 or #2 and, finally, #1.
A secret is anything that none else than me should know. It could be anything: a file, a directory of files, a password, a passphrase, a crypto key ...
A secret is safe until is known by only one person. None or nothing else. Otherwise, in the best case, it becomes a partially compromised hidden information protected by something weak and hard to define called trust.
Trust is the enemy.
Ideally speaking I should trust nothing and none. Unfortunately this leads to sterile isolation which is a solution only to secrecy and nothing else.
Identities constantly produce secrets. Identity isolation increases the production of secrets even more. For instance the browsing history or the logs of each identity might be a valuable piece of information for an adversary.
I try to destroy secrets as much as I can. Secrets are best protected in human memory but it's faulty and this is not always a bad thing but sooner or later something must be protected from its unreliability: there I have a file.
Of course there is data that can't even be stored in memory like a picture, a video or a song. There I have files again.
Once a file is written on a digital memory, I delegate secrecy to my device and its operating system. This requires trusting the system.
Then the question is: how to have a trustworthy digital device?
My answer is: R.I.S.K.S.
Losing control over credentials leads to a total disaster. The gravity of the situation depends on many factors but it's always bad.
Reusing credentials or passwords is always a horrible idea. It doesn't just weaken the security of the system it also represents a privacy threat: identical passwords can be used to spot the user's real identity.
The root of credentials reuse is the fact that the user relies on memory but in my experience the chances of forgetting credentials are several orders of magnitude higher than being hacked, attacked or victim of a theft.
Credentials reuse also leads to short passwords which means weak password that can be easily guessed via brute force.
The only real solution in protecting credentials is to use a credential-manager which generates random passwords and provides a convenient way to store, retrieve and update credentials.
R.I.S.K.S. uses a combination of pass and mpw to provide credentials management.
Passphrases are crucial. The advent of crypto-currency makes them even more important.
Passphrases can be guessed by using brute force so, if every possible password is tried, sooner or later the right one will be found. The question is: Will that be too soon . . . or enough later?
This article explains how Ben Oliver succeeded in brute forcing his own GPG passphrase.
Good passphrases are absolutely mandatory but hard to remember passphrases are even worse than weak ones because they lead to passphrase loss.
In my experience the chances of forgetting a passphrase are several orders of magnitude higher than being hacked, attacked or victim of a theft.
A good tool for producing a passphrase is diceware. This is the technique I use.
Six word passphrases or longer are advised, something like:
cleft cam synod lacy yr wok