RISC-V: Secure Boot and Remote Attestation in the Sanctum Processor

Cryptology ePrint Archive: Report 2018/427

Secure Boot and Remote Attestation in the Sanctum Processor

During the secure boot process for a trusted execution environment, the processor must provide a chain of certificates to the remote client demonstrating that their secure container was established as specified. This certificate chain is rooted at the hardware manufacturer who is responsible for constructing chips according to the correct specification and provisioning them with key material. We consider a semi-honest manufacturer who is assumed to construct chips correctly, but may attempt to obtain knowledge of client private keys during the process. Using the RISC-V Rocket chip architecture as a base, we design, document, and implement an attested execution processor that does not require secure non-volatile memory, nor a private key explicitly assigned by the manufacturer. Instead, the processor derives its cryptographic identity from manufacturing variation measured by a Physical Unclonable Function (PUF). Software executed by a bootloader built into the processor transforms the PUF output into an elliptic curve key pair. The (re)generated private key is used to sign trusted portions of the boot image, and is immediately destroyed. The platform can therefore provide attestations about its state to remote clients. Reliability and security of PUF keys are ensured through the use of a trapdoor computational fuzzy extractor.

We present detailed evaluation results for secure boot and attestation by a client of a Rocket chip implementation on a Xilinx Zynq 7000 FPGA.




Lenovo LEN-20241: System x Secure Boot Vulnerability

System x Secure Boot Vulnerability
Lenovo Security Advisory: LEN-20241
Potential Impact: Booting unauthenticated code
Severity: High
Scope of Impact: Lenovo-only
CVE Identifier: CVE-2017-3775

Lenovo internal testing discovered some System x server BIOS/UEFI versions that, when Secure Boot mode is enabled by a system administrator, do not properly authenticate signed code before booting it. As a result, an attacker with physical access to the system could boot unsigned code. Lenovo ships these systems with Secure Boot disabled by default, because signed code is relatively new in the data center environment, and standard operator configurations disable signature checking. Apply the BIOS/UEFI update appropriate for your model described in the product impact section below. If you are relying on Secure Boot, you may want to control physical access to systems prior to applying the updates.[…]



On the Path to a Secure Boot Solution for RISC-V

On the Path to a Secure Boot Solution for RISC-V
By SecureRF | April 26, 2018 | 0

As the RISC-V ISA gains in popularity and more industries proceed with plans to build and deploy systems based on RISC-V technologies, the security requirements of those systems will grow. One avenue that hackers have used to exploit systems has been to modify the firmware and cause it to misbehave. For example, one of the recent vehicle hacks involved corrupting firmware in order to jump from an infotainment center to the CAN-BUS. The solution to this style of attack is a secure boot, and with minimal additions to the ISA, RISC-V can provide secure boot hooks directly. Secure boot is a self-hosted root of trust that uses a digital signature and a known, trusted, public key to protect the firmware before it loads. The RISC-V system validates the signature over the firmware using the trusted public key and will run the code only if the signature verifies correctly. If the firmware has been modified in any way, the signature validation will fail. Once this initial trusted load completes, subsequent loads can use the same process to chain the trust to additional loads.[…]



GetSecureBootPolicy.ps1: Partially-completed Secure Boot policy parser

Re: https://firmwaresecurity.com/2018/03/31/geoff-chappell-secure-boot-internals/


Click on above URL or remove spaces in below URL (WordPress mangles Github Gist URLs…)

https://gist. github.com/mattifestation /f1e160bc970c8a7b82355d7e5946901b


Oracle Solaris 11.4: UEFI Secure Boot on Intel HW

UEFI Secure Boot on Oracle Solaris x86 enables you to install and boot Oracle Solaris on platforms where UEFI Secure Boot is enabled. This feature provides more security by maintaining a chain of trust during boot: digital signatures of the firmware and software are verified before executing the next stage. No break occurs in the chain because of unsigned, corrupt, or rogue firmware or software during the boot process. This feature helps assure that the firmware and software used to boot Oracle Solaris on a hardware platform is correct, and has not been modified or corrupted.





MacAdmins Podcast: Episode 70: Secure Boot

Synopsis: Tim Perfitt joins the pod to talk about SecureBoot, the iMac Pro, the future of securing everything, and the history of BootRunner and other products at Twocanoes.

Your Hosts:
Tom Bridge, Partner at Technolutionary LLC [@tbridge]
Pepijn Bruienne, R&D Engineer at Duo Security [@bruienne], Proprietor of EnterpriseMac.Bruienne.com
Charles Edge, Director of Marketplace at Jamf, [@cedge318]

Guests: Tim Perfitt, Founder of Twocanoes Software


show notes: