[dm-crypt] iv generation from third-party code

[dm-crypt] iv generation from third-party code

[Fraser Scott]

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

Hi all,

I had a Western Digital My Book World Edition which died a few years ago.
My wife now wants the photos that were on it :)

The good news is, the hard disk is fine. The bad news is that I used the
hardware assisted encryption on the data partition.

WD make the source code available, so I've been poking around. Thanks to
help from the peeps on ##crypto (freenode), it seems clear that the custom
device mapper module isn't using any keys store on a chip etc, it is just
using hardware for speed. It looks like it is using AES in LRW mode but
uses some sort of custom IV tweaking.

What are my chance of "porting" the IV stuff from the module to a clean
dm-crypt.c so that I can do the AES decryption in software? Given that I
don't know much C, or know much about kernel development or dm-crypt? ;) In
the meantime I am trying to source some replacement hardware.

The module was called as follows:

# echo 0 $(cat /sys/block/md4/size)  ox-crypt hexkey hexiv 0 /dev/md4 0 |
dmsetup create dmmd4

(I have the key and IV)

and can be viewed here:

https://gist.github.com/zeroXten/be5322ee4a1000c0c7fc

My attempt so far can be seen here:

https://gist.github.com/zeroXten/0ba59291f05aa5a0f513

Many thanks!
-Fraser

[-- Attachment #2: Type: text/html, Size: 1741 bytes --]

Re: [dm-crypt] iv generation from third-party code

[Arno Wagner]

Hi,

On Wed, May 06, 2015 at 22:28:20 CEST, Fraser Scott wrote:
> Hi all,
> 
> I had a Western Digital My Book World Edition which died a few years ago.
> My wife now wants the photos that were on it :)
> 
> The good news is, the hard disk is fine. The bad news is that I used the
> hardware assisted encryption on the data partition.

So the hardware assist sits in some USB bridge or the like?

> WD make the source code available, so I've been poking around. Thanks to
> help from the peeps on ##crypto (freenode), it seems clear that the custom
> device mapper module isn't using any keys store on a chip etc, it is just
> using hardware for speed. It looks like it is using AES in LRW mode but
> uses some sort of custom IV tweaking.

If you can, get the datasheet and hope it describes what it does...
 
> What are my chance of "porting" the IV stuff from the module to a clean
> dm-crypt.c so that I can do the AES decryption in software? Given that I
> don't know much C, or know much about kernel development or dm-crypt? ;) In
> the meantime I am trying to source some replacement hardware.

Depends on how much time you want to invest. Afterwards you will
know quite a bit about C programming. The dm-crypt/kernel part is 
less of a problem as you can use the module you have, you just 
need to replace all hardware crypto with equivalent software
crypto. That may be anything from vwey easy to very hard. It gets
harder, the less you know about the hardware crypto engine.

The thing you probably need to replace is 

   ox800_aeslrw_decrypt()

As far as I can see, the source for that is missing. 
Probably in a driver for the "OX800 DPE core". Do you have 
that driver and its sources? Because it does not seem to 
be a part of the standard kernel. At least in 3.14.29, I
find nothing. Of course you can try to replace it with
a standard aes-lrw implementation and hope that it has
that semantics and does nto require anything special and
non-standard with its parameters.

Anyways, expect to invest at least a few weeks.

Gr"usse,
Arno


> The module was called as follows:
> 
> # echo 0 $(cat /sys/block/md4/size)  ox-crypt hexkey hexiv 0 /dev/md4 0 |
> dmsetup create dmmd4
> 
> (I have the key and IV)
> 
> and can be viewed here:
> 
> https://gist.github.com/zeroXten/be5322ee4a1000c0c7fc
> 
> My attempt so far can be seen here:
> 
> https://gist.github.com/zeroXten/0ba59291f05aa5a0f513
> 
> Many thanks!
> -Fraser

> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt


-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
A good decision is based on knowledge and not on numbers. -- Plato

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] iv generation from third-party code

[Fraser Scott]

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

Thanks for taking the time to reply.

On 7 May 2015 at 07:40, Arno Wagner <arno@wagner.name> wrote:
>
> So the hardware assist sits in some USB bridge or the like?
>

Its an ARM based system-on-a-chip, specifically the Oxford Semiconductor
OXE800.

