Re: Keyfile Support for GRUBs LUKS

[Glenn Washburn]

On Wed, 20 Nov 2013 08:36:40 +0100
Vladimir 'φ-coder/phcoder' Serbinenko <address@hidden> wrote:

> On 20.11.2013 08:02, Glenn Washburn wrote:
> > On Wed, 20 Nov 2013 06:48:40 +0100
> > Vladimir 'φ-coder/phcoder' Serbinenko <address@hidden> wrote:
> > 
> >> On 20.11.2013 06:43, Glenn Washburn wrote:
> >>> Modifying the cipher text just
> >>> manifests as random data corruption of the plain text device,
> >>> again not a security issue and nothing that signatures would
> >>> prevent.
> >> It's a security threat. Imagine you have somewhere a routine which
> >> verifies SSH-key when connecting by network. Replace it with random
> >> data. With some significant probability this decodes to valid
> >> opcodes but which do no check. Now everyone can use your SSH.
> >> encryption provides secrecy. Signatures provide verification. Using
> >> one to achieve the other will always fail.
> >>
> > 
> > Let me see if I understand you.  Suppose an attacker can modify the
> > LUKS containers cipher text and happens to know the exact block
> > which contains the routine for verifying the ssh key.
> This is determenistic.

Are you suggesting that given a LUKS partition and no key material, it
is a deterministic process to determine where the kernel is?  Say you
steal my laptop.  Remember you can't actually read the kernel to boot
because you can't decrypt the LUKS device.

> >  The attacker then
> > writes some data to that block, which will then manifest as random
> > bytes once unencrypted.
> > 
> > You're claiming that there's a more than insignificant probability
> > that this could cause the verification to not happen?  And thus for
> > anyone to be able to log into the system via ssh?  I hope you're not
> > suggesting that because it would be ludicrously improbable (try
> > executing data from /dev/random and see how far you get).
> It's not as low as you claim. You change only 16 bytes. And you don't
> need the resulting code to be doing anything useful, just not crash.
> In CBC modes this attack is even somewhat easier.
> Read http://www.cs.berkeley.edu/~daw/teaching/cs261-f12/misc/if.html

Very interesting reference.  However, luckily, we don't have that
situation.  It would be highly improbable that an attacker can do
cipher text modification and then see the results of that (even more
improbable that it would be repeatable).

> > Also, if this kind of threat were worth considering, why doesn't
> > LUKS address this?  It would seem fairly easy (add some HMACs in
> > the blocks).
> It's not that easy. Trouble is that you need to also prevent
> inconsistent rollback and for this you need to have a hash tree. Then
> since power failure is a possibility you need this tree to be
> consistent at every moment. Those issues are a bit easier to handle
> on FS level. ZFS supports HMACs. BtrFS perhaps will one day.
> 

Why do you need rollbacks?  That would seem to imply versioned block
data.

Thanks for the insightful response.

signature.asc
Description: PGP signature