Can anyone else explain in simple words the difference between Secure boot and Trusted boot.
Thank you Greg for your continued elaboration. On Thu, Jan 10, 2019 at 6:28 PM Dr. Greg <g...@enjellic.com> wrote: > On Tue, Jan 08, 2019 at 03:02:32PM -0800, Mat wrote: > > Good evening, I hope the week has gone well. > > > There are firmware based secure boot using fTPM secure partitioning and > > more. > > > > Some chipset vendors also support secure boot natively. > > If you are talking fTPM I assume you are referring to ARM hardware. > Platform Trust Technology (PTT) would be the equivalent on Intel > which, presumably, runs on the Management Engine rather then in a > TrustZone TEE which is where the fTPM is implemented on ARM. > > So if you have fTPM support and the ARM platform is UEFI I'm assuming > the OEM has wired up their hardware to implement the UEFI Secure Boot > standard. > > > 1. Is there a cpu architecture-neutral way to implement > > secure/trusted boot. > > I think to assist the conversation it is important to differentiate > between Secure Boot and Trusted Boot, they are entirely different > concepts. > > 'Secure Boot' implies that the firmware will verify that the operating > system image that is being loaded has been signed with an asymmetric > key that it has access to. The security predicate that you are > operating with is a guarantee that at system boot time an operating > system image with known provenance was loaded. > > 'Trusted Boot' is a much broader security guarantee that has no > equivalent in the ARM world, as far as I know. In the Intel world, > where it is implemented as Trusted eXecution Technology (TXT), it > provides a guarantee that an authenticated/signed code module was used > to initialize a root of trust that a system integrity predicate can be > constructed on. > > The Intel Software Development Manual (SDM) has an entire section on > how TXT works. The short description is that Intel supplies system > initialization code in the form of an Authenticated Code Module (ACM). > Special processor instructions (GETSEC leaf instructions) execute this > module after verifying the signature on the module and further > verifying that the processor and chipset are in a known state. > > The code in the ACM runs at a privilege level that allows access to a > hardware TPM that is unavailable at any other time. The ACM clears > Platform Configuration Registers (PCR's) and then seeds them through > linear extension with checksums over various critical aspects of the > system such as the firmware and its configuration. The ACM also can > implement a launch control policy that can be used to verify the > system is in a specific state before control is returned to the > security hypervisor (tboot) which continues on with the system boot. > > As the operating system continues forward it has an assurance that the > hardware TPM has been initialized to a precisely known state. The > strategy for a 'trusted system' is to extend the PCR's with values > derived from operational elements of the system, such as the > cryptographic hashes of executables run by the operating system. > > So that is how 'Trusted Boot' works. > > If you have fTPM support and the ARM platform is UEFI and the OEM has > wired up their hardware to implement the UEFI Secure Boot standard you > would be in a position to implement 'Secure Boot', ie. a signed > operating system image. > > The platform vendor should have options available through the BIOS to > install a custom platform key. The default will undoubtedly be the > Microsoft signing key. > > You can install a custom signing key and then sign your operating > system image with the private portion of the key. At that point the > firmware will only load an operating system whose signature matches > that which is authenticated by the public/private keypair you have > loaded. > > The issue is that anything can happen after that point. With 'Trusted > Boot' you are in a position to detect that but 'Secure Boot' doesn't > provide the ability to do that by default. You do have access to a > TPM (fTPM) so with a bit of effort you could construct something > similar but it will require a bit of code rolling. Without chipset > support you will not be able to implement the type of guarantee that > is available with TXT. > > Given that Secure Boot is a UEFI standard it would be the closest > thing possible to a cpu/architecture independent method of > establishing some type of security construct. Extending a security > guarantee beyond boot is a decidedly non-trivial process. > > > 2. Assuming an internet facing router(without secure/trusted boot) > > is hardened enough with basic security measures, what are different > > attack vectors to install malicious code on the router. > > If it was easy to predict that we wouldn't have the cybersecurity > challenge that we have on our hands.... :-) The whole concept of > 0-day's is that they are a class of vulnerability that no one knew > existed. > > The solution to that is allowing the platform to engage in only known > behaviors. The goal of 'Trusted Boot', or something equivalent built > on top of Secure Boot, is to have confidence that the current behavior > of a platform could only have been achieved through a trajectory path > of known behaviors, originating from a known and trusted origin point. > > A methodology for doing that is certainly not something that is > codified in any type of cpu or architecturally independent manner. > > > -C > > Hopefully the above is helpful. > > Good luck with your efforts. > > Dr. Greg > > As always, > Dr. G.W. Wettstein, Ph.D. Enjellic Systems Development, LLC. > 4206 N. 19th Ave. Specializing in information infra-structure > Fargo, ND 58102 development. > PH: 701-281-1686 > FAX: 701-281-3949 EMAIL: g...@enjellic.com > > ------------------------------------------------------------------------------ > "Simplicity is prerequisite for reliability." > -- Edsger W. Dijkstra >
_______________________________________________ tboot-devel mailing list tboot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tboot-devel
