[dm-crypt] using a salt for encrypting blocks

[dm-crypt] using a salt for encrypting blocks

[octane indice]

Hello

I'm working with dm-crypt.
Basically, we have a key, which I call Master key, which is used to cipher
blocks (or sectors).
This master key is wrapped with another keys, the 8 slots, this is not the
point here.

Each block is then ciphered. the cipher mode is CBC, and each block has a
different IV. Today, the ESSIV is used, which means that the IV is derived
by the sector number and a hash of the master key. I'm OK with that.

So, this means that the same block of the same plaintext is ciphered the
same way. So if a file is unchanged, then the ciphered is unchanged.

Which means that an attacker could track the change of the ciphered blocks
and gain some (very little) knowledge, as the size of the document being
added to a encrypted partition.

My question is: can we avoid this? The answer is yes, we just have to use a
salt.
For example, for 512byte blocks, we could use 16bytes of salt for each block.

Which means that one block each 32 blocks stores the salt of the other
blocks. This way, it's possible to update all blocks and cipher them. Same
data, cipher is different.
I think we could have 
-performance issue, 
-decrease the size of 'usable' part of disk, 3% is used to store the salt,
which is acceptable.

but an attacker wouldn't be able to gain any information!

Any advice on that, or a reason why the salt is not used for encrypting blocks?

thanks

Envoyé avec Inmano, ma messagerie renversante et gratuite : http://www.inmano.com

Re: [dm-crypt] using a salt for encrypting blocks

[Arno Wagner]

On Mon, Dec 27, 2010 at 05:10:12PM +0100, octane indice wrote:
> Hello
> 
> I'm working with dm-crypt.
> Basically, we have a key, which I call Master key, which is used to cipher
> blocks (or sectors).
> This master key is wrapped with another keys, the 8 slots, this is not the
> point here.
> 
> Each block is then ciphered. the cipher mode is CBC, and each block has a
> different IV. Today, the ESSIV is used, which means that the IV is derived
> by the sector number and a hash of the master key. I'm OK with that.
> 
> So, this means that the same block of the same plaintext is ciphered the
> same way. So if a file is unchanged, then the ciphered is unchanged.
> 
> Which means that an attacker could track the change of the ciphered blocks
> and gain some (very little) knowledge, as the size of the document being
> added to a encrypted partition.
> 
> My question is: can we avoid this? The answer is yes, we just have to use a
> salt.
> For example, for 512byte blocks, we could use 16bytes of salt for each block.

The anzwer is actually no. As changed information has to be 
written to diek, an attacker can allways tell when a sector 
is changed. This is a fundamental limitation of filesystem
encryption. The only way around would be to write far more
on each update, with the expected catastrophic impact on 
performance.

> Which means that one block each 32 blocks stores the salt of the other
> blocks. This way, it's possible to update all blocks and cipher them. Same
> data, cipher is different.
> I think we could have 
> -performance issue, 
> -decrease the size of 'usable' part of disk, 3% is used to store the salt,
> which is acceptable.
> 
> but an attacker wouldn't be able to gain any information!

Wrong. The attacker could still detect the changed blocks.
 
> Any advice on that, or a reason why the salt is not used for 
> encrypting blocks?

Because it does not help at all. Salts only help as defense
against rainbow tables.

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 

Re: [dm-crypt] using a salt for encrypting blocks

[octane indice]

En réponse à Arno Wagner <arno@wagner.name> :
> The anzwer is actually no. As changed information has to be 
> written to diek, an attacker can allways tell when a sector 
> is changed.

My idea is to cipher _all_ blocks by changing the salt.

> This is a fundamental limitation of filesystem
> encryption. The only way around would be to write far more
> on each update,

yes

> with the expected catastrophic impact on 
> performance.
>
not so much, depending on how much data you cipher.
I use files of less than 100Mbytes and cipher them. On
close, a full recipher wouldn't take long.
 
> > but an attacker wouldn't be able to gain any information!
> 
> Wrong. The attacker could still detect the changed blocks.
>
not if I change all of them.
  
