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

Tue Apr 5 02:15:15 UTC 2016

I may be able to  answer some of the questions here:

1.       Does UEFI support HDD password?

Yes and No.  UEFI is extensible, such that new drivers can be added to the firmware image.  Theoretically, one such driver could transfer a password from Firmware to the HDD directly (if technically possible - I do not know how the HDD receives its password, so if the mechanism is strict or proprietary it may not be technically possible to perform the operation).  So, to do this will require the driver writer to understand the mechanism which stores the password in the system as well as the mechanism to transfer that password to the HDD.  This assumes a lot of specifics which may or may not be true.   I do not believe such a driver has been written already, so it will be a new development.

Example: The password could be stored in a non-volatile UEFI variable (possibly even as an authenticated variable).  But that storage is NOT protected, and someone with the right knowledge and tools, who can get to the shell on your platform could possibly retrieve that data.   Per you question about TPM, a greater answer awaits that question, but for this part of this question, it should be possible to store a password (like a key) in the fTPM, but fTPM is implemented such that the key storage is a one way trip.  You can put data into the storage, but you cannot retrieve the data, but rather you can ask the fTPM to confirm the key/hash you have against the data in the store (but that data is never exposed).    This is not useful to your needs.

As for passing the password to the HDD, that is a question of how the HDD receives its password.  If the mechanism is documented so you can bypass the keyboard entry implementation, and put your own driver in place to send the password directly to the drive, then it should be possible.  However, that is a function of the HDD and the software interface around that HDD device (and not a function of the UEFI firmware).  It may even be that the HDD does not allow input of the password, except by keyboard, as that would ensure that the person on the system at boot actually has authorization to the data.

Your requested implementation is not a standard feature of any system I am aware of, so the hardware may not be compatible with this kind of solution.  Most people who have HDD protection, are not as interested in making it platform specific as they are in protecting the data from access by anyone not authorized.  Many security people would consider this kind of implementation a security fault, as the data is open to anyone as long as the drive stays with the platform.

2.       (several questions) Is it possible to modify UEFI firmware to bypass entering the password by hard-coding it in the UEFI firmware?

As stated before the UEFI firmware is provided in an open source format, and the build can be modified.   If such drivers (as described above) are technically possible (per the HDD interface and other requirements), then the firmware can be modified to run the driver and perform the operation.   And as stated above, it will probably take an application to get the password into storage to begin with.  So you would have to design the entire implementation, including recovery options should the firmware be re-programmed, and other real world possibilities.

Is TPM support by MinnowBoard Turbot?

The MinnowBoard MAX and Turbot do not have TPM onboard.  There is some support for adding a TPM, through the I2S bus, but I do not have the details.  The MinnowBoards do have a form of TPM through the processor, this feature is referred to as fTPM (firmware TPM).  This means that there is no discrete TPM part on the either MinnowBoard product, but rather the processor has a TPM emulation built into it.

Originally, the MinnowBoard MAX was to be a non-secure system, and a discrete TPM was considered an unnecessary additional cost on the board.  However the fTPM feature was a low cost mechanism to provide UEFI secure boot, when that became a feature requirement by some customers.   The fTPM feature support was added to the MinnowBoard in the 0.80 firmware release (May 2015).  The firmware release notes (from 0.80 on) include a discussion of how to enable the fTPM feature.  However, I doubt this will meet your needs (per discussion in question #1).

3.       Is there no way to protect the firmware from reading and flashing?

The firmware SPI part itself is not protected.  There is a connector on the board itself that allows the user to update the SPI directly via a programmer, or SPI writing utility.  Beyond this, the MinnowBoard MAX/Turbot was not designed to be a 'hardened system' in fact quite the opposite, as the platform was designed with experimenters in mind, allowing them access to as much of the hardware as possible.   There are no protections in the software for the SPI write access.  And considering that the SPI contains the pre-boot execution code, even less protections against reading the part.

So putting a password in the SPI flash, would be placing it on a storage that is not necessarily secure, or even safe (if someone re-flashes the firmware, the password could be lost.

Bottom line: The UEFI standard allows for a lot of customization of firmware, and it may be possible to implement your new feature (in some form).  However, it is not something that you will likely find "on the shelf" and will require research, solution planning/designing, and custom firmware development.  It may also require some additional hardware to be added to the board to safely and securely store and retrieve the password.

Sincerely,

Michael Krau

While I am an Intel employee, I do not represent Intel and am not authorized to speak for Intel.

From: elinux-MinnowBoard [mailto:elinux-minnowboard-bounces at lists.elinux.org] On Behalf Of Abdelghani Ouchabane
Sent: Monday, April 04, 2016 6:45 AM
To: MinnowBoard Development and Community Discussion <elinux-minnowboard at lists.elinux.org>; Hawley, John <john.hawley at intel.com>
Subject: Re: [MinnowBoard] MinnowBoard Turbot & mSATA self encrypted SSD & UEFI

On 01/04/16 19:39, John Hawley wrote:

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.
Thanks john.

Well, as I understood that: the data encrypt and decrypt is automatically done on a hard drive (it works regardless of the motherboard), but SEDs also allow you to set what is called an Authentication Key (AK) which acts as a password that locks the drive until the key is entered. And the board has to have the ability to enter the Authentication Key, and this should be implemented in the UEFI.

Please correct me if I am wrong.

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
Sure, I am want to protect the content of the SSD, so the user will not be able to look into its data and only my system can boot and read the content of the SSD.

So, if the drive is plugged into a different computer the drive will still require the AK to be entered in order for the drive to unlock.

a quick glance, what you are proposing only really protects you against

a drive being separated from the board permanently, and it being forever
Right

"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
is TPM support by MinnowBoard Turbot?

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.
Do you mean filesystem/disk encryption?

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.
I see

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
So, there is no way to protect the firmware from reading and flashing.

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<mailto:elinux-MinnowBoard at lists.elinux.org>

http://lists.elinux.org/mailman/listinfo/elinux-minnowboard

_______________________________________________

elinux-MinnowBoard mailing list

elinux-MinnowBoard at lists.elinux.org<mailto:elinux-MinnowBoard at lists.elinux.org>

http://lists.elinux.org/mailman/listinfo/elinux-minnowboard

This email has been scanned by Barracuda Networks.   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.elinux.org/pipermail/elinux-minnowboard/attachments/20160405/3879c863/attachment-0001.html>