[MinnowBoard] MinnowBoard Turbot & mSATA self encrypted SSD & UEFI

[John Hawley]

Inline -JH

On 4/1/2016 8:40 AM, Abdelghani Ouchabane wrote:
> Hallo for all,
>   I am planning to plug in a mSATA self encrypted SSD to the board but I
> have some concerns:
> 
> 1. As I understood a self encrypted SSD works without any setup and
> configuration but the user needs to protect the drive's access with a
> HDD password, so my question is:  does  UEFI support HDD password?

To be honest, I'm not sure how most hard drives handle this, there's a
couple of possible ways, but I don't believe it's the responsibility of
the firmware to directly include this kind of support.  I.E. the
solution should be firmware agnostic, or the support burden for these
drives may never reach other machines.  It's possible someone from the
firmware team, who's on the list, knows something I don't and will
contradict me here, but I'm pretty sure the unlocking probably happens,
effectively, as a first stage boot loader on the drive - so it's
possible it's completely outside the firmware's hands even, as it may
(effectively) be passed off to the real boot loader already.

> 2. If yes, I want to have non-interactive boot, I mean the user will not
> have to enter the password on every boot, is it possible to modify UEFI
> firmware to bypass entering the password by hard-coding it in the UEFI
> firmware?

It's going to be hard to have any reasonable discussion on this point
without understanding the threat model you are worrying about here.  At
a quick glance, what you are proposing only really protects you against
a drive being separated from the board permanently, and it being forever
"locked".  I suppose something similar could be accomplished by
encrypting the drive based on a key from the TPM, but that's a level of
interaction I don't believe I've seen in production, and I don't believe
a SED would work well in that case, as I don't believe SATA has a good
communications channel to the TPM.

Either way I'm not sure, with a SED, you can hard-code the password into
the firmware without a fair amount of work to accomplish this, and you'd
be stuck on the hook to support your custom firmware going forward.

I've seen some suggestions / thoughts on software encrypted drives, such
as luks volumes under Linux, being modified to read key data from usb
keys that are plugged into the system, but that's a purely software
encryption solution (though that has the advantage of being slightly
more flexible in the general sense), but again doesn't have any direct
correlation to the firmware.

> 3. Is it possible to lock the UEFI firmware's flashing in the
> MinnowBoard Turbot, so none can flash UEFI firmware without password?

Considering that the Turbot has a physical header where the entire
firmware flash can be read/written to, I'm not sure there's really a way
to lock the firmware the way you are intending, but this might be a moot
point based on questions #1 and #2

> 
> Many thanks in advance
> 
> My best regards
> Ghani
> 
> This email has been scanned by Barracuda Networks.
> _______________________________________________
> elinux-MinnowBoard mailing list
> elinux-MinnowBoard at lists.elinux.org
> http://lists.elinux.org/mailman/listinfo/elinux-minnowboard