[dm-crypt] IV generation for dm-crypt

[dm-crypt] IV generation for dm-crypt

[EXTERNAL D Sharmila (Iwave, RBEI/PAC-PF)]

Hi team,
        I am able to successfully encrypt custom device physical
partition using dmsetup utility. I have used dm-crypt and dm-integrity
for the same. I have one query related to IV generation of dm-crypt.

Query:
        Whether Random number generator used to generate IV, generates
same IV repeatedly or unique IV will be generated ? How the IV
generation handled in dm-crypt ?

The commands I used to create dm-integrity and dm-crypt is as below

dmsetup create test-integrity --table '0 14240 integrity /dev/mmcblk0p5
0 32 J 1
internal_hash:hmac(sha256):30313233343536373839414243444546303132333435
36373839414243444546' 

dmsetup create test-integrity-crypt --table '0 14240 crypt aes-cbc-
essiv:sha256 :32:user:test-key 0 /dev/mapper/test-integrity 0'


Please give your valuable response for the above query. 

Regards,
Sharmila

Re: [dm-crypt] IV generation for dm-crypt

[Milan Broz]

Dear Sharmila,

when I sent you to the list, because the issue tracker is not a support forum
and our time is extremely limited, I expected you will AT LEAST read the link
to the documentation I provided.

Please do not expect from the community any support for questions you just
copy&paste without even trying to study documentation yourself.

Anyway.

First, really think about using integritysetup/cryptsetup. Using dmsetup
is super fragile (it is the lowest tool, basically just wrapper through IOCTL).

On 29/01/2020 09:18, EXTERNAL D Sharmila (Iwave, RBEI/PAC-PF) wrote:
> Query:
>         Whether Random number generator used to generate IV, generates
> same IV repeatedly or unique IV will be generated ? How the IV
> generation handled in dm-crypt ?

https://gitlab.com/cryptsetup/cryptsetup/-/wikis/DMCrypt#iv-generators

So, if you use "random" IV it is regenerated on every write (can be used onlt for
authenticated encryption).
For other IVs it is either fixed (null) or derived from sector offset.

I would strongly suggest to use aes-xts-plain64 these days for length preserving
encryption in dm-crypt.

> The commands I used to create dm-integrity and dm-crypt is as below
> 
> dmsetup create test-integrity --table '0 14240 integrity /dev/mmcblk0p5
> 0 32 J 1
> internal_hash:hmac(sha256):30313233343536373839414243444546303132333435
> 36373839414243444546' 
> 
> dmsetup create test-integrity-crypt --table '0 14240 crypt aes-cbc-
> essiv:sha256 :32:user:test-key 0 /dev/mapper/test-integrity 0'

So here you use integrity protected device with keyded MAC, and over
it length preserving encryption using aes-cbc-essiv.

So IV in dmcrypt is fixed, but unpredictable (derived from encryption key).

Again, read the documentation.
https://gitlab.com/cryptsetup/cryptsetup/-/wikis/DMIntegrity

Namely that key specification for internal_hash is in hexa.
Your "random" HMAC key above is very suspicious in this regard, for example.

m.

Re: [dm-crypt] IV generation for dm-crypt

[EXTERNAL D Sharmila (Iwave, RBEI/PAC-PF)]

Hi Milan, 

	I understand your suggestion and I gone through the document
which you provided. I even dumped my IV value and got to know that it
is fixed for each operation. I cannot use "random" as our requirement
is not on that. So here I need to use encryption using aes-cbc-essiv
only. 
I am using same key for dm-integrity and dm-crypt and I am saving the
same key in keyring. So dm-crypt will take key from keyrings.

After digging into the issue I found some patch regarding kernel dm-
crypt driver. Can you please provide me the input on this, weather this
patch will be helpful?

https://lore.kernel.org/patchwork/patch/777700/

Regards,
Sharmila


