Re: Disk/Partition level encryption.

From: Pawel Jakub Dawidek (pjd_at_FreeBSD.org)
Date: 03/31/05 

Date: Wed, 30 Mar 2005 22:09:04 +0000 (UTC)

Tom St Denis <tomstdenis@gmail.com> wrote:
> And why must the IV be publicly available? What if each sector
> contained
>
> |start bits|sector_number|IV|writecount|MAC|data|stop_bits|
>
> Where MAC is GMAC(IV,writecount,data) [from GCM]. The write count
> would increment on each write. The "data" would be the only user
> visible part of the sector. So say somehow you disable the crypto
> engine and move a sector, well you're only moving the data. The MAC
> won't match.

This is not practical for two reasons:
1. To increase writecount you first must read it and it costs at lot.
2. This gives you sector size < 512 and probably not power of 2.
   You have to be very lucky to find file system which can work on
   not-power-of-2 sectors.

I'm trying to find a way which doesn't cost any additional I/O operations
and doesn't change device sector size.
In addition, when I get request to write one sector, I want to encrypt the
data and write exactly one sector. If it involves more I/O operation (more
sectors to write) we can run is nasty races (I assume that one sector
write operation is atomic).

I don't really care about data integrity checking - if an attacker cannot
put any sensible (after decrypting) data, file system is going to detect
it. The worst scenario is kernel panic, but that's ok.

My current thinking is as follows:

I've a key from the user (KUSER).
I create two random keys (KDATA, KIV), encrypt those key with KUSER and
store on my device.

Now, when I want to write a sector I do, eg.:

        iv = sha256(sector_number+KIV)
        encdata = encrypt(aes256-cbc, KDATA, iv, data)
        write(sector_number, encdata)

Does it makes sense? 

-- 
Pawel Jakub Dawidek                       http://www.wheel.pl
pjd@FreeBSD.org                           http://www.FreeBSD.org
FreeBSD committer                         Am I Evil? Yes, I Am!

Relevant Pages

  • Re: PROBLEM: AES cryptoloop corruption under recent -mm kernels
    ... If bytes 0...511 represent the 512 bytes of sector, then on encrypt IV is ... Because file backed loops don't scale well to multiple simultaneous ... If some file system code, ...
    (Linux-Kernel)
  • Re: Encrypted slice with geli
    ... I was thinking of makeing a slice encrypted with geli. ... It only uses the last sector to store the metadata. ... because it will also encrypt sectors ...
    (freebsd-questions)
  • Re: Help secure my data (They will steal my drive)
    ... I tested the soft, i verified that all sector were encrypted, and this was ... The soft encrypt all sectors with a diffirent IV for ... long when you encrypt the disk the first time but after it's very fast, ... Be carefull if you don't use an US keyboard because when you boot the PC, ...
    (sci.crypt)
  • Re: Disk/Partition level encryption.
    ... > The idea is to encrypt each sector with a tweakable block cipher. ... It to has a GF multiplier but only requires the ... a per write MAC tag ...
    (sci.crypt)
  • BestCrypt - Major Security Flaw Found
    ... to encrypt each sector, which enables an attacker in some ...
    (sci.crypt)
Quantcast