There are firmware based secure boot using fTPM secure partitioning and more.
Some chipset vendors also support secure boot natively. 1. Is there a cpu architecture-neutral way to implement secure/trusted boot. 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. -C On Tue, Jan 8, 2019 at 1:53 AM Dr. Greg <g...@enjellic.com> wrote: > On Mon, Jan 07, 2019 at 09:25:55PM -0800, Mat wrote: > > Good day again. > > > So, what is the criterion to implement Secure boot or Trusted boot. > > Where are the instructions to implement either? What are some > > minimum pre-requisites on existing Router (say) to implement either. > > As I noted in my previous e-mail, the most fundamental issue is > hardware support for either Secure Boot or TXT. > > If you choose to use Secure Boot I doubt if your routers are running > Windows so you will need to install a platform key that you hold the > private key for. You will use that private key to sign whatever > operating system image you will be booting. There are any number of > resources available on the WEB that describe how to create and install > a custom platform key. > > Implementing TXT is a bit more involved. At a minimum you need to > reconfigure the boot process to use tboot as the primary kernel image > and to specify the kernel as a multiboot module along with its > initrd/initramfs image as an additional module. > > This will produce a system that boots the kernel into a known hardware > state. You will, at a minimum, want to have a Launch Policy (LP) that > specifies the desired signature (hash) of the kernel to verify the > kernel that booted is the one you wanted to boot. > > A more sophisticated implementation will also want to include > verification of a hardware quote over TPM based Platform Configuration > Registers (PCR's) that verify a known state of the hardware/firmware > that the known kernel image is booting into. > > As I mentioned in my previous e-mail, all of this gets you to a point > where you have a known operating system image running. Verifying the > ongoing status of the platform requires that an integrity verification > architecture be built upon this root of trust. > > The Linux Integrity Measurement Architecture (IMA) is built to sit on > top of a TXT based boot and provide hardware based integrity logging. > I haven't looked at the code in a while but I believe there has been > some work to link the integrity chain it provides to a Secure Boot > root of trust as well. > > In order to implement a competent security statement there has to be > some type of attestation by an external verifying party as to the > state of the integrity logs. > > In either the case of TXT or Secure Boot, a correct solution involves > more then invoking some instructions or commands. Constructing a high > security assurance platform requires a fair amount of platform > engineering and architecture expertise. Personally I don't think it > is the domain of standard Linux distributions given how large and > complex they have become. > > Hopefully the above information is helpful. > > Dr. Greg > > As always, > Dr. Greg Wettstein, Ph.D, Worker > IDfusion, LLC > 4206 N. 19th Ave. Implementing measured information privacy > Fargo, ND 58102 and integrity architectures. > PH: 701-281-1686 > FAX: 701-281-3949 EMAIL: g...@idfusion.org > > ------------------------------------------------------------------------------ > "I can only provide the information, I can't make you hear it." > -- Shelley Bainter >
_______________________________________________ tboot-devel mailing list tboot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tboot-devel
