The pre-conference preview videos are coming out… 🙂 One firmware one that caught my attention:
Thunderstrike 2 “firmworm” for MacBooks Preview Video
Category: Uncategorized
Microsoft Windows HSTI (Hardware Security Test Interface)
I just noticed that Microsoft has a “Hardware Security Testability Specification”, still at version 1.0, which defines the Microsoft Windows “Hardware Security Test Interface” (HSTI). The Windows Hardware Certification Program is a self-testing and certification process for Windows OEMs and IHVs. The OEMs/IHVs run some tests, pass them, upload the test log output showing the passing, the vendor gets their code signed and/or they won’t get their marketing logo. Though the test name and the group name have changed, these tests have been around since the beginning of Windows NT. The tests have grown over time to cover more system components, and certification and logo requirements have gotten more tied to passing test results. As these tests are only useful for Windows-centric IHVs and OEMs, I’ve not paid much attention to what firmware tests are available. These days, there are tests for chip vendors and for IBVs (Independent BIOS Vendors), in addition to OEMs and IHVs. It looks like they have a few UEFI-centric tests regarding Secure Boot, and dealing with system suspend/resume.
Jeremiah Cox of Microsoft gave a talk at the Summer 2013 UEFI Forum plugfest (Summerfest): “Validating Hardware Security Through Firmware Interfaces“, see below for URL to slides.
Excerpts from the MSDN web page:
“HSTI helps avoid misconfiguration of security features on devices running Windows. Thus, HSTI provides better assurance of compliance with Windows Hardware Security Requirements. HSTI aims to simplify the interface for designing tests to ensure compliance, reducing the effort required to comply with Windows Hardware Security Requirements. The results of HSTI tests will be consumed by Windows Certification Tests and can be used to verify that devices have been properly configured to enable supported security features. These tests may be used to identify unsecure engineering devices in the field; for example, engineering devices which may contain unsecure test keys. The results of these tests may be used by the Windows operating system to display a watermark (or similar indicator) on unsecured devices. The IHV will develop reference security designs for their platforms that comply with the Windows Compatibility Requirements. In addition, IHVs and IBVs will also implement programmatic tests that verify proper enablement of the reference security implementations and report the results via the Hardware Security Test Interface. These tests are delivered to OEMs & ODMs as compiled modules (not source) and should work without modification. If an OEM/ODM deviates from reference security designs, these test modules may report failures, and the OEM/ODM will need to contact Microsoft to review the modifications and implement an additional HSTI instance that reports these exceptions. OEMs should be able to leverage these security modules with no modification required by following the reference design and documentation. OEMs who wish to add additional security modules, or modify the behavior of any security module, must undergo a design review with Microsoft. Silicon suppliers and IBVs who support Connected Standby systems must implement the platform independent interfaces for querying the respective hardware and firmware security states of their reference platforms. These implementations must be delivered as compiled modules. It is recommended that these modules be signed, and that a signature check is performed when they are run. The purpose is to query the hardware and firmware designs and states to report proper security provisioning of the platform. If an OEM wants to provide an alternate implementation of HSTI tested security features the OEM may provide additional tests. OEM security checks must at least fully cover one IHV or IBV security test. Before use, OEMs must submit to a design review by Microsoft and are subject to the same Documentation and Tool disclosure requirements as other HSTI test providers. Upon approval from Microsoft, the OEM may include security tests that extend upon the IHV and IBV tests. Note that OEM attestation is not required as part of the HSTI design. HSTI is not a list of requirements for OEMs; it is an interface to guarantee effective programmatic security testing of firmware, hardware, and configuration parameters. Silicon and firmware suppliers should make available to Microsoft all necessary security-related reference documentation and tools that they provide to OEMs. This documentation and tools should be made available no later than they are provided to Windows OEMs. This should include, but is not limited to, all documentation and tools related to fusing, installing and updating firmware, firmware and boot recovery, hardware diagnostics, firmware diagnostics, & boot diagnostics. This documentation and tools provided should be fully sufficient to perform HSTI checks in a lab environment.”
Beyond Canonical’s FirmWare Test Suite (FWTS) tool for Ubuntu systems, I wonder if Linux Foundation (and FreeBSD Foundation) have anything close to this testing and certification policy for (not just a test), to help encourage silicon vendors, IBVs, IHVs, and OEMs to best (and most securely) work with Linux (and FreeBSD). In addition to passing FWTS, Intel-based systems should also have to pass current CHIPSEC release before Linux or FreeBSD should touch the platform.
This also reminds me of my last blog post, about getting CHIPSEC results more widely available for consumer’s pre-sales knowledge, depending on the strength of these Windows tests, Microsoft may have some OEM/IBV test results that I wish they’d share (but they never would share that kind of data about their Partner, of course).
For the good of all OSes, not just Windows, I wish Microsoft would add CHIPSEC to their test suites, to force OEMs to pass CHIPSEC. I wonder if CHIPSEC works using IronPython when run as an OS-level app on Windows. 🙂
More Information:
Click to access UEFI_Summerfest_2013_-_Microsoft_Hardware_Security_Test_Interface.pdf
http://www.uefi.org/learning_center/presentationsandvideos
https://msdn.microsoft.com/en-us/library/windows/hardware/dn879006.aspx
New Hardware Reviewers: please post CHIPSEC logs
CONSUMERS:
Run CHIPSEC immediately upon receipt of any new hardware. If it fails, the unit is defective, return it to the vendor for a refund, or an improved model. Individual citizens may not be able to do this (but they should try!), but large enterprises can do this. If the unit fails, post the CHIPSEC logs and OEM model specifics online, for other consumers to find. If you don’t have a blog, send the report here and I’ll port them here. See top right of blog for email address, or click on some of the top center graphics, for email address.
HARDWARE REVIEWERS:
Please help consumers of Intel-based computers by posting the results of the Intel CHIPSEC tool (chipsec_main.py’s output). Or work with LegbaCore and/or MITRE to get the data from their Copernicus tool, and post those similar results. Without the results of Intel CHIPSEC or LegbaCore/MITRE Copernicus, consumers have no idea if the OEMs built a system with insecure firmware or not. CHIPSEC tests for all known public vulnerabilities. Right now, your reviews are WORTHLESS for firmware security. Spending 5min to boot LUV-live, run CHIPSEC, and include the final result summary of the output would be an EXPONENTIAL improvement to the content you provide. PLEASE help consumers. Only by shaming OEMs when they ship known-bad products will we get the OEMs’ QA teams to also start running CHIPSEC, and then we’re helping ALL consumers, not just the ones that know about CHIPSEC or that read your reviews. A while ago, LegbaCore hinted that they’d start releasing information about some OEM systems, this’ll trump any hardware reviews as the primary source for pre-sales hardware information. You can make your content useful by adding firmware tests today.
You can test systems easily using Intel’s LUV-live boot image, which contains CHIPSEC. LUV-live is based on LUVos, Linux UEFI Validation, a diagnostic-centric distribution. LUV-live also includes FWTS (FirmWare TestSuite, and if you run that and find any failures, that’ll also help give potential consumers proper security information. CHIPSEC tests both BIOS- and UEFI-based systems. Right now, CHIPSEC only works on Intel x86 and 64 systems. But Linaro is looking at porting it to ARM (AArch64), and AMD is now aware of this tool, hopefully we’ll soon see new CHIPSEC ports that’ll enable even more comprehensive reviews. Watch for new CHIPSEC releases, new releases usually include new security test modules, which you need to re-run against all modern hardware. If you have user questions with CHIPSEC, use the newly-created mailing lists.
Better still, someone create a site where consumers can upload CHIPSEC results, and the site will be the aggregate of all results. That’d be a great new database of invaluable pre-sales information that’d help bring eyeballs to your review site! 🙂
OEMs: Please post CHIPSEC log results in your pre-sales techincal information. Include specific information about what kind of firmware your systems have, if coreboot what payload, if UEFI what UEFI version, if outsourced what IBV, and what features (eg, Absolute’s ComputeTrace, etc.) are included in your firmware. And, like Phoenix said at the last UEFI Forum plugfest, make sure your QA teams are running the latest CHIPSEC before they ship units. Right now, HP appears to be the best OEM when it comes to documenting the pre-OS software they install, at least for enterprise-class systems. I wish other OEMs could match or beat HP’s level of firmware documentation.
Please help forward this to any hardware reviewers — and large-quantity hardware purchasers — that you know of. I don’t have any contacts at any of them, and I doubt they are reading this blog, so your forwarding this information to the right person is probably the only way they’ll get a clue. Please help!!
Thanks!
https://github.com/chipsec/chipsec
https://lists.01.org/mailman/listinfo/chipsec
https://01.org/linux-uefi-validation/downloads/luv-live-image
https://firmwaresecurity.com/tag/chipsec/
Wired on Apple EFI vulnerabilities
Wired magazine has a new story focusing on Apple Mac EFI vulnerabilties. Well-written article, nice background details.
http://www.wired.com/2015/08/researchers-create-first-firmware-worm-attacks-macs/
TrustZone TEE vulnerability for Huawei Mate 7
Found on @ABazhaniuk’s Twitter feed:
https://twitter.com/_jsoo_/status/627436330918658048
Security Advisory – Two Privilege Escalation Vulnerabilities in Huawei Mate 7 Smartphones
The tzdriver module of Huawei Mate 7 smartphone has an input check error, which allows the user-mode application to modify kernel-mode memory data and maybe make system break down or application elevate privilege. (Vulnerability ID: HWPSIRT-2015-03011) These Vulnerabilities have been assigned Common Vulnerabilities and Exposures (CVE) ID: CVE-2015-4421. The TEEOS module of Huawei Mate 7 smartphone which is used to realize the function of fingerprint identification has an input check error, which enables the attackers with the root permission to modify kernel-mode memory data of TEEOS module, which could make system break down, TEEOS be tampered or malicious code execution. (Vulnerability ID: HWPSIRT-2015-03012) These Vulnerabilities have been assigned Common Vulnerabilities and Exposures (CVE) ID: CVE-2015-4422.
HWPSIRT-2015-03011: Attackers can write data into an invalid address to crash the system or elevate their privileges through elaborate applications.
HWPSIRT-2015-03012: After privilege escalation, attackers can craft malicious applications to crash the TEEOS or execute arbitrary code on the TEEOS.
Temporary Fix: None
See the Huawei Security Advisory for full details:
http://www.huawei.com/en/security/psirt/security-bulletins/security-advisories/hw-432799.htm
There’s also a Github sample:
“With two vulnerabilities,any installed application is able to execute arbitrary code in TEE of Huawei Mate7 . This source code is a PoC which may read fingerprint image from sensor(FPC1020) on Mate 7.”
AMD AGESA
I’m learning about AMD firmware solutions, and AGESA is first acronym on the list. According to Wikipedia:
“AMD Generic Encapsulated Software Architecture (AGESA), is a bootstrap protocol by which system devices on AMD64-architecture mainboards are initialized. The AGESA software in the BIOS of such mainboards is responsible for the initialization of the processor cores, memory, and the HyperTransport controller. AGESA documentation was previously available only to AMD partners that had signed an NDA. AGESA source code was open sourced in early 2011 to gain track in coreboot.”
There are two firmware ecosystems, coreboot and UEFI, where the former has a lot of Chrome OEMs, and the latter has a lot of Windows OEMs. UEFI and coreboot work on Intel and AMD (and ARM) systems. AMD makes both x86 and ARM systems, but I’m focusing on their x86 systems here.
For coreboot, Sage Engineering is main coreboot IBVs (Independent BIOS Vendors), AFAICT. Sage currently supports AMD systems, offering coreboot with AGESA.
https://www.se-eng.com/products/sagebios-bsp-for-amd-processors/
“Sage supports many modern x86 platforms from AMD. In early BSP releases,our source code license allowed us to directly modify and include AGESA source code. Later versions include the AGESA binary PI from AMD to initialize the CPU. SageBIOS(TM) Custom BSPs deliver full-featured firmware designed for AMD platforms.”
https://www.se-eng.com/firmware-solutions-for-intel-and-amd-x86-processor-systems/
“AMD was the first […] to support an open source boot solution with its support of the One Laptop Per Child program, which was immersed in the Linux open source community, and the Linux firmware boot solutions that would ultimately become coreboot. Sage Electronic Engineering founder Scott Hoot was heavily involved in that the children’s laptop project, as a firmware designer for AMD, and would soon embrace open source firmware solution as a foundation for his startup company. Sage would have distinct advantages over other open source firmware development companies in that Hoot already had a insight into AMD’s proprietary architecture, which he would cement with a agreements with AMD to help forge the way into expanded open source BIOS and firmware coding. Sage would continue to forge a trail in the community with its support of the coreboot(R) solution and the proprietary hybrid that Sage developed for more rapid deployment, SageBIOS. Open source development as a whole continue to progress with AMD’s AGESA and Intel’s Firmware Support Package, essentially giving open source firmware designers a better look at the architecture than was previously allowed.”
Over in the UEFI Forum ecosystem, it appears that most of the ‘mainstream’ IBVs also support ARM via AGESA in their products as well. I see support from Insyde Software and AMI, at least.
I’m still not clear if TianoCore can use AGESA directly, or if an IBV is still needed to integrate the two.
More Information:
http://review.coreboot.org/gitweb?p=coreboot.git;a=tree;f=src/vendorcode/amd
https://chromium.googlesource.com/chromiumos/third_party/coreboot/+/a46a712610c130cdadfe1ebf6bec9ad22e474dac/src/cpu/amd/agesa
Click to access AGESA_Interface_specification_for_Arch2008.pdf
[I just realized that I’ve not written a blog on Intel Firmware Support Package (FSP) yet…. I’ll do one in a few days.]
Recapping Marek’s Jan2015 AMD security vulnerability
[I’m pretty dumb when it comes to AMD systems. 😦 I am just catching up to what most of the rest of the world knows about their technology, and security. I asked on the EDK2-devel mailing list for a clue on AMD’s firmware strategy, and Gary Simpson of AMD was kind enough to answer my questions. I’ll post a version of his answers in an upcoming blog, in the mean time look on the edk2-devel archives on 7/31 for his message. I’m still trying to understand some of the answers from AMD, from firmware development perspective, mainly AGSEA and how it works. Much more on this in future blog posts. In the mean time, I’m also catching up to AMD silicon/firmware security, and the most recent public story appears to be from January:]
Back in January of this year, there were a few stories on one AMD firmware vulnerability, reported last April, fixed last November, reported at December’s Chaos Communications Congress. At 31C3, Rudolf Marek, a Czech programmer, gave a presentation about a security vulnerability on AMD’s x86 chips, insufficient security checks before execution allows malware injection. AMD’s Mullins, Beema, Temash, Trinity, Richland, Kaveri, and Kabini chips are impacted. AMD released new free firmware update to resolve things.
It is nice to hear that “AMD responded quickly” and that this vulnerability was resolved in a “timely” manner!
If you have AMD systems, make sure you have this recent update!
Some quotes from stories on this vulnerability:
“The problem is caused by a vulnerability in the AMD SMU (System Management Unit) Unit APU / SoC mentioned, which does not perform pre-implementation code ‘appropriate checks’. AMD responded quickly, closing this security gap with a firmware update to your AGESA (AMD Generic Encapsulated Software Architecture), which is available for manufacturers of motherboards for PCs, notebooks and tablets, based on these APU / SoC AMD. The developer recommends users, requiring manufacturers of compatible motherboards with the APU / SoC affected, the release of new versions of BIOS with the new version of AGESA incorporated; since some motherboard manufacturers might not feel obliged to publish BIOS updates for older products such as stem socket FM2 cards (compatible with Trinity and Richland).”
“Marek told an audience at the Chaos Communications Congress that he worked with AMD for a year to fix the security flaw. He recommended that users contact their motherboard vendors to push the fix to their computers. “[Ask] your vendors for a fixed AGESA [AMD Generic Encapsulated Software Architecture],” Marek said. “This is the only way to push vendors to update BIOSes for older platforms,” he added.”
“As pointed out by Marek firmware insufficiently correctly checks the signature code that allows an attacker to insert your own code and execute it. This is done via the System Management Unit (SMU), which is also responsible for the power saving function. But he was also deeply involved in the configuration. The firmware on 32-bit controller LatticeMicro32 (LM32) from Lattice Semiconductor. Rudolf Marek broke the key used to sign the code hash SHA1. He took the code from SMU update BIOS, and then run the code on an emulator. After breaking the code Rudolph was able to add their own team in SMU and execute them.”
“The firmware is available as part of AMD AGESA (AMD Generic Encapsulated Software Architecture). It has already been updated AMD in late November, the request was sent to manufacturers of motherboards, notebooks and complete systems. They should implement AGESA in your BIOS and UEFI. Updates should already be implemented for most systems, but manufacturers do not disclose relevant information.”
“Back in April last year, Rudolf Marek informed of its existence AMD, who has confirmed the vulnerability in the summer, and it was fixed at the end of November. Hopefully, manufacturers have responded to this problem in a timely manner, and added in a modified AGESA updating the BIOS.”
More Information:
http://www.theregister.co.uk/2015/01/14/amd_plugs_chip_firmware_holes/
http://www.fierceitsecurity.com/story/research-uncovers-security-hole-amd-chips-enable-attack-inject-malware/2015-01-20
https://lenzfire.wordpress.com/2015/01/17/amd-releases-new-free-firmware-for-vulnerabilities-in-their-fm2-fm2-am1-apu-
http://www.hardwareluxx.ru/index.php/news/hardware/prozessoren/33090-amd-firmware-apu.html
http://www.heise.de/newsticker/meldung/Sicherheitsluecke-in-Firmware-von-AMD-Prozessoren-2512960.html
https://events.ccc.de/congress/2014/Fahrplan/events/6103.html
https://media.ccc.de/browse/congress/2014/31c3_-_6103_-_en_-_saal_2_-_201412272145_-_amd_x86_smu_firmware_analysis_-_rudolf_marek.html#video
book mini-review: combat: UEFI Principles and Programming (in Chinese)
Ok, I’m writing a book review about a book I didn’t read. 😦 The book is written in Chinese, and I’m not good enough at translation software yet to read the book. But for anyone who can read Chinese, if you don’t already know about this book, you should check it out.
According to Amazon.com. the author is Director of Intel Labs China, and the book has a developer focus. The github site includes a snapshot of the EDK2, with a few examples. Even if you can’t read Chinese, you can still benefit from reading the samples. The book was published January 1st 2015, and Gthub appears to have last been updated in May. From the Amazon.com abstract:
“combat: UEFI Principles and Programming is the first UEFI monograph in Chinese, which is written by senior UEFI expert and evangelist. Director of Intel Labs China, Wu Gansha, strongly recommended! This book is combat-oriented for UEFI users and developers. It describes the UEFI system components, boot process, advantages, and a variety of systems development environment to build; Then it analyzes the UEFI components from deverloper’s view, including UEFI modules, a variety of protocols. basic services, events, hard drives and file systems; Finally it explaines UEFI development , involving the development of UEFI services(video decoder service though ffmpeg), UEFI-driver development(AC97 audio driver), the development of multi-tasking applications, the development of network applications and GUI application development.”
https://github.com/zhenghuadai/uefi-programming
https://github.com/zhenghuadai/uefi-programming/blob/master/README.md
book review: Platform Embedded Security Technology Revealed
Book review:
Platform Embedded Security Technology Revealed: Safeguarding the Future of Computing with Intel Embedded Security and Management Engine
Xiaoyu Ruan (Intel)
APress Open, 2014
ISBN: 978-1-4302-6571-9 and 978-1-4302-6572-6
http://www.apress.com/9781430265719
The book reveals the technical details of Intel’s security and management engine, with the focus on the architecture and design of its firmware infrastructure. For the past several years, the engine has been serving as the base of many security technologies included in Intel platforms. This book talks about the various Intel boot security technologies, focusing on the Intel Management Engine (ME) and how ME interacts with the other Intel security technologies at the hardware, firmware, and OS-levels. Much of the book focuses on boot integrity, process isolation, and various Intel hardware-based protections. The book gives good background on how a chip vendor deals with hardware/firmware hybrid solutions, as well as how recent security researcher’s attacks against Intel have impacted their product designs.
It is from APress Open, not Intel Press. But it does read like an book-length whitepaper by Intel, explaining most of Intel’s hardware/firmware security offerings, with some crypto background on some of the designs. The author, Xiaoyu Ruan, is a security researcher with the Platform Engineering Group at Intel Corporation, and is responsible for designing cryptography infrastructure and security applications for Intel’s security and management engine.
The Management Engine (ME) is sometimes just called a management engine, later is starts to become called the security engine:
“Depending on the end product in which the embedded engine resides, the engine is denominated differently. For the embedded system shipped with computing devices featuring Intel Core family microprocessors, it is called the management engine. For the embedded system shipped with computing devices featuring the Intel Atom system-on-chip (SoC), it is called the security engine. Note that not all Atom platforms use the security engine introduced in this book.”
The list of Intel security technologies and acronyms discussed in this book is extensive:
* Intel Security Security Engine, aka Management Engine (ME)
* Intel Boot Guard
* Intel Trusted Execution Technology (TXT)
* Intel Software Guard Extensions (SGX)
* Intel Identity Protection Technology (IPT)
* Intel Active Management Technology (AMT)
* TCG’s TPM
* Intel Virtualization Technology
* Intel Anti-Theft Technology
* Intel management engine BIOS extension (MEBX)
* Host-Embedded Controller Interface (HECI)
* Intel EPID (Enhanced Privacy Identification)
* Intel PAVP (Protected Audio And Video Path)
* Intel Platform Trust Technology (PTT)
The discussion on Boot Guard goes into detail as to how it works with Verified Boot and Measured Boot, including use of TPM on Measured Boot. There is a comparison of these various Intel HW/FW security technologies to ARM’s TrustZone. There is discussion on how some of these security technologies are used for “Rights Protection” (DRM), including Intel Sandy Bridge hardware protection technology for UltraViolet-based video content. The author talks about WS-Management interfaces, as well as pre-WSMAN SOAP-based External Operations Interface (EOI) interfaces to engine. There is discussion of the OS-level drivers used to communicate with ME, including Baseboard Management Controllers (BMC) and Out-of-bound traffic to systems via ME on servers. There is some clarification of ME -vs- AMT -vs- vPro, as well as ME use of TPM (discrete or software-based).
The engine has many features. It includes a secure timer, a protected real-time clock in the engine. It can be used for secure storage:
“A partition of the SPI flash chip is reserved for storing the security and management engine’s nonvolatile data. As the flash size is very limited, the files cannot be too large. Generally speaking, the storage is intended for keys and credentials, such as device private keys, AMT passwords, and so on. It is not designed for storing bulk data such as video frames or network traffic.”
Regarding debugging, production parts have fewer silicon diagnostic abilities, but the ME “offers two ways—debug messaging and special production-signed firmware—to facilitate debugging on production parts.”
The book helps enlighten you as to some of the reasons your firmware is generating network traffic, eg:
“To get the current date/time information, the EPID manager requests a real-time OCSP (Online Certificate Status Protocol) response from a trusted OCSP server, which was endorsed by Intel.”
“As an embedded system, the security and management engine does not have convenient network access. Therefore, the SIGMA protocol is designed such that the platform does not communicate with the OCSP server directly but only connects with the verifier.”
The engine adds new crypto protocols, new PKIs, for cryptographers to enjoy. I’m not sure what code outside the engine uses this yet.
Intel EPID (Enhanced Privacy Identification) was added to the management engine:
“Intel’s chipset series 5 (released in 2008) and newer natively support the EPID platform functionality. A unique private key, in its encrypted form, is burned into security fuses for every chipset part during manufacturing. For this EPID ecosystem, Intel acts as the EPID authority. Using the private key, the security and management engine proves that it is a genuine Intel platform, and hence eligible for premium services that are only available for Intel platforms.
Yet it sounds like there is hardware and knowledge available for attackers to obtain to sidestep some of this technology, and rubberhoses can trump NDAs:
“The implementation of the security and management engine attempts to ensure that the EPID key cannot be revealed from a device without special and expensive equipment and advanced expertise in hacking.”
The engine includes a Dynamic Application Launcher (DAL). One thing that jumped out to me about the ME is that it runs Java code from the hard drive! After spending a lot of time explaining why ME is isolated and secure from third-party code, the author mentions two ME limitations: not enough space on Flash for more ME-based firmware apps, and inability of third parties to use the ME.
“To address these drawbacks to some extent, newer versions of the security and management engine firmware include a module called the Dynamic Application Loader, or DAL for short. As indicated by the name, the DAL allows the engine to dynamically load and execute Java applets at runtime. The applets are not stored on the flash, but on the host’s hard drive. With the DAL, the embedded engine is no longer a closed-door realm. The engine is now open to more flexibility and possibilities to be explored.”
“The DAL is essentially a Java virtual machine that enables the operation of Java applets in the security and management engine’s firmware environment. The Java applets in bytecode implement their designed functionalities that can be executed in the firmware.”
“Depending on product, the IPT may be implemented as an applet for the engine’s DAL feature, or a native firmware module on the engine. If the firmware supports DAL, for example, on most Intel Ultrabook models, then the IPT implementation will be distributed in a Java applet. On certain smartphones and other products where the DAL is not built into the engine’s firmware, the IPT will be a native firmware ingredient that is loaded from the system’s flash chip. The firmware design and functionalities of the IPT component are identical for both variants.”
Interestingly, it sounds like the management engine uses some open source code, but doesn’t mention what code is used, only that the TLS used in AMT is not ported from OpenSSL:
“In the security and management engine’s firmware, only a small fraction originates from open-source domain, and it is only used in modules that do not assume security responsibilities. For example, the TLS implementation in the AMT firmware application is not ported from OpenSSL and hence not affected by OpenSSL’s vulnerabilities such as the Heartbleed. The validation of the engine does not discriminate between open source and closed source. Thorough testing is performed against open-source software used by the engine.
(Tianocore’s UEFI implementation of Secure Boot requires the use of libOpenSSL to implement the crypto. OEMs/IBVs could replace that with another library, and may be doing so, but there’s no docs to clarify this.)
In some ways, I look at Intel platforms a bit differently now. In the beginning, it was simple (and insecure): BIOS loaded MS-DOS, then you had a shell, and you ran an app, with the occasional service (TSR). These days, OSes are much more complex, BIOS was replaced by UEFI, which itself a new OS added to stack. The mangement engine and SMM are two background layers to the stack as well. Before reading this, I really thought of the non-UEFI, non-SMM, non-TPM, non-IPMI background interactions were infrequent. But the management engine looks like a significant new addition to the stack, running it’s own drivers, virtual TPMs, ISV Java code off the hard disk, it sounds like yet-another OS (er, platform) added to the stack. It makes sense if you are Intel, I suppose. But I feel uneasy about how complex HW/FW is becoming… Some of these technologies are going to get in the way of General Purpose Computing, helping some companies make disposable systems where vendors dictate all FW/OS choices, and you cannot install your own OS. On the other hand, security issues need addressing, somehow. Boot system, start SMM, start background ME OS, then start background UEFI OS, then load user’s main OS, …that’s a lot of platforms in one stack.
In summary, I liked this book. Unlike my blog posts, the book was well-written. 🙂 The author knows a LOT about Intel security technologies. I learned a lot. If you care about firmware security on Intel platforms, you should get this book. You might be able to avoid the book if you spend a lot of time researching the various technologies off Intel’s web sites and online, but this book does a great job of integrating all of these technologies into one source. I hope to see a 2nd edition once Intel adds more features to the engine.
Black Hat Briefings
Not only is DEF CON happening (maybe):
but Black Hat Briefings is also happening:
https://www.blackhat.com/us-15/briefings.html
There are numerous talks related to firmware security. Here’s the initial list of events that caught my eye, and I’m sure I missed a few gems. The Thunderstrike talk sounds very interesting, as does the talk on firmware attacks to hypervisors! I’m looking forward to trying Unicorn and Angr. The problem with big conferences is there’s too many good talks to attend, and I haven’t cloned myself yet.
* Advanced IC Reverse Engineering Techniques: In Depth Analysis of a Modern Smart Card, Olivier Thomas
* Using Static Binary Analysis to Find Vulnerabilities and Backdoors in Firmware, Christopher Kruegel, Yan Shoshitaishvili
* Attacking Hypervisors Using Firmware and Hardware, Yuriy Bulygin, Alexander Matrosov, Mikhail Gorobets, Oleksandr Bazhaniuk
* Attacking Your Trusted Core: Exploiting Trustzone on Android, Di Shen
* Cloning 3G/4G SIM Cards with a PC and an Oscilloscope: Lessons Learned in Physical Security, Yu Yu
* Exploiting the DRAM Rowhammer Bug to Gain Kernel Privileges, Mark Seaborn, Halvar Flake
* Fuzzing Android System Services by Binder Call to Escalate Privilege, Guang Gong
* The Memory Sinkhole – Unleashing an x86 Design Flaw Allowing Universal Privilege Escalation, Christopher Domas
* These are Not Your Grand Daddys CPU Performance Counters – CPU Hardware Performance Counters for Security, Nishad Herath, Anders Fogh
* ThunderStrike 2: Sith Strike, Trammell Hudson, Xeno Kovah, Corey Kallenberg
* Unicorn: Next Generation CPU Emulator Framework, Nguyen Anh Quynh, Hoang-Vu Dang
Qubes 3.0-RC2 released
Today the Qubes OS released v3.0 release candidate 2.
They ALSO created a new Twitter feed, @QubesOS.
Qubes is a Linux distribution created by Invisible Things Lab (ITL), a security research firm that specializes in hardware/firmware security; Qubes includes virtualization technology to isolate each process from each other in ways to help increase security.
“There have been no new features in this release compared to Qubes 3.0-rc1 that we released in April, only bugfixes. Although Qubes 3.0-rc2 is major improvement over Qubes 3.0-rc1, there are still some issues to be resolved – check “Known Issues” section of installation guide. Qubes 3.0.0 will follow soon (coming weeks), together with 3.1-rc1 that is currently being merged (and which is bringing a bunch of cool new features, as discussed in the previous annoucment).
More Information:
https://groups.google.com/forum/#!topic/qubes-devel/jw9CdQepMPE
http://blog.invisiblethings.org/2015/04/23/qubes-30rc1-and-roadmap.html
https://www.qubes-os.org/doc/QubesDownloads/
Analysis of embedded Linux online firmware update
Earlier this week, w_s_m_i_t_h wrote an article on Reddit, researching the online firmware update of a vendor, including use of wireshark, binwalk, and other tools. The GNU FDL 1.3-licensed posting is listed here:
Roku – A little Roku with my morning coffee; A firmware update MITM technique
Jeff Thomas leaves Sage Engineering
Hmm, I don’t understand what is happening at Sage Engineering, it looks like there are are multiple coreboot people who are looking for a job(?), see below bold sentences (emphasis mine):
http://www.se-eng.com/2015/07/so-long-and-thanks-for-all-the-fish/
I woke up this morning dreaming about different chipsets and boot solutions, though quickly realizing there was no longer a reason. Because today I’m writing my last blog for Sage Electronic Engineering. Along with myself, the change the technical to non-technical writer, there are a lot of fine coreboot engineers now looking for work. I’d like to thank everyone who followed this blog, notably Vincent Zimmer at Intel, as it has meant a lot to me, as well as my company. I’d also like to thank Sage CEO Scott Hoot and VP of Marketing Dennis Batchelor for having me along, as well as the numerous engineers and managers, Drew Jensen and Steve Goodrich come to mind, I’ve bothered with questions along the way. I enjoyed working here very much. Mostly, I’d like to note that I never did get around to writing about owner/engineer Kimarie Hoot, who certainly deserves an award for both a woman in software and a woman in business. Some publicist I am. Kimarie is much more than a credit to her gender and electronic engineering. I’m not sure what’s going to happen to some very fine engineering here at Sage, especially the SageBIOS for Intel and AMD processors, but I’d like to believe it will be available in some form. Seems like an incredible waste otherwise. Everyone I’ve worked with here has been a credit to x86 embedded development. When they asked me what I knew about BIOS and firmware when I interviewed here, I said, “Well I’ve updated BIOS on my laptop, pretty much know what that does, and I’ve flashed a couple of routers — that’s about it.” Hopefully, I’ve found my way around a bit since then. Anyway, my last stab at humor, and there have been some outstanding failures in this department, comes from the Hitchhiker’s Guide to the Galaxy series. So long, and thanks for all the fish.
New FCC requirements may impact use of open source firmware
The FCC has new regulation that may impact embedded system, unclear how this impacts UEFI’s WiFi usage on embedded systems. I’ve not looked into this yet, so I’ll defer to some existing news sources. Quoting the InfoQ article:
“The United States Federal Communications Commission (FCC) has introduced ‘software security requirements’ obliging WiFi device manufacturers to “ensure that only properly authenticated software is loaded and operating the device”. The document specifically calls out the DD-WRT open source router project, but clearly also applies to other popular distributions such as OpenWRT. This could become an early battle in ‘The war on general purpose computing’ as many smartphones and Internet of Things devices contain WiFi router capabilities that would be covered by the same rules. The rules are apparently motivated by a desire to ensure that devices operated within the US comply to FCC regulations on radio frequency spectrum management and power output. Given the size of the US market, and manufacturers’ desire to create products that reach a global market, the rules are likely to have a global impact. This regulation applies to U-NII devices operating in the 5GHz band, though as dual band systems have become more popular, in routers and phones, this will increasingly apply to most devices with WiFi.”
More Information:
New FCC Rules May Prevent Installing OpenWRT on WiFi Routers
http://www.infoq.com/news/2015/07/FCC-Blocks-Open-Source
https://news.ycombinator.com/item?id=9959088
ARM acquires Sansa Security for IoT security
Yesterday ARM Ltd announced acquisition of Sansa Security, the acquisition will offer hardware and software-based security features, boosting protection for sensitive data and content on any connected device. Press release:
ARM has acquired Israel-based Sansa Security, a provider of hardware security IP and software for advanced system-on-chip components deployed in IoT and mobile devices. The company currently enables security in more than 150 million products a year and Sansa Security technology is deployed across a range of smart connected devices and enterprise systems. The deal complements the ARM security portfolio, including ARM(R) TrustZone(R) technology and SecurCore(R) processor IP. Terms have not been disclosed.
“Any connected device could be a target for a malicious attack so we must embed security at every potential attack point,” said Mike Muller, CTO, ARM. “Protection against hackers works best when it is multi-layered, so we are extending our security technology capability into hardware subsystems and trusted software. This means our partners will be able to license a comprehensive security suite from a single source.”
Sansa Security technology makes it easier for manufacturers to build secure products by offering a complete hardware subsystem that adds additional isolation of security operations from the main application processor. This is complemented by software components operating on top of trusted execution environments to perform security-sensitive operations. The acquisition builds upon ARM’s embedded TrustZone technology, creating extra protection against malware and malicious software. It is a system-wide approach that underpins security-related chipset and trusted software needs. This enables the protection of any connected device and management of sensitive data and content.
“Our technology is already being used to protect data gathered and transmitted by a multitude of IoT and mobile devices,” said Coby Sella, CEO, Sansa Security. “Joining ARM will enable us to scale the business by helping ARM’s global technology partners to address their most pressing security needs. Aligning what we do with the world’s leading IP company, allows us to develop our products and capability to new levels.”
Security forms one of the main pillars of ARM’s business. The company offers the world’s most comprehensive IP security portfolio for smart connected devices. The acquisition of Sansa Security is the latest in a series of acquisitions and product launches aimed at simplifying the development and deployment of secure connected devices. Other activity in the development of ARM’s IoT business during the last 12 months includes:
June 1, 2015: Launched a IoT sub-system IP package to de-risk the design cycle for IoT chips
April 16, 2015: Launched ARM Cordio(R), the IT industry’s first sub-one-volt self-contained radio block and related firmware to simplify radio deployment in IoT devices
Feb. 24, 2015: Launch the ARM mbed(TM) IoT starter kit to simplify the process of adding IoT capabilities and secure cloud connectivity for device manufacturers
Feb. 9, 2015: Announced the acquisition of Offspark to integrate the world’s most pervasive embedded Transport Layer Security (TLS) solution in to the ARM mbed portfolio
Oct. 1, 2014: Launched ARM mbed, a new software platform and free operating system to simplify and speed up the creation and deployment of Internet of Things (IoT) products.
Sansa Security is a world-leading provider of system-wide security operating from the silicon chipset level to provisioning security in the enterprise cloud. Its technology enables the creation of secure devices through hardware security IP that complements ARM TrustZone. The company’s trusted software security IP, running in TrustZone-based Trusted Execution Environments, also protects code and data assets. Sansa Security’s IP will be integrated in to ARM’s TrustZone and IoT portfolios.
More Information:
https://www.sansasecurity.com/
Joe Fitzpatrick joins Xipiter
I didn’t know about this company until today. It looks like Joe Fitzpatrick of SecuringHardware is or soon will be joining them:
https://twitter.com/XipiterSec/status/616275086652235776
It appears Xipiter does security training, including Intel- and ARM-based hardware-level courses, including at upcoming DEF CON. They appear to have an upcoming Android course in the works, related to the Wiley Android Hacker’s Handbook, which has a nice chapter on ARM firmware hacking. They have other services besides training, and some hardware products as well.
http://www.xipiter.com/
http://www.xipiter.com/team.html
http://www.xipiter.com/training.html
Intel ATR research on CERT VU 976132
Earlier today I posted on US-CERT’s recent vulnerability note for multiple UEFI vulnerabilties:
Later today, Intel has released new research about this:
Technical Details of the S3 Resume Boot Script Vulnerability
“This paper describes technical details of a vulnerability (VU #976132 / CVE-2014-8274) in the protection of EFI based system firmware and platform configuration when resuming from the S3 sleep state. The issue was independently discovered and presented at 31C3 in December 2014. After discovering this issue, the Advanced Threat Research team has been working to notify BIOS developers and ensure that mitigations are created. We are releasing a test module for the open source CHIPSEC platform security assessment framework. This will assist users in identifying whether their platforms might be affected by this issue.“
Read the full report here:
Click to access WP_Intel_ATR_S3_ResBS_Vuln.pdf
Note the part about a new CHIPSEC test, to test for this vulnerability, so watch the CHIPSEC Github for an update. I don’t see an update as of yet.
OEMS: please watch the security talk from Phoenix from the last UEFI Forum plugfest, especially the advise to run CHIPSEC before you ship any new systems. Please ensure your QA team uses fresh CHIPSEC builds.
Consumer Reports and other PC reviewers: Please add the CHIPSEC pass/fail data for any new systems. OEMs will improve their internal QA once they realize that the first thing the public reviewers will be calling out the OEMs on known-bad products.
More information:
US CERT BIOS Vulnerability Note VU#577140!
Today, US CERT released a Vulernability Notice for UEFI firmware:
Vulnerability Note VU#577140
BIOS implementations fail to properly set UEFI write protections after waking from sleep mode
Multiple BIOS implementations fail to properly set write protections after waking from sleep, leading to the possibility of an arbitrary BIOS image reflash.
Description
According to Cornwell, Butterworth, Kovah, and Kallenberg, who reported the issue affecting certain Dell client systems (CVE-2015-2890):
There are a number of chipset mechanisms on Intel x86-based computers that provide protection of the BIOS from arbitrary reflash with attacker-controlled data. One of these is the BIOSLE and BIOSWE pair of bits found in the BIOS_CNTL register in the chipset. When the BIOSLE bit is set, the protection mechanism is enabled. The BIOS_CNTL is reset to its default value after a system reset. By default, the BIOSLE bit of the BIOS_CNTL register is cleared (disabled). The BIOS is responsible for re-enabling it after a reset. When a system goes to sleep and then wakes up, this is considered a reset from the hardware’s point of view.
Therefore, the BIOS_CNTL register must be reconfigured after waking from sleep. In a normal boot, the BIOS_CNTL is properly configured. However, in some instances BIOS makers do not properly re-set BIOS_CNTL bits upon wakeup. Therefore, an attacker is free to reflash the BIOS with an arbitrary image simply by forcing the system to go to sleep and wakes again. This bypasses the enforcement of signed updates or any other vendor mechanisms for protecting the BIOS from an arbitary reflash.
A similar issue affecting Apple systems (CVE-2015-3692) involves the FLOCKDN bit remaining unset after waking from sleep. For more information, refer to Pedro Vilaça’s blog disclosure.
See URL for full Notice.
HP QuickLook: EFI PIM for MS Outlook
In business-class HP systems, they include various pre-OS tools. In addition to “HP System Diagnostics”, some older HP laptops (and perhaps desktops, but hopefully not servers) include “HP QuickLook”, a UEFI Pre-OS application which is a PIM (Personal Information Manager) for Microsoft Outlook (email, calendar, tasks, contacts).
From an HP PDF entitled “HP Business Notebook Computer EFI Guidelines”, also in below URLs:
—-snip—-
The HP EFI partition includes the following applications, which are accessible during computer startup:
* HP QuickLook or later versions (select models)
* <…omitted…>
QuickLook is a personal information manager (PIM) viewer for Microsoft(R) Outlook 2003 and 2007. QuickLook captures Microsoft Outlook email, calendar, task, and contact information, and then displays it without starting the operating system and without launching Microsoft Outlook. QuickLook can access cached Outlook information at the press of a single button, whether the computer is off or in Hibernation.
—snip—-
That’s rather scary. UEFI Pre-OS office applications. I’m not sure if it is a UEFI Application which gets run when you press the button, or if it is a UEFI RunTime Service, that is always running and only provides UI when button is pressed.
Plus, the EFI System Partition (ESP) is a FAT32-based partition, no file system-level security. Granted, a Unix-based system could mount the volume in such a way to help protect the contents, but on a Windows-based platform the user will have full read-write access to the HP .EFI executables.
It looks like there is a 2010-era HP QuickLook 3.2, perhaps later versions. I am not sure if this software is on modern HP UEFI systems, I don’t see it anymore on some docs, it may no longer be used, I’m not sure.
So, some business-class HP systems can be attacked via email network protocols, with added system complexity of being surrounded by a firmware suspend-resume! Network and content-media attacks are both options for this application. System administrators should check if this is installed on any modern systems, and consider the security risks -vs- the convenience this offers. Hiding inside corrupted HP PIM pre-OS app/service would be a great place for malware to hang out, or gain foothold via “a single button, whether the computer is off or in Hibernation”.
http://h20564.www2.hp.com/hpsc/swd/public/detail?swItemId=ob_70686_2&swEnvOid=4054
http://h20564.www2.hp.com/hpsc/swd/public/detail?swItemId=ob_79720_1&swEnvOid=4059
Survey of Boot security technologies
Wow, there’s a lot of “Boot” buzzwords out there: U-Boot verified boot, Solaris Verified Boot, Chrome Verified Boot, Android Verified Boot (Class A and Class B), UEFI Secure Boot (sometimes called Windows Secure Boot), ARM TrustZone, UEFI Secure Boot, ARM TZ Secure Boot, Measured Boot (sometimes called TCG Measured Boot), Trusted Boot (Windows and Linux concepts) and most likely half a dozen others I don’t even know about… 🙂
UEFI Secure Boot aside, I’m still learning some of these other boot technologies, and how they overlap. I still have a LOT of questions about many of them. I think Verified Boot in Chrome and Android share the same Linux linux kernel technology, but have implemented things differently between Chrome and Android. UEFI’s Secure Boot doesn’t use a TPM, yet Microsoft requires OEMs to have a TPM. 😦 There’s the Trusted Boot that Windows has, and there’s also the tboot (Trusted Boot) loader that is Linux-centric. ARM’s TZ Secure Boot appears to be a different Secure Boot than the UEFI one. Solaris had their Verified Boot, but recently added UEFI support, so what is going to happen with UEFI Secure Boot, and will that mix with existing Solaris Verified Boot? Ditto on Android-IA, which only uses UEFI, will UEFI Secure Boot ever mix with Android Verified Boot?
None of these are full security solutions. For example, Intel has Boot Guard to help protect the system before UEFI Secure Boot’s protections kick in.
Below is a bit more information for each one. This is the first blog post on this topic, I’ll be doing further posts with more details about most of these in the future.
=================
U-Boot verified boot
“U-Boot 2013.07 introduces a feature allowing for the verification of a kernel and other images. U-Boot’s new verified boot feature provides a mechanism for verifying images while still allowing them to be field-upgraded. It fits in seamlessly with the existing image loading infrastructure in U-Boot. U-Boot verified boot relies on two familiar technologies: cryptographic hashing (e.g. SHA-1) and public key cryptography (e.g. RSA). Using these technologies it is possible to distribute images and have them verified on a device. Specifically we can create a key, hash an image, sign that hash, and publish the public key. On the device we can obtain an image and verify it was signed by the private key. Images can be chained one after the other and signed in reverse order either using the same keys or sub-keys (keys derived from other keys). For example, U-Boot may load an image containing a new U-Boot, then boot that. That U-Boot in turn may load an image containing a kernel. Doing that would allow U-Boot itself to be updated with the firmware without risking having an unbootable device due to a bad update. In principle this chain can be any length, but there must be an initial trusted image (“root of trust”) that can start the process. This can be stored in read-only media during manufacture or perhaps protected by on-chip crypto using its own signing scheme. The “root of trust” U-Boot must include the initial public key, held in U-Boot’s device tree (often called the flattened device tree or FDT). A more sophisticated scheme would allow the public keys to be provided by the user, perhaps by inserting an SD card containing the key. This could be implemented using a U-Boot script or with a more sophisticated user interface. A TPM can be used to hold rollback counters, to protect against rolling back to an older, compromised firmware. U-Boot also provides TPM support for trusted boot and remote attestation.”
http://git.denx.de/?p=u-boot.git;a=blob;f=doc/uImage.FIT/verified-boot.txt;
http://git.denx.de/?p=u-boot.git;a=blob;f=doc/uImage.FIT/signature.txt;
http://git.denx.de/?p=u-boot.git;a=blob;f=test/vboot/sign-images.its
https://lwn.net/Articles/571031/
=================
Solaris Verified Boot
“Solaris Verified Boot is a solution for Oracle’s version of Solaris. Solaris Verified Boot refers to verification of object modules before execution using digital signatures. If enabled, Solaris Verified Boot checks the factory-signed signature in a kernel module before loading and executing the module. This is to detect accidental or malicious modification of a module. The action taken is configurable and, when enabled, will either print a warning message and continue loading and executing the module or will fail and not load and execute the module. Solaris Verified Boot checks kernel modules before execution and reports if the module is modified. Optionally on failures, the module is not loaded. For Solaris, Solaris Verified Boot will verify kernel modules before execution, beginning with the initial bootstrap SPARC ‘bootblk’ sectors and initial ‘unix’ module. Both of these are verified by SPARC OpenBoot (because Solaris is not running yet). The Solaris kernel loader (krtld) then takes over and verifies the main (generic) “genunix” module and all subsequent modules loaded by the Solaris kernel. The policy to use on failures is configurable with three policy settings: none, warning, and enforce. The default policy is none (that is, Verified Boot is disabled); None is the default behavior — no verification before execution. Re: TPMs, Solaris Verified Boot has no impact on the TPM chip or TPM software (TrouSerS). However, the TPM still serves complementary functions such as providing a secure keystore or taking measurements of firmware executibles. Verified Boot settings are maintained by Oracle ILOM. Anyone with ILOM spsh shell access can modify these settings. Solaris Verified Boot is available with Solaris 11.2 for Sun SPARC T5/M5/M6 hardware platforms for host domains (with Sun Firmware FW 9.1.0 or better) and Fujitsu M10 systems (with Firmware XCP2250 firmware). Verified Boot is supported for the host domain in the Global Zone. Non-global, non-kernel zones do not have their own copy of the Solaris kernel and do not load kernel modules. Verified Boot is not supported initially for Solaris on X86, T4 or older SPARC platforms, LDoms guest domains, or Kernel Zones. We plan to support more hardware.”
https://blogs.oracle.com/DanX/entry/verified_boot
https://blogs.oracle.com/DanX/entry/solaris_kernel_zones_verified_boot
http://docs.oracle.com/cd/E36784_01/html/E37121/gmwce.html#OSSADgmwce
=================
Chrome Verified Boot
“Chrome Verified Boot is a solution for Google’s Chromium OS. The Chromium OS team is implementing a verified boot solution that strives to ensure that users feel secure when logging into a Chromium OS device. Verified boot starts with a read-only portion of firmware, which only executes the next chunk of boot code after verification. Verified boot strives to ensure that all executed code comes from the Chromium OS source tree, rather than from an attacker or corruption. Verified boot is focused on stopping the opportunistic attacker. While verified boot is not expected to detect every attack, the goal is to be a significant deterrent which will be improved upon iteratively. Verification during boot is performed on-the-fly to avoid delaying system start up. It uses stored cryptographic hashes and may be compatible with any trusted kernel. This feature is not expected to provide 100% detection of attacks. Instead, it is meant to raise the attack bar significantly and in a way that can be improved upon iteratively.”
https://www.chromium.org/chromium-os/chromiumos-design-docs/verified-boot
https://www.chromium.org/chromium-os/chromiumos-design-docs/verified-boot-crypto
https://sites.google.com/site/chromeoswikisite/home/what-s-new-in-dev-and-beta/shell-acess-with-verified-boot
http://research.google.com/pubs/pub42038.html
http://chrome.blogspot.com/2011/07/chromebook-security-browsing-more.html
=================
Android Verified Boot
“Android Verified Boot is a solution for Google’s Android OS. Android’s Verified boot guarantees the integrity of the device software starting from a hardware root of trust up to the system partition. During boot, each stage verifies the integrity and authenticity of the next stage before executing it. This capability can be used to warn users of unexpected changes to the software when they acquire a used device, for example. It will also provide an additional signal of device integrity for remote attestation, and together with encryption and Trusted Execution Environment (TEE) root of trust binding, adds another layer of protection for user data against malicious system software. We define two implementation classes for verified boot depending on how fully the device implements this specification. Class A implements verified boot with full chain of trust up to verified partitions. This implementation must support the LOCKED device state, and GREEN and RED boot states. Class B implements Class A and additionally supports the UNLOCKED device state and the ORANGE boot state.”
https://source.android.com/devices/tech/security/verifiedboot/verified-boot.html
https://source.android.com/devices/tech/security/verifiedboot/index.html
https://source.android.com/devices/tech/security/dm-verity.html
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/device-mapper/verity.txt
http://nelenkov.blogspot.com/2014/05/using-kitkat-verified-boot.html
https://lwn.net/Articles/638627/
=================
UEFI Secure Boot
“UEFI Secure Boot, sometimes called Windows Secure Boot, is an optional security feature of UEFI that can be enabled by a PC OEM to enhance the security by helping to make sure that your PC boots using only software that is trusted by the PC manufacturer. When the PC starts, the firmware checks the signature of each piece of boot software, including firmware drivers (Option ROMs) and the operating system. If the signatures are good, the PC boots, and the firmware gives control to the operating system. Secure Boot does not require a TPM.”
https://technet.microsoft.com/en-us/library/Hh824987.aspx
http://go.microsoft.com/fwlink/?LinkId=278911
Click to access lf_uefi_secure_boot_open_platforms.pdf
https://fedoraproject.org/wiki/Secureboot
https://wiki.ubuntu.com/SecurityTeam/SecureBoot
https://wiki.freebsd.org/SecureBoot
https://en.wikipedia.org/wiki/Unified_Extensible_Firmware_Interface#Secure_boot
http://en.community.dell.com/techcenter/os-applications/w/wiki/7568.secure-boot-overview
http://en.altlinux.org/UEFI_SecureBoot_mini-HOWTO
https://en.opensuse.org/openSUSE:UEFI
=================
Measured Boot
“I think some refer to Measured Boot as TCG Measured Boot. Windows supports Measured Boot, Trusted Boot, and Secure Boot. Windows 8 introduces a new feature called Measured Boot, which measures each component, from firmware up through the boot start drivers, stores those measurements in the TPM on the machine, and then makes available a log that can be tested remotely to verify the boot state of the client. The Measured Boot feature provides AM software with a trusted (resistant to spoofing and tampering) log of all boot components that started before AM software. AM software can use the log to determine whether components that ran before it are trustworthy or if they are infected with malware. The AM software on the local machine can send the log to a remote sever for evaluation. The remote server may initiate remediation actions either by interacting with software on the client or through out-of-band mechanisms, as appropriate. Working with the TPM and non-Microsoft software, Measured Boot in Windows 8.1 allows a trusted server on the network to verify the integrity of the Windows startup process.”
https://msdn.microsoft.com/en-us/library/windows/desktop/Hh848050%28v=VS.85%29.aspx
https://msdn.microsoft.com/en-us/library/windows/hardware/Dn653311%28v=VS.85%29.aspx
https://technet.microsoft.com/en-us/windows/dn168167.aspx
http://www.jwsecure.com/2011/10/18/secure-measured-boot-in-windows-8/
https://mbt.codeplex.com/
http://blogs.msdn.com/b/olivnie/archive/2013/01/09/windows-8-trusted-boot-secure-boot-measured-boot.aspx
https://msdn.microsoft.com/en-us/library/windows/desktop/Hh848050%28v=VS.85%29.aspx
https://www.ibm.com/developerworks/community/blogs/smartersecurity/entry/uefi_secure_boot_and_the_tpm_implementing_secure_boot_with_a_tpm27?lang=en
https://technet.microsoft.com/en-us/windows/dn168169.aspx
http://mjg59.dreamwidth.org/10971.html
UEFI Secure Boot aside, it appears that ARM TrustZone also uses Secure Boot as a non-UEFI-based concept:
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.prd29-genc-009492c/CACGCHFE.html
=================
Trusted Boot
“Windows supports Measured Boot, Trusted Boot, and Secure Boot. With Trusted Boot, Windows checks the integrity of every component of the startup process before loading it. Trusted Boot takes over where Secure Boot leaves off. The bootloader verifies the digital signature of the Windows 8.1 kernel before loading it. The Windows 8.1 kernel, in turn, verifies every other component of the Windows startup process, including the boot drivers, startup files, and ELAM. If a file has been modified, the bootloader detects the problem and refuses to load the corrupted component. Often, Windows 8.1 can automatically repair the corrupted component, restoring the integrity of Windows and allowing the PC to start normally.”
https://technet.microsoft.com/en-us/windows/dn168167.aspx
http://blogs.msdn.com/b/olivnie/archive/2013/01/09/windows-8-trusted-boot-secure-boot-measured-boot.aspx
“Trusted Boot (boot) is ALSO the name of an open source, pre-kernel/VMM module for Linux, that uses Intel TXT to perform a measured and verified launch of an OS kernel/VMM. Intel TXT provides a hardware- based root of trust to ensure that a platform boots with a known good configuration of firmware, BIOS, virtual machine monitor, and operating system.”
http://hg.code.sf.net/p/tboot/code
http://www.trustedcomputinggroup.org/resources/trusted_boot
https://software.intel.com/en-us/articles/intel-trusted-execution-technology
http://www-01.ibm.com/support/knowledgecenter/SSTQK9_1.1.3/com.ibm.powersc113.se/trusted_boot_concepts.htm
=================
Enterprises which are responsible for user/data security usually like these kinds of technologies. Citizens who like to control their own devices, including installing their preferred operating system, instead of using the pre-installed OEM OS, often find these security technologies a hindrance to their normal usage. OEMs — except Google, with the Developer Mode of their ChromeBook — ignore this latter, smaller consumer demographic, and focus strictly on the security-focused market, creating opportunities for “micro-OEMs” like Purism and Bunnie Studios.
http://www.fsf.org/campaigns/secure-boot-vs-restricted-boot/statement
https://en.wikipedia.org/wiki/Hardware_restriction
Firmware Security 
You must be logged in to post a comment.