On Wed, 2020-01-29 at 10:48 +0100, Milan Broz wrote:
> Dear Sharmila,
> 
> when I sent you to the list, because the issue tracker is not a
> support forum
> and our time is extremely limited, I expected you will AT LEAST read
> the link
> to the documentation I provided.
> 
> Please do not expect from the community any support for questions you
> just
> copy&paste without even trying to study documentation yourself.
> 
> Anyway.
> 
> First, really think about using integritysetup/cryptsetup. Using
> dmsetup
> is super fragile (it is the lowest tool, basically just wrapper
> through IOCTL).
> 
> On 29/01/2020 09:18, EXTERNAL D Sharmila (Iwave, RBEI/PAC-PF) wrote:
> > Query:
> >         Whether Random number generator used to generate IV,
> > generates
> > same IV repeatedly or unique IV will be generated ? How the IV
> > generation handled in dm-crypt ?
> 
> 
https://gitlab.com/cryptsetup/cryptsetup/-/wikis/DMCrypt#iv-generators
> 
> So, if you use "random" IV it is regenerated on every write (can be
> used onlt for
> authenticated encryption).
> For other IVs it is either fixed (null) or derived from sector
> offset.
> 
> I would strongly suggest to use aes-xts-plain64 these days for length
> preserving
> encryption in dm-crypt.
> 
> > The commands I used to create dm-integrity and dm-crypt is as below
> > 
> > dmsetup create test-integrity --table '0 14240 integrity
> > /dev/mmcblk0p5
> > 0 32 J 1
> > internal_hash:hmac(sha256):3031323334353637383941424344454630313233
> > 3435
> > 36373839414243444546' 
> > 
> > dmsetup create test-integrity-crypt --table '0 14240 crypt aes-cbc-
> > essiv:sha256 :32:user:test-key 0 /dev/mapper/test-integrity 0'
> 
> So here you use integrity protected device with keyded MAC, and over
> it length preserving encryption using aes-cbc-essiv.
> 
> So IV in dmcrypt is fixed, but unpredictable (derived from encryption
> key).
> 
> Again, read the documentation.
> https://gitlab.com/cryptsetup/cryptsetup/-/wikis/DMIntegrity
> 
> Namely that key specification for internal_hash is in hexa.
> Your "random" HMAC key above is very suspicious in this regard, for
> example.
> 
> m.

Re: [dm-crypt] Data corruption of encrypted partition

[EXTERNAL D Sharmila (Iwave, RBEI/PAC-PF)]

Hi team,

I am encrypting my partition using dm-integrity and dm-crypt utility. I
am trying to corrupt my encryted partition using dd command utiltity as
below

/factory/ is a mounted point of encrypted partition
(/dev/mapper/factory-integrity-crypt)

dd if=/security/file.txt of=/factory/file.txt bs=512 seek=8

I am able to see my file.txt content using cat command

I am trying to corrupt the file content by writing to physical layer of
the encrypted partition using below command

dd if=/security/file.txt of=/dev/mmcblk0p5 bs=512 seek=8


/dev/mmcblk0p5 is the physical layer of the encrypted logical layer
(/dev/mapper/factory-integrity-crypt)


When I open the file , the file content is not corrupted and even I can
unmount and mount the partition again even if I corrupt the physical
block device of encrypted partition. Is this behaviour is expected?
Please provide your input.

Regards,
Sharmila

Re: [dm-crypt] IV generation for dm-crypt

[Milan Broz]

On 29/01/2020 11:28, EXTERNAL D Sharmila (Iwave, RBEI/PAC-PF) wrote:
> After digging into the issue I found some patch regarding kernel dm-
> crypt driver. Can you please provide me the input on this, weather this
> patch will be helpful?
> 
> https://lore.kernel.org/patchwork/patch/777700/

This patch is obsolete. There was a discussion if we need to move all IV generators
to core crypto library, currently mainline kernel moved ESSIV only
(because it is used also in fscrypt), the rest remains in dm-crypt.

There is no change in behaviour except the new dependence on "essiv.ko" module.

If you have an older kernel, you do not need to apply anything, it was
just code cleaning (and avoiding code duplication).

m.