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

Krau, Michael P michael.p.krau at intel.com
Fri Apr 8 18:55:01 UTC 2016


Hello Ghani,

It looks like you did the extra research, which I applaud.

There are a couple of UDK2015 questions below that could be discussed.  The 0.90 firmware for MinnowBoard MAX/Turbot is based upon UDK2014.SP1.P1.  However, the upcoming 0.91 firmware is going to be based upon the UDK2015.  (This is why there is a 12 week window between 0.90 and 0.91, instead of the usual 5-6 weeks, the re-base of a firmware is not a simple or trivial task)

However, it should also be noted that the UDK2015 is still integrating the UEFI specification features form the latest UEFI specification (version 2.6) so some features may not be in the UDK2015 at this time.   As for Firmware Engine, yes, the platform support for MinnowBoard MAX/Turbot is based upon UDK2015 , but the same disclaimer applies.

The UEFI specification does provide the protocols for communicating with Secure storage, but

I agree that TPM is not required for advanced security of a platform (like hardware encryption), but it does provide some hardware options that can be useful.

When you state:
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 !!

It seems to me that it is really is up to the SED's PBA as to the source of the key.  See, once the PBA is running, it has the power to query any system resource (including the operator via console) for the password/key.  This is actually rather clever, as it allows the PBA (an integral part of the SED system) to have autonomous control of the process, rather than expecting the system firmware (which may have to support several SED implementations - each with different mechanisms) to provide the interface specifics).   Though the SED may have system requirements that have to be met (i.e. if the PBA is going to use a biometric device for key/hash entry, then the system will have to have that device).


Sincerely,



Michael Krau

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

On 06/04/16 20:21, Krau, Michael P wrote:
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.
It is 2.0

http://prosauce.org/blog/2016/1/11/minnowboard-max-enable-and-test-the-firmware-txe-tpm-20

https://github.com/tianocore/edk2/blob/master/SecurityPkg/SecurityPkg.dec



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).
Yes, it is in:

https://github.com/tianocore/edk2/tree/master/MdePkg/Include/IndustryStandard/Tpm12.h
https://github.com/tianocore/edk2/tree/master/MdePkg/Include/IndustryStandard/Tpm20.h



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.

To add:

Self Encrypted Hard Drive ( SED ) needs:

Storage Security Command Protocol for encrypted HDD (EFI_STORAGE_SECURITY_COMMAND_PROTOCOL) it was added since UEFI 2.3.1a, this enables security protocol commands to be sent to and from the SED (it is used to allow programs running in the EFI boot services environment to send security protocol commands to the drive).

The master supports Opal 2.0/1.0 standard.

For the password support it is in: https://github.com/tianocore/edk2/tree/master/SecurityPkg/Tcg/Opal

But it is not in UDK2015



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


TPM is not required in order to run hardware encryption. However, a TPM can provide additional data security functions, such as mating the SED to the host system so it cannot be operated in any other host computer.

I checked Intel(r) Firmware Engine 2.0 : https://firmware.intel.com/learn/intel-firmware-engine/intel-firmware-engine

It is a great tool to build platform firmware images, it supports MinnowBoard MAX & MinnowBoard Turbot, it looks that is based on UDK2015, is it right?

But it does not support Self Encrypted Hard Drive (SED) yet.

Thanks a lot.
Ghani

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


More information about the elinux-MinnowBoard mailing list