In our December update, we promised more detail about our third-party security reviews as they become available. The formal FIPS review work, being conducted by Penumbra, continues. The project is expected to be registered with NIST as one of the next steps after receiving the final feedback on the physical security pieces, particularly relating to deep analysis of the security shell enclosing the electronic components.

We’ve also completed specifying the work that will be performed by Kasper & Oswald GmbH (KAOS) in Germany, which includes both a general review of the various portions of the system and several very specific review items that are in-line with their areas of deep expertise, including analysis of vulnerabilities surrounding the RF portions of the system (NFC and BLE) with a particular eye on the protocols as well as relay and replay attacks.

Kasper & Oslwald’s claim to fame is the VW hack, and their ChameleonMini project. Some of the most prominent research they’ve been involved with surrounds automotive and RFID hacking - and these RF interfaces used have a lot in common with ORWL. Here is a summary of the full statement of work we’ve specified together, including more about them in their own words.

Project Description

DS is developing ORWL, an open-source PC specifically secured against physical attacks. DS wishes KAOS to evaluate the security of the “secure subsystem” of ORWL, which comprises a secure microcontroller, certain parts of the interface to the main CPU/BIOS, NFC and BLE interfaces, and a wireless keyfob.

Kasper & Oswald

The engineering company Kasper & Oswald GmbH provides comprehensive consulting services and product development in the field of embedded security. Our business activities comprise the analysis, design, and realization of corresponding security solutions. In training courses and lectures we illustrate the relevant security issues of hardware and software implementations and introduce the state-of-the-art of solving these problems. In the past years, KAOS has developed outstanding expertise and resources in the context of the security of embedded systems.

Content and Work Packages

DS provides documentation, source code (where necessary), and, one or (if possible) two ORWL units to KAOS. At the end of the project, KAOS provides a final report to DS, summarizing the results of the security analysis. During the project, KAOS and DS regularly communicate to discuss intermediate results and possible next steps. The work packages (WPs) proposed below can be adapted during the course of the project.

WP A: Initial Evaluation and Security analysis of NFC / BLE keyfob subsystem

• WP A.1: Definition of adversary models and evaluation of attack surface

Based on the provided documentation and discussions with DS, KAOS defines attacker model(s) applicable to the use cases of ORWL (e.g. “evil maid”, government-level adversary, “hacker”) together with their respective capabilities. Furthermore, the hardware attack surface (internal and external interfaces, wireless connections, etc.) is systematically investigated. The results of this WP are discussed with DS and form the basis for the subsequent security evaluation.

• WP A.2: Security analysis of NFC / BLE keyfob subsystem

To unlock ORWL, the user has to present an NFC / BLE keyfob. The authenticity of the keyfob is initially established via NFC; subsequently, the proximity of the user is periodically checked via BLE. In this WP, the attack surface of this subsystem is assessed, again based on WP A.1/discussions. Relevant aspects can include:
- Overall security architecture (based on documentation/code)
- Mathematical security of NFC protocol, initially based on documentation/code
- Subsequently, the NFC communication is sniffed and compared to the protocol specification
- Mathematical security of BLE protocol, initially based on documentation/code; if necessary, sniffing and comparison to specification possible
- Possibility of logical attacks (buffer overflows, code injection, etc.) over wireless interfaces (not a complete formal verification/review of source code)
- Possibility of and threat due to replay (BLE) and relay (NFC / BLE) attacks. Due to high efforts, practical verification only performed if separately agreed.
- Possibility of implementation attacks to extract cryptographic keys (side-channel analysis, fault injection, invasive attacks) from keyfob. Due to the high effort, practical tests only performed if separately agreed.

WP B: Security analysis of computer subsystem

The computer subsystem relates to the main x86 CPU and its boot process, which is controlled by the secure MCU. Therefore, this WP is strongly interrelated with WP C. The analysis comprises:

• Overall security architecture (based on documentation/code)
• Interfaces between main CPU and secure MCU (based on documentation/code)
• Security of ORWL if one processor (CPU / secure MCU) has been compromised (based on documentation/code)
• BIOS update procedure, possibilities for modification of flash contents and respective internal signals (WriteProtect#). Based on documentation/code, certain practical tests possible (e.g. verification of boot failure after flash modification).

WP C: Security analysis of secure MCU subsystem

The OWRL employs a Maxim MAX32550 secure MCU that controls most security-sensitive operations and stores/processes important cryptographic keys. Furthermore, the MCU is responsible for the tamper detection functionality. In this WP, attacks targeting the secure MCU are considered and evaluated. Where possible within the scope of the project, certain practical tests are conducted, or respective parts of source code analyzed. The exact analyses performed in this WP are defined based on WP A and discussions with DS. Potential aspects of the analysis include:

• Overall security architecture (based on documentation/code)
• Security of code execution/storage and firmware update process (based on documentation/code, verification of update procedure with oscilloscope if possible)
• Generation and distribution of cryptographic keys and random numbers, potential for

“cryptographic backdoors” (based on documentation/code)

• Possibility of implementation attacks to extract cryptographic keys (side-channel analysis, fault injection, invasive attacks). Due to the high effort, practical tests are only carried out if separately requested by DS.
• Tamper-detection system (including practical verification of correct operation), possibility for external manipulation of internal signals (e.g. power switch line, interface switches)

We are really excited to have KAOS as part of our third-party security review team!