Vitro Shard Threat Models and mitigation

This document is an overview of potential threats to which Vitro Shard and Vitro Shard Edge are exposed. Beyond showing threat models, it also introduces possible solutions and how to prevent or mitigate these threats.

📘
This documentation aims to keep expanding by indicating new threats, security gaps, and potential mitigation to them.

Physical access to SWD interface (MCU flash)

Serial Wire Debug is an interface that is used in STM32 MCU for interacting with flash memory. Typically it is reading current firmware or flashing a new one. SWD uses only four pins - SWCLK, SWDIO, NRST, GND. The programmer can be found on any Nucleo board, so it is widely available. Moreover, even if there is no dedicated header on Vitro Shard, connecting directly to the MCU's pads is still possible.

There are two threat models related to this exposure.

Threat model 1

The entire firmware binary can be read out from flash memory. In such a scenario, firmware can be reverse-engineered. By doing this, it provides insights into the firmware vulnerabilities. This may lead to disclosing some mechanism, which should not be explicitly available to the user.

Impact

First of all, Vitro Shard's binaries (already compiled application) can be obtained by users without much effort. You only need to download the application's source code repository and rebuild it. There will be firmware images available, so extracting them from Vitro Shard's flash memory is redundant. Secondly, most of the application is open-source. Therefore, subjecting it to reverse engineering is pointless. Moreover, the only closed part of the application is the vitroio-sdk library. However, it is already given as a binary file with a dedicated, described API as well.

Prevention

Reading and mass erasing flash memory can be completely disabled using the STM32 feature Read-out protection (RDP). Its behavior is defined by the level which is set:

Level 0: Disables the read-out protection, i.e., there is no flash memory protection at all.
Level 1: Protects the entire memory against reading and erasing, but with the option to revert to level 0.
Level 2: Permanently protects the entire memory, without the option to revert to a lower level. As such, flash memory is protected, and JTAG and boundary scan are disabled (JTAG fuse).

Mitigation

As an extra barrier, the SWD header on Vitro Shard is removed. Although the pads are still accessible, the attacker will need to solder precisely.

Threat model 2

Malicious firmware can be flashed to Vitro Shard. In such a scenario, the attacker, directly or after reverse engineering, can insert malicious code in the firmware and flash it into Vitro Shard.

Impact

This threat model assumes that the user wants to flash Vitro Shard with malicious firmware. As the developer can build applications, it is impossible to prevent firmware changes. Also, as access to writing flash memory is relatively easy, we can assume that almost every user with physical access can re-flash Vitro Shard. Moreover, data read from sensors can be manipulated. As long as valid keys are used for encryption and signature, there is no way to catch the error and recognize that Vitro Shard's firmware has been corrupted. This threat model must be considered vulnerable for Vitro Shard, Vitro Shard Edge, and the entire setup.

Prevention

Writing anything to flash memory can be completely disabled using the write protection feature in STM32. There is the possibility to protect selected sectors only. Those selected sectors can't be erased or programmed. It might seem that this feature completely resolves the given threat.

However, as write-protected flash memory can't be written anymore, it won't be possible to perform any firmware updates. As Vitro Shard utilizes OTA, this solution is unacceptable.

Mitigation

One solution that prevents Vitro Shard from booting malicious firmware while allowing OTA updates is the Secure Boot feature. Secure Boot is a mechanism that utilizes the Root of Trust concept. Every firmware component (bootloader, application, etc.) is checked against corruption by the preceding one during device boot up. This is possible by signing the given component with the key provided by the manufacturer. Details about the feature and specific implementations can be found here.

Secure Boot implementation is possible in Vitro Shard and should be considered a must-have feature. Moreover, Secure Boot also solves more threats models that will be considered in this documentation.

Physical access to the CAN bus

When the attacker ha
s physical access to the CAN bus, this allows reading raw data exchanged between Vitro Shard and Vitro Crystal. From Vitro Shard's perspective, the attacker has access to the IoT Block data. From Crystal, it is a new Vitro Shard's firmware update using OTA.

Threat model 3

Everyone with physical access to the CAN bus can sniff data being transmitted.

Impact

Possession of an IoT Block without the symmetric key is harmless. Sensor's data is encrypted, so there is no way to retrieve it. Assuming that the symmetric key is kept secret and there is no way the attacker can obtain it, this Threat Model shouldn't be treated as a security gap. However, the attacker can manipulate the IoT Block data. In such a situation, messages coming to AWS will be corrupted, and sensor data can no longer be extracted.

Another possibility is the attacker can repeat old messages obtained on the CAN bus. Although the attacker does not know the data content, it can: saturate the communication channel or provide some insight into security flaws (e.g., CAN error messages sent from and to Vitro Crystal).

