Re: Keyfile Support for GRUBs LUKS

["Vladimir 'φ-coder/phcoder' Serbinenko" <phcoder@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2205 bytes --]

On 20.11.2013 08:02, Glenn Washburn wrote:
> On Wed, 20 Nov 2013 06:48:40 +0100
> Vladimir 'φ-coder/phcoder' Serbinenko <phcoder@gmail.com> 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.
>  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
> 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.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 291 bytes --]