On Tue, 19 May 2020 at 22:21, Grant Likely grant.likely@arm.com wrote:
On 12/03/2020 04:58, Sumit Garg wrote:
On Thu, 12 Mar 2020 at 03:11, Francois Ozog francois.ozog@linaro.org wrote:
Le mer. 11 mars 2020 à 22:22, Heinrich Schuchardt xypron.glpk@gmx.de a écrit :
On 3/11/20 12:10 PM, Daniel Thompson wrote:
On Tue, Mar 10, 2020 at 06:34:35PM +0100, Francois Ozog wrote:
On Tue, 10 Mar 2020 at 18:19, Daniel Thompson <
daniel.thompson@linaro.org>
wrote:
> On Tue, Mar 10, 2020 at 05:02:27PM +0100, Francois Ozog wrote: >> 0.1 - EBBR goal >> May be a reassessment on the "for what" the specification is built. >> >> Following all the discussions with prominent industry players, I start >> to think that limiting the constraints to be EBBR compliant may become >> counter productive. There will be both EBBR non compliant and EBBR >> compliant systems. This is inevitable. But EBBR exist for a number of >> use cases in a number of markets. The value of EBBR is consistent >> behavior across those. >> >> Maximising number of EBBR compliant systems without stating use case >> parameters ( "why" and "for what") may not be the best goal. >> >> Out of things to be more explicit are supported secure boot flows >> (with/without shim+grub or direct). Some vendors require shim+grub >> while industry players want the exact opposite: nothing but UEFI. This >> drivers a number of requirements in terms of UEFI protocols needed > > We have resisted levels in EBBR until now but this might be where might > have a need for them. > > Put another way I agree that getting explicit about mandatory features > for secure boot flows is useful. > > However I also think that is remains valuable to define best practice > for how firmware and OS interact on systems that have not implemented > secure boot. > > It's all about the target use:
- industrial (manufacturing, automotive, robotics, medical...)
components
- telecom edge
- 96boards
- developer desktop
- server
As I just consider 1 and 2, I have no case without secure boot... Now the dev platform can come without the secureboot active and SElinx deactivated.... In what context you think this is usefull?
I would like it to be possible for dev boards and SoMs whose SoCs do not have a built-in root of trust to have some basic level of EBBR compliance.
I don't like to optics of saying "this standard cannot possibly apply to a Raspberry Pi"[1]. Taking the RPi Zero or CM3 as examples[2], I can't
see any
value added by secure boot since the root-of-trust would have to start on the same media as the operating system anyway.
There is a TPMv2 module available for Raspberries.
https://buyzero.de/products/letstrust-hardware-tpm-trusted-platform-module?v...
Would we be able to use this as root of trust?
AFAIK, TPM in itself can't act as a root of trust. It is rather a passive device which can provide you with trusted/secure services. In general a root of trust is the first piece of *non-modifiable* code that runs on a platform which is BootROM that establishes the chain of trust via verifying the first stage boot-loader which in turn continues the chain of trust to next boot stages and so on.
I think there is a distinction to be made between useful platforms for development where most of the functionality required for secure boot should be usable, and actual secure platforms that have the needed hardware characteristics.
EBBR should account for RPi and similar because it is a very convenient development platform, but there are very few security requirements that can be guaranteed.
What do you think of a security addendum or checklist that goes alongside EBBR to detail what is required to make the platform actually secure?
I would be in favour of such a security addendum.
IMO, "make the platform actually secure" has a bit wider scope than just secure boot. And the scope may vary depending on the threat model which may be specific to a particular use-case. So I will try to list down security features along with their requirements as follows. Please feel free to extend this list in case I missed any relevant security feature:
Feature: Secure boot Platform requirements: - BootROM being the Root of Trust for Secure boot shall initiate the chain of trust via verifying the first stage boot-loader. - Provide platform binding of the root public key used for verification.
Feature: Anti-rollback protection Platform requirements: - BootROM shall provide anti-rollback protection for first stage boot-loader updates.
Feature: Unbrickable firmware updates Platform requirements: - BootROM shall support A/B partition scheme to load first stage boot-loader from alternate locations.
Feature: Secure storage Platform requirements: - Either provide a dedicated non-volatile memory accessible to secure world only or provide a RPMB based secure storage. - Provide a Hardware Unique Key (HUK) which is accessible to the secure world only.
Feature: Secure entropy source Platform requirements: - Provide a hardware entropy source which is accessible to secure world only.
Feature: Memory firewalls / TZASC Platform requirements: - Provide a way to carve out DRAM so that it's accessible to the secure world only.
Feature: Secure peripherals / TZPC Platform requirements: - Provide a way to partition peripherals so that secure peripherals are accessible to secure world only.
-Sumit
EBBR proper can specify the functional interfaces, but security certification is outside EBBR scope.
g. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.