Re: Whole Disk Encryption + SSD

[David Christensen]

On 7/2/21 8:02 AM, David Wright wrote:

On Thu 01 Jul 2021 at 20:43:09 (-0700), David Christensen wrote:

On 7/1/21 7:55 PM, David Wright wrote:

On Mon 28 Jun 2021 at 13:36:35 (-0700), David Christensen wrote:


I do not set the 'discard' (trim) option in fstab(5).  If and when I
want to erase unused blocks (such as before taking an image), I use
fstrim(8).



What improvement does erasing unused blocks achieve?


Zero blocks are readily compressed, reducing the size of the image file.


Ah, I see. So a spinning rust analogy might be:

. Take an old conventional disk, sdz, where df shows 10% uasge,
. cp /dev/zero a-file-on-sdz
. rm a-file-on-sdz
. dd if=/dev/sdz … and compressing it, saving ~90% space.

But can I tweak my question a little—

Say that /dev/sdz contained one partition, sdz1, which filled the disk
and was a LUKS encrypted /home. In this case, the above would fail to
save space because the raw device sdz would be full of "random" data.

But what happens with an SSD? If, after the rm step above, you
# fstrim /home
the mountpoint, where /etc/fstab has the line
   /dev/mapper/luks-fedcba98-7654-3210-… LABEL1 ext4 /home
then what gets zeroed, the container or the contained?
I can't put my finger on any documentation that spells it out.



AIUI userland programs such as fstrim(8) interact with the kernel via an 
application programming interface (API).  Device drivers interact with 
the kernel and/or each other via device driver interfaces (DDI).  Some 
device drivers are designed to interact with hardware.  Other device 
drivers are designed to fit in between the kernel and/or device drivers 
-- for example, LVM, md, and dm-crypt.  So, you can layer ext4 on top of 
LVM on top of dm-crypt (LUKS) on top of md on top of several SSD's.



Given a file system driver that supports trim, fstrim makes an API call 
to the file system driver telling the file system driver to erase unused 
blocks.  The file system driver knows what blocks are unused and makes 
DDI calls to trim those blocks.  If everything between the file system 
driver and the SSD(s) supports trim commands, eventually the trim 
commands reach the SSD(s) and blocks are erased.  Similarly, the 
response codes must be passed upwards from the SSD(s) to the file system 
driver, which then responds to fstrim.



David

Re: Whole Disk Encryption + SSD

[Michael Stone]

On Fri, Jul 02, 2021 at 10:02:18AM -0500, David Wright wrote:

But what happens with an SSD? If, after the rm step above, you
# fstrim /home
the mountpoint, where /etc/fstab has the line
 /dev/mapper/luks-fedcba98-7654-3210-… LABEL1 ext4 /home
then what gets zeroed


If everything's appropriately configured the free sectors will be marked 
as unused by the SSD and erased for reuse.

Re: Whole Disk Encryption + SSD

[David Wright]

On Thu 01 Jul 2021 at 20:43:09 (-0700), David Christensen wrote:
> On 7/1/21 7:55 PM, David Wright wrote:
> > On Mon 28 Jun 2021 at 13:36:35 (-0700), David Christensen wrote:
> > 
> > > I do not set the 'discard' (trim) option in fstab(5).  If and when I
> > > want to erase unused blocks (such as before taking an image), I use
> > > fstrim(8).
> > 
> > Can you elaborate on a couple of things:
> > 
> > How do you "take an image". Is this equivalent to a conventional
> > dd if=/dev/sda …, or to some other process?
> 
> I wrote a script.  To "take an image", the script invokes dd(1) and
> pipes the output to gzip(1), copying raw device octets to a file.  To
> "restore an image", the process is reversed.
> 
> 
> > When I copy an entire conventional drive or partition, all the
> > free blocks/unused sectors are carefully transferred to the copy.
> 
> Same here.
> 
> 
> > What improvement does erasing unused blocks achieve?
> 
> Zero blocks are readily compressed, reducing the size of the image file.

