From: Arno Wagner <arno@wagner.name>
To: dm-crypt@saout.de
Subject: Re: [dm-crypt] Passphrase protected key file?
Date: Thu, 14 Jul 2011 21:27:52 +0200 [thread overview]
Message-ID: <20110714192752.GA2191@tansi.org> (raw)
In-Reply-To: <4E1EF95D.40406@web.de>
On Thu, Jul 14, 2011 at 04:12:45PM +0200, Heiko Rosemann wrote:
> On 07/14/2011 03:35 PM, Arno Wagner wrote:
> > On Thu, Jul 14, 2011 at 01:55:50PM +0200, Ma Begaj wrote:
> >>> Also note that an attacker that has access to the storage could
> >>> patch your GnuPG binary or other system components.
> >>
> >> well that is an another story because an attacker could in that
> >> case patch cryptsetup too. if s/he can do that it is not important
> >> whether you use encrypted key file on usb stick or directly
> >> cryptsetup.
> >
> > Indeed. But are there any realistic scenarios where
> >
> > a) a passphrase is signifiacntly less secure than an encrypted
> > passphrase stored on USB with a second pasphrase to decrypt that
> >
> > and
> >
> > b) the attacker does not have the possibility to patch
> > GnuPG/cryptup/other things that make the second passphrase just as
> > weak as the first one?
> >
> > My claim is that a realistic risk analysis will show there are no
> > such scenarios that are typical and hence having an encrypted
> > passphrase on an USB stick does not offer improved security.
>
> Improved security over which other setup?
>
> a) Unencrypted passphrase stored on a USB key. Here the second
> encryption step will probably give additional security in case the user
> looses the USB key.
And the default situation does not have an USB key. So a net
security loss.
> b) Directly entering passphrase without the need of a USB key. Here we
> have a typical risk of users using the same passphrase for different
> things or even of writing it down (on a post-it note on the screen or
> keyboard...). If we depend upon a USB stick with the real passphrase
> (encrypted by the one on the post-it note) being present at boot the
> attacker won't be able to utilize that passphrase.
If we have stupid users, they will just tape the USB key to the
monitor besides the post-it. Or put it on a pice of string.
Then passphrase reuse will have the original risks, no improvement
by USB key usage.
If they are not stupid, they will have different passphrases
and not post-it to the screen.
> If we move kernel+initrd+cryptsetup to the USB stick and boot the
> machine from USB, we can even encrypt the entire harddisk, thus even
> someone with physical access to the machine cannot patch cryptsetup/gnupg.
Leaveing the scenario there. In this scenario we can use the
conventional passphrase input mechnism without any loss of
security. no need for an encrypted passphrase on the USB key.
> Now it only boils down to whether a user writing down his passphrase
> will remember to remove the USB key ;)
Indeed.
> Regards, Heiko
>
> P.S: Thinking of law enforcement as the attacker (guess that is not that
> a great risk for most of us), it is possible to destroy all access to
> your data by destroying all the USB keys with the encrypted passphrase
> on them - and then you can even tell them your passphrase...
You an do that with LUKS, just overwrite the slots you are using
with random passphrases. The question is what is easier. My guess
would be that fast destruction of USB keys is not that easy.
Not wanting to be obstinate here (but I have a lot experience
with risk evaluation), the main risk I see is that the USB-key
scheme is more complex and exposes you to a higher risk of data
loss as a consequence. I still do not see any advantage to
having a separetely encrypted passphrase in a disk file.
I do see advantages to the kernel+initrd+cryptsetup on USB
option. That would indeed help against some attacks.
Arno
--
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@wagner.name
GnuPG: ID: 1E25338F FP: 0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 338F
----
Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans
If it's in the news, don't worry about it. The very definition of
"news" is "something that hardly ever happens." -- Bruce Schneier
next prev parent reply other threads:[~2011-07-14 19:27 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-11 22:17 [dm-crypt] Passphrase protected key file? Laurence Darby
2011-07-12 11:40 ` Jorge Fábregas
2011-07-12 12:47 ` Arno Wagner
2011-07-14 9:10 ` Ma Begaj
2011-07-14 11:04 ` Arno Wagner
2011-07-14 11:55 ` Ma Begaj
2011-07-14 13:35 ` Arno Wagner
2011-07-14 14:12 ` Heiko Rosemann
2011-07-14 14:46 ` [dm-crypt] Status of trim for SSds? André Gall
2011-07-14 15:55 ` Milan Broz
2011-07-14 16:04 ` Christoph Anton Mitterer
2011-07-14 16:39 ` Philipp Wendler
2011-07-14 16:52 ` Milan Broz
2011-07-14 17:14 ` Philipp Wendler
2011-07-15 13:59 ` Christian Hesse
2011-07-15 14:48 ` Milan Broz
2011-07-18 8:45 ` Christian Hesse
2011-07-18 10:04 ` Milan Broz
2011-07-18 10:16 ` Christian Hesse
2011-07-21 12:55 ` Christian Hesse
2011-07-24 17:18 ` MkFly
2011-07-24 18:34 ` Milan Broz
2011-07-14 19:27 ` Arno Wagner [this message]
2011-07-14 21:21 ` [dm-crypt] Passphrase protected key file? Heiko Rosemann
2011-07-14 21:44 ` Arno Wagner
2011-07-15 5:33 ` Iggy
2011-08-03 12:09 ` Laurence Darby
2011-08-03 13:41 ` Arno Wagner
2011-08-03 11:35 ` Laurence Darby
2011-08-03 13:45 ` Arno Wagner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20110714192752.GA2191@tansi.org \
--to=arno@wagner.name \
--cc=dm-crypt@saout.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox