On Wed, Jan 23, 2013 at 4:20 AM, Kasatkin, Dmitry <dmitry.kasatkin@xxxxxxxxx> wrote: > On Wed, Jan 23, 2013 at 8:09 AM, Will Drewry <redpig@xxxxxxxxxxxxx> wrote: >> On Tue, Jan 22, 2013 at 5:29 PM, Mikulas Patocka <mpatocka@xxxxxxxxxx> wrote: >>> On Fri, 18 Jan 2013, Kasatkin, Dmitry wrote: >>>> Hi Mikulas, >>>> >>>> Thanks for looking into it. >>>> >>>> On Thu, Jan 17, 2013 at 6:54 AM, Mikulas Patocka <mpatocka@xxxxxxxxxx> wrote: [snip] >>> Can the attacker modify the partition with hashes? - or do you store it in >>> another place that is supposed to be secure? >> >> Given that HMACs are being used to authenticate blocks, I'd assume, >> until corrected, that the HMACs aren't required to be on secure >> storage. To that end, it seems like there is a distinct risk that an >> attacker could use old data blocks and old HMACs to construct an >> "authentic" dm-integrity target that doesn't match anything the >> user/TPM ever saw in aggregate before. Perhaps I missed something >> when I skimmed the code, but it doesn't seem trivial to version the >> data or bind them to a large enough group of adjacent blocks without >> paying more computational costs (like using a Merkle tree with an >> HMAC'd root node). Technically, all the blocks would still be >> authentic, but the ordering in time and space wouldn't be. I'd love to >> know what ideas you have for that, or if that sort of attack is out of >> scope? For ordering in space, inclusion of the sector index in the >> HMAC might help. >> > > Hello, > > Yes. You are right. All is about computational and IO costs. > "In time" is really hard to manage. The key is the same and there is a > possibility to > replace the blocks with older block. > > But this is a case with encryption as well. right? I'm not a crypto-expert, but it all depends on if blocks are interrelated in any way (and thus the algorithm and configuration). Of course, encryption and integrity are often separate for a reason :) The 'in time' problem is tricky, but I guess this is a good reason to extend dm-verity to also have a kernel-supported write mode. It could be used as an alternative to the hmac'd block approach (with a TPM/whatever-signed root hash) to achieve both in-time and in-space resilience. Of course, the user would need to decide on the cost then -- more I/O+CPU versus their risk tolerance. > "in space" - it is easier. As you said sector index might be used like > with encryption. > Please have a look to dm_int_calc_hmac(). It uses already offset in > calculations.. > > err = crypto_shash_init(&desc.shash); > if (!err) > err = crypto_shash_update(&desc.shash, digest, size); > if (!err) > err = crypto_shash_finup(&desc.shash, (u8 *)&offset, > sizeof(offset), hmac); Nice - I misread that! At least that keeps replays pinned to the same block index for direct replays. cheers! will -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
