Trustworthy Computing Group update

TCG’s monthly newsletter came out today. Here are a few highlights:

TCG’s Stefan Thom has an article on the IoT security implications of remote firmware updates:
http://www.trustedcomputinggroup.org/media_room/news/404

TCG has announced a new liaison relationship with the Industrial Internet Consortium (IIC), related to Industrial IoT security and trust:
http://www.trustedcomputinggroup.org/media_room/news/405

TCG’s TPM 2.0 Library Specification was approved as a formal international standard under ISO/IEC. The specification was submitted to the ISO/IEC JTC 1 by the TCG following the JTC 1 Publicly Available Specification (PAS) Transposition process.
http://www.trustedcomputinggroup.org/media_room/news/392

TCG has a few specs for public review:
* TCG PC Client Specific Platform Firmware Profile for TPM 2.0 Systems Revision 1.0 Version 21
* TPM 2.0 Mobile Common Profile Family 2.0 Level 00 Revision 29
* TCG Storage Opal Integration Guidelines, Version 1.00 Revision 1.14
* TCG Trusted Network Communications Server Discovery and Validation Version 1.0, Revision 19
http://www.trustedcomputinggroup.org/resources/specifications_in_public_review

More information:

Welcome To Trusted Computing Group

libSboot: Secure Boot for U-Boot

Teddy Reed wrote libSboot 3 years ago, and I am just noticing it. 😦 This “Secure Boot” is different than the UEFI definition/implementation, and is U-Boot-specific. Excerpting the readme:


libSboot provides an example ‘Secured Boot’ for U-Boot and a U-Boot Second Phase Loader (SPL). libSboot attempts to define an example of how a platform can measure a pre-OS boot environment, thus providing a capability to ensure that a libSboot-enforced OS is only loaded in an owner-authorized  fashion. A ‘Secure Boot’ concept is a common means to ensure platform security and integrity; understand that there are many implementations of a ‘Secure Boot’.  libSboot uses a TPM v1.2 to implement a secure boot using a static root of trust measurement (SRTM). The static adjective implies a ‘read-only’  attribute, meaning libSboot expects its initialization to occur from ROM code.  During this initialization libSboot performs a TPM_Start, TPM_SelfTest and  checks that the TPM is neither deactivated nor disabled. The TPM must have its NVRAM locked, meaning access control is enforced. Initialization then checks  each PCR used to measure the pre-boot environment and verifies they are reset. Finally Physical Presence is asserted to satisfy NVRAM read/write permissions.

https://github.com/theopolis/sboot
https://github.com/theopolis/u-boot-sboot
http://www.trustedcomputinggroup.org/community/2013/03/securing_embedded_devices_with_the_tpm__a_schmoocon_talk
http://prosauce.org/blog/2013/2/11/embedded-trust-p2-u-boot-secured-boot.html

TPM updates for Linux Shim and GRUB

Matthew Garrett has updated the Linux UEFI Shim and GRUB to support, based on some Trusted Grub patchset. He’s written a blog post with useful details on this update.

More information:

https://github.com/mjg59/shim/tree/tpm

https://github.com/mjg59/grub

http://mjg59.dreamwidth.org/37656.html

Microsoft Device Guard

Thanks to Matt Graeber’s Twitter post, I became aware of Microsoft’s new documentation for Device Guard, a security technology for Microsoft Windows.

https://twitter.com/mattifestation/status/643817965620588544

Microsoft Device Guard is a feature set that consists of both hardware and software system integrity hardening features that revolutionize the Windows operating system’s security. Windows 10 employs Device Guard as well as code integrity and advanced hardware features such as CPU virtualization extensions, Trusted Platform Module, and second-level address translation to offer comprehensive modern security to its users. This guide explores the individual features in Device Guard as well as how to plan for, configure, and deploy them. […]

https://technet.microsoft.com/en-us/library/mt463091%28v=vs.85%29.aspx

Linux Foundation IT Security Policies: firmware guidance

A  few days ago, the Linux Foundation released new guidance for securing Linux systems. Since the Linux Foundation has mostly remote workers, there are currently 2 documents: one on hardening Linux Workstations, and one for secure group communications, the latter something like a CryptoParty Handbook. Here’s an excerpt of the Hardware/Firmware/Pre-OS section from the Workstation document:

Choosing the right hardware

We do not mandate that our admins use a specific vendor or a specific model, so this section addresses core considerations when choosing a work system.