Ah, I see. So a spinning rust analogy might be:

. Take an old conventional disk, sdz, where df shows 10% uasge,
. cp /dev/zero a-file-on-sdz
. rm a-file-on-sdz
. dd if=/dev/sdz … and compressing it, saving ~90% space.

But can I tweak my question a little—

Say that /dev/sdz contained one partition, sdz1, which filled the disk
and was a LUKS encrypted /home. In this case, the above would fail to
save space because the raw device sdz would be full of "random" data.

But what happens with an SSD? If, after the rm step above, you
# fstrim /home
the mountpoint, where /etc/fstab has the line
  /dev/mapper/luks-fedcba98-7654-3210-… LABEL1 ext4 /home
then what gets zeroed, the container or the contained?
I can't put my finger on any documentation that spells it out.

Cheers,
David.

Re: Whole Disk Encryption + SSD

[David Christensen]

On 7/1/21 7:55 PM, David Wright wrote:

On Mon 28 Jun 2021 at 13:36:35 (-0700), David Christensen wrote:


I do not set the 'discard' (trim) option in fstab(5).  If and when I
want to erase unused blocks (such as before taking an image), I use
fstrim(8).


Can you elaborate on a couple of things:

How do you "take an image". Is this equivalent to a conventional
dd if=/dev/sda …, or to some other process?


I wrote a script.  To "take an image", the script invokes dd(1) and 
pipes the output to gzip(1), copying raw device octets to a file.  To 
"restore an image", the process is reversed.




When I copy an entire conventional drive or partition, all the
free blocks/unused sectors are carefully transferred to the copy.


Same here.



What improvement does erasing unused blocks achieve?


Zero blocks are readily compressed, reducing the size of the image file.


David

Re: Whole Disk Encryption + SSD

[David Wright]

On Mon 28 Jun 2021 at 13:36:35 (-0700), David Christensen wrote:

> I do not set the 'discard' (trim) option in fstab(5).  If and when I
> want to erase unused blocks (such as before taking an image), I use
> fstrim(8).

Can you elaborate on a couple of things:

How do you "take an image". Is this equivalent to a conventional
dd if=/dev/sda …, or to some other process?

When I copy an entire conventional drive or partition, all the
free blocks/unused sectors are carefully transferred to the copy.
What improvement does erasing unused blocks achieve?

Cheers,
David.

Re: Whole Disk Encryption + SSD

[Stefan Monnier]

>> > Along with SED, I suggest that you also implement Secure Boot.

>> Can someone give me pointers to actually known attacks (not
>> hypothetical ones, which I can invent myself without much difficulty)
>> that would have been prevented by Secure Boot?

> [2] https://en.wikipedia.org/wiki/Evil_maid_attack

Thanks.


Stefan

Re: Whole Disk Encryption + SSD

[David Christensen]

On 6/29/21 5:02 AM, piorunz wrote:


I don't trust SED, after listening to Steve Gibson analysis on state of
this feature.

Audio podcast: http://media.GRC.com/sn/SN-689.mp3
Transcript: https://www.grc.com/sn/sn-689.pdf

His findings were sourced, among other things, on work of security
researchers at the Radboud University in the Netherlands, titled:
"Self-Encrypting Deception: Weaknesses in the encryption of solid-
state drives."
https://ieeexplore.ieee.org/abstract/document/8835339


Interesting.  The IEEE paper seems to cover Crucial, Samsung, and 
Western Digital/Sandisk devices.  I'm using Intel SSD 520 Series 2.5" 
SATA drives.  STFW I don't see any CVE's.



AIUI for my Intel SSD's [1], the encryption key is stored inside the 
drive controller and is inaccessible to the outside world.  Encryption/ 
decryption is always running and the bits in the storage transistors are 
always encrypted.  Performing a Secure Erase or Enhanced Secure Erase 
will clear the storage transistors and generate a new encryption key. 
The passphrase is a feature that is independent of the encryption key 
and stored bits.  The passphrase is accessible via the motherboard CMOS 
Setup program (and specific utilities).  Changing the passphrase does 
not change the encryption key nor the bits in the storage transistors; 
from a human viewpoint, it is instantaneous.  Done correctly, data 
stored on the drive remains accessible and unchanged.



