Penetration Test Report (Cure53): pentest report cryptech

Dr.-Ing. Mario Heiderich, Cure53
Bielefelder Str. 14
D 10709 Berlin
cure53.de · mario@cure53.de
Audit-Report CrypTech/DiamondKey 09.2018
Cure53 & Trustworks, Dr.-Ing. M. Heiderich, M. Wege, MSc. N. Kobeissi, MSc. N. Krein,
MSc. D. Weißer, BSc. J. Hector, Dr. M. Müllner, Dr. M. Kammerstetter
Index
Introduction
Scope
Identified Vulnerabilities
CT-01-005 MCU: OOB writes through dynamic stack allocations (Critical)
CT-01-006 MCU: Value cast allows a bypass of the size checks (Critical)
CT-01-007 MCU: Buffer overflow via Set- and Get- attributes (Critical)
CT-01-008 MCU: Session reuse via weak client handles (High)
CT-01-009 MCU: OOB read/write via ASN.1 key files with large numbers (High)
Miscellaneous Issues
CT-01-001 FPGA: Incomplete asynchronous reset of FPGA modules (Low)
CT-01-002 FPGA: Side-effects on writes to memory-mapped interface (Low)
CT-01-003 FPGA: Readout of intermediate results via the external Interface (Low)
CT-01-004 MCU: Hardening memory-mapped interface access in libhal (Low)
Conclusions
C-Code Audit
Cryptography
Verilog Code Audit
General Impressions
Closing Notes
Cure53, Berlin · 09/26/18 1/19
Dr.-Ing. Mario Heiderich, Cure53
Bielefelder Str. 14
D 10709 Berlin
cure53.de · mario@cure53.de
Introduction
“The goal of the CrypTech project is to create an open-source hardware cryptographic
engine that can be built by anyone from public hardware specifications and open-source
firmware and operated without fees of any kind. The team working on the project is a loose
international collective of engineers trying to improve assurance and privacy on the Internet.
It is funded diversely and is administratively quartered outside the US.
The project solicits functional requirements from a wide range of organizations. It will focus
on the classic low level cryptographic functions and primitives, and not get drawn into re-
implementation of application protocol layers.”
From https://cryptech.is
This report documents the results of a large-scale security assessment of the CrypTech/
DiamondKey HSM firmware. The project was carried out in September 2018 by a joint
team comprising members of Cure53, Berlin, and Trustworks, Vienna. It entailed a
source code audit, a cryptography review and additional, relevant tests against the
aforementioned compound. Nine security-relevant discoveries were made by the testing
team.
In terms of resources and timeline, the project team included six testers from Cure53
and two engineers representing Trustworks. Once the agreements on the scope and
schedule were reached, the testing team was granted a time budget of thirtytwo days,
which had then been invested into investigations completed through a range of varied
approaches. In addition, some of the budgeted days were allocated to communications
and coordination of the actual assessment. The vast majority of work took place in
September 2018, specifically in Calendar Weeks (CWs) 38 and 39.
Moving on to the approach, a white-box methodology was used for this assessment.
This means that the testers had been provided with access to all relevant sources, as
well as benefitted from several test-devices sent by the customer for the testing
purposes. In addition, the CrypTech/DiamondKey teams organized several walkthroughs
in order to makes sure that the intricate and complex nature of the scope is fully
understood. In relation to the complexity, the assessment was divided into six Work
Packages (WPs), each with clear objectives and targets. While the WP1 encompassed
Documentation Review and WP2 entailed investigations of the System Build/Boot, the
remaining four WPs pertained to audits of the demarcated areas of interest. Specifically,
these were the Verilog Audit (WP3), C/Verilog Interface Audit (WP4), General C Audit
(WP5), and, last but not least, the Cryptography Audit (WP6).
Given the excellent product overviews and walkthroughs that the Cure53 and Trustworks
teams received prior to the start of the assessment, the need for clarifications or contact
during the actual project was not overly pronounced. For the most part, Cure53 provided
status updates to the CrypTech/DiamondKey teams and only posed very few minor
questions. Live test-related communications were done on several, dedicated and
Cure53, Berlin · 09/26/18 2/19
Dr.-Ing. Mario Heiderich, Cure53
Bielefelder Str. 14
D 10709 Berlin
cure53.de · mario@cure53.de
shared Slack channels. One channel was used to coordinate the work between Cure53
and Trustworks, while the other served as a direct line between the testers and the in-
house teams at CrypTech/DiamondKey. With this setup, the project progressed well and
without any major delays, even in the face of several test devices arriving late at their
final destinations due to logistical problems.
The assessment was successful in so far that it revealed a number of issues that the
CrypTech/DiamondKey teams clearly needs to tackle. Among the aforementioned nine
discoveries, five were categorized as actual security vulnerabilities and four belong to
the class of general, less-severe weaknesses. It is vital to underline that all
vulnerabilities had greatly elevated rankings, meaning that the risks they posed were
significant. Three problems were ascribed with the highest-possible “Critical” severity,
while the remaining two vulnerabilities were deemed to signify “High”-level, substantial
threats. Foreshadowing some of the conclusions, this clearly indicates that - from a
security perspective - the results are not satisfactory when seen vis-à-vis the CrypTech/
DiamondKey HSM firmware’s goals.
In the following sections, this report will first shed light on the items in scope of this
assessment. Then, the findings will be described in a considerable, technical detail on a
case-by-case basis. Whenever possible, the testing team also furnishes advice on
possible mitigation routes for the spotted and distinct problems. Lastly, the report shares
some general impressions gained by the Cure53 and Trustworks testing team,
commenting on the overall security posture of the CrypTech/DiamondKey HSM
compound.
Scope
• CrypTech/DiamondKey Firmware
◦ Cure53 was tasked with auditing the code for the CrypTech/DiamondKey firmware;
full access to all relevant sources was granted.
◦ Cure53 was also supplied with several test-devices to directly work on.
◦ The teams also go access to the extended documentation pertaining to the inner-
workings of the firmware. This facilitated reaching a better coverage during this audit.
Cure53, Berlin · 09/26/18 3/19
Dr.-Ing. Mario Heiderich, Cure53
Bielefelder Str. 14
D 10709 Berlin
cure53.de · mario@cure53.de
Identified Vulnerabilities
The following sections list both vulnerabilities and implementation issues spotted during
the testing period. Note that findings are listed in a chronological order rather than by
their degree of severity and impact. The aforementioned severity rank is simply given in
brackets following the title heading for each vulnerability. Each vulnerability is
additionally given a unique identifier (e.g. CT-01-001) for the purpose of facilitating any
future follow-up correspondence.
CT-01-005 MCU: OOB writes through dynamic stack allocations (Critical)
Throughout the code, multiple locations use untrusted user-input to dynamically allocate
memory on the stack. This can lead to out-of-bound (OOB) writes and therefore memory
corruptions, effectively due to overly large parameters. Below is an example code
excerpt that depicts vulnerability to this issue. An attacker can trigger an OOB write by
providing a negative value for attributes_len.
Affected File:
Source/Cryptech/releng/alpha/source/sw/libhal/rpc_server.c
An Example of Affected Code:
static hal_error_t pkey_get_attributes(const uint8_t **iptr, const uint8_t *
const ilimit, uint8_t **optr, const uint8_t * const olimit)
{
hal_client_handle_t client;
hal_pkey_handle_t pkey;
uint32_t attributes_len, u32;
uint8_t *optr_orig = *optr;
hal_error_t err;
check(hal_xdr_decode_int(iptr, ilimi