If you can, get the datasheet and hope it describes what it does...
>

There is a datasheet, but it is pretty useless. It has chip pins etc but
only mentions AES as a feature - no details.


Depends on how much time you want to invest. Afterwards you will
> know quite a bit about C programming. The dm-crypt/kernel part is
> less of a problem as you can use the module you have, you just
> need to replace all hardware crypto with equivalent software
> crypto. That may be anything from vwey easy to very hard. It gets
> harder, the less you know about the hardware crypto engine.
>

Yeah.

The thing you probably need to replace is
>
>    ox800_aeslrw_decrypt()


> As far as I can see, the source for that is missing.
> Probably in a driver for the "OX800 DPE core". Do you have
> that driver and its sources? Because it does not seem to
> be a part of the standard kernel. At least in 3.14.29, I
> find nothing. Of course you can try to replace it with
> a standard aes-lrw implementation and hope that it has
> that semantics and does nto require anything special and
> non-standard with its parameters.
>

The source for that lives in another file, also provided by WD.

https://gist.github.com/zeroXten/a0bbc92e85fdab87d3ae

I did some playing around in Ruby before getting further help from IRC. I
was able to decrypt the first 32 bytes in ECB mode using some counter mode
inspired IV tweaking. The first 16 bytes were decrypted using an IV of 0x0
and the next 16 bytes were decrypted using the unmodified user supplied IV.
After that it gets a bit funky, but I believe this matches up with what is
expected from LRW mode.

[-- Attachment #2: Type: text/html, Size: 3269 bytes --]

Re: [dm-crypt] iv generation from third-party code

[Arno Wagner]

On Thu, May 07, 2015 at 10:12:42 CEST, Fraser Scott wrote:
> Thanks for taking the time to reply.

No problem.

> I did some playing around in Ruby before getting further help from IRC. I
> was able to decrypt the first 32 bytes in ECB mode using some counter mode
> inspired IV tweaking. The first 16 bytes were decrypted using an IV of 0x0
> and the next 16 bytes were decrypted using the unmodified user supplied IV.
> After that it gets a bit funky, but I believe this matches up with what is
> expected from LRW mode.

In that case, you should probably aim to do the whole decryption 
in Ruby. Will be a lot less effort on the development side, and
who cares if it takes some hours or days to do the full decryption 
once it works. (And disk-encryption can be very easily paralellized on
sector-level in addition.) This way you can do away with all the 
kernel-module and driver stuff and just have to get the crypto right.

As to LRW-Mode, from 
  http://en.wikipedia.org/wiki/Disk_encryption_theory#Liskov.2C_Rivest.2C_and_Wagner_.28LRW.29
I deduce, that indeed you get X = 0 for the first 16 byte block 
and X = F for the second. From block 2 onwards, you need GF(2^128)
multiplication to get X. However, for the second nlock (index 1),
that should be E_k(Block + X) + X with "+" as addition ing GF(2^128), 
so just using X as the "IV" would not be enough. (Decryption works 
the same, just replace E_k by D_k).

I am not sure what LRW does with sector numbers, it may just 
divide the whole device into 16 byte blocks and count them from 
the start.

The math can be googled with "gf(2^128)".

Easiest way on the coding side would probably be to just make an 
image-file of the drive and work with that and decrypt to a second 
image file. Linux has no problems with files that are a few
fundred GB large.

Just one remark: Your terminology seems to be off, as ECB does not 
have an IV. I suggets using the formula from Wikipedia directly and
to forget about "IV"s.

Arno 

-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
A good decision is based on knowledge and not on numbers. -- Plato

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] iv generation from third-party code

[Fraser Scott]

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

On 7 May 2015 at 10:29, Arno Wagner <arno@wagner.name> wrote:

In that case, you should probably aim to do the whole decryption
> in Ruby. Will be a lot less effort on the development side, and
> who cares if it takes some hours or days to do the full decryption
> once it works. (And disk-encryption can be very easily paralellized on
> sector-level in addition.) This way you can do away with all the
> kernel-module and driver stuff and just have to get the crypto right.
>

Yeah, that makes sense.