I would suggest shopping for a good SSD.  Per my other post, it will 
likely have SED.  If so, verify that the drive has no known SED 
problems.  You should be able to set or clear the passphrase as desired 
(verify with testing as soon as you get the drive).



Will fstrim work with Debian-encrypted /home partition? 
fstrim will show

trimmed gigabytes, just like on normal system?
If yes then that's in, my enquiry is solved.



fstrim(8) works on an ext4 filesystem on LUKS:

2021-06-29 16:16:32 root@dipsy ~/dipsy.tracy.holgerdanske.com/etc
# fstrim -v /scratch
/scratch: 27.7 GiB (29705924608 bytes) trimmed

2021-06-29 16:18:42 root@dipsy ~
# mount | grep scratch
/dev/mapper/sda4_crypt on /scratch type ext4 (rw,relatime)

2021-06-29 16:18:49 root@dipsy ~
# grep scratch /etc/fstab
/dev/mapper/sda4_crypt  /scratch
ext4defaults0   2


If you use file systems other than ext4, you should test.



I would not worry about wearing out a good SSD in a daily driver laptop.
  I have been using Intel SSD 520 Series 2.5" SATA in my SOHO laptops,
desktops, and servers for many years; they all work and have available
lifespans in the high 90%'s.


I prefer to preserve SSD life if I can. And with this problem, it's a
matter of proper configuring it ONCE during install, and then reap the
benefits for years to come. I don't want to throw away free performance
and longevity boost.



When I first started using SSD's, I read various articles and worried 
about over-provisioning, trim, performance, lifetime, etc..  My 
experience has been that simple OOTB settings are just fine for my SOHO 
workloads.  People running servers with workloads that hammer the SSD's 
24x7 are the ones who need to worry.



David



[1] 
https://www.intel.com/content/dam/www/public/us/en/documents/technology-briefs/ssd-520-aes-tech-brief.pdf

Re: Whole Disk Encryption + SSD

[David Christensen]

On 6/29/21 12:47 AM, to...@tuxteam.de wrote:

On Mon, Jun 28, 2021 at 07:56:47PM -0400, Stefan Monnier wrote:

Along with SED, I suggest that you also implement Secure Boot.


Can someone give me pointers to actually known attacks (not
hypothetical ones, which I can invent myself without much difficulty)
that would have been prevented by Secure Boot?


Basically, subverting the unencrypted loader amounts to what is known
as "evil maid attack" [1]: the most practical variant being that the
subverted loader records your passphrase (or whatever auth thingie you
provide) and either "phones home" or stashes it away in a place your
opponent can retrieve it.

The second time they have control over your device, they can unlock
the disk.

The whole thing is well described in Wikipedia [2], along with some
accounts of actual cases.

So /if/ you leave your laptop unsupervised and have the hunch that
someone might have a chance at it, make sure you reinstall :-)

There is another, low-tech alternative to the monstrous Secure
Boot [3] thingies bandied around here: carry your real boot partition
with you, either in an USB stick or (nicer form factor) an SD card.
Bonus points: you can leave a fake boot partition in your hard disk
which can be checked at each boot; if it changed, you can go "Hmmm...
someone tried to fool me..." and perhaps send them some passphrase.
The wrong one, of course.

Cheers

[1] Yes, a sexist term, but it stuck, unfortunately. OTOH, perhaps
it's realistic in that it acknowledges that underpaid jobs are
usually carried out by women. Sigh.

[2] https://en.wikipedia.org/wiki/Evil_maid_attack

[3] I always have the impression that, with Secure Boot, Microsoft
has more control of the hardware (I paid for dearly, dammit!)
than myself. Don't ask me why, but I thoroughly dislike that
impression. So far I try to steer clear of it.



Thank you for that information.  :-)


I am reminded of the strategy of Defense in Depth [4].


