Re: [Tails-dev] Adding KeepassX to Tails Startup; can it be …

Delete this message

Reply to this message
Author: Andrew Gallagher
Date:  
To: tails-dev
Subject: Re: [Tails-dev] Adding KeepassX to Tails Startup; can it be done!
On 29/02/16 18:26, madx@??? wrote:
>
> Another bigger issue that should be considered is: Implementing a
> failsafe mechanism that wipes the persistent drive if a number of failed
> attempts are made.
>
> I really think that type of protection is needed. Say after 5 failed
> attempts it locks a user for an hour and after 8 failed attempts it
> wipes the drive totally.


The simple answer to this is: it can't be done.

In order to enforce a policy like that you must have a process running
either in software or firmware - but an adversary is not limited to
cracking your encryption using a computer that you control. If they
wanted to crack a Tails partition, they would not do it by first booting
into Tails! They would copy an image of the encrypted disk onto their
own cracking hardware, where processor speed is the only limit on how
many decryption attempts they can make.

The reason that retry limits can be enforced on an iPhone is because the
enemy needs the built-in security coprocessor to generate part of the
disk decryption key, and it can refuse to cooperate. But all this does
is prevent them from converting PINs into keys - they could desolder the
flash chip from the baseboard and brute force the full key just as
easily as with any other encrypted storage.

In both cases, the attacker is defeated by the strength of the full
encryption key. Retry limiting only prevents them from using the
user-friendly shortcuts in embedded firmware such as security
coprocessors or smart cards. Pure software (such as Tails) cannot
enforce anything, because general-purpose hardware cannot be compelled
to obey it.

All is not lost though. If you want to implement retry-limited PIN-based
encryption *in*firmware*, PGP smartcards are your friend. You would keep
the symmetric encryption key in pubkey-encrypted form and use the
smartcard to unlock it at boot time instead of calculating it through
password hashing. This means you can take advantage of the physical
security measures (including retry limiting) of the smartcard.

Luckily, other people have already done the hard work for you...!
http://digitalbrains.com/2014/gpgcryptroot

Just remember that the symmetric encryption key will always be
brute-forceable in principle, and a hashed-passphrase symmetric key can
be made to approach the strength of a random one arbitrarily closely if
you're thorough enough. All that the above tricks will gain you is
convenience.

A