Prevention

TODO: How to minimize the likelihood of CAN frames sniffing? How to reduce access to it? Currently, CAN is used to exchange data between Shard and Crystal, and it's easily accessible. There are CAN connectors and dedicated block terminals on the Shard Edge board. Anyone with physical access to them can attach a sniffer and read or even change data.

Mitigation

It is harmless to read IoT Blocks. Modifying them, especially in real-time, breaks the operation of the entire system. Physical access to devices should be restricted to prevent these attacks. For timing attacks, it is best not to handle errors at all. The Vitro Crystal's IoT Block processing time gives valuable information. Therefore, it is best to process each IoT Block as it was a valid one. Only after the processing, Vitro Crystal can choose the send or reject it. Having a message counter also helps to detect repeated messages.

Threat model 4

OTA firmware is not encrypted. Man in the middle can change given bits. Thus, making the OTA process to flash malicious firmware when an update is triggered.

Impact

When OTA is performed, images authenticity is checked by Vitro Crystal. Afterward, there is no more image authenticity test between Vitro Crystal and Vitro Shard (CAN bus). The attacker can modify binaries, so malicious firmware is flashed into VItro Shard. Vitro Crystal and Vitro Shard won't detect it, as authenticity has been done and the procedure has been triggered.

Prevention

TODO: The issue is the same as in Threat Model 3. How can we minimize the likelihood of CAN frames sniffing?

Mitigation

This Threat Model can be fully mitigated by introducing the Secure Firmware Update feature. It works almost the same way as the current OTA works. However, unlike OTA, new firmware authenticity is checked in Vitro Shard, not Vitro Crystal. This change mitigates described attack. If updated firmware is modified, it would be detected by Vitro Shard, and the update will be stopped.

Secure Firmware Update is described with details here.

Physical access to I2C interface

The crypto-module ATECC508 communicates with the MCU through the I2C interface. Anyone with physical access to it can retrieve the symmetric keys.

Impact

If the attacker has access to the I2C interface between the MCU and the crypto-module, it can obtain the symmetric keys. This beaks the entire system's cryptography.

Prevention

To substitute the crypto-module to the safer ATECC608, which stores symmetric keys internally. Therefore, the attacker can't extract the keys.

Mitigation

Vitro Shard comes with a soldered case over the MCU and the crypto-module to make access to its pins harder.

Physical access to UART

UART gives access to debug information only, but there is no communication in the other direction. Therefore, as long as the firmware doesn't read UART inputs, there is no threat from physical access to it.

Replacing Vitro Shard with another custom mPCIe module

This model assumes that a custom mPCIe module entirely imitates Vitro Shard. In such a scenario, the user can flash any firmware and gain control of the Shard Edge board.

Threat model 5

Use GSM/WIFI/Ethernet module via SPI to access the network and use a custom Cloud. It will successfully bypass Vitro Crystal and our AWS.

Impact

This Threat Model should be considered dangerous only from a business point of view. The user who bought Vitro Shard and Vitro Shard Edge is intended to use the entire set with Vitro Crystal and AWS. Access to Vitro Shard Edge capabilities is open, so one can buy this board and treat it as an expansion board in its project.

Prevention

Hide mPCIe connector pinout. Without knowing it, the supposed user would have problems figuring it out themself. Therefore, developing custom applications will be unprofitable.

Mitigation

TODO: How to mitigate this Threat Model? Do we need any prevention here?

Simultaneous access to the CAN bus and I2C line

Threat model 6

Users with simultaneous access to the CAN bus and I2C line can easily imitate Vitro Shard with a valid Vitro Shard ID and private keys.

Impact

This threat model is very dangerous. Physical access to both mentioned lines, open-source code, and knowledge about CAN segmentation protocol use might be used to imitate an actual Vitro Shard attached to Vitro Shard Edge. In this case, there is no way to figure out that such a situation took place because the IoT Blocks transmitted are completely correct. Moreover, even if the attacker doesn't have knowledge about actual private keys, they can still access it via the crypto-module. In such a scenario, malicious IoT Blocks will be sent to AWS, and there will be no way to distinguish them from valid ones.

Prevention

Such a situation can't be prevented entirely. The question of how to avoid it is the same as in Threat Model 3. It can be only limited by placing Vitro Shard Edge in a secure environment or hardly accessible place.

Mitigation

As long as Vitro Shard and Vitro Shard Edge are not closed in some cases, it is hard to mitigate physical attacks. Thus, closing this set in an anti-tamper box or case reduces the threat. In such a scenario, if the case is tampered with, the device sends a warning message and breaks communication with Vitro Crystal. By knowing its ID, imitating it will be pointless and easily detected by Vitro Crystal and AWS.