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
