[plug] Self encrypting drives

[David Godfrey]

Hi Brad,

I believe this didn't go through last time, something about html content.
So lets try again

Interesting info.

FYI below I have a quickly hacked together revision for your script.

As I don't have any drives with SED capabilities I haven't tested it,
but it should be pretty close.


|#!/bin/bash||
||
||SEDU=/usr/local/bin/sedutil-cli||
||do_start () {||
||    while read -t5 Line; do||
||        Dev=${Line%% *}||
||        if [[ $Dev =~ '\/dev\/' ]]; then||
||            wasLocked=false||
||            while read -t5 qLine; do||
||                if [[ $qLine =~ 'Locked = Y' ]] ; then||
||                    echo "$Dev Locked"||
||                    if [ -z "$KEY" ] ; then||
||                        KEY=`get-key-script`||
||                    fi;||
||                    $SEDU --setlockingrange 0 rw $KEY $Dev||
||                    $SEDU --setMBRDone on $KEY $Dev||
||                    /sbin/blockdev --rereadpt $Dev||
||                    wasLocked=true;||
||                fi||
||            done < <($SEDU --query $Dev)||
||            if $wasLocked; then||
||                echo "$Dev Already Unlocked"||
||            fi;||
||        fi||
||    done < <( $SEDU --scan )||
||}||
|

Regards

David G


On 20/01/17 15:54, Brad Campbell wrote:
> G'day all,
>
> I run (ran) LUKS/dm-crypt on all my data drives, swap and basically
> anything other than boot/root on all my machines.
>
> The 6 year old root SSD on my desktop started to crap out yesterday,
> so I replaced both root and home drives with a pair of new Samsung
> 850's. These shiny new drives support SED, so I thought I'd have a
> crack at replacing dm-crypt on the home drive with SED, and I thought
> it might be of interest so I made some notes.
>
> My machines are relatively archaic, so I couldn't get sedutil to
> compile from source because of way out of date header files. I didn't
> actually try very hard, I just used their pre-compiled cli binary.
>
> Because I'm only encrypting a data drive I don't need the pre-boot
> environment or any of that complexity. Nor do I need this to come up
> in the initramfs.
>
> I set the drive up with --initialsetup, then enabled encryption with
> --enableLockingRange 0. I thought I'd be clever and not bother
> enabling the fake MBR as I didn't need the PBE. *Big* mistake. Booting
> a kernel with a locked drive that does not have the MBR enabled spends
> about 30 seconds spewing ATA errors into the logs as it tries over and
> over again to read the MBR. This is not a trickle, rather a continuous
> blast.
>
> So, *always* enable the fake mbr (--setMBREnable on) when you encrypt
> the drive.
>
> To unlock the disk, I've created a little initscript that runs very
> early in the boot process that basically contains the following
> (excuse the gross bash) :
>
> SEDU=/usr/local/bin/sedutil-cli
> do_start () {
>     for i in `$SEDU --scan | awk '{print $1}' | grep '/dev/'` ; do
>         if [ -n "`$SEDU --query $i | grep 'Locked = Y'`" ] ; then
>             echo $i Locked
>             if [ -z "$KEY" ] ; then
>                 KEY=`get-key-script`
>             fi;
>             $SEDU --setlockingrange 0 rw $KEY $i
>             $SEDU --setMBRDone on $KEY $i
>             /sbin/blockdev --rereadpt $i
>         else
>             echo $i Already Unlocked
>         fi;
>     done;
> }
>
> This uses sedutil to get a list of all drives that support SED, it
> then iterates them to see if any are locked and if so it proceeds to
> unlock them. No point trying to unlock an already unlocked drive, and
> as I rarely power cycle my machines on most boots they'll already be
> unlocked.
>
> It's important to re-read the partition table after unlocking and
> swapping the MBRs.
>
> The only thing this loses over using dm-crypt is the machine is now
> susceptible to power-on attacks. So you can soft-boot it into another
> OS and get access to the disk. For my particular threat model that's
> not an issue. I'm more worried by someone breaking in and walking away
> with the box, and if they do that I'm covered.
>
> Encrypting the drive is really just enabling the locking and setting a
> key, so there is no data loss or other interaction required with the
> disk.
>
> Regards,
> Brad
> _______________________________________________
> PLUG discussion list: plug at plug.org.au
> http://lists.plug.org.au/mailman/listinfo/plug
> Committee e-mail: committee at plug.org.au
> PLUG Membership: http://www.plug.org.au/membership
>