tillitis-key/doc/threat_model/threat_model.md

Threat model

Introduction

The Tillitis TKey device is a platform for running device apps in a secure, restricted execution environment physically separate from the client. The device provides the device app access to secrets derived through measurement of the loaded device app. The device app in turn provides functionality and controlled access to assets to a companion client app as needed to solve different use cases.

This document describes the threat model for the Tillitis TKey device and the device app. Based on the system description and use cases, the threat model tries to capture and describe the threats that needs to be mitigated in order for the device app to work in a secure and trustworthy manner.

Assumptions

• There are no backdoors or vulnerabilities in Lattice iCE40 UltraPlus FPGA devices that allow external access to the internal configuration memory (Non-Volatile Configuration Memory, NVCM) after the device configuration has been written to the NVCM and external access has been locked down through the fuses.

• There is no access path to the contents of the NVCM from the FPGA fabric besides the configuration circuit.

• There exist a possible warm boot attack against the Lattice iCE40 UltraPlus FPGAs, which allows an attacker with physical access to load a FPGA configuration even though the NVCM has been programmed and locked.

• The FPGA development toolchain, including YoSys, NextPnR and IceStorm generates a correct design, and also does not inject hardware exfiltration mechanisms in the generated bitstream.

• The end user is not an attacker. The end user at least doesn't knowingly aid the attacker in attacks on their device.

Assets

• UDS - Unique Device Secret. Provisioned and stored in the FPGA NVCM during TKey device provisioning. Never to be replaced or altered during the life time of a given TKey device. Used to derive application secrets. Must never leave the device. Tillitis must NOT not store a copy of the UDS.

• UDI - Unique Device ID. Provisioned and stored in the FPGA NVCM during TKey device provisioning. Never to be replaced or altered during the life time of a given device. May be copied, extracted, read from the device.

• USS - User Supplied Secret. Provisioned by the user from the client during loading of the device app. Should not be revealed to a third party.

• CDI - Compound Device Identity. Computed by firmware when an application is loaded using the UDS, the USS, and a hash of the device app binary. Used by the application to derive secrets, keys etc. as needed. The CDI should never be exposed outside of the FPGA.

Threats and threat vectors

There are two major type of attacks

1. Software (SW) based. These are attacks against the TKey device that are performed from a client and enter the TKey device through the USB port. The SW attacks includes buffer flow attacks, attacks on the firmware protocol.

2. Hardware (HW) based. These are attacks against the FPGA design of the TKey device as well as the PCB. The HW attacks includes fault injection, side-channel leakage as well as warm boot attacks. These attacks may be performed from the client through the USB port, through the TKey enclosure, or near the TKey device.

Threat Actors - The bad guys

Different actors have different reasons for performing attacks. They have also different access to competence, resources etc. This description tries to capture examples of possible attacks and how the TKey device should be able to stand up against them.

0. Average Joe

Average Joe Soundtrack

• Curious opportunist
• No real competence, no resources beyond a personal computer
• No planning or preparation before an attack
• Prepared to invest little time (minutes) or resources - for example to connect a device found, try a few user supplied secrets
• End game is to gain access to possible information, client resources unknown to the attacker before the attack is performed

Attacks by Average Joe will come from the USB port and is SW based, or just manual attempts. Given a hard to guess USS, the TKey Device should withstand any attack no matter how long time the attack is allowed

1. The CCC Hacker

CCC Hacker Soundtrack

• Sympathetic to the goals of the project
• Wants to probe all parts and the system in a quest to determine how the device really works, use it in possibly different ways, find weaknesses (and get them fixed)
• Is possibly a user, but in this case not the legitimate end user
• Have a high level of competence
• Prepared to spend time to prepare and perform an attack. Possibly low effort over an extended period
• Access to compute resources. Possibly access to lab equipment
• Will try all possible SW and HW attack vectors. In and out of scope
• End game is to find flaws in threat model. Acquire knowledge and findings to produce an interesting talk at CCC, USENIX or Security Fest

Over time (with new releases), and given feedback by the CCC Hacker, the TKey device should be able to withstand attacks by the CCC Hacker.

2. vERyRevil

vERyRevil Soundtrack

• Ransomware gang. Driven by short term financial gain
• Short term focus. Fastest possible access to economic assets
• Have, or can acquire high level of competence
• Have access to large amount of resources
• Have time and is prepared to spend time on preparations
• Short time to perform an attack. Will not persist for a long time
• Will do strict cost benefit-analysis to decide to perform, abort attacks if they don't work
• SW based attacks. Is assumed to remotely own the host
• Supply chain attacks on secure application, host application, SDK, infiltration of device and application development
• End game is to gain access, control over resources protected by the device. Resources that can be used as leverage for financial gain

Over time (with new releases), The TKey device should be able to withstand SW attacks by vERyRevil.

4. APT4711

APT4711 Soundtrack

• State actor
• Interested in access to information, perform surveillance, and possibly control of the end user or resources
• Long term focus. Attacks are discreet and persistent
• Access to high competence
• Access to very large amounts of resources
• Prepared to invest a lot of time, effort to prepare and execute an attack
• Prepared to perform physical visits (evil maid missions) at target (end user) as well as Tillitis or the suppliers to Tillitis as needed to manipulate, steal, replace components, systems
• SW based attacks. Is assumed to remotely own the host
• Supply chain attacks - both on SW and HW, components
• Supply chain attacks on application, host application, SDK, development
• End game: Long term stealth presence providing access to information about the end user

Over time (with new releases), The TKey device should be able to withstand SW based attacks. Over time, the TKey Device should be able to make evil maid attacks take long enough time to make in infeasible to perform without the user discovering the missing device.

TKey Release specific scope

This threat model will be updated for each release of the TKey device. For each version we describe what threats are in scope, what threats are out of scope and what mitigations are in place.

TKey Unlocked

Note that the threat model and the mitigations per release (see below) applies to TKey Unlocked devices too as long as they have been provisioned with:

• the bitstream from the release,
• A unique, random UDS
• A unique UDI

The configuration must have been written into the NVCM and locked by blowing the fuses.

TK1-24.03-Bellatrix

Mitigations

• USB port attacks - boot protocol:

  • Instead of exiting to an eternal loop on errors, firmware now forces a CPU trap state that requires a reboot.

• Software attacks:

  Access outside of physical RAM forces the CPU into a trap state that requires a reboot.

TK1-23.03.2-Bellatrix

This release contains a BOM update to the Tkey hardware for the touch capabilites, hence the specific scope for TK1-23.03-1-Bellatrix is valid for this release.

TK1-23.03.1-Bellatrix

This is the first general release of the TKey TK1 end user device. In this device the FPGA bitstream is stored and locked into the NVCM. This means that the bitstream can't be changed or read out from the device.

The UDS and UDI assets are generated during provisioning by Tillitis, and are stored as part of the FPGA bitstream. The UDS is generated using the tpt tool and is not stored by Tillitis after generation.

The FPGA design contain some mechanisms for execution protection, execution monitoring as well as functionality designed to make warm boot based evil maid attacks harder to successfully perform, i.e. take longer time. Moreover the transparent TKey casing is glued together which makes it harder to open up without leaving physical marks indicating tamper attempts.

The FPGA design as well as the firmware has been audited, and hardening of these has been performed to some degree. For more information, see the Release Notes

Mitigations

• To protect the UDS the hardware design allows only one read per word of the UDS per power-cycle.

• USB port attacks - boot protocol:

  • The firmware has a more strict protocol state machine and exits out to an eternal loop on any errors.

  • Firmware stack is protected by hardware for execution.

• Software attacks:

  • Firmware uses its own FW_RAM for sensitive computations which is not available in app mode.

  • Device apps can protect arbitrarly parts of RAM, typically heap + stack, with hardware support.

• Hardware attacks:

  • The reading and handling of the UDS is randomized so it doesn't always occur on the same cycle.

  • Firmware turns on hardware assisted RAM address and data scrambling mechanisms. It makes it harder for an outside attacker to find assets generated by and stored in the RAM by applications. Note that this mitigates an attack from outside the CPU, not from an exploit towards applications running on it.

Known possible weakneses

The CH552 MCU providing USB host communication contains firmware that implements the UART communication with the FPGA. The CH552 firmware can be updated by performing port knocking. The knock sequence is to apply 3.3V through a 10k resistor to the D+ line, while powering on the device.

There may be possible buffer overflow attacks via the USB host interface into the firmware of the CH552, allowing both execution and modification of the firmware CH552.

In scope

• SW attacks from the host against the firmware in the FPGA as well as the FPGA design itself via the USB host interface.

• Timing attacks on the firmware and the FPGA design.

Out of scope

• Leakage and glitching attacks including:

  • Faulting of the execution by the CPU in the FPGA and the CH552 MCU
  • EM leakage

• Warm boot attacks. It should be hard to successfully perform against the TKey, but the attack is not yet fully mitigated.

• Attacks on the TKey device apps.

engineering-release-1

This is an early release aimed at developers interested in writing applications for Tillitis TKey. The design allows easy access to the board, and is even shipped with a programmer to download new FPGA bitstreams.

Known weakneses

The bitstream, which includes the Unique Device Secret (UDS) as well as the firmware implementing the measured boot are stored as part of the bitstream in an external Flash memory connected with SPI to the FPGA.

The CH552 MCU providing USB host communication contains firmware that implements the UART communication with the FPGA. The firmware can be updated by performing port knocking. The knock sequence is to apply 3.3V through a 10k resistor to the D+ line, while powering on the device.

There may be possible buffer overflows via the USB host interface to the firmware of the CH552, allowing both execution and modification of the firmware CH552.

In scope

(Attacks we really would like to have investigated.)

• Digital attacks from the host against the firmware in the FPGA, and the FPGA design itself via the host interface.

• Timing attacks on the firmware in the FPGA.

Out of scope

• All physical and electrical attacks applied to the board, including:

  • Reading out of the UDS from the external Flash chip
  • Triggering of the FPGA warm boot functionality
  • Triggering firmware update of the CH552 MCU, using the port knocking mechanism

• Glitching attacks including:

  • Faulting of the execution by the CPU in the FPGA and the CH552 MCU
  • Disturbance of the TRNG entropy generation

• EM leakage