[dm-crypt] Prepare SSD for encrypted linux install

[dm-crypt] Prepare SSD for encrypted linux install

[Merlin Büge]

Hello all,


I want to use an SSD (Samsung 850 PRO 512GB) for a fully encrypted Linux
system. I've read the cryptsetup FAQ and various posts in the
internet and I'm familiar with the common problems/pitfalls regarding
dm-crypt on SSDs.

To avoid information leakage about the storage device's usage patterns,
it is generally recommended to fill the entire device with random data
before setting up encryption. It is also recommended to issue an 'ATA
secure erase' to SSDs before using it to avoid performance issues.

But doing these two things, either my (1) random data gets 'deleted' via
the (2) 'ATA secure erase' (the SSD will report all zeros), or I end up
with degraded performance when (1) issuing 'ATA secure erase' before
(2) putting random data on it.

I thought of TRIMing the SSD via 'blkdiscard' instead of using
'ATA secure erase' after putting random data on it (twice, see [0]),
but that should make no difference, since the SSD will most probably
report all zeros for TRIMed sectors. Either way, the flash chips will
contain all random data (making it impossible to distinguish encrypted
data from free space) but the drive controller will still report all
zeros for the entire SSD (making it possible to distinguish encrypted
data from free space).

(Note: I'm assuming that an 'ATA secure erase' does not actually empty
the flash cells, but merely changes the internal encryption key. I'm not
sure on this, but it doesn't really matter.)

Any solution/thoughts on this?


Regards,

Merlin



[0]
"Second, overwriting the entire visible address space of an SSD twice
is usually, but not always, sufficient to sanitize the drive."
https://www.usenix.org/legacy/events/fast11/tech/full_papers/Wei.pdf


-- 
Merlin Büge <toni@bluenox07.de>

Re: [dm-crypt] Prepare SSD for encrypted linux install

[Heinz Diehl]

On 08.11.2017, Merlin Büge wrote: 

> To avoid information leakage about the storage device's usage patterns,
> it is generally recommended to fill the entire device with random data
> before setting up encryption. It is also recommended to issue an 'ATA
> secure erase' to SSDs before using it to avoid performance issues.

As far as I know (and the fine people here on the list will surely
correct me if I'm wrong), there is no need to do anything else than
partitioning your SSD and establish a crypto device via device mapper.

Of course, somebody with access to your harddisk will be able to
identify which blocks are real data and which are not, but it won't
have any impact on the security of our data unless the underlying
device mapper has a major bug or the crypto is broken. Most of the
"security flaws" are more of an academic nature. Yes, TRIM does make
it possible to gather data on patterns of disk usage. It may also be
possible to identify (or guess) the underlying filesystem. But does
this ultimately lead to data access? Most probably not.

Wear levelling is often discussed to be a problem, because old data
may linger somewhere in the dark depth of memory cells. As long as
you don't change the password/keyslot and a password with enough
entropy is used, I can see no real danger.

Most of the encrypted data is being "decrypted" because of keyloggers,
physical access to the machine while running, trojans, viruses and
weak passwords - and not because of using an SSD. Attacking the crypto
itself is plain stupid, unless you have found the holy grail of
mathematics.

Cheers,
 Heinz
 

Re: [dm-crypt] Prepare SSD for encrypted linux install

[David Christensen]

On 11/08/17 09:36, Merlin Büge wrote:
> I want to use an SSD (Samsung 850 PRO 512GB) for a fully encrypted Linux
> system. I've read the cryptsetup FAQ and various posts in the
> internet and I'm familiar with the common problems/pitfalls regarding
> dm-crypt on SSDs.
> 
> To avoid information leakage about the storage device's usage patterns,
> it is generally recommended to fill the entire device with random data
> before setting up encryption. It is also recommended to issue an 'ATA
> secure erase' to SSDs before using it to avoid performance issues.
> 
> But doing these two things, either my (1) random data gets 'deleted' via
> the (2) 'ATA secure erase' (the SSD will report all zeros), or I end up
> with degraded performance when (1) issuing 'ATA secure erase' before
> (2) putting random data on it.
> 
> I thought of TRIMing the SSD via 'blkdiscard' instead of using
> 'ATA secure erase' after putting random data on it (twice, see [0]),
> but that should make no difference, since the SSD will most probably
> report all zeros for TRIMed sectors. Either way, the flash chips will
> contain all random data (making it impossible to distinguish encrypted
> data from free space) but the drive controller will still report all
> zeros for the entire SSD (making it possible to distinguish encrypted
> data from free space).
> 
> (Note: I'm assuming that an 'ATA secure erase' does not actually empty
> the flash cells, but merely changes the internal encryption key. I'm not
> sure on this, but it doesn't really matter.)
> 
> Any solution/thoughts on this?

Choosing between randomizing, secure erase, trim, zerofree, etc., is a 
matter of balancing conflicting goals -- security, performance, 
longevity, maintenance, etc..


Filling an SSD with random bytes and then doing a secure erase will 
produce nearly the same result as doing a secure erase alone (a drive 
full of zero's), but wastes one erase/write cycle of the cells written.


Doing a secure erase and then filling an SSD with random bytes will 
produce nearly the same result as filling the drive with random bytes 
alone (a drive full of random bytes), but wastes one write/erase cycle 
of all drive storage cells and limits available erased cells to those 
kept in reserve by the SSD controller (see below).


Random filling unused blocks is a form of steganography [1], which some 
believe makes brute-force attacks harder.  (Finding weaknesses in the 
science or technology makes brute-force attacks easier.)  But, it is my 
understanding that successful brute-force attacks are uncommon -- most 
successful attacks involve obtaining the passphrase (through psychology, 
espionage, interrogation, blackmail, extortion, torture, etc.).


SSD's require erased cells to write data.  The SSD controller maps drive 
blocks to cells.  There are more cells than there are drive blocks.  The 
difference is hidden from your operating system by the controller.  This 
allows the controller to erase dirty cells in the background and 
maintain a pool of erased cells for future writes.  If your operating 
system is doing a lot of writes and the pool of erased cells runs out, 
writes will stall while dirty blocks are erased.  This can cause 
operating system write timeout failures, and can easily snowball if the 
device is a system drive and/or swap device.  If your workload involves 
heavy writes and/or swapping, use devices separate from your system 
drive and consider "over-provisioning" [2]


Cells are rated for a finite number of erase/write cycles, so it is best 
to conserve them.


Drive imaging is a useful technique for system provisioning and disaster 
preparedness/ recovery.  Trimmed blocks read as zeros, which compress 
nicely; thus saving time and storage requirements.


I use Debian 9 GNU/Linux for my SOHO network, as described below.


For my system drives:

1.  I prefer 16~60 GB SSD's for workstations.  For headless servers, USB 
3.0 flash drives are a cheap alternative.

2.  I backup the data and/or take an image.

3.  If the device supports secure erase and I have the right tool, I 
erase the device.

4.  I use the Debian installer:

     a.  MBR partition table/ boot block (default).

     b.  ~1 GB partition with btrfs for /boot.

     c.  ~1 GB partition with LUKS (random key) for swap.  If the device 
does not support trim, I randomize the partition.

     d.  10~12 GB partition with LUKS (passphrase) and btrfs for root. 
If the device does not support trim, I randomize the partition.


I was using 1.5 TB HDD, LUKS, and btrfs for data drives.  I believe I 
created them with Debian 7.  I have experienced weirdness using these 
drives with Debian 9.  The btrfs on my Debian 9 system drives was 
created by Debian 9, and I haven't seen any weirdness yet, but I'm 
having doubts about btrfs.


I recently migrated the data in my primary file server to two 1.5 TB 
HDD's in mdadm RAID 1, LUKS, and ext4.  So far, it has been very stable.


My backups, archives, and images are on 3 TB HDD's, GPT, LUKS, and ext4. 
  The drives are mounted in mobile docks and I use a rotation scheme. 
These are also very stable.


HTH,

David


References:

[1] https://en.wikipedia.org/wiki/Steganography

[2] https://duckduckgo.com/?q=ssd+over+provisioning&t=ffsb&ia=web

Re: [dm-crypt] Prepare SSD for encrypted linux install

[Robert Nichols]

On 11/08/2017 11:36 AM, Merlin Büge wrote:
> Hello all,
> 
> 
> I want to use an SSD (Samsung 850 PRO 512GB) for a fully encrypted Linux
> system. I've read the cryptsetup FAQ and various posts in the
> internet and I'm familiar with the common problems/pitfalls regarding
> dm-crypt on SSDs.
> 
> To avoid information leakage about the storage device's usage patterns,
> it is generally recommended to fill the entire device with random data
> before setting up encryption. It is also recommended to issue an 'ATA
> secure erase' to SSDs before using it to avoid performance issues.
> 
> But doing these two things, either my (1) random data gets 'deleted' via
> the (2) 'ATA secure erase' (the SSD will report all zeros), or I end up
> with degraded performance when (1) issuing 'ATA secure erase' before
> (2) putting random data on it.
> 
> I thought of TRIMing the SSD via 'blkdiscard' instead of using
> 'ATA secure erase' after putting random data on it (twice, see [0]),
> but that should make no difference, since the SSD will most probably
> report all zeros for TRIMed sectors. Either way, the flash chips will
> contain all random data ...

No, they won't. They will all be cleared. The whole point of TRIM or blkdiscard is to allow the controller to clear the blocks of flash cells so that they will be immediately available for writing when needed. Writing random data to the flash cells and then immediately clearing them is fairly pointless. All it does is mask any residue a cleared cell might have of the last data it contained. People who need that level of security don't ask about it here.

-- 
Bob Nichols     "NOSPAM" is really part of my email address.
                 Do NOT delete it.

Re: [dm-crypt] Prepare SSD for encrypted linux install

[Arno Wagner]

On Thu, Nov 09, 2017 at 01:34:38 CET, Robert Nichols wrote:
> On 11/08/2017 11:36 AM, Merlin Büge wrote:
> >Hello all,
...
> >I thought of TRIMing the SSD via 'blkdiscard' instead of using
> >'ATA secure erase' after putting random data on it (twice, see [0]),
> >but that should make no difference, since the SSD will most probably
> >report all zeros for TRIMed sectors. Either way, the flash chips will
> >contain all random data ...
> 
> No, they won't.  They will all be cleared.  The whole point of TRIM or
> blkdiscard is to allow the controller to clear the blocks of flash cells
> so that they will be immediately available for writing when needed. 
> Writing random data to the flash cells and then immediately clearing them
> is fairly pointless.  All it does is mask any residue a cleared cell might
> have of the last data it contained.  People who need that level of
> security don't ask about it here.

And that is just it: To get any security benefit, the random
data must be still there on a read-back. 

Hence the procedure is exactly the same as for a HDD:
Write random data to disk and leave it there, no "secure" erase,
no TRIM.

Regards,
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] Prepare SSD for encrypted linux install

[Merlin Büge]

Thank you all for your detailed answering, I appreciate it.


It seems I have some misunderstandings regarding how SSDs work
internally. Will do further reading :)

By the way my question was more of an 'academic' nature, I'm aware I
certainly don't need that level of security, I was just thinking about
it after reading a lot about it.


> > report all zeros for TRIMed sectors. Either way, the flash chips
> > will contain all random data ...
> 
> No, they won't. They will all be cleared.

Of course... now I read about it, it's clear to me.


For my setup, I will just do an ATA secure erase before using the drive.


Thanks again,

Merlin




On Wed, 8 Nov 2017 18:34:38 -0600
Robert Nichols <rnicholsNOSPAM@comcast.net> wrote:

> On 11/08/2017 11:36 AM, Merlin Büge wrote:
> > Hello all,
> > 
> > 
> > I want to use an SSD (Samsung 850 PRO 512GB) for a fully encrypted
> > Linux system. I've read the cryptsetup FAQ and various posts in the
> > internet and I'm familiar with the common problems/pitfalls
> > regarding dm-crypt on SSDs.
> > 
> > To avoid information leakage about the storage device's usage
> > patterns, it is generally recommended to fill the entire device
> > with random data before setting up encryption. It is also
> > recommended to issue an 'ATA secure erase' to SSDs before using it
> > to avoid performance issues.
> > 
> > But doing these two things, either my (1) random data gets
> > 'deleted' via the (2) 'ATA secure erase' (the SSD will report all
> > zeros), or I end up with degraded performance when (1) issuing 'ATA
> > secure erase' before
> > (2) putting random data on it.
> > 
> > I thought of TRIMing the SSD via 'blkdiscard' instead of using
> > 'ATA secure erase' after putting random data on it (twice, see [0]),
> > but that should make no difference, since the SSD will most probably
> > report all zeros for TRIMed sectors. Either way, the flash chips
> > will contain all random data ...
> 
> No, they won't. They will all be cleared. The whole point of TRIM or
> blkdiscard is to allow the controller to clear the blocks of flash
> cells so that they will be immediately available for writing when
> needed. Writing random data to the flash cells and then immediately
> clearing them is fairly pointless. All it does is mask any residue a
> cleared cell might have of the last data it contained. People who
> need that level of security don't ask about it here.
> 
> -- 
> Bob Nichols     "NOSPAM" is really part of my email address.
>                  Do NOT delete it.
> 
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt


-- 
Merlin Büge <toni@bluenox07.de>

Re: [dm-crypt] Prepare SSD for encrypted linux install

[Arno Wagner]

On Thu, Nov 09, 2017 at 12:05:55 CET, Merlin Büge wrote:
> 
> Thank you all for your detailed answering, I appreciate it.
> 
> 
> It seems I have some misunderstandings regarding how SSDs work
> internally. Will do further reading :)
> 
> By the way my question was more of an 'academic' nature, I'm aware I
> certainly don't need that level of security, I was just thinking about
> it after reading a lot about it.

No problem. Such questions are welcome here as well. 

Regards,
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