<div class="socmaildefaultfont" dir="ltr" style="font-family:Arial, Helvetica, sans-serif;font-size:10pt" ><div dir="ltr" >Unfortunately I have not had time to go back to my original proposal and address comments and make updates. The original proposal added the ability through physical presence to perform a key transition of at least the keys used to validate U-Boot and the linux kernel/fit. This was added for many reasons:</div>
<div dir="ltr" >- Possible GPL v3 concerns as you guys have been discussing</div>
<div dir="ltr" >- Lab/Development to allow developers to sign and test secure boot with a set of development keys while keeping the production keys under tighter control</div>
<div dir="ltr" >- Allowing customers to take control/ownership of the systems FW stack which is an important goal for us as we work towards open source FW stacks. Patrick also listed a bunch of use cases that add to the importance of this.</div>
<div dir="ltr" > </div>
<div dir="ltr" >As was discussed the AST2600 CRT is not as flexible due to the OTP. We are still finalizing our plans around this but we will probably have to end up where we don't allow these to be changed on HW in the field which means the U-Boot SPL will have to remain signed by IBM but we will have flexibility in the remainder of the stack.</div>
<div dir="ltr" > </div>
<div dir="ltr" >We are still working to define what our final delivery will be for our systems but for the most part our final goals still line up with my original proposal.</div>
<div dir="ltr" ><div class="socmaildefaultfont" dir="ltr" style="font-family:Arial, Helvetica, sans-serif;font-size:10pt" ><div class="socmaildefaultfont" dir="ltr" style="font-family:Arial, Helvetica, sans-serif;font-size:10.5pt" ><div class="socmaildefaultfont" dir="ltr" style="font-family:Arial, Helvetica, sans-serif;font-size:10.5pt" ><div dir="ltr" >
<div><br>Chris Engel<br>Power Firmware Security Architect<br>IBM Rochester, MN<br>(507)253-2306<br>internet: cjengel@us.ibm.com</div>
<div> </div>
<div>"Security is not a binary; it is a sliding scale of risk management" - Josh Bressers</div></div></div></div></div></div>
<div dir="ltr" > </div>
<div dir="ltr" > </div>
<blockquote data-history-content-modified="1" dir="ltr" style="border-left:solid #aaaaaa 2px; margin-left:5px; padding-left:5px; direction:ltr; margin-right:0px" >----- Original message -----<br>From: "Joseph Reynolds" <jrey@linux.ibm.com><br>To: "Vernon Mauery" <vernon.mauery@linux.intel.com>, "Patrick Williams" <patrick@stwcx.xyz><br>Cc: Christopher J Engel/Rochester/IBM@IBMUS, openbmc@lists.ozlabs.org, "Deepak Kodihalli" <deepak.kodihalli.83@gmail.com>, joseph-reynolds@charter.net<br>Subject: Re: Secure boot/signed images and GPL code<br>Date: Fri, Nov 6, 2020 3:24 PM<br>
<div><font size="2" face="Default Monospace,Courier New,Courier,monospace" >On 11/6/20 11:19 AM, Vernon Mauery wrote:<br>> On 03-Nov-2020 02:56 PM, Patrick Williams wrote:<br>>><br>>> In the doc you pointed to, I asked how key transition works, but the<br>>> doc hasn't been updated to better describe it yet[2]. The initial<br>>> response makes it seem like the AST2600 OTP doesn't give a whole lot of<br>>> capabilities here, which is fairly concerning. I know there are some<br>>> design proposals that use a secondary device to assist with<br>>> secureboot[3,4,5] which might better handle key transition.<br>><br>> You are right, the AST2600 OTP leaves something to be desired. If all<br>> the key regions are not initially programmed, it is possible to<br>> program a new key, deprecate all the old keys, and take control of the<br>> system. But programming all the keys prevents transferring the system<br>> from one owner to another (where the owner is the one providing<br>> firmware).<br>><br>> Storing and provisioning keys is hardest part of any crypto system. If<br>> we have ideas on how to make the AST2700 better, Aspeed has engineers<br>> on this list and would probably like to hear any great ideas.<br><br>The OCP (Open Compute Project) Security Project has ongoing discussions<br>on similar topics including secure transfer of ownership, secure boot,<br>and secure recovery.<br><br>I don't have more details because it's not my technical area. The wiki<br>has links to OCP Security goals, papers, and their meetings.<br><a href="https://www.opencompute.org/wiki/Security" target="_blank" >https://www.opencompute.org/wiki/Security</a><br><br>- Joseph<br><br>><br>> --Vernon<br>></font><br> </div></blockquote>
<div dir="ltr" > </div></div><BR>