SED, dm-crypt, and LUKS are mostly orthogonal to Secure Boot.  The 
former protects all or part of the drive contents, but only when the 
computer is off.  The latter protects critical system files, both when 
the computer is off and when the computer is booting and/or running.



SED provides all of the defenses dm-crypt and LUKS provide when the 
dm-crypt and LUKS partitions are on the SED.  But if the dm-crypt and 
LUKS partitions are moved off the SED in raw encrypted form (e.g. image/ 
clone), dm-crypt and LUKS have the advantage that security is preserved. 
 (If the partitions are decrypted and then moved -- e.g. backup/ 
restore -- security is lost.)



The only way to get all of the defenses is to implement all of the 
technologies -- SED, dm-crypt, LUKS, and Secure Boot.



This should be possible with Debian and a ~5 year old laptop -- SED is a 
purchasing decision, the laptop should have UEFI firmware that supports 
SED and Secure Boot, and Debian 10 supports Secure Boot, dm-crypt and 
LUKS.  But, as always, the only way to find out for a specific 
combination of Debian installer and computer is to try it.



David


[4] https://en.wikipedia.org/wiki/Security-in-depth

Re: Whole Disk Encryption + SSD

[piorunz]

Hi David,

Thanks for your reply.

On 28/06/2021 21:36, David Christensen wrote:


Software encryption (dm-crypt, Linux Unified Key System (LUKS), etc.)
for a system drive is typically applied to the swap, root, and/or data
partitions, but the master boot record (partition table and boot
loader), extensible firmware interface (EFI) system partition contents,
and boot partition contents are plaintext and easily modified by an
attacker with physical access.  You will want a CPU with AES-NI or
equivalent to accelerate encryption/ decryption (should get 90%+
performance).  Without AES-NI, performance will be fractional.


Thanks. I will check out AES-NI on this CPU.


The simplest way to protect a drive at rest (e.g. powered off) is to get
a self-encrypting drive (SED).  The motherboard firmware prompts for the
passphrase after the power on self test (POST) and before reading the
drive.  Once the SED passphrase is entered, the entire drive appears as
plaintext.  Encryption/ decryption is handled by hardware inside the
drive controller, at full performance.


I don't trust SED, after listening to Steve Gibson analysis on state of
this feature.

Audio podcast: http://media.GRC.com/sn/SN-689.mp3
Transcript: https://www.grc.com/sn/sn-689.pdf

His findings were sourced, among other things, on work of security
researchers at the Radboud University in the Netherlands, titled:
"Self-Encrypting Deception: Weaknesses in the encryption of solid-
state drives."
https://ieeexplore.ieee.org/abstract/document/8835339


I do not set the 'discard' (trim) option in fstab(5).  If and when I
want to erase unused blocks (such as before taking an image), I use
fstrim(8).


Yes, I use fstrim on weekly basis via crontab on all my SSD based
computers. I don't use discard option in fstab.
Will fstrim work with Debian-encrypted /home partition? fstrim will show
trimmed gigabytes, just like on normal system?
If yes then that's in, my enquiry is solved.


I would not worry about wearing out a good SSD in a daily driver laptop.
  I have been using Intel SSD 520 Series 2.5" SATA in my SOHO laptops,
desktops, and servers for many years; they all work and have available
lifespans in the high 90%'s.


I prefer to preserve SSD life if I can. And with this problem, it's a
matter of proper configuring it ONCE during install, and then reap the
benefits for years to come. I don't want to throw away free performance
and longevity boost.


Along with SED, I suggest that you also implement Secure Boot.  This
provides cryptographic signatures and chain of trust for critical files,
such as boot loaders and the kernel, whenever those files are to be
executed (e.g. boot, dynamic loading, etc.).


Thanks, I plan to use that. I already use it on my desktop.

--

With kindest regards, piorunz.

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org
⠈⠳⣄

Re: Whole Disk Encryption + SSD

[Jonathan Dowland]

