[dm-crypt] Detecting the use of a keyfile
sector9 at ftml.net
sector9 at ftml.net
Thu May 23 17:21:44 CEST 2013
Appreciate the response. Yes that is correct. I am asking about the
plausibility of denying one's access to an encrypted volume because the
keyfile is lost when there is no keyfile in actuality.
Legal factors aside (i.e. burden of proof of security level and absence
of backups) why is this a losing strategy?
Could a forensic analysis or otherwise prove the false claim one is
making about the absence of a non-existent keyfile? You seemed to have
answered this by indicating the initrd or init-script giving away the
presence or non-presence of a keyfile. To mitigate this one could place
the boot partition on a USB and claim that it is lost. Now, without
access to the initrd or init-scripts what does that mean for attempts to
detecting the use of a keyfile?
On Thu, May 23, 2013, at 16:55, Arno Wagner wrote:
> On Thu, May 23, 2013 at 03:27:25PM +0200, sector9 at ftml.net wrote:
> > During the boot stage is it possible for an attacker with physical
> > access to detect if a keyfile is used to unlock an encrypted volume?
> Yes, very easily. Just look at the initrd or init-script that does it.
> Booting with a USB/CD Linux (e.g. Knoppix) makes this easy, including
> the test whether the keyfile is valid.
> > Does it yield to protest that the keyfile is lost/unknown/destroyed when
> > in reality there is no keyfile but instead a regular non-keyfile
> > passphrase?
> Aehm, what are you asking? Whether you could lie about the former
> presence of a keyfile and claim the data is now inacessible due
> to its absence? That depends very much so how much technological
> knowledge those have that should believe it and what mechnism for
> its loss or destruction you propose. Also, keyfiles are not
> secure, so you would have to justify the low securuity level and
> the absebce of backups as well.
> Generally, I would call it a losing strategy.
> Arno Wagner, Dr. sc. techn., Dipl. Inform., Email:
> arno at wagner.name
> GnuPG: ID: CB5D9718 FP: 12D6 C03B 1B30 33BB 13CF B774 E35C 5FA1 CB5D
> There are two ways of constructing a software design: One way is to make
> so simple that there are obviously no deficiencies, and the other way is
> make it so complicated that there are no obvious deficiencies. The first
> method is far more difficult. --Tony Hoare
> dm-crypt mailing list
> dm-crypt at saout.de
More information about the dm-crypt