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.

https://eprint.iacr.org/2018/427

Click to access 427.pdf

Symbiotic: tool for finding bugs in computer programs based on instrumentation, program slicing and KLEE

Symbiotic is a tool for analysis of computer programs. It can check all common safety properties like assertion violations, invalid pointer dereference, double free, memory leaks, etc. Symbiotic uses three well-know techniques: instrumentation, program slicing, and symbolic execution. We use LLVM as program representation.

https://github.com/staticafi/symbiotic

http://staticafi.github.io/symbiotic/

DMTF Redfish and PCIMG form alliance for Industrial IoT standards

DMTF and PICMG Form Alliance

DMTF and the PCI Industrial Computer Manufacturer Group (PICMG) have formed an alliance to help ensure the two organizations’ standards are coordinated and aligned in the Industrial Internet of Things (IIoT) domain.

Click to access PICMG_Work_Register_v1.0.pdf

https://www.picmg.org/https://dmtf.org/

Expect to see Redfish listed as 10th entry here shortly, I am guessing:

Open Standards

 

CacheQuote: Efficiently Recovering Long-term Secrets of SGX EPID via Cache Attacks

CacheQuote: Efficiently Recovering Long-term Secrets of SGX EPID via Cache Attacks

Intel Software Guard Extensions (SGX) allows users to perform secure computation on platforms that run untrusted software. To validate that the computation is correctly initialized and that it executes on trusted hardware, SGX supports attestation providers that can vouch for the user’s computation. Communication with these attestation providers is based on the Extended Privacy ID (EPID) protocol, which not only validates the computation but is also designed to maintain the user’s privacy. In particular, EPID is designed to ensure that the attestation provider is unable to identify the host on which the computation executes. In this work we investigate the security of the Intel implementation of the EPID protocol. We identify an implementation weakness that leaks information via a cache side channel. We show that a malicious attestation provider can use the leaked information to break the unlinkability guarantees of EPID. We analyze the leaked information using a lattice-based approach for solving the hidden number problem, which we adapt to the zero-knowledge proof in the EPID scheme, extending prior attacks on signature schemes.

https://tches.iacr.org/index.php/TCHES/article/view/879

Don’t buy System76 hardware and expect to get firmware updates from the LVFS

Re: https://firmwaresecurity.com/2018/01/29/linux-oems-support-fwupd-org/

This is a good example of how vendors have vendor-centric tools. Windows Update supports updating firmware, but most Windows OEMs don’t use it. LVFS supports updating firmware on Linux, but most Linux OEMs don’t use it. Sad for users. It seems a bit worse now that UEFI supposedly has a common interface to update firmware, there’s still a problem with UEFI firmware updates. 😦

tl;dr: Don’t buy System76 hardware and expect to get firmware updates from the LVFS

System76 and the LVFS

 

 

QEMU v2.12.0 released (with Spectre/Meltdown update)

QEMU version 2.12.0 released
24 Apr 2018
This release contains 2700+ commits from 204 authors.

* Spectre/Meltdown mitigation support for x86/pseries/s390 guests.
* Better IPMI support for Platform Events and SEL logging in internal BMC emulation
* SMBIOS support for “OEM Strings”, which can be used for automating guest image activation without relying on network-based querying

[…]A previous post detailed how QEMU/KVM might be affected by Spectre/Meltdown attacks, and what the plan was to mitigate them in QEMU 2.11.1 (and eventually QEMU 2.12). QEMU 2.11.1 is now available, and contains the aforementioned mitigation functionality for x86 guests, along with additional mitigation functionality for pseries and s390x guests (ARM guests do not currently require additional QEMU patches). However, enabling this functionality requires additional configuration beyond just updating QEMU, which we want to address with this post.[…]

https://www.qemu.org/2018/04/24/qemu-2-12-0/

More on QEMU and Spectre/Meltdown:

https://www.qemu.org/2018/02/14/qemu-2-11-1-and-spectre-update/

https://www.qemu.org/2018/01/04/spectre/

Microsoft: Hardware Security Test Interface (HSTI) 1.1a

I think this web page has just changed. However, I’m not sure if HSTI 1.1a is new or I’ve got a “false positive” in my searching for new stuff… 🙂 The checklist of issues for IBVs and IHVs is worth [re]reading.

Hardware Security Test Interface (HSTI) 1.1a
05/07/2018
HSTI specifies a standard test interface for proprietary platform security technologies that enforce the Secure Boot promise (for example, SPI flash or eMMC partition locking, proper SMM configuration, Intel Boot Guard properly configured, and so on). Silicon and BIOS vendors specify and implement the necessary test cases which are shipped in release firmware as a built-in self-test. The inclusion of the test interface into the firmware allows the knowledgeable consumer the ability to verify the presence or absence of firmware security features.[…]

https://docs.microsoft.com/en-us/windows-hardware/drivers/bringup/hardware-security-test-interface-1-1a

https://docs.microsoft.com/en-us/windows-hardware/test/hlk/testref/hardware-security-testability-specification

 

Microsoft: C++ Developer Guidance for Speculative Execution Side Channels

C++ Developer Guidance for Speculative Execution Side Channels
05/03/2018
Matt Miller Colin Robertson Mike B