On Mon, Jun 28, 2021 at 01:36:35PM -0700, David Christensen wrote:
I do not set the 'discard' (trim) option in fstab(5).  If and when I 
want to erase unused blocks (such as before taking an image), I use 
fstrim(8).


I believe this is installed and enabled by default in Bullseye (at least
new installs from currently released Bullseye install media).



--
Please do not CC me for listmail.

  Jonathan Dowland
✎j...@debian.org
   https://jmtd.net

Re: Whole Disk Encryption + SSD

[tomas]

On Mon, Jun 28, 2021 at 07:56:47PM -0400, Stefan Monnier wrote:
> > Along with SED, I suggest that you also implement Secure Boot.
> 
> Can someone give me pointers to actually known attacks (not
> hypothetical ones, which I can invent myself without much difficulty)
> that would have been prevented by Secure Boot?

Basically, subverting the unencrypted loader amounts to what is known
as "evil maid attack" [1]: the most practical variant being that the
subverted loader records your passphrase (or whatever auth thingie you
provide) and either "phones home" or stashes it away in a place your
opponent can retrieve it.

The second time they have control over your device, they can unlock
the disk.

The whole thing is well described in Wikipedia [2], along with some
accounts of actual cases.

So /if/ you leave your laptop unsupervised and have the hunch that
someone might have a chance at it, make sure you reinstall :-)

There is another, low-tech alternative to the monstrous Secure
Boot [3] thingies bandied around here: carry your real boot partition
with you, either in an USB stick or (nicer form factor) an SD card.
Bonus points: you can leave a fake boot partition in your hard disk
which can be checked at each boot; if it changed, you can go "Hmmm...
someone tried to fool me..." and perhaps send them some passphrase.
The wrong one, of course.

Cheers

[1] Yes, a sexist term, but it stuck, unfortunately. OTOH, perhaps
   it's realistic in that it acknowledges that underpaid jobs are
   usually carried out by women. Sigh.

[2] https://en.wikipedia.org/wiki/Evil_maid_attack

[3] I always have the impression that, with Secure Boot, Microsoft
   has more control of the hardware (I paid for dearly, dammit!)
   than myself. Don't ask me why, but I thoroughly dislike that
   impression. So far I try to steer clear of it.

-- tomás


signature.asc
Description: Digital signature

Re: Whole Disk Encryption + SSD

[Stefan Monnier]

> Along with SED, I suggest that you also implement Secure Boot.

Can someone give me pointers to actually known attacks (not
hypothetical ones, which I can invent myself without much difficulty)
that would have been prevented by Secure Boot?

I can see that subverting the early boot might be a good way for
rootkits to install themselves in a way that's hard to detect and/or
remove, but it's not like there aren't plenty of other ways to get
pretty much the same result.

IOW it sounds to me a bit like putting a reinforced steel frame around
a cardboard door.


Stefan

Re: Whole Disk Encryption + SSD

[David Christensen]

On 6/28/21 1:36 PM, David Christensen wrote:


(Dell factory default for drives is 'RAID'; 'ACPI' may be required).


Correction: AHCI.


David

Re: Whole Disk Encryption + SSD

[David Christensen]

On 6/28/21 7:52 AM, piorunz wrote:

Hi all,

I've got about 5 years old HP laptop with SSD SATA drive 240 GB. Debian
Bullseye will be installed on it once it's released, as my secondary
computer to use.
I have question regarding whole disk encryption. What technology should
I use, to have encryption of everything, or at least /home, but preserve
free blocks and have TRIM? I don't want encryption to use entire drive
as "full" blob, I want to preserve SSDs life. What solutions should I
use? Thanks!


Booting a computer involves the motherboard firmware and one or more 
stages of on-disk boot loaders.  Boot loader stages, initial RAM 
filesystem (initramfs), kernel, device drivers, system configuration 
files, etc., must be available as plaintext when needed.



