All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matthias Schniedermeyer <ms@citd.de>
To: Stavros Kousidis <dabros.kuhsadas@web.de>
Cc: dm-crypt@saout.de
Subject: Re: [dm-crypt] Cryptographic issues with SSD-technology and wide-block encryption modes
Date: Wed, 6 Feb 2013 12:07:13 +0100	[thread overview]
Message-ID: <20130206110713.GA701@citd.de> (raw)
In-Reply-To: <trinity-5d2068d0-c1b0-4655-b90c-be14a707caa4-1360145171481@3capp-webde-bs30>

On 06.02.2013 11:06, Stavros Kousidis wrote:
> 
> One essential issue that concerns full disk encryption on SSDs, that I 
> have not seen in a mail discussion here so far (might be there and I 
> simply missed it), is the distribution of an uncontrollable amount of 
> copies of SSD-page contents (~4096 Bytes) where only a limited number 
> of blocks (~16 Bytes) have changed. This is initiated by local changes 
> in userspace data and technically due to the complex nature of the 
> flash translation layer (mainly wear leveling techniques), the 
> narrow-block encryption modes (here: XTS) and sector-wise constant 
> IVs. In Cipher-block chaining mode the position where a bit-flip 
> happened is visible in principle.

Let me paraphrase, you are worried about someone physically ripping the 
SSD out of your computer, desoldering the chips and reverse engeneering 
the wear-leveling. In the off-change that there actually are several 
generations of a somehow vulnerable block (or several) and the changes 
would tell the attacker "something".

With the slight variatians:
a) Somone with root-priviles making full-copies of the device at 
different points in time
b) Somone with root-priviledes and the SSD containing some vendor 
specific commands to read the RAW contents of the flash and/or 
possibility to get older versions of blocks (at different points in 
time)
c) Taking the SSD out and making full copies at different points in 
time.
d) c in variant b
e) Things that don't come to my mind



In short:
I would worry about these things, before i worry about POTENTIAL 
information leakage of several generations of a specific block.
In all cases you already need a vulnerability to even get to the 
information.

I don't say the theoretical vulnerability doesn't exist, but there are 
things much more serious before worrying about such theoretical things.
Among the first i would worry about: The so called "cold-boot attack".
At least for cases were you worry about someone with physical access.

I would call this is a typical case for the: "Law Of Diminishing 
Returns"
There is a gain, but the amount of work is disproportional.



-- 

Matthias

  parent reply	other threads:[~2013-02-06 11:07 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <mailman.6.1360140726.2399.dm-crypt@saout.de>
2013-02-06 10:06 ` [dm-crypt] Cryptographic issues with SSD-technology and wide-block encryption modes Stavros Kousidis
2013-02-06 10:32   ` Arno Wagner
2013-02-06 12:52     ` Milan Broz
2013-02-06 13:06       ` Arno Wagner
2013-02-06 11:07   ` Matthias Schniedermeyer [this message]
2013-02-06 12:45     ` Arno Wagner
2013-02-06 13:18     ` Stavros Kousidis
2013-02-06 12:38   ` Milan Broz
2013-02-06 13:34     ` Stavros Kousidis
2013-02-06 14:08       ` Milan Broz
2013-02-06 13:59     ` Stavros Kousidis
2013-02-09 14:20       ` Alex Elsayed
     [not found] <mailman.1.1360494001.22742.dm-crypt@saout.de>
2013-02-12  8:47 ` Stavros Kousidis
2013-02-12 12:41   ` Arno Wagner
     [not found] <mailman.1.1360148402.2056.dm-crypt@saout.de>
2013-02-06 13:22 ` Stavros Kousidis
2013-02-06  8:52 Stavros Kousidis

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130206110713.GA701@citd.de \
    --to=ms@citd.de \
    --cc=dabros.kuhsadas@web.de \
    --cc=dm-crypt@saout.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.