This article contains guidance for developers to assist with identifying and mitigating speculative execution side channel hardware vulnerabilities in C++ software. These vulnerabilities can disclose sensitive information across trust boundaries and can affect software that runs on processors that support speculative, out-of-order execution of instructions. This class of vulnerabilities was first described in January, 2018 and additional background and guidance can be found in Microsoft’s security advisory. The guidance provided by this article is related to the class of vulnerabilities represented by CVE-2017-5753, also known as Spectre variant 1. This hardware vulnerability class is related to side channels that can arise due to speculative execution that occurs as a result of a conditional branch misprediction. The Visual C++ compiler in Visual Studio 2017 (starting with version 15.5.5) includes support for the /Qspectre switch provides a compile-time mitigation for a limited set of potentially vulnerable coding patterns related to CVE-2017-5753. The documentation for the /Qspectre flag provides more information on its effects and usage.[…]

https://docs.microsoft.com/en-us/cpp/security/developer-guidance-speculative-execution

[…]An accessible introduction to speculative execution side channel vulnerabilities can be found in the presentation titled The Case of Spectre and Meltdown by one of the research teams that discovered these issues.[…]

 

Linaro Connect Vancouver BC: CfP open

 

Call for Proposals: opened 8 May 2018
Deadline to submit proposals: ends 23 July 2018

 

http://connect.linaro.org/cfp/
http://connect.linaro.org/

PS: Resources from last Linaro Connect:

http://connect.linaro.org/hkg18/resources/

Model checking boot code from AWS data centers

Model checking boot code from AWS data centers

This paper describes our experience with symbolic model checking in an industrial setting. We have proved that the initial boot code running in data centers at Amazon Web Services is memory safe, an essential step in establishing the security of any data center. Standard static analysis tools cannot be easily used on boot code without modification owing to issues not commonly found in higher-level code, including memory-mapped device interfaces, byte-level memory access, and linker scripts. This paper describes automated solutions to these issues and their implementation in the C Bounded Model Checker (CBMC). CBMC is now the first source-level static analysis tool to extract the memory layout described in a linker script for use in its analysis.

https://ora.ox.ac.uk/objects/uuid:a4566b04-ad64-4bed-9bbe-20b5a4d98c2d

About


https://easychair.org/smart-program/FLoC2018/CAV-program.html

Intel reboots Android-IA as Project Celadon

We are excited to let you know about the refresh of the Android-IA project called Celadon. Celadon is the open sourced Android reference stack for Intel architecture that you are already familiar with, but now with more added to the stack. What started with a few open source drivers support including Mesa i965, I915 Linux Kernel Graphics Driver, and Video Acceleration API last year has since grown into a feature-rich Android stack for IA. Celadon will continue to be dedicated to driving Android support and innovation on IA in addition to providing a place for collaboration. We believe Celadon can help you enhance validation, debug and accelerate development across Android implementations on IA platforms.

https://lists.01.org/pipermail/celadon/2018-May/001235.html
https://lists.01.org/pipermail/celadon/2018-May/001237.html
https://01.org/projectceladon
https://github.com/projectceladon

Qt for Microcontrollers

 

http://doc.qt.io/QtForDeviceCreation/qtee-supported-platforms.html#minimum-hardware-requirements

http://blog.qt.io/blog/2018/05/03/qt-microncontrollers-mcu/

PS: I wonder when the Qt project will pick up the UEFI ports done by EFIDroid:

Qtbase: EFIDroid port of Qt to UEFI!

RouterSploit 3.0 released

[…]Also, RouterSploit will now be maintained by Threat9, which means there will be more resources to improve the tool.[…]

https://www.threat9.com/blog.html

https://github.com/threat9/routersploit

asciicast

Platform Security Summit

https://twitter.com/platformsec/status/989654674469998592

Platform Security Summit
May 23-24, 2018 · Fairfax, VA

Day 1 topics include:
* Incentives, policy and software ecosystems
* Hypervisor requirements and use cases
* Boot integrity and firmware security

Day 2 topics include:
* Hypervisor-based products
* Operating system boot integrity
* Hypervisor research and development

Open Source Software and the Department of Defense David A. Wheeler
A Model of Agent Authority: Interpretation, Trust, and the Role of Rules Tim Clancy
SecureView Overview Kevin Pearson
Enterprise Scale Separation VMM Systems Myong Kang
TrenchBoot: Unified Approach to Harness Boot Integrity Technologies Daniel Smith
Dell Firmware Security: Past, Present, and Future Justin Johnson
Endpoint Resiliency in an Age of Advanced Persistent Threats Jim Mann
Firmware is the new Software Trammell Hudson
Open-Source Host Firmware Directions Vincent Zimmer
A penny per visit adds up real fast: designing effective defenses against an adversary that makes more money than your entire company does Michael Tiffany
Xen Security Weather Report 2018 Lars Kurth
Crucible: Tailoring Xen to support Critical Systems Ryan Thibodeaux
Introduction to the Bareflank Hypervisor and OpenXT Rian Quinn
XenTT: Deterministic System Analysis in Xen Anton Burtsev
Bear – A Resilient Operating System Stephen Kuhn
Anti-Evil Maid with UEFI and Xen Brendan Kerrigan
TPM 2.0 Software Stack: Usability, Privacy and Security Philip Tricca
STM PE Eugene Myers
Magrana Server John Shackleton
The meta-virtualization Layer of OpenEmbedded Bruce Ashfield
Improving the security of QEMU as a device emulator in Xen Paul Durrant

 

 

https://www.platformsecuritysummit.com/

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.[…]

https://support.lenovo.com/us/en/solutions/len-20241

Lenovo Patches Arbitrary Code Execution Flaw