Software encryption (dm-crypt, Linux Unified Key System (LUKS), etc.) 
for a system drive is typically applied to the swap, root, and/or data 
partitions, but the master boot record (partition table and boot 
loader), extensible firmware interface (EFI) system partition contents, 
and boot partition contents are plaintext and easily modified by an 
attacker with physical access.  You will want a CPU with AES-NI or 
equivalent to accelerate encryption/ decryption (should get 90%+ 
performance).  Without AES-NI, performance will be fractional.



The simplest way to protect a drive at rest (e.g. powered off) is to get 
a self-encrypting drive (SED).  The motherboard firmware prompts for the 
passphrase after the power on self test (POST) and before reading the 
drive.  Once the SED passphrase is entered, the entire drive appears as 
plaintext.  Encryption/ decryption is handled by hardware inside the 
drive controller, at full performance.



I do not set the 'discard' (trim) option in fstab(5).  If and when I 
want to erase unused blocks (such as before taking an image), I use 
fstrim(8).



I would not worry about wearing out a good SSD in a daily driver laptop. 
 I have been using Intel SSD 520 Series 2.5" SATA in my SOHO laptops, 
desktops, and servers for many years; they all work and have available 
lifespans in the high 90%'s.



Along with SED, I suggest that you also implement Secure Boot.  This 
provides cryptographic signatures and chain of trust for critical files, 
such as boot loaders and the kernel, whenever those files are to be 
executed (e.g. boot, dynamic loading, etc.).



Reset the CMOS settings to factory defaults, enable/ verify Unified EFI 
(UEFI) mode, enable/ verify Secure Boot, and boot the Debian Installer 
(d-i).  Hopefully, everything should Just Work.  If not, you may have to 
modify the drive settings (Dell factory default for drives is 'RAID'; 
'ACPI' may be required).  Take good notes, STFW, RTFM, and/or post here 
if you have problems.  Post your solution when you figure it out.



David

Re: Whole Disk Encryption + SSD

[Jochen Spieker]

piorunz:
> 
> I have question regarding whole disk encryption. What technology should
> I use, to have encryption of everything, or at least /home, but preserve
> free blocks and have TRIM?

The canonical answer is "LUKS". You can configure it during installation
if you want to. I always use LVM as well. It is up to you whether you
want to use LVM on LUKS or the other way round.

I am not sure how well full-disk encrpytion is supported nowadays. For
common scenarios (like loss or simple theft of the storage medium, no
state-level attackers) you do not need it, in my opinion.

Oh, the buster release notes mention that encrypted /boot is not
supported, everything else may be encrypted, even the root filesystem.

https://www.debian.org/releases/buster/amd64/ch06s03.en.html#partman-crypto

If you think you need protection against somebody tampering with your
boot loader and/or kernel, you need to configure Secure Boot which I
have never really looked at. I guess this is overkill for now.

> I don't want encryption to use entire drive
> as "full" blob, I want to preserve SSDs life.

I am not sure what this means and whether there is any relation between
"full blob" and life-preserving measures. But let me assure you that
your SSD will be fine, not matter how you are setting up encryption. You
can set up both LUKS and LVM to pass through the "discard" command which
you need for TRIM to work and this is more of a performance measure than
a method to reliably lengthen the lifespan of your SSD.

How long do you think you will need your SSD? I recently removed an
Intel X25m from an old system. It was more than ten years old and was
first used heavily in a laptop and later on ran 24/7 for several years
as OS drive in a NAS system. And that SSD didn't even support TRIM!

Do not worry about the lifetime of your SSD.  Worry about backups.

You use LUKS by telling it which disk partition it should encrypt. You
then get a new logical block device which you can treat like any "real"
partition. Most importantly, you can create a regular filesystem on it
(or an LVM physical volume) which is encrypted before anything is
written to the physical disk. The amount of free space in your
filesystem is not dependent on having a LUKS container beneath it.

> What solutions should I
> use? Thanks!

Get familiar with LUKS and possibly LVM. There are options like ecryptfs
which work on regular filesystem and encrypt individual files as well as
their names. But those are 

-- 
When standing at the top of beachy head I find the rocks below very
attractive.
[Agree]   [Disagree]
 


signature.asc
Description: PGP signature