<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:"French Script MT";
panose-1:3 2 4 2 4 6 7 4 6 5;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman",serif;
color:black;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p
{mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman",serif;
color:black;}
pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0in;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New";
color:black;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman",serif;
color:black;}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:Consolas;
color:black;}
span.EmailStyle20
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:#1F497D;}
span.st
{mso-style-name:st;}
span.EmailStyle23
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:661660618;
mso-list-template-ids:1514339292;}
@list l0:level1
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:.75in;
mso-level-number-position:left;
margin-left:.75in;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:1.25in;
mso-level-number-position:left;
margin-left:1.25in;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:"Courier New";
mso-bidi-font-family:"Times New Roman";}
@list l0:level3
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:1.75in;
mso-level-number-position:left;
margin-left:1.75in;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l0:level4
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:2.25in;
mso-level-number-position:left;
margin-left:2.25in;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l0:level5
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:2.75in;
mso-level-number-position:left;
margin-left:2.75in;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l0:level6
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:3.25in;
mso-level-number-position:left;
margin-left:3.25in;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l0:level7
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:3.75in;
mso-level-number-position:left;
margin-left:3.75in;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l0:level8
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:4.25in;
mso-level-number-position:left;
margin-left:4.25in;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l0:level9
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:4.75in;
mso-level-number-position:left;
margin-left:4.75in;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l1
{mso-list-id:964238290;
mso-list-type:hybrid;
mso-list-template-ids:-745094388 67698703 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l1:level1
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level2
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level3
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l1:level4
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level5
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level6
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l1:level7
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level8
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level9
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body bgcolor="white" lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><a name="_MailEndCompose"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Condensing the discussion to the now open elements:<o:p></o:p></span></a></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal">Is it TPM 1.2 or 2.0? Does it have a persistent memory?<br>
<span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">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.
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal">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.<span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">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).
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal">Do you know any supported discrete TPM by UEFI on MinnowBoard MAX ?<span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">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)<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal">Does UEFI (Release 0.80) support pre-boot authentication (<span class="st">PBA)</span> communication?<br>
<span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">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. <o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">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.
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">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.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal">As I understood SED drives come with the pre-boot authentication (<span class="st">PBA) installed, so does
</span>UEFI have to receive the request to send the encryption key to the SED drive
<b>OR</b> 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 !!<br>
<br>
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:
<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.75in;text-indent:-.25in;mso-list:l0 level1 lfo3">
<![if !supportLists]><span style="font-size:10.0pt;font-family:Symbol"><span style="mso-list:Ignore">·<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]>in the form of a password or passphrase;<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.75in;text-indent:-.25in;mso-list:l0 level1 lfo3">
<![if !supportLists]><span style="font-size:10.0pt;font-family:Symbol"><span style="mso-list:Ignore">·<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]>by inserting a USB drive containing the key;<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.75in;text-indent:-.25in;mso-list:l0 level1 lfo3">
<![if !supportLists]><span style="font-size:10.0pt;font-family:Symbol"><span style="mso-list:Ignore">·<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]>using a one-time password generating device such as an RSA token;<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.75in;text-indent:-.25in;mso-list:l0 level1 lfo3">
<![if !supportLists]><span style="font-size:10.0pt;font-family:Symbol"><span style="mso-list:Ignore">·<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]>using some biometric device such as a fingerprint reader (usually connected to a
<a href="http://en.wikipedia.org/wiki/Trusted_Platform_Module">Trusted Platform Module</a> which holds the actual encryption key<o:p></o:p></p>
<p>When the <b>BIOS</b> requests the <b>Master Boot Record</b> from the drive, the
<b>drive</b> instead returns the <b>pre-boot record</b> to the user. This <b>pre-boot</b> record is a complete,
<b>though quite restricted OS, usually something simple like MS-DOS or LINUX.</b> The
<b>pre-boot</b> 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.<o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">From your description, the PBA basically adds another stage in the bootstrap process. Normally: Firmware
</span><span style="font-size:11.0pt;font-family:Wingdings;color:#1F497D">è</span><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> OS loader
</span><span style="font-size:11.0pt;font-family:Wingdings;color:#1F497D">è</span><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> OS execution. With PBA: Firmware
</span><span style="font-size:11.0pt;font-family:Wingdings;color:#1F497D">è</span><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> PBA
</span><span style="font-size:11.0pt;font-family:Wingdings;color:#1F497D">è</span><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> OS Loader
</span><span style="font-size:11.0pt;font-family:Wingdings;color:#1F497D">è</span><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> OS execution.
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">So it sounds like the PBA takes care of itself.
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">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).
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Sincerely,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<div>
<p class="MsoNormal"><span style="font-size:18.0pt;font-family:"French Script MT";color:#1F497D">Michael Krau</span><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> <o:p></o:p></span></p>
<p class="MsoNormal"><i><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">While I am an Intel employee, I do not represent Intel and am not authorized to speak for Intel. </span></i><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p></o:p></span></p>
</div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><a name="_____replyseparator"></a><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext"> Abdelghani Ouchabane
[mailto:abdelghani@ezono.com] <br>
<b>Sent:</b> Wednesday, April 06, 2016 7:29 AM<br>
<b>To:</b> MinnowBoard Development and Community Discussion <elinux-minnowboard@lists.elinux.org>; Krau, Michael P <michael.p.krau@intel.com><br>
<b>Subject:</b> Re: [MinnowBoard] MinnowBoard Turbot & mSATA self encrypted SSD & UEFI<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">On 05/04/16 04:15, Krau, Michael P wrote:<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">I may be able to answer some of the questions here:</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoListParagraph" style="text-indent:-.25in;mso-list:l1 level1 lfo2"><![if !supportLists]><span style="mso-list:Ignore">1.<span style="font:7.0pt "Times New Roman"">
</span></span><![endif]><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Does UEFI support HDD password?
</span><o:p></o:p></p>
<p class="MsoListParagraph"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">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.</span><o:p></o:p></p>
</blockquote>
<p class="MsoNormal">Right<br>
<br>
<br>
<o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoListParagraph"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoListParagraph"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">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.
</span><o:p></o:p></p>
</blockquote>
<p class="MsoNormal">Yes<br>
<br>
<br>
<o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoListParagraph"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoListParagraph"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">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.</span><o:p></o:p></p>
<p class="MsoListParagraph"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoListParagraph"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">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. </span><o:p></o:p></p>
<p class="MsoListParagraph"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoListParagraph" style="text-indent:-.25in;mso-list:l1 level1 lfo2"><![if !supportLists]><span style="mso-list:Ignore">2.<span style="font:7.0pt "Times New Roman"">
</span></span><![endif]><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">(several questions) Is it possible to modify UEFI firmware to bypass entering the password by hard-coding it in the UEFI firmware?</span><o:p></o:p></p>
<p class="MsoListParagraph"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">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.</span><o:p></o:p></p>
<p class="MsoListParagraph"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
</blockquote>
<p class="MsoNormal">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.<br>
<br>
<br>
<o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoListParagraph"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Is TPM support by MinnowBoard Turbot?</span><o:p></o:p></p>
<p class="MsoListParagraph"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">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.
</span><o:p></o:p></p>
</blockquote>
<p class="MsoNormal">Is it TPM 1.2 or 2.0? Does it have a persistent memory?<br>
<br>
<br>
<o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoListParagraph"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoListParagraph"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">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).
</span><o:p></o:p></p>
<p class="MsoListParagraph"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
</blockquote>
<p class="MsoNormal">Do you know any supported discrete TPM by UEFI on MinnowBoard MAX ?
<br>
<br>
<br>
<o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoListParagraph"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoListParagraph" style="text-indent:-.25in;mso-list:l1 level1 lfo2"><![if !supportLists]><span style="mso-list:Ignore">3.<span style="font:7.0pt "Times New Roman"">
</span></span><![endif]><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Is there no way to protect the firmware from reading and flashing?</span><o:p></o:p></p>
<p class="MsoListParagraph"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">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. </span><o:p></o:p></p>
<p class="MsoListParagraph"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
</blockquote>
<p class="MsoNormal">I see<br>
<br>
<br>
<o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoListParagraph"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">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.</span><o:p></o:p></p>
</blockquote>
<p class="MsoNormal">I agree<br>
<br>
<br>
<o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoListParagraph"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoListParagraph" style="margin-left:0in"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">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. </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
</blockquote>
<p class="MsoNormal">Does UEFI (Release 0.80) support pre-boot authentication (<span class="st">PBA)</span> communication ?<br>
<br>
As I understood SED drives come with the pre-boot authentication (<span class="st">PBA) installed, so does
</span>UEFI have to receive the request to send the encryption key to the SED drive
<b>OR</b> 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 !!<br>
<br>
1-<br>
<br>
"...<br>
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:
<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.75in;text-indent:-.25in;mso-list:l0 level1 lfo3">
<![if !supportLists]><span style="font-size:10.0pt;font-family:Symbol"><span style="mso-list:Ignore">·<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]>in the form of a password or passphrase;<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.75in;text-indent:-.25in;mso-list:l0 level1 lfo3">
<![if !supportLists]><span style="font-size:10.0pt;font-family:Symbol"><span style="mso-list:Ignore">·<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]>by inserting a USB drive containing the key;<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.75in;text-indent:-.25in;mso-list:l0 level1 lfo3">
<![if !supportLists]><span style="font-size:10.0pt;font-family:Symbol"><span style="mso-list:Ignore">·<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]>using a one-time password generating device such as an RSA token;<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.75in;text-indent:-.25in;mso-list:l0 level1 lfo3">
<![if !supportLists]><span style="font-size:10.0pt;font-family:Symbol"><span style="mso-list:Ignore">·<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]>using some biometric device such as a fingerprint reader (usually connected to a
<a href="http://en.wikipedia.org/wiki/Trusted_Platform_Module">Trusted Platform Module</a> which holds the actual encryption key.<o:p></o:p></p>
<p>..."<o:p></o:p></p>
<p><br>
2-<o:p></o:p></p>
<p>"<br>
When the <b>BIOS</b> requests the <b>Master Boot Record</b> from the drive, the <b>
drive</b> instead returns the <b>pre-boot record</b> to the user. This <b>pre-boot</b> record is a complete,
<b>though quite restricted OS, usually something simple like MS-DOS or LINUX.</b> The
<b>pre-boot</b> 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.<o:p></o:p></p>
<p>"<o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Sincerely,</span><o:p></o:p></p>
</blockquote>
<p class="MsoNormal">Many thanks<br>
<br>
<br>
<br>
This email has been scanned by Barracuda Networks. <o:p></o:p></p>
</div>
</body>
</html>