> > Any advice on that, or a reason why the salt is not used for
> > encrypting blocks?
> 
> Because it does not help at all. Salts only help as defense
> against rainbow tables.
> 
In this situation it helps in order to change the ciphered version even if
we don't change the clear.
-We could change the master key: impossible in practice.
-We could change the IV: I don't see how.
Plus, both options can't afford a break (as of power loss) in the
reciphering: which key would be used after?

If we use a salt, we can always decipher, even if a break occurs while
reciphering; at last, only one block could be unreadable.

thanks
> _______________________________________________









Envoyé avec Inmano, ma messagerie renversante et gratuite : http://www.inmano.com

Re: [dm-crypt] using a salt for encrypting blocks

[Milan Broz]

On 12/28/2010 09:29 AM, octane indice wrote:
> En réponse à Arno Wagner <arno@wagner.name> :
>> The anzwer is actually no. As changed information has to be 
>> written to diek, an attacker can allways tell when a sector 
>> is changed.
> 
> My idea is to cipher _all_ blocks by changing the salt.

You forgot one fundamental thing.

If an attacker can do snapshots in time (IOW he can read the cipher
text device after user performed some changes) he has either
physical access to the system or he has administrator permissions.

This allows more powerfull attacks already (installing keylogger,
modifying kernel, bios, ...).

If an attacker has such access nothing will help you.
The chain is weaker somewhere else here.

> not so much, depending on how much data you cipher.
> I use files of less than 100Mbytes and cipher them. On
> close, a full recipher wouldn't take long.

Then use encryption on filesystem level (e.g. with CTR mode, iow
stream mode) and not sector level block device encryption.

Milan

Re: [dm-crypt] using a salt for encrypting blocks

[octane indice]

En réponse à Milan Broz <mbroz@redhat.com> :
> > My idea is to cipher _all_ blocks by changing the salt.
> 
> You forgot one fundamental thing.
> 
> If an attacker can do snapshots in time (IOW he can read the
> cipher text device after user performed some changes) he has
> either physical access to the system or he has administrator
> permissions.
> 
physical access.

