<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 01/04/16 19:39, John Hawley wrote:<br>
</div>
<blockquote cite="mid:56FEB265.7010806@intel.com" type="cite">
<pre wrap="">Inline -JH
On 4/1/2016 8:40 AM, Abdelghani Ouchabane wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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?
</pre>
</blockquote>
<pre wrap="">
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.</pre>
</blockquote>
Thanks john.<br>
<br>
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 <span
style="font-size: 1em; line-height: 1.4em;">ability to enter the
Authentication Key</span>, and this should be implemented in the
UEFI.<br>
<br>
Please correct me if I am wrong.<br>
<br>
<blockquote cite="mid:56FEB265.7010806@intel.com" type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">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?
</pre>
</blockquote>
<pre wrap="">
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</pre>
</blockquote>
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.<br>
<br>
So, if the drive is plugged into a different computer the drive will
still <span style="font-size: 1em; line-height: 1.4em;">require the
AK to be entered in order for the drive to unlock.</span><br>
<br>
<blockquote cite="mid:56FEB265.7010806@intel.com" type="cite">
<pre wrap="">
a quick glance, what you are proposing only really protects you against
a drive being separated from the board permanently, and it being forever</pre>
</blockquote>
Right<br>
<blockquote cite="mid:56FEB265.7010806@intel.com" type="cite">
<pre wrap="">
"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</pre>
</blockquote>
is TPM support by MinnowBoard Turbot?<br>
<br>
<blockquote cite="mid:56FEB265.7010806@intel.com" type="cite">
<pre wrap="">
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.</pre>
</blockquote>
Do you mean filesystem/disk encryption?<br>
<br>
<blockquote cite="mid:56FEB265.7010806@intel.com" type="cite">
<pre wrap="">
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.</pre>
</blockquote>
I see<br>
<br>
<blockquote cite="mid:56FEB265.7010806@intel.com" type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">3. Is it possible to lock the UEFI firmware's flashing in the
MinnowBoard Turbot, so none can flash UEFI firmware without password?
</pre>
</blockquote>
<pre wrap="">
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</pre>
</blockquote>
So, there is no way to protect the firmware from reading and
flashing.<br>
<br>
<br>
<blockquote cite="mid:56FEB265.7010806@intel.com" type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">
Many thanks in advance
My best regards
Ghani
This email has been scanned by Barracuda Networks.
_______________________________________________
elinux-MinnowBoard mailing list
<a class="moz-txt-link-abbreviated" href="mailto:elinux-MinnowBoard@lists.elinux.org">elinux-MinnowBoard@lists.elinux.org</a>
<a class="moz-txt-link-freetext" href="http://lists.elinux.org/mailman/listinfo/elinux-minnowboard">http://lists.elinux.org/mailman/listinfo/elinux-minnowboard</a>
</pre>
</blockquote>
<pre wrap="">_______________________________________________
elinux-MinnowBoard mailing list
<a class="moz-txt-link-abbreviated" href="mailto:elinux-MinnowBoard@lists.elinux.org">elinux-MinnowBoard@lists.elinux.org</a>
<a class="moz-txt-link-freetext" href="http://lists.elinux.org/mailman/listinfo/elinux-minnowboard">http://lists.elinux.org/mailman/listinfo/elinux-minnowboard</a>
</pre>
</blockquote>
<br>
<br>This email has been scanned by Barracuda Networks.
</body>
</html>