NXP security during the boot process

Data Protection with the NXP QorIQ Platform Trust Architecture
Mike Slonosky
With the increased sophistication of embedded applications, systems designers and their customers are expressing heightened concerns regarding the importance of protecting the data residing in their systems, and by extension, their investment in intellectual property. Curtiss-Wright Defense Solutions has given data protection a very high priority in the design of its Power Architecture single board computers (SBC). Curtiss-Wright utilizes NXP’s (formerly Freescale) next generation system-on-chip (SoC) QorIQ T2080 Platform for its rugged, SWaP-optimized Power Architecture modules. The QorIQ Platform’s Trust Architecture allows for developing systems to achieve higher levels of security, with reductions in cost, size and power. This paper will refer solely to the T2080 Processor when stating the name of this QorIQ processor family. For a detailed review of the P4080 Processor, please read the following white paper: Embedded High Assurance Computing Using NXP Trust Architecture. This paper presents an overview of the potential threats to an embedded system, and how the Trust Architecture can effectively defend against these threats.[…]

https://www.curtisswrightds.com/infocenter/white-papers/trusted-architecture—data-protection-with-the-qoriq-platform-trust-architecture.html

https://www.curtisswrightds.com/content/images/T2080-with-QorIQ-Trust-Architecture.JPG

NXP: designing IoT devices with secure boot

NXP has a webinar for IoT makers, talking about secure booting. ‘Webinar’ scared me, but there’s no registration required. 🙂

Watch this on-demand presentation to learn how to:
* Manage the life cycle of an IoT edge node from development to deployment.
* Leverage hardware and software offerings available with the Kinetis MCU portfolio that can help you protect against attacks.
* Ease the burden of secure IoT edge node development using new processors and architectures from ARM.

https://community.arm.com/processors/trustzone-for-armv8-m/b/blog/posts/designing-secure-iot-devices-starts-with-a-secure-boot

http://www.nxp.com/video/designing-secure-iot-devices-starts-with-a-secure-boot:DESIGNING-SECURE-IOT-DEVICES

slides: https://www.nxp.com/docs/en/supporting-information/Designing-Secure-IoT-Devices-Starts-with-a-Secure-Boot.pdf

Click to access Designing-Secure-IoT-Devices-Starts-with-a-Secure-Boot.pdf

NXP LPC1343 Bootloader Bypass, part 1of3

https://twitter.com/nedos/status/893406313992073216

NXP LPC1343 Bootloader Bypass (Part 1)
Aug 4, 2017

This will be the first of a three part series on bypassing the security of the embedded NXP LPC1343 In System Programmer (ISP) bootloader. Although we’ll focus on the LPC1343, keep in mind that this bootloader is the embedded bootloader in many NXP LPC microcontrollers. One more thing worth mentioning, is that although the details outlined in this series will be specific to NXP LPC’s you’ll be able to find similar vulnerabilities in almost all non-secure microcontrollers. As Jasper van Woudenberg (@jzvw) recently said at a an event we were both speaking at “If no-one implemented countermeasures – it means it’s vulnerable”. Also a big shoutout goes to Chris Gerlinsky (@akacastor) for dumping, dissassembling and documenting the bootloader as part of his Recon Brussels 2017 Talk. You should take a look at this talk before you begin and both the slides and the video of the talk are available.[…]

https://toothless.co/blog/bootloader-bypass-part1/

https://toothless.co/trainings/

Click to access RECON-BRX-2017-Breaking_CRP_on_NXP_LPC_Microcontrollers_slides.pdf

Quarkslab’s vulnerabilitries in NXP i.MX secure boot

 

Vulnerabilities in High Assurance Boot of NXP i.MX microprocessors
By Guillaume Delugré Iván Arce

This blog post provides details about two vulnerabilities found by Quarkslab’s researchers Guillaume Delugré and Kévin Szkudłapski in the secure boot feature of the i.MX family of application processors [1] built by NXP Semiconductors. The bugs allow an attacker to subvert the secure boot process to bypass code signature verification and load and execute arbitrary code on i.MX application processors that have the High Assurance Boot feature enabled. These bugs affect 12 i.MX processor families. The vulnerabilities were discovered and reported to the vendor in September 2016 and the technical details included in this blogpost were disclosed in a joint Quarkslab-NXP presentation at the Qualcomm Mobile Security Summit 2017 [2] in May 19th, 2017. National computer emergency response teams (CERTs) from 4 countries were informed about the issues in March, 2017. NXP has issued an Engineering Bulletin and two Errata documents (EB00854, ERR010872 and ERR0108873 respectively) [3] providing a brief description of both vulnerabilities, the list of affected processor models along with resolution plans and possible mitigations. In the rest of the blogpost we describe the relevant features in i.MX processors and the vulnerabilities affecting them.[…]InversePath, vendor of USB Armory [6], an affected device confirmed the vulnerabilities and developed proof of concept programs to demonstrate them.[…]

https://blog.quarkslab.com/vulnerabilities-in-high-assurance-boot-of-nxp-imx-microprocessors.html

https://labsblog.f-secure.com/2017/07/19/break-your-own-product-and-break-it-hard/

https://github.com/inversepath/usbarmory/blob/master/software/secure_boot/Security_Advisory-Ref_QBVR2017-0001.txt

USB Armory: High Assurance Boot (HABv4) bypass

Security advisory: High Assurance Boot (HABv4) bypass

The NXP i.MX53 System-on-Chip, main processor used in the USB armory Mk I board [1] design, suffers from vulnerabilities that allow bypass of the optional High Assurance Boot function (HABv4). The HABv4 [2] enables on-chip internal boot ROM authentication of the initial bootloader with a digital signature, establishing the first trust anchor for further code authentication. This functionality is commonly known as Secure Boot [3] and it can be activated by users who require authentication of the bootloader (e.g. U-Boot) to further maintain, and verify, trust of executed code. Quarkslab reported [4] to NXP, and subsequently to Inverse Path, two different techniques for bypassing HABv4 by means of exploiting validation errors in the SoC internal boot ROM [5], which are exposed before bootloader authentication takes place. While the two vulnerabilities have been initially reported for the i.MX6 SoC, Inverse Path evaluated that both issues also apply to the i.MX53 SoC, used on the USB armory Mk I.
[…]
Technical details under embargo until July 18th, by mutual agreement between
reported and NXP.
[…]

https://github.com/inversepath/usbarmory/blob/master/software/secure_boot/Security_Advisory-Ref_QBVR2017-0001.txt

U-Boot gets NVMe support

Zhikang Zhang of NXP added NVMe driver support to U-Boot.

Add Support of devices that follow the NVM Express standard

 Basic functions:
    nvme init/scan
    nvme info – show the basic information of device
    nvme Read/Write

 Driver model:
    Use block device(CONFIG_BLK)’s structure to support nvme’s DM.
    Use UCLASS_PCI as a parent uclass.

The driver code heavily copy from the NVMe driver code in Linux Kernel.

Add nvme commands in U-Boot command line.

1. “nvme list” – show all available NVMe blk devices
2. “nvme info” – show current or a specific NVMe blk device
3. “nvme device” – show or set current device
4. “nvme part” – print partition table
5. “nvme read” – read data from NVMe blk device
6. “nvme write” – write data to NVMe blk device

More info: U-Boot mailing list.