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

Wed Apr 6 18:21:09 UTC 2016

Condensing the discussion to the now open elements:

Is it TPM 1.2 or 2.0? Does it have a persistent memory?
I believe the fTPM is 2.0 standard (but have not found confirmation).  The fTPM does have its own persistent memory, though I do not have specifics on how much and where.

Storing the password in TPM's secure storage area will be the right option, but as you said with fTPM is not possible, so maybe an external TPM can do that.

I believe there is some TPM support in the UEFI Open Sources, but not currently pulled into the MinnowBoard MAX Build.  We do not pull code support into firmware images unless there is a requirement to do so.  In the case of the MAX/Turbot, the general product does not require TPM support, so the sources are not included in the build.   (they can be added).

Do you know any supported discrete TPM by UEFI on MinnowBoard MAX ?
Work was done on the MAX/Turbot to support the I2S Bus for the purpose of supporting peripherals like TPM.  So there is some support, but it was provided as expansion capability (good question to the TIanocore.org mailing lists)

Does UEFI (Release 0.80) support pre-boot authentication (PBA) communication?
Not as such.  This was not a requirement of code base, and I am not sure if there are any examples in the current Open Source repositories.   However see my notes below regarding PBA and how it probably works with firmware.

A Note on terminology:  The firmware for the MinnowBoard MAX/Turbot (as shipped on the product and provided at Firmware.intel.com) does conform to the UEFI Specification (as opposed to coreboot or Uboot, or legacy BIOS).  However, to use the term "UEFI" to represent any specific firmware implementation (for any specific product) is a miss use of the term UEFI.  UEFI is a standard Forum, of over 250 members within the industry.  The UEFI forum is responsible for several specifications, including the UEFI specification, PI specification, UEFI Shell Specification, and ACPI Specification.   The UEFI specification supports many technologies and capabilities, some of which are mutually exclusive.   There are hundreds (if not thousands) of products using UEFI specification compliant code to boot, across different architectures and classes of devices.

So it is highly possible that there are in existence, somewhere, UEFI based firmware solutions that support unique and special technologies.  However, those firmware solutions may be proprietarily owned, closed sourced, specific to a specialized product, and basically not appropriate to the discussion of the MinnowBoard platform.   The real question is what is currently available for MinnowBoard MAX/Turbot and/or what can be found in the Open Source code base that can be included (if it is not a part of the current product).   Otherwise it would still  be possible to support new and unique technology in the MinnowBoard MAX/Turbot firmware, but it will be a development process to create the appropriate drivers and applications and integrate them in the firmware image.

As I understood SED drives come with the pre-boot authentication (PBA) installed, so does UEFI have to receive the request to send the encryption key to the SED drive OR the communication is only done between the pre-boot and the user, TPM ..etc ? So it is up to the SED on how to get the encryption key !!

Most Full Disk Encryption products allow administrators to enable users to provide the encryption key for a system at the pre-boot stage in several ways:
*         in the form of a password or passphrase;
*         by inserting a USB drive containing the key;
*         using a one-time password generating device such as an RSA token;
*         using some biometric device such as a fingerprint reader (usually connected to a Trusted Platform Module<http://en.wikipedia.org/wiki/Trusted_Platform_Module> which holds the actual encryption key

When the BIOS requests the Master Boot Record from the drive, the drive instead returns the pre-boot record to the user. This pre-boot record is a complete, though quite restricted OS, usually something simple like MS-DOS or LINUX. The pre-boot image requests the Authentication Credentials from the user, which are passed to and checked directly by the drive logic. If accepted, then the drive returns the MBR and the OS is loaded. Important point: This pre-boot authentication is the FIRST thing that happens and is controlled by the drive directly. This has the added advantages of not modifying the MBR, which many software encryption products do, and allowing the MBR to be encrypted like all other user accessible data.
>From your description, the PBA basically adds another stage in the bootstrap process.   Normally: Firmware ==> OS loader ==> OS execution.  With PBA: Firmware ==> PBA ==> OS Loader ==> OS execution.
So it sounds like the PBA takes care of itself.

Basically since the pre-boot record is an OS, the firmware will boot to the pre-boot record, and the pre-boot record then goes about getting the authentication from the system.  Using standard channels.  It sounds to me like you wish to expand the pre-boot record to access another device (i.e. TPM) and retrieve the password from it.  The firmware might provide some Basic I/O primitives to make the OS's job of device access easier, but that would be an implementation aspect of the PBA.   I would also imagine that the PBA does not call ExitBootServices (which terminates the boot time services of UEFI compliant firmware) but would rather leave the UEFI boot services running so the final (decrypted) OS image can utilize the UEFI boot services as a part of its boot process (and then call ExitBootServices when it is ready to terminate UEFI boot support).

Sincerely,

Michael Krau

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

From: Abdelghani Ouchabane [mailto:abdelghani at ezono.com]
Sent: Wednesday, April 06, 2016 7:29 AM
To: MinnowBoard Development and Community Discussion <elinux-minnowboard at lists.elinux.org>; Krau, Michael P <michael.p.krau at intel.com>
Subject: Re: [MinnowBoard] MinnowBoard Turbot & mSATA self encrypted SSD & UEFI

On 05/04/16 04:15, Krau, Michael P wrote:
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.
Right

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.
Yes

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.

Storing the password in TPM's secure storage area will be the right option, but as you said with fTPM is not possible, so maybe an external TPM can do that.

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.
Is it TPM 1.2 or 2.0? Does it have a persistent memory?

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).

Do you know any supported discrete TPM by UEFI on MinnowBoard MAX ?

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.

I see

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

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.

Does UEFI (Release 0.80) support pre-boot authentication (PBA) communication ?

As I understood SED drives come with the pre-boot authentication (PBA) installed, so does UEFI have to receive the request to send the encryption key to the SED drive OR the communication is only done between the pre-boot and the user, TPM ..etc ? So it is up to the SED on how to get the encryption key !!

1-

"...
Most Full Disk Encryption products allow administrators to enable users to provide the encryption key for a system at the pre-boot stage in several ways:
*         in the form of a password or passphrase;
*         by inserting a USB drive containing the key;
*         using a one-time password generating device such as an RSA token;
*         using some biometric device such as a fingerprint reader (usually connected to a Trusted Platform Module<http://en.wikipedia.org/wiki/Trusted_Platform_Module> which holds the actual encryption key.

..."

2-

"
When the BIOS requests the Master Boot Record from the drive, the drive instead returns the pre-boot record to the user. This pre-boot record is a complete, though quite restricted OS, usually something simple like MS-DOS or LINUX. The pre-boot image requests the Authentication Credentials from the user, which are passed to and checked directly by the drive logic. If accepted, then the drive returns the MBR and the OS is loaded. Important point: This pre-boot authentication is the FIRST thing that happens and is controlled by the drive directly. This has the added advantages of not modifying the MBR, which many software encryption products do, and allowing the MBR to be encrypted like all other user accessible data.

"

Sincerely,
Many thanks

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