Date: Mon, 13 Dec 2010 14:49:55 -0500
From: "Everhart, Glenn" <glenn.everhart@...se.com>
To: "noloader@...il.com" <noloader@...il.com>
Cc: "full-disclosure@...ts.grok.org.uk" <full-disclosure@...ts.grok.org.uk>
Subject: Re: Possible issues with encrypted Linux
 filesystems?

You don't use block number as a key; you use it as part of the computation
to select one. Actual encryption needs to use a strong algorithm but
you want to make sure the key differs for every cipher block. If nothing
else, there tend to be many places in a disk filestructure that contain
all zeroes, or other highly predictable plaintext.

The modes (XTS for example that Truecrypt uses) derive from such ideas.

A decently implemented cryptodisk will also consider adding its own tests
to do some access control, since as long as the system has the driver working
there is code in the system to automatically decrypt it. (Some of that WAS in
the 1979 code mentioned.)

Glenn Everhart


-----Original Message-----
From: Jeffrey Walton [mailto:noloader@...il.com] 
Sent: Monday, December 13, 2010 12:32 PM
To: Everhart, Glenn
Cc: Levente Peres; full-disclosure@...ts.grok.org.uk
Subject: Re: [Full-disclosure] Possible issues with encrypted Linux filesystems?

On Mon, Dec 13, 2010 at 11:40 AM, Everhart, Glenn
<glenn.everhart@...se.com> wrote:
> If you are making an encrypted disk, you must be able to start decrypting
> any parts you like. This makes use of common encryption modes other than ECB
> harder.
CTR (and CTS) or XTS comes to mind. CTR should be considered since its
seekable. I would have to read NIST's Special Publication 800-38E for
XTS.

> However you have the block number of the disk available. If it is used as part
> of the encryption calculation you can have what amounts to a different encryption
> key for every disk block (derivative of course but still all different). This
> prevents you from being able readily to get information about each cipher block
> by noting patterns where the ciphertext is identical (due to identical plaintext).
Block Id's, inodes and such should probably be considered public
information [under some threat models] and hence, relegated to an IV.
In this respect, the block Id or inode is very similar to a counter.

I would  be wary of trying to use a block id as a key. In addition,
id's and inode numbers should be authenticated even though the data
contained in the block is encrypted (confer: copy/paste attacks). With
that said, authentication is usually shed in an attempt to balance
usability and security (confer: Microsoft' elephant diffuser and "Poor
man's authentication").

> My VMS cryptodisk back in mid 1980s did that. Don't recall if the RSX cryptodisk
> from 1979 did it or not; those machines were slow enough by modern standards it
> was difficult even to get modestly strong crypto and have the machine do anything
> else useful at the same time.
:)

Jeff

