Uncategorized

Intel TXE 3.0 security update??

Quoting an article from hexus.net:

MSI adds latest Intel TXE 3.0 security update

In order to avoid severe security vulnerabilities for the platforms, MSI motherboards now support the latest Intel Trusted Execution Engine (TXE) 3.0 for safer system protection. According to recent Intel comprehensive security review, security vulnerabilities are identified and could potentially allow attackers to gain unauthorized access to platforms features, secrets and 3rdparty secrets protected by Intel TXE. Therefore, Intel has validated and released Intel TXE 3.0 updates to address the encountered security situations. Currently all MSI 100,200 and 300 series motherboards are supporting the newest Intel TXE 3.0 by updating to the latest BIOS and installing the latest software updates. MSI always places strong emphasis on security and anti-hack issues to makes sure all MSI motherboard users are operating under the most secure circumstances. MSI will continue to provide additional updates if necessary to ensure maximum platform security protection for users.[…]

https://hexus.net/tech/items/mainboard/111626-msi-adds-latest-intel-txe-30-security-update/

[ Update: my last paragraph was wrong, removed. see Comment by reader. :-). ]

Standard
Uncategorized

OpenXT

Linux.com has a nice article on Xen, Linux, TPM, and TXT. It also mentions the OpenXT toolkit.

https://www.linux.com/blog/event/elce/2017/10/device-we-trust-measure-twice-compute-once-xen-linux-tpm-20-and-txt

OpenXT is an open-source development toolkit for hardware-assisted security research and appliance integration. Released as Open-Source Software (OSS) in June 2014, OpenXT stands on the shoulders of Xen Project and OpenEmbedded. It is derived from XenClient XT, which was first released in May 2011. It includes hardened Xen VMs that can be configured as a user-facing virtualization appliance, for client devices with Linux and/or Windows guests. It has been used to develop managed software appliances to isolate demanding graphics workloads, untrusted workloads and multiple networks on a single laptop or desktop. OpenXT is optimized for x86 devices with Intel VT-d, TXT (Trusted Execution Technology) and a TPM. OpenXT is being developed to meet the varied needs of the security and virtualization communities, as a toolkit for the configurable disaggregation of operating systems and user workflows. Client appliances developed on OpenXT can contain a mixture of open-source and proprietary software, supporting a range of business models.[…]

https://openxt.atlassian.net/wiki/spaces/OD/pages/10747915/What+is+OpenXT

 

Standard
Uncategorized

EFI TBOOT

The EFI TBOOT project is currently under development! EFI TBOOT is mostly a proof of concept at this point. It is not currently functional. It can be built and installed as an EFI boot loader. It only works in conjunction with Xen at the moment. The current development work is being done on Fedora 25 x64. The status as of March 14, 2017 is:
 – EFI TBOOT will boot, but it needs a few key strokes to get going (this is for debugging purposes).
 – EFI TBOOT will relocate itself to EFI runtime memory and setup a shared runtime variable with Xen.
 – EFI related configuration setup is done as well as standard TBOOT pre-launch configuration.
 – Xen is launched and has code to call EFI TBOOT back after EBS.
 – EFI TBOOT then does the SENTER successfully in the callback.
 – The post launch entry point is reached but the switch back to long mode is not working.
[…]
EFI TBOOT needs a number of platform support files used with TXT (called Authenticated Code Modules or ACMs). For convenience the packages can be gotten from the OpenXT mirror:
http://mirror.openxt.org/
[…]

https://github.com/rossphilipson/efi-tboot

Standard
Uncategorized

VZ on Secure Boot, Intel TXT, Linux, and UEFI

Earlier today, Matthew Garret posted a problem on Twitter about Intel Linux and Intel TXT mode:

https://firmwaresecurity.com/2015/10/19/mjg-on-secure-boot-intel-txt-linux-and-security/

Later that day, Vincent Zimmer of Intel is apparently helping to get that Intel project working with UEFI:

A few weeks ago, a similar thing happened with Intel SGX. Intel is lucky to have Vincent Zimmer, who is very engaged with Linux security/development community, in helping to fix Intel projects to properly support UEFI. Many large companies do not have this kind of public individual involvement.

Standard
Uncategorized

MJG on Secure Boot, Intel TXT, Linux, and security

A short security lesson from Matthew (click on Twitter link for follow-up post):

[BTW, sorry WordPress doesn’t seem to render Twitter’s HTML table when scrolling through the site If you ever see multiple blank lines in the post it is probably a Twitter URL that WordPress didn’t render, refresh to fix. You have to refresh on new pages, often, or view the post on a separate page (which generates a refresh). I post messages while online and finding news, but don’t spend a huge amount of extra time formatting the posting, simple ASCII text plus a few URLs. The interactive WordPress HTML UI to add a hyperlink triples the time to post each message, and WordPress won’t accept HTML <A> links. WordPress renders some URLs differently, like showing the image of a JPEG/PNG/etc, and showing the Youtube video link and hiding the rest of a web page which contains a Youtube URL — like Kickstart funding pages.]

Standard
Uncategorized

Intel KGT

Wow, I wasn’t aware of Intel’s Kernel-Guard Technology (KGT) for Linux, until today. 😦

As found on the Twitter feed of Alex Bazhaniuk (@ABazhaniuk):

Intel Kernel-Guard Technology (Intel KGT) is a policy specification and enforcement framework for ensuring runtime integrity of kernel and platform assets.  The Intel® KGT framework allows policy writers to specify:
 * Which OS/platform resources to monitor
 * Actions to take when the monitored resource is accessed
 * A policy

A policy can be specified at build-time (embedded in the code), boot-time (such as through grub module), or at runtime (via configfs and script), and is enforced by an outside-OS component.  The Intel KGT framework, along with an appropriate policy, can be used to achieve immutability and runtime integrity of critical resources such as kernel code pages, kernel pagetable mappings, kernel interrupt descriptor table (IDT), control registers (CRs), MSRs, and MMIO regions. The Intel KGT is based on xmon, which is a thin VT-x component. Xmon runs in vmx-root (ring -1), de-privileges the OS, and uses VTx controls to trap access to specified resources and enforce policy specified actions. Xmon is not limited to using VT-x and, in the future, is expected to incorporate other CPU and platform features in addition to VT-x to enforce policy.    

Their Overview page gives a good introduction.
https://01.org/intel-kgt/overview

It looks like the last release was August 7th, with Intel TXT/tboot support:
https://lists.01.org/pipermail/intel-kgt/2015-August/000012.html

More Information:
https://github.com/01org/ikgt-manifest
https://01.org/intel-kgt/

Standard
Uncategorized

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
http://www.amazon.com/Platform-Embedded-Security-Technology-Revealed/dp/143026571X/

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.

Standard