Re: [Full-disclosure] Possible issues with encrypted Linux filesystems?

[Jeffrey Walton <noloader@xxxxxxxxx>]

On Mon, Dec 13, 2010 at 11:40 AM, Everhart, Glenn
<glenn.everhart@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxx 
> [mailto:full-disclosure-bounces@xxxxxxxxxxxxxxxxx] On Behalf Of Jeffrey Walton
> Sent: Monday, December 13, 2010 11:12 AM
> To: Levente Peres
> Cc: full-disclosure@xxxxxxxxxxxxxxxxx
> Subject: Re: [Full-disclosure] Possible issues with encrypted Linux 
> filesystems?
>
> On Mon, Dec 13, 2010 at 9:16 AM, Levente Peres <sheridan@xxxxxxxxx> 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.
>

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