> As to LRW-Mode, from
>
> http://en.wikipedia.org/wiki/Disk_encryption_theory#Liskov.2C_Rivest.2C_and_Wagner_.28LRW.29
> I deduce, that indeed you get X = 0 for the first 16 byte block
> and X = F for the second. From block 2 onwards, you need GF(2^128)
> multiplication to get X. However, for the second nlock (index 1),
> that should be E_k(Block + X) + X with "+" as addition ing GF(2^128),
> so just using X as the "IV" would not be enough. (Decryption works
> the same, just replace E_k by D_k).
>
> I am not sure what LRW does with sector numbers, it may just
> divide the whole device into 16 byte blocks and count them from
> the start.
>
> The math can be googled with "gf(2^128)".
>

Thanks for that, I'll take a closer look.


> Easiest way on the coding side would probably be to just make an
> image-file of the drive and work with that and decrypt to a second
> image file. Linux has no problems with files that are a few
> fundred GB large.
>

Yeah. I've got some limitations as to where I can keep a 400GB file, so for
now I'll just work with a hundred meg or so. Once I can strings that to get
what looks like a file system, I'll apply the code to the whole image.

Just one remark: Your terminology seems to be off, as ECB does not
> have an IV. I suggets using the formula from Wikipedia directly and
> to forget about "IV"s.
>

What I meant was I was using openssl's AES in ECB mode as a building block
for doing LRW myself. So I was doing something like E_k(tweak(IV, sector))
^ tweak(IV, sector) with ECB providing E_k.

[-- Attachment #2: Type: text/html, Size: 3124 bytes --]

Re: [dm-crypt] iv generation from third-party code

[Arno Wagner]

On Thu, May 07, 2015 at 11:36:49 CEST, Fraser Scott wrote:
> On 7 May 2015 at 10:29, Arno Wagner <arno@wagner.name> wrote:
[...] 
> Yeah. I've got some limitations as to where I can keep a 400GB file, so for
> now I'll just work with a hundred meg or so. Once I can strings that to get
> what looks like a file system, I'll apply the code to the whole image.

Just get a 1TB or larger external USB disk. They are not expensive.
And probably a lot cheaper than your wive's wrath of you accidentally
kill the original disk. Firts rule of all data-recovery: Never work
on the original, always on a copy. And if the data has any worth,
make two backups and only work on one.
 
> Just one remark: Your terminology seems to be off, as ECB does not
> > have an IV. I suggets using the formula from Wikipedia directly and
> > to forget about "IV"s.
> >
> 
> What I meant was I was using openssl's AES in ECB mode as a building block
> for doing LRW myself. So I was doing something like E_k(tweak(IV, sector))
> ^ tweak(IV, sector) with ECB providing E_k.

Ok. The thing is though that "ECB" is a "mode" while E_k is 
one elementary encryption op. ECB means encryting b0,b1,b2 as 
E_k(b0),E_k(b1),E_k(b2). For just one block, they are the same, 
but the term "mode" does not make sense for just one block.

Not trying to be a smart-ass, but people will understand you 
better with the right terminology.

Arno
-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
A good decision is based on knowledge and not on numbers. -- Plato

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] iv generation from third-party code

[Milan Broz]

On 05/06/2015 10:28 PM, Fraser Scott wrote:
> 
> I had a Western Digital My Book World Edition which died a few years
> ago. My wife now wants the photos that were on it :)
> 
> The good news is, the hard disk is fine. The bad news is that I used
> the hardware assisted encryption on the data partition.
> 
> WD make the source code available, so I've been poking around. Thanks
> to help from the peeps on ##crypto (freenode), it seems clear that
> the custom device mapper module isn't using any keys store on a chip
> etc, it is just using hardware for speed. It looks like it is using
> AES in LRW mode but uses some sort of custom IV tweaking.

Do you have some pointer to official source code modified by WD?

For what products it was used? (WD have sometimes different chips even
in the same product line.)

I remember I tried to find some documentation for WD encrypted drives
and there was nothing available.

> What are my chance of "porting" the IV stuff from the module to a
> clean dm-crypt.c so that I can do the AES decryption in software?
> Given that I don't know much C, or know much about kernel development
> or dm-crypt? ;) In the meantime I am trying to source some
> replacement hardware.

If there is some test image and it is really only about IV, then
it should be relatively simple.
(And maybe it would be nice to include it upstream as well.)

If they are using some modified LRW mode, it is much more worse
(you will have to write own crypto mode implementation).

Milan