> -----Original Message-----
> From: full-disclosure-bounces@...ts.grok.org.uk [mailto:full-disclosure-bounces@...ts.grok.org.uk] On Behalf Of Jeffrey Walton
> Sent: Monday, December 13, 2010 11:12 AM
> To: Levente Peres
> Cc: full-disclosure@...ts.grok.org.uk
> Subject: Re: [Full-disclosure] Possible issues with encrypted Linux filesystems?
>
> On Mon, Dec 13, 2010 at 9:16 AM, Levente Peres <sheridan@...sz.org> wrote:
>> Dear All,
>>
>> Yesterday I had a very interesting conversation with Anthony G. Basile,
>> Ph. D. of D'Youville College about filesystem security. We thought that
>> we should continue this discussion here, so we could all contemplate on
>> the possibility of such a thing being possible.
>>
>> After reading Anthony's article, which you may find here...
>>
>> http://opensource.dyc.edu/random-vs-encrypted
>
> I'm aware of a couple of papers which might interest you. First is
> "TKS1 - An anti-forensic, two level, and iterated key setup scheme" by
>  Clemens Fruhwirth. Second is "AES-CBC + Elephant Diffuser, A Disk
> Encryption Algorithm for Windows Vista" by Niels Ferguson.
>
> Fruhwirth's paper relates to LUKS, while Ferguson's paper relates to
> BitLocker. Both papers discuss threats and design decisions. Keep in
> mind both papers were released well before XTS and other tweakable
> modes.
>
> I'm not well read on LUKS, dmcrypt, cryptsetup, etc. From my 10,000
> foot view, the papers are similar in that they attempt to solve the
> same problem in slightly different problem domains.
>
> Jeff
>
>> ...I've became worried about something very alarming, which I'd like to hear your opinion about.
>>
>> You see, it's one thing that you encrypt data, and then make backups, encrypt those backups, and the attacker could get valuable information by comparing the patterns of the two... But when encrypting an entire operating system space, you actually encrypt much more than the data you wish to protect: you encrypt your system files, your packages, all of it. Now this may sound like an ideal thing to do, but I'm not so sure about that anymore.
>>
>> Now, as we know, most Linux distributions have at least some files, directories, whatever that are bound to be the same on all systems. For example, binaries of gcc, some base directory names like /var, /usr, /home, layouts, and things like that. Even more, if you are using a "standard" distro like CentOS, you are assured to have literally gigabytes of data in forms of binary RPM packages on a default "base" installation, which not only are sure to be the same on all systems, but even their distribution across filesystems are prone to be predictable. For simplicity's sake, let's just put these into one bucket and call them "known artefacts".
>>
>> I'm now worried that if an attacker knows, or "guesses" that you are using, say, CentOS Linux 5.5, (or at least some mutation of Red Hat), he might use this knowledge of "known artefacts" to his advantage, by starting out from the data he knows "must be there", and looking for it's "patterns". I don't know... This may be a longshot, wishful thinking or both, but somehow it feels to me like it's a lot easier to break a code when you already know exactly what the decrypted data is, and what it looks like. It should be like reverse-engineering ancient-egyptian text by seeing the same damn text in two or three other different languages you can actually understand... Essentially you could at the very least improve your chances at success if you have several certain, fixed points of reference for the decryption procedure (these "artefacts" we mentioned).
>>
>> I'll dare to go even further... Even if you are not encrypting your entire system, just the data... you could be leaving behind arefacts like file format headers, etc etc... or in case of LVM, logical flesystems within the LVM could leave behind headers, identifiers to mark the type, end or beginning, etc. of FS, whatever. I agree it's not much, and probably no concern, but if you want to be extremely paranoid, it's something.
>>
>> Now I'm not pretending to be an encryption expert... But I've go to tell it to you, If there's any possibility to this - then it creeps me out. Worst case scenario, we could be looking at the possibility of breaking virtually any
>> "standard" distro as long as one could "guess" (or "brute-force-guess") the version and type of the distro, AND the system is encrypted along with the data to be protected...
>>
>> I'd like you guys to put me back to ease by either proving me fatally wrong, or if there's anything to this... well, then we should discuss anyway.
>>
>> Best Regards,
>>
>> Levente Peres
>>
>> _______________________________________________
>> Full-Disclosure - We believe in it.
>> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
>> Hosted and sponsored by Secunia - http://secunia.com/
>>
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
> This transmission may contain information that is privileged,
> confidential, legally privileged, and/or exempt from disclosure
> under applicable law.  If you are not the intended recipient, you
> are hereby notified that any disclosure, copying, distribution, or
> use of the information contained herein (including any reliance
> thereon) is STRICTLY PROHIBITED.  Although this transmission and
> any attachments are believed to be free of any virus or other
> defect that might affect any computer system into which it is
> received and opened, it is the responsibility of the recipient to
> ensure that it is virus free and no responsibility is accepted by
> JPMorgan Chase & Co., its subsidiaries and affiliates, as
> applicable, for any loss or damage arising in any way from its use.
>  If you received this transmission in error, please immediately
> contact the sender and destroy the material in its entirety,
> whether in electronic or hard copy format. Thank you.
>
This transmission may contain information that is privileged,
confidential, legally privileged, and/or exempt from disclosure
under applicable law.  If you are not the intended recipient, you
are hereby notified that any disclosure, copying, distribution, or
use of the information contained herein (including any reliance
thereon) is STRICTLY PROHIBITED.  Although this transmission and
any attachments are believed to be free of any virus or other
defect that might affect any computer system into which it is
received and opened, it is the responsibility of the recipient to
ensure that it is virus free and no responsibility is accepted by
JPMorgan Chase & Co., its subsidiaries and affiliates, as
applicable, for any loss or damage arising in any way from its use.
 If you received this transmission in error, please immediately
contact the sender and destroy the material in its entirety,
whether in electronic or hard copy format. Thank you.

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Powered by blists - more mailing lists