From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.server123.net (Postfix) with ESMTPS for ; Wed, 6 May 2015 22:28:41 +0200 (CEST) Received: by wgiu9 with SMTP id u9so23808920wgi.3 for ; Wed, 06 May 2015 13:28:40 -0700 (PDT) MIME-Version: 1.0 From: Fraser Scott Date: Wed, 6 May 2015 21:28:20 +0100 Message-ID: Content-Type: multipart/alternative; boundary=f46d04138a9d0019a805156fa4d5 Subject: [dm-crypt] iv generation from third-party code List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: dm-crypt@saout.de --f46d04138a9d0019a805156fa4d5 Content-Type: text/plain; charset=UTF-8 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 --f46d04138a9d0019a805156fa4d5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi all,

I had a Western Digital My Book= World Edition which died a few years ago. My wife now wants the photos tha= t 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 u= sing 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 twea= king.

What are my chance of "porting" th= e IV stuff from the module to a clean dm-crypt.c so that I can do the AES d= ecryption in software? Given that I don't know much C, or know much abo= ut 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) = =C2=A0ox-crypt hexkey hexiv 0 /dev/md4 0 | dmsetup create dmmd4
<= br>
(I have the key and IV)

and can be v= iewed here:


My attempt so far can be seen here:=


Many thanks!
-Fraser

<= /div>

--f46d04138a9d0019a805156fa4d5-- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from v6.tansi.org (ns.km31936-01.keymachine.de [87.118.116.4]) by mail.server123.net (Postfix) with ESMTP for ; Thu, 7 May 2015 08:40:56 +0200 (CEST) Received: from gatewagner.dyndns.org (77-57-54-224.dclient.hispeed.ch [77.57.54.224]) by v6.tansi.org (Postfix) with ESMTPA id 08FFE20DC1FA for ; Thu, 7 May 2015 08:40:56 +0200 (CEST) Date: Thu, 7 May 2015 08:40:55 +0200 From: Arno Wagner Message-ID: <20150507064055.GA17900@tansi.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [dm-crypt] iv generation from third-party code List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: dm-crypt@saout.de 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.server123.net (Postfix) with ESMTPS for ; Thu, 7 May 2015 09:03:37 +0200 (CEST) Received: by widdi4 with SMTP id di4so229837466wid.0 for ; Thu, 07 May 2015 00:03:36 -0700 (PDT) Message-ID: <554B0E46.7000102@gmail.com> Date: Thu, 07 May 2015 09:03:34 +0200 From: Milan Broz MIME-Version: 1.0 References: In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [dm-crypt] iv generation from third-party code List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Fraser Scott , dm-crypt@saout.de 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.server123.net (Postfix) with ESMTPS for ; Thu, 7 May 2015 10:13:04 +0200 (CEST) Received: by wizk4 with SMTP id k4so232284075wiz.1 for ; Thu, 07 May 2015 01:13:03 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20150507064055.GA17900@tansi.org> References: <20150507064055.GA17900@tansi.org> From: Fraser Scott Date: Thu, 7 May 2015 09:12:42 +0100 Message-ID: Content-Type: multipart/alternative; boundary=001a11c2677c0c376a0515797be8 Subject: Re: [dm-crypt] iv generation from third-party code List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: dm-crypt@saout.de --001a11c2677c0c376a0515797be8 Content-Type: text/plain; charset=UTF-8 Thanks for taking the time to reply. On 7 May 2015 at 07:40, Arno Wagner 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. --001a11c2677c0c376a0515797be8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks for taking the time to reply.

On 7 May 2015 at 07:40, Arno Wagner= <arno@wagner.name> wrote:
So the hardware as= sist 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 on= ly mentions AES as a feature - no details.=C2=A0

<= br>
Depends on how much time you want to invest. Afte= rwards 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

=C2=A0 =C2=A0ox800_aeslrw_decrypt()=C2=A0

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 s= ource for that lives in another file, also provided by WD.

I did some playing around in Ruby before getting further help f= rom IRC. I was able to decrypt the first 32 bytes in ECB mode using some co= unter 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 s= upplied IV. After that it gets a bit funky, but I believe this matches up w= ith what is expected from LRW mode.
--001a11c2677c0c376a0515797be8-- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from v6.tansi.org (ns.km31936-01.keymachine.de [87.118.116.4]) by mail.server123.net (Postfix) with ESMTP for ; Thu, 7 May 2015 11:29:44 +0200 (CEST) Received: from gatewagner.dyndns.org (77-57-54-224.dclient.hispeed.ch [77.57.54.224]) by v6.tansi.org (Postfix) with ESMTPA id 21BA620DC1FA for ; Thu, 7 May 2015 11:29:44 +0200 (CEST) Date: Thu, 7 May 2015 11:29:43 +0200 From: Arno Wagner Message-ID: <20150507092943.GA25092@tansi.org> References: <20150507064055.GA17900@tansi.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [dm-crypt] iv generation from third-party code List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: dm-crypt@saout.de 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.server123.net (Postfix) with ESMTPS for ; Thu, 7 May 2015 11:37:12 +0200 (CEST) Received: by widdi4 with SMTP id di4so234654546wid.0 for ; Thu, 07 May 2015 02:37:10 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20150507092943.GA25092@tansi.org> References: <20150507064055.GA17900@tansi.org> <20150507092943.GA25092@tansi.org> From: Fraser Scott Date: Thu, 7 May 2015 10:36:49 +0100 Message-ID: Content-Type: multipart/alternative; boundary=089e01493d12df43e705157aa79d Subject: Re: [dm-crypt] iv generation from third-party code List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: dm-crypt@saout.de --089e01493d12df43e705157aa79d Content-Type: text/plain; charset=UTF-8 On 7 May 2015 at 10:29, Arno Wagner 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. --089e01493d12df43e705157aa79d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


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

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.
=C2=A0
As to LRW-Mode, from
=C2=A0 http://en.wikipedia.= org/wiki/Disk_encryption_theory#Liskov.2C_Rivest.2C_and_Wagner_.28LRW.29
I deduce, that indeed you get X =3D 0 for the first 16 byte block
and X =3D 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^1= 28),
so just using X as the "IV" would not be enough. (Decryption work= s
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 p= robably 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.

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

<= /div> --089e01493d12df43e705157aa79d-- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from v6.tansi.org (ns.km31936-01.keymachine.de [87.118.116.4]) by mail.server123.net (Postfix) with ESMTP for ; Thu, 7 May 2015 12:09:48 +0200 (CEST) Received: from gatewagner.dyndns.org (77-57-54-224.dclient.hispeed.ch [77.57.54.224]) by v6.tansi.org (Postfix) with ESMTPA id 1CE2320DC1FA for ; Thu, 7 May 2015 12:09:48 +0200 (CEST) Date: Thu, 7 May 2015 12:09:47 +0200 From: Arno Wagner Message-ID: <20150507100947.GA27143@tansi.org> References: <20150507064055.GA17900@tansi.org> <20150507092943.GA25092@tansi.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [dm-crypt] iv generation from third-party code List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: dm-crypt@saout.de On Thu, May 07, 2015 at 11:36:49 CEST, Fraser Scott wrote: > On 7 May 2015 at 10:29, Arno Wagner 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