* [dm-crypt] Detecting the use of a keyfile @ 2013-05-23 13:27 sector9 2013-05-23 14:55 ` Arno Wagner 0 siblings, 1 reply; 6+ messages in thread From: sector9 @ 2013-05-23 13:27 UTC (permalink / raw) To: dm-crypt 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? 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? ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [dm-crypt] Detecting the use of a keyfile 2013-05-23 13:27 [dm-crypt] Detecting the use of a keyfile sector9 @ 2013-05-23 14:55 ` Arno Wagner 2013-05-23 15:21 ` sector9 0 siblings, 1 reply; 6+ messages in thread From: Arno Wagner @ 2013-05-23 14:55 UTC (permalink / raw) To: dm-crypt On Thu, May 23, 2013 at 03:27:25PM +0200, sector9@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 -- Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: arno@wagner.name GnuPG: ID: CB5D9718 FP: 12D6 C03B 1B30 33BB 13CF B774 E35C 5FA1 CB5D 9718 ---- There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult. --Tony Hoare ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [dm-crypt] Detecting the use of a keyfile 2013-05-23 14:55 ` Arno Wagner @ 2013-05-23 15:21 ` sector9 2013-05-23 15:40 ` Arno Wagner 0 siblings, 1 reply; 6+ messages in thread From: sector9 @ 2013-05-23 15:21 UTC (permalink / raw) To: dm-crypt 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@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 > -- > Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: > arno@wagner.name > GnuPG: ID: CB5D9718 FP: 12D6 C03B 1B30 33BB 13CF B774 E35C 5FA1 CB5D > 9718 > ---- > There are two ways of constructing a software design: One way is to make > it > so simple that there are obviously no deficiencies, and the other way is > to > 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@saout.de > http://www.saout.de/mailman/listinfo/dm-crypt ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [dm-crypt] Detecting the use of a keyfile 2013-05-23 15:21 ` sector9 @ 2013-05-23 15:40 ` Arno Wagner 2013-05-23 17:13 ` sector9 0 siblings, 1 reply; 6+ messages in thread From: Arno Wagner @ 2013-05-23 15:40 UTC (permalink / raw) To: dm-crypt On Thu, May 23, 2013 at 05:21:44PM +0200, sector9@ftml.net wrote: > 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? I think it is just too implausible, also because not using a keyfile is the standard mode. Unless you have scripts in place that make interactive passphrase entry impossible or very hard, the explanation just does not hold water. If, on the other hand, you need to change something actively to make the secnario plausible, just wipe th LUKS header and keyslot-area instead. > Could a forensic analysis or otherwise prove the false claim one is > making about the absence of a non-existent keyfile? As soon as you make any mistake in your explanation, yes. You may also remember that directory entries are only marked invalid, not overwritten on most causes that could cause loss of a keyfile. The blocks may not be referenced anymore, but the filename should be present somewhere. Also, mounting of partition goes into system logs and may be recorded in some fashion in other places. If you claim to have lost access, but your logs show you do not, that would be pretty bad. > You seemed to have > answered this by indicating the initrd or init-script giving away the > presence or non-presence of a keyfile. They give away a call to cryptsetup using or not using a keyfile. > To mitigate this one could place the boot partition on a USB and > claim that it is lost. That claim must then stand up to a search, and depending on your justisdiction, possibly to significant intimidation. > Now, without > access to the initrd or init-scripts what does that mean for attempts to > detecting the use of a keyfile? In that case showing the use of a keyfile is impossible. However your boot-process is broken as well. You could maybe come up with something like claiming to have this alternate boot process on stick that also miounts the encrypted partition, wehile the normal one does not. However leaving traces that indicate this is untrue is very easy. Also don't place to much faith in your ability to explain things to people that can demand encryption keys. They just may demand them anyways, ignore (or not understand) your explanations and just do bad things to you. http://xkcd.com/538/ very much applies. It is a also easy to place you in a situation where suddently you have give evidence to defend yourself and some bad thing about you is otherwise sufficiently shown to do bad things to you. Arno > On Thu, May 23, 2013, at 16:55, Arno Wagner wrote: > > On Thu, May 23, 2013 at 03:27:25PM +0200, sector9@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 > > -- > > Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: > > arno@wagner.name > > GnuPG: ID: CB5D9718 FP: 12D6 C03B 1B30 33BB 13CF B774 E35C 5FA1 CB5D > > 9718 > > ---- > > There are two ways of constructing a software design: One way is to make > > it > > so simple that there are obviously no deficiencies, and the other way is > > to > > 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@saout.de > > http://www.saout.de/mailman/listinfo/dm-crypt > _______________________________________________ > dm-crypt mailing list > dm-crypt@saout.de > http://www.saout.de/mailman/listinfo/dm-crypt -- Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: arno@wagner.name GnuPG: ID: CB5D9718 FP: 12D6 C03B 1B30 33BB 13CF B774 E35C 5FA1 CB5D 9718 ---- There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult. --Tony Hoare ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [dm-crypt] Detecting the use of a keyfile 2013-05-23 15:40 ` Arno Wagner @ 2013-05-23 17:13 ` sector9 2013-05-23 17:36 ` Arno Wagner 0 siblings, 1 reply; 6+ messages in thread From: sector9 @ 2013-05-23 17:13 UTC (permalink / raw) To: dm-crypt Understood. The problematic nature of claiming plausible deniability with regard to a lost non-existent keyfile comes down to extralegal practices and testimony on behalf of the user. On the technical side, if done properly, one could place the boot partition on a separate USB and claim it is lost along with the keyfile. This setup would allow one to perfectly conceal whether or not one is using a keyfile and therefore provide plausible deniability about access to an encrypted system. The good old xkcd depiction of the reality of rubberhose cryptanalysis is so eloquent in its simplicity. Yet we explore sidechannel attacks, social engineering, etc to bolster the use of the strong crypto ciphers. This variety of defense that I was inquiring about is another possibility to explore. I appreciate your answers very much. On Thu, May 23, 2013, at 17:40, Arno Wagner wrote: > On Thu, May 23, 2013 at 05:21:44PM +0200, sector9@ftml.net wrote: > > 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? > > I think it is just too implausible, also because not using a keyfile is > the standard mode. Unless you have scripts in place that make interactive > passphrase entry impossible or very hard, the explanation just does > not hold water. If, on the other hand, you need to change something > actively to make the secnario plausible, just wipe th LUKS header and > keyslot-area instead. > > > Could a forensic analysis or otherwise prove the false claim one is > > making about the absence of a non-existent keyfile? > > As soon as you make any mistake in your explanation, yes. You may also > remember that directory entries are only marked invalid, not overwritten > on most causes that could cause loss of a keyfile. The blocks may not be > referenced anymore, but the filename should be present somewhere. > > Also, mounting of partition goes into system logs and may be recorded > in some fashion in other places. If you claim to have lost access, but > your logs show you do not, that would be pretty bad. > > > You seemed to have > > answered this by indicating the initrd or init-script giving away the > > presence or non-presence of a keyfile. > > They give away a call to cryptsetup using or not using a keyfile. > > > To mitigate this one could place the boot partition on a USB and > > claim that it is lost. > > That claim must then stand up to a search, and depending on your > justisdiction, possibly to significant intimidation. > > > Now, without > > access to the initrd or init-scripts what does that mean for attempts to > > detecting the use of a keyfile? > > In that case showing the use of a keyfile is impossible. However your > boot-process is broken as well. You could maybe come up with something > like claiming to have this alternate boot process on stick that also > miounts the encrypted partition, wehile the normal one does not. > However leaving traces that indicate this is untrue is very easy. > > Also don't place to much faith in your ability to explain things to > people that can demand encryption keys. They just may demand them > anyways, ignore (or not understand) your explanations and just do > bad things to you. http://xkcd.com/538/ very much applies. It is a > also easy to place you in a situation where suddently you have > give evidence to defend yourself and some bad thing about you > is otherwise sufficiently shown to do bad things to you. > > > Arno > > > > > On Thu, May 23, 2013, at 16:55, Arno Wagner wrote: > > > On Thu, May 23, 2013 at 03:27:25PM +0200, sector9@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 > > > -- > > > Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: > > > arno@wagner.name > > > GnuPG: ID: CB5D9718 FP: 12D6 C03B 1B30 33BB 13CF B774 E35C 5FA1 CB5D > > > 9718 > > > ---- > > > There are two ways of constructing a software design: One way is to make > > > it > > > so simple that there are obviously no deficiencies, and the other way is > > > to > > > 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@saout.de > > > http://www.saout.de/mailman/listinfo/dm-crypt > > _______________________________________________ > > dm-crypt mailing list > > dm-crypt@saout.de > > http://www.saout.de/mailman/listinfo/dm-crypt > > -- > Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: > arno@wagner.name > GnuPG: ID: CB5D9718 FP: 12D6 C03B 1B30 33BB 13CF B774 E35C 5FA1 CB5D > 9718 > ---- > There are two ways of constructing a software design: One way is to make > it > so simple that there are obviously no deficiencies, and the other way is > to > 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@saout.de > http://www.saout.de/mailman/listinfo/dm-crypt ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [dm-crypt] Detecting the use of a keyfile 2013-05-23 17:13 ` sector9 @ 2013-05-23 17:36 ` Arno Wagner 0 siblings, 0 replies; 6+ messages in thread From: Arno Wagner @ 2013-05-23 17:36 UTC (permalink / raw) To: dm-crypt On Thu, May 23, 2013 at 07:13:03PM +0200, sector9@ftml.net wrote: > Understood. The problematic nature of claiming plausible deniability > with regard to a lost non-existent keyfile comes down to extralegal > practices and testimony on behalf of the user. Indeed. Or legal practices where the police or prosecution has a lot of leeway and when they think you are "difficult" they can bring the hammer down. Completely unethical of course, but entirely legal. Remember that any form of authorities traditionally had the purpose to make the subjects do what the ruling class wanted, typically by threat of force. Laws were not about what is right, but about what behaviours were undesired by those in power. This still shows and by my impression some western countries are again strongly going in that direction, e.g. by calling people "terrorists" more and more frequently to take the rights away they would have had as mere murderers. > On the technical side, if done properly, one could place the boot > partition on a separate USB and claim it is lost along with the keyfile. > This setup would allow one to perfectly conceal whether or not one is > using a keyfile and therefore provide plausible deniability about access > to an encrypted system. > > The good old xkcd depiction of the reality of rubberhose cryptanalysis > is so eloquent in its simplicity. Indeed. The message could not be clearer. Some XKCDs are prue genius. > Yet we explore sidechannel attacks, > social engineering, etc to bolster the use of the strong crypto ciphers. > This variety of defense that I was inquiring about is another > possibility to explore. > > I appreciate your answers very much. You are very welcome. It is a discussion that needs revisiting from time to time as things change. And there is a lot of change currently. Arno -- Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: arno@wagner.name GnuPG: ID: CB5D9718 FP: 12D6 C03B 1B30 33BB 13CF B774 E35C 5FA1 CB5D 9718 ---- There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult. --Tony Hoare ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2013-05-23 17:36 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2013-05-23 13:27 [dm-crypt] Detecting the use of a keyfile sector9 2013-05-23 14:55 ` Arno Wagner 2013-05-23 15:21 ` sector9 2013-05-23 15:40 ` Arno Wagner 2013-05-23 17:13 ` sector9 2013-05-23 17:36 ` Arno Wagner
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.