> This allows more powerfull attacks already (installing
> keylogger

I also use full disk encryption. 

[You can say that I don't have to care for an encrypted file, but yes, I
have to. The attacker can allways watch modified blocks, either it's
ciphered another time by FDE. the position of files doesn't change often in
a disk. So if somebody has repeated access to my FDE system, then the
password, he can know where the 100Mbyte file resides, then check which
blocks have changed on the encrypted partition.]

> modifying kernel

I'm using a TPM chip to enforce that everything in my /boot partition
(kernel, initramfs, bootloader and options) is unchanged between reboots.

> bios,

I don't really believe in that. By the way, BIOS with TPM have one part
read-only unchangeable, and TPM chips guarantee (that's its purpose) that
it's unchanged.

> ...).
> 
> If an attacker has such access nothing will help you.
> The chain is weaker somewhere else here.
>
I hope I took care all of these problems.
 
> > not so much, depending on how much data you cipher.
> > I use files of less than 100Mbytes and cipher them. On
> > close, a full recipher wouldn't take long.
> 
> Then use encryption on filesystem level (e.g. with CTR mode,
> iow stream mode) and not sector level block device encryption.
> 
I'm not sure I understand (??) A stream mode would help? With filesystem
level encryption? But maybe it's not the right mailing list if the talk goes
that way.


> ------------------- Fin du message d'origine ---------------------










Envoyé avec Inmano, ma messagerie renversante et gratuite : http://www.inmano.com

Re: [dm-crypt] using a salt for encrypting blocks

[Milan Broz]

On 12/28/2010 03:05 PM, octane indice wrote:

>> If an attacker has such access nothing will help you.
>> The chain is weaker somewhere else here.
>>
> I hope I took care all of these problems.

Good luck. Do you know how easy is to use hw keylogger for example?
How do you detect that attacker installed such hw device when
he has repeated access to the system?
TPM will not help here.
(Btw read what truecrypt developers say about TPM - see FAQ there.)

>> Then use encryption on filesystem level (e.g. with CTR mode,
>> iow stream mode) and not sector level block device encryption.
>>
> I'm not sure I understand (??) A stream mode would help? With filesystem
> level encryption? But maybe it's not the right mailing list if the talk goes
> that way.

That was just an example - why do you want to invent something new?
I meant if you want to reencrypt everything why not do that
(either use using stream mode with some salt or with completely new key)
on the file level directly?

You cannot fix block level encryption to not leak info which block changed
without completely destroying performance.
The block device must be transparent to the system and also you do not
want to kill cache and hw acceleration here.

What is possible is to provide on-the-fly master key change and simply
reencrypt the whole device on-fly when needed.

You can implement is such way, that it will survive even unexpected power fail.

LVM has similar concept for pvmove - moved (here reencrypted) area is mirrored,
when mirror is synchronised, it will switch to final destination.

For encryption here you then need some temporary area and after switch
to destination area add wipe of old area with random data.

If power fails, it will simple start resyncing again (so for some
time both keys are active). Of course this also handle all IO requests
to the storage during reencryption.

So if this is what you want - yes, I would like to see some such functionality,
but this is work for LVM, not dmcrypt.

Milan

Re: [dm-crypt] using a salt for encrypting blocks

[octane indice]

En réponse à Milan Broz <mbroz@redhat.com> :
> Good luck. Do you know how easy is to use hw keylogger for
> example?

yes.

> How do you detect that attacker installed such hw device when
> he has repeated access to the system?
> TPM will not help here.

no. TPM won't help against an hw keylogger.
But it will help in order to detect a change in my /boot 
partition. And for that, it works. It's so easy to break the
encryption by modifying /boot than something has to be 
done. Here, TPM can help, so I use.

For hardware keylogger, I would use a laptop
very tiny where every change would be noticed.
For example, a mac book air. So thin, you can't add
a hardware keylogger. But it's not discussion for dm-crypt
mailing list I guess.

> (Btw read what truecrypt developers say about TPM - see FAQ
> there.)
> 
Done.

> You cannot fix block level encryption to not leak info which
> block changed without completely destroying performance.
> The block device must be transparent to the system and also
> you do not want to kill cache and hw acceleration here.
> 
Ok.

> What is possible is to provide on-the-fly master key change
> and simply reencrypt the whole device on-fly when needed.
> 
> You can implement is such way, that it will survive even
> unexpected power fail.
> 
> LVM has similar concept for pvmove - moved (here reencrypted)
> area is mirrored, when mirror is synchronised, it will switch to final
> destination.
> 
> For encryption here you then need some temporary area and
> after switch to destination area add wipe of old area with random data.
>
sure
 
> If power fails, it will simple start resyncing again (so for
> some time both keys are active). Of course this also handle all IO
> requests to the storage during reencryption.
> 
> So if this is what you want

a thing like that, yes

> - yes, I would like to see some
> such functionality, but this is work for LVM, not dmcrypt.
> 
Ok, I think I understand. I will look to LVM docs.

Thanks

> _______________________________________________






Envoyé avec Inmano, ma messagerie renversante et gratuite : http://www.inmano.com

Re: [dm-crypt] using a salt for encrypting blocks

[Arno Wagner]

On Thu, Dec 30, 2010 at 11:11:18AM +0100, octane indice wrote:
> En r?ponse ? Milan Broz <mbroz@redhat.com> :
> > Good luck. Do you know how easy is to use hw keylogger for
> > example?
> 
> yes.
> 
> > How do you detect that attacker installed such hw device when
> > he has repeated access to the system?
> > TPM will not help here.
> 
> no. TPM won't help against an hw keylogger.
> But it will help in order to detect a change in my /boot 
> partition. And for that, it works. It's so easy to break the
> encryption by modifying /boot than something has to be 
> done. Here, TPM can help, so I use.
> 
> For hardware keylogger, I would use a laptop
> very tiny where every change would be noticed.
> For example, a mac book air. So thin, you can't add
> a hardware keylogger. 

Good luck with that. Or rather forget about that. 
There is ample space.

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 

Re: [dm-crypt] using a salt for encrypting blocks

[Arno Wagner]

On Tue, Dec 28, 2010 at 09:29:23AM +0100, octane indice wrote:
> En r?ponse ? Arno Wagner <arno@wagner.name> :
> > The anzwer is actually no. As changed information has to be 
> > written to diek, an attacker can allways tell when a sector 
> > is changed.
> 
> My idea is to cipher _all_ blocks by changing the salt.
> 
> > This is a fundamental limitation of filesystem
> > encryption. The only way around would be to write far more
> > on each update,
> 
> yes
> 
> > with the expected catastrophic impact on 
> > performance.
> >
> not so much, depending on how much data you cipher.
> I use files of less than 100Mbytes and cipher them. On
> close, a full recipher wouldn't take long.

If you do not recipher the whole device, information about 
what was encrypted does till leak. The information is
sampled and rounded, but with a bit longer observation 
period a similar attack as against the original is still 
possible.
  
> > > but an attacker wouldn't be able to gain any information!
> > 
> > Wrong. The attacker could still detect the changed blocks.
> >
> not if I change all of them.

Indeed. Which you cannot do in practice.
 
> > > Any advice on that, or a reason why the salt is not used for
> > > encrypting blocks?
> > 
> > Because it does not help at all. Salts only help as defense
> > against rainbow tables.
> > 
> In this situation it helps in order to change the ciphered 
> version even if we don't change the clear.
> -We could change the master key: impossible in practice.

Not harder than changing the salt, actually. You do have
to recrypt the whole device anyways for this to be secure, 
so changing the master key is entrierly possible.

> -We could change the IV: I don't see how.
> Plus, both options can't afford a break (as of power loss) in the
> reciphering: which key would be used after?

Not a problem with careful journalling. 

> If we use a salt, we can always decipher, even if a break occurs while
> reciphering; at last, only one block could be unreadable.

If thet one block holds critical meta-information, the 
damage can be extreme.

Sorry, this is not the way to go. And you are not the
first with this (or a similar) idea as well. If you really
want to prevent visibility of what was changed in the 
encrypted device (and as Milan rightfully points out, the
attacker already has repeated access), the only good way 
is to make it a filesystem feature and write a lot
of fake data in addition.  AFAIK, nobody cared enough
for the, at best, marginal increase in security to
actually implement such a scheme.

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 

Re: [dm-crypt] using a salt for encrypting blocks

[octane indice]

En réponse à Arno Wagner <arno@wagner.name> :
> > not if I change all of them.
> 
> Indeed. Which you cannot do in practice.
>
By changing the salt, yes. I understand that's a huge performance issue on
closing the device, but it's acceptable in regard of the privacy gain.
  
> > In this situation it helps in order to change the ciphered 
> > version even if we don't change the clear.
> > -We could change the master key: impossible in practice.
> 
> Not harder than changing the salt, actually. You do have
> to recrypt the whole device anyways for this to be secure, 
> so changing the master key is entrierly possible.
>
No. The problem lies when you trans-cipher the device from the
old master key to the new master key.
You begin to transcipher to the half of the device, then you 
encounter a power loss of your laptop. The next boot, you 
lost a lot of things. Either the new master key is saved, then 
you read only what has been transciphered, or the old 
master key, and you can read the other half. And if you have 
both keys, you can't determine which one has to be used for
a specific block, or you must track what's has been 
transciphered which seems to be harder to implement than 
just changing the salt.

Plus, but I didn't want to say it, you can imagine random block changes when
using the device. Just check when the system is not busy, check an unused
block, recipher it.
 
> > If we use a salt, we can always decipher, even if a break
> > occurs while reciphering; at last, only one block could be
> > unreadable.
> 
> If thet one block holds critical meta-information, the 
> damage can be extreme.
> 
Yes but it's allways the situation when a disk is hard-stop
by a power loss.

> Sorry, this is not the way to go. And you are not the
> first with this (or a similar) idea as well. If you really
> want to prevent visibility of what was changed in the 
> encrypted device

yes

> (and as Milan rightfully points out, the
> attacker already has repeated access),

Yes, I think that's unavoidable. You have to consider
that an attacker has repeated access to your computer.

> the only good way 
> is to make it a filesystem feature and write a lot
> of fake data in addition.

ok. but it would be tight to a filesystem. Working with
the block level could be used with anything.

>  AFAIK, nobody cared enough
> for the, at best, marginal increase in security to
> actually implement such a scheme.
> 
ok. I understand, but I disagree with the "marginal" 
impact :-)

thanks

> _______________________________________________








Envoyé avec Inmano, ma messagerie renversante et gratuite : http://www.inmano.com