Checklist

    System supports SecureBoot (CRITICAL)
    System has no firewire, thunderbolt or ExpressCard ports (MODERATE)
    System has a TPM chip (LOW)

Considerations

SecureBoot

Despite its controversial nature, SecureBoot offers prevention against many attacks targeting workstations (Rootkits, “Evil Maid,” etc), without introducing too much extra hassle. It will not stop a truly dedicated attacker, plus there is a pretty high degree of certainty that state security agencies have ways to defeat it (probably by design), but having SecureBoot is better than having nothing at all. Alternatively, you may set up Anti Evil Maid which offers a more wholesome protection against the type of attacks that SecureBoot is supposed to prevent, but it will require more effort to set up and maintain.

Firewire, thunderbolt, and ExpressCard ports

Firewire is a standard that, by design, allows any connecting device full direct memory access to your system (see Wikipedia). Thunderbolt and ExpressCard are guilty of the same, though some later implementations of Thunderbolt attempt to limit the scope of memory access. It is best if the system you are getting has none of these ports, but it is not critical, as they usually can be turned off via UEFI or disabled in the kernel itself.

TPM Chip

Trusted Platform Module (TPM) is a crypto chip bundled with the motherboard separately from the core processor, which can be used for additional platform security (such as to store full-disk encryption keys), but is not normally used for day-to-day workstation operation. At best, this is a nice-to-have, unless you have a specific need to use TPM for your workstation security.

Pre-boot environment

This is a set of recommendations for your workstation before you even start with OS installation.

Checklist

    UEFI boot mode is used (not legacy BIOS) (CRITICAL)
    Password is required to enter UEFI configuration (CRITICAL)
    SecureBoot is enabled (CRITICAL)
    UEFI-level password is required to boot the system (LOW)

Considerations

UEFI and SecureBoot

UEFI, with all its warts, offers a lot of goodies that legacy BIOS doesn’t, such as SecureBoot. Most modern systems come with UEFI mode on by default.

Make sure a strong password is required to enter UEFI configuration mode. Pay attention, as many manufacturers quietly limit the length of the password you are allowed to use, so you may need to choose high-entropy short passwords vs. long passphrases (see below for more on passphrases).

Depending on the Linux distribution you decide to use, you may or may not have to jump through additional hoops in order to import your distribution’s SecureBoot key that would allow you to boot the distro. Many distributions have partnered with Microsoft to sign their released kernels with a key that is already recognized by most system manufacturers, therefore saving you the trouble of having to deal with key importing.

As an extra measure, before someone is allowed to even get to the boot partition and try some badness there, let’s make them enter a password. This password should be different from your UEFI management password, in order to prevent shoulder-surfing. If you shut down and start a lot, you may choose to not bother with this, as you will already have to enter a LUKS passphrase and this will save you a few extra keystrokes.

Full information:

https://github.com/lfit/itpol

https://github.com/lfit/itpol/blob/master/linux-workstation-security.md

http://linuxfoundation.org/

PS: The Linux Foundation also just started a Core Infrastructure Initiative, which has security implications, which I’ve got to find out more on, and will blog on later.

U-Boot TPM driver model added

Yesterday Simon Glass of Chromium has submitted a large (28-part) patch to U-Boot, adding a driver model for TPMs.

[PATCH v2 00/28] dm: Convert TPM drivers to driver model

This series adds driver model support for Trusted Platform Modules (TPMs). These have a very simple interface and are configured via the device tree.

Two bus types are supported at present: I2C and LPC (Intel Low-Pin-Count).

Most drivers and users are converted over to driver model. The exception is the Atmel TPM and its users.

The I2C driver has been cleaned up and simplified. It was ported from Linux and was pretty hard to follow. This series includes patches to unify the code, remove duplicated data structures and drop unnecessary indirection.

Also this series enables the TPM on all Chromebooks supported by upstream U-Boot (snow, spring, nyan-big, pit, pi, link, panther) since some did not have it fully enabled.

As before, the ‘tpm’ command can be used to implement TPM functionality. In addition a ‘tpmtest’ command provides some basic TPM tests taken from Chrome OS U-Boot. These are fairly rudimentary but are useful if you know what you are doing.

For more information, see the U-boot mailing list:
http://lists.denx.de/mailman/listinfo/u-boot

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.

Windows 10 and Secure Boot

Microsoft made Windows 10 available today, free upgrade for v7 and v8 users. The spec says:

“Secure boot requires firmware that supports UEFI v2.3.1 Errata B and has the Microsoft Windows Certification Authority in the UEFI signature database.”

For more information on Window 10’s firmware/hardware security requirements, look at Microsoft’s talk from the last UEFI Forum plugfest, from May: “Overview of Windows 10 Requirements for TPM, HVCI and SecureBoot“, by Gabe Stocco, Scott Anderson and Suhas Manangi (Microsoft):

More Information:

http://www.microsoft.com/en-us/windows/windows-10-specifications

Click to access UEFI_Plugfest_May_2015%20Windows%2010%20Requirements%20for%20TPM%2C%20HVCI%20and%20SecureBoot.pdf

http://blogs.windows.com/bloggingwindows/2015/07/28/windows-10-free-upgrade-available-in-190-countries-today/

tool mini-review: UEFI Reverse

UEFI Reverse (uefireverse) is a collection of tools to help with analysis of UEFI-based firwmare, written by Jethro Beekman (jethrogb). It consists of four tools.

1) EFI PE Run (efiperun): Load and run EFI PE image files on Linux.

DISCLAIMER: This program loads and runs PE image files. It does this without any protection mechanisms. Certain memory sections will be mapped writable and executable simultaneously. Do not run this on untrusted software. Think carefully before running this on trusted software. Load and run EFI PE image files on your favorite operation system (Linux). PE images are just x86 code that will run fine as long as the environment is correct. efiperun is to EFI as Wine is to Windows, but much less advanced. This tool is not meant for long-term use and only for debugging. There’s instrumentation everywhere, which is great for debugging but makes things slow.Memory generally doesn’t get freed. Most EFI functionality is not implemented. Functions that are implemented only provide the bare minimum. This tool aims to aid in debugging/reverse engineering by providing a framework that you can extend as necessary. By default, this program will load a PE image specified on the command-line, call the entry point, and exit once that returns. If the entry point does not return in 10 seconds, the program will abort with SIGALRM. Beyond running images, you can also extend this execution, with a “debug module”, an extension to efiperun that can run code before and after loading a PE image. This is useful to install protocols beforehand that the PE image will use or to access the protocols that the PE image installed afterwards.

See the tool’s readme, there are more ways to hook into the execution process.

2) GUID DataBase (guiddb): Create C source listing of TianoCore GUIDs.

A few programs that Scan EDK-II .DEC build files for GUIDs, and output them in C-source file format.

(There are about 4 GUID tools by different authors. One of these days, I’ll need to compare the various UEFI GUID tools’s output to see which’re more accurate…)

3) Memory Dump (memdmp): Tools to dump UEFI memory.

First, there’s a patch against UEFI Shell’s “memmap” dump memory command to pipe that to a file called “mdmp”. Then, run “dmp2seg” to convert that output file into many files with the actual memory contents. Then, run “make_elf.rb” to make a single ELF file with all the memory contents. The ELF file is not executable or anything, it’s just a convenient format to store memory segments.

4) Tree (tree): Ruby firmware tree on your filesystem.

A class file that will provides a Ruby tree abstraction for a firmware tree on your filesystem previously extracted by UEFITool’s UEFIExtract tool.

UEFI Reverse is a collection of some specialized UEFI research tools that may help augment your toolbox.

UEFI Reverse-aside, Jethro also has some TPMv2 project as well, that is worth checking out, if you use Linux and are into TPMs…

More Information:

https://github.com/jethrogb/uefireverse
https://github.com/jethrogb/tpm2-utils

OSCON post-conference proceedings

OSCON2015, the O’Reilly Open Source Convention, just ended. In addition to Matthew’s TPM CloudOS talk, there were a few other interesting talks:

Building a trustworthy computer
Matthew Garrett (CoreOS)
As we become more and more reliant on our computers, attackers become more and more sophisticated. How can we build a computer that’s resilient to some of the more subtle attacks such as firmware modification?
http://cdn.oreillystatic.com/en/assets/1/event/129/Building%20a%20trustworthy%20computer%20Presentation.odp

Closed devices powered by open source software? The IoT Paradox.
Peter Hoddie (Marvell)
The Internet of Things is built on open source software, and yet the devices are far from open. This isn’t the future that free and open source contributors have been working toward. It’s a disappointment for the Open Source Community, but we can lead the way to freedom, transparency, and collaboration in IoT. And we must—to avert impending frustration for increasingly savvy consumers.
http://cdn.oreillystatic.com/en/assets/1/event/129/Closed%20devices%20powered%20by%20open%20source%20software_%20The%20IoT%20Paradox_%20Presentation.pdf

Hacking smart electronics
Robert Gallup (XOBXOB)
Prototypes allow us to see, touch, feel, and refine ideas and designs. Starting from zero, this hands-on workshop explores smart hardware prototyping using a micro-controller and basic electronic components. You’ll connect LEDs, buttons, and knobs, then program a micro-controller to define behavior. Through this you’ll better understand the tools and process of designing smart, connected products.
http://cdn.oreillystatic.com/en/assets/1/event/129/Hacking%20smart%20electronics%20Presentation.zip
http://robertgallup.github.io/get/OSCONCourseware.zip

Introduction to developing embedded Linux device drivers
Nick Gudman (Hewlett Packard)
Learning to develop device drivers can be intimidating, but Linux makes it simpler than ever to write your own device driver. Using a simple driver for a monochromatic character display as a guide, we will briefly explore important topics for developing embedded Linux device drivers.
http://cdn.oreillystatic.com/en/assets/1/event/129/Introduction%20to%20developing%20embedded%20Linux%20device%20drivers%20Presentation.odp

Ironic: A modern approach to hardware provisioning
Devananda van der Veen (HP Cloud)
Ironic is a modern tool for hardware provisioning. Combining a RESTful API, scalable control plane, and pluggable hardware drivers, Ironic installs operating systems efficiently and repeatably on diverse hardware. We will demonstrate Ironic with Ansible, install, build, and deploy a machine image, and discuss the project’s architecture, history, and goals. Deep knowledge is not required.
http://cdn.oreillystatic.com/en/assets/1/event/129/Ironic_%20A%20modern%20approach%20to%20hardware%20provisioning%20Presentation.pdf

Raspberry Pi hacks
Ruth Suehle (Red Hat), Tom “spot” Callaway (Red Hat)
Ruth Suehle and Tom Callaway, authors of _Raspberry Pi Hacks_ (O’Reilly, December 2013) offer technical tips for makers, hackers, and tinkerers who want to take advantage of the Raspberry Pi. You’ll learn universally useful things, like how to add a power switch, followed by a show-and-tell of fun things that Ruth and Tom as well as many others have built.
http://cdn.oreillystatic.com/en/assets/1/event/129/Raspberry%20Pi%20hacks%20Presentation.pdf

Using open source tools to secure containers and clouds
Derek Thurston (Booz Allen Hamilton)
Is your cloud secure? Is your cloud of containers secure? Security should be built-in from Day Zero, and not layered in as an afterthought. What open source tools are out there now to help you in your quest to not be on the front page of the news? How are all of the latest hacks happening, and how can we put tools in place to prevent these from happening again?
http://cdn.oreillystatic.com/en/assets/1/event/129/Using%20open%20source%20tools%20to%20secure%20containers%20and%20clouds%20Presentation.ppt

I’m sure there’re some other gems too, the above list is what caught my eye… Mr. O’Reilly, please make the video — or at least audio — publicly-available too, don’t just for post-conference proceedings!

http://www.oscon.com/open-source-2015/public/schedule/proceedings

Matthew Garrett hardware talk at OSCON

As reported on by Seth on the Cypherpunks list, Matthew Garrett of CoreOS gave a talk earlier today at OSCON, on open hardware design, with a security background. OSCON is The O’Reilly Open Source Convention, probably the largest open source convention in North America. The slides are online, no audio/video yet, AFAICT. (I hope OSCON doesn’t continue to charge for access to post-conference video…)

http://www.oscon.com/open-source-2015/public/schedule/detail/41536

http://cdn.oreillystatic.com/en/assets/1/event/129/Building%20a%20trustworthy%20computer%20Presentation.odp

 

Building a trustworthy computer
Matthew Garrett (CoreOS)
11:10am–11:50am Friday, 07/24/2015

The Snowden revelations demonstrated the lengths that government agencies  
were willing and able to go to in order to subvert computers. But these  
attacks aren’t limited to state-level actors – security researchers  
continue to demonstrate new vulnerabilities and weaknesses that would  
permit sophisticated criminals to achieve the same goals.

In the face of these advanced attacks, what can we do to detect and  
mitigate them? How can we make use of existing security features, and what  
changes can we make to system design? In short, how can we ensure that a  
user can trust that their computer is acting in their interests rather  
than somebody else’s?

This presentation will cover some of the existing security features and  
recent design changes in systems that can make it easier to detect  
attacks, and provide mechanisms for defending against them in the first  
place, along with simple design changes that would make it easier for  
users to ensure that components haven’t been backdoored. In addition it  
will discuss some of the remaining challenges that don’t have solid  
answers as yet. Topics covered will include: Firmware security, Trusted
platform modules, attestation, and associated privacy risks, Hardware
design to support offline verification, Remaining components that could
act against the interests of the  hardware owner

Matthew Garrett is a security developer at CoreOS, specializing in the  
areas where software starts knowing a little more about hardware than  
you’d like. He implemented much of Linux’s support for UEFI Secure Boot,  
does things with TPMs and has found more bugs in system firmware than he’s  
entirely comfortable with.

LinuxCon North America this August in Seattle

LinuxCon North America is happening this August, in Seattle for the first time (I think). A quick look at their schedule shows a variety of interesting presentations related to firmware security:

* Extending the Secure Boot Certificate and Signature Chain of Trust in the OS – Fionnuala Gunter, Hypori
* Resurrecting Internet Booting – Boot Boot, Booting Over the Internet – John Hawley, Intel
* Demystifying ACPI and EFI via Python and BITS – Josh Triplett
* ACPI for Network Switches – Dustin Byford, Cumulus Networks
* Tying TPMs Throughout The Stack – Matthew Garrett, CoreOS
* Turtles All The Way: Running Linux on Open Hardware – Rob Landley
* ACPI 6 and Linux – Rafael J. Wysocki, Intel
* The Bare-Metal Hypervisor as a Platform for Innovation – Russell Pavlicek, Citrix
* Suspend/Resume at the Speed of Light – Len Brown, Intel

Josh Triplett on BIOS BITS sounds especially interesting. It’ll be interesting to see if the boot boot reboot will get integrated with UEFI HTTP Boot support.

More information:
http://events.linuxfoundation.org/events/linuxcon-north-america
http://events.linuxfoundation.org/events/linuxcon-north-america/program/schedule

RMS on Free Hardware from LibrePlanet 2015

The Free Software Foundation has released some of the videos from LibrePlanet 2015. The presentation from RMS is described as:

Free software, free hardware, and other things by Richard Stallman, founder of the Free Software Foundation. Richard gives his take on some major issues facing the world of free software and explains how the free software philosophy extends to hardware.

It is a 45-minute video, the first 23 minutes are presentation, the remainder are QA. Video is here:
https://media.libreplanet.org/u/libreplanet/m/richard-stallman-free-software-free-hardware/

I have few questions of my own, from watching it:

At the beginning, he mentions that remote attestation of TPM doesn’t work, without any details on why he thinks that. I don’t understand what he’s talking about, there are multiple TNC implemenations, as well as non-TNC equivalent solutions that use TPM for network attestation. Linux-based Chrome OS, StrongSwan for Linux, Linux-IMA or OpenAttestation (OAT) for example.
If someone has more background on his perspective on remote attestation of TPM doesn’t work, please speak up. Heck, even the UEFI firmware on most modern systems have TNC support. IMO, it would have been more interesting to hear a discussion about new TPM 2.0 features, as well as TrustZone on ARM, and how that impacts various Free Software/Firmware/Hardware movements.
https://github.com/OpenAttestation/OpenAttestation/wiki
https://wiki.strongswan.org/projects/strongswan/wiki/TrustedNetworkConnect
http://linux-ima.sourceforge.net/

Later, he talks about “Free Hardware” term, which AFAICT isn’t that well-defined, and recommends using GPLv3 for hardware, and doesn’t mention OSHWA license, except to say that the alternatives offer no value. I am not sure that the existing OSHWA has the same opinion as RMS with his “Free Hardware” perspective, see March-April thread on the OSHWA list. IMO, Free Hardware -vs- Open Hardware needs some clarification. I guess, like with software, we’ll have the Open camps and the Free camp, with FSF as the Free owner and OSHWA instead of OSI for the Open camps, in addition to the Closed camps. However, unlike ISVs, I’ve never met an OEM or IHV that likes the GPL, so any Free Hardware will likely have to be community-funded, like Novena; I hope the FSF plans community-funded Free Hardware in the coming months.
https://www.fsf.org/bulletin/2012/fall/a-bit-about-free-hardware
http://www.wired.com/2015/03/need-free-digital-hardware-designs/
http://www.wired.com/2015/03/richard-stallman-how-to-make-hardware-designs-free/
http://lists.oshwa.org/pipermail/discuss/2015-March/thread.html
https://www.crowdsupply.com/kosagi/novena