When is Cybersecurity Not Enough?
September 22, 2022
Blog
When does a cyber security problem become a physical security problem? Or stated differently, when do semiconductors have to have built-in tamper detectors?
For companies building next generation weapons systems for the United States Armed Forces, or any armed forces the answer is clear. They must assume the equipment will be left behind and subsequently tampered with. Semiconductors with built-in tamper detectors give engineers the tools necessary to satisfy DoD requirements and are used quite extensively to enable foreign military sales.
But what about the broader non-defense market? Some think that cyber security is all they need. After all, they have “physical” security through fences, gates, guards, cameras, firewalls, and leverage their own employees to build and or manufacture their systems. That may be enough. But one must ask themself, under what conditions would anyone (could be an employee) have access to a piece of equipment and what could they do to it to allow the function the equipment serves to be exploited or secrets extracted?
This inevitably leads a company answer the question “Is my supply chain managed securely?” Do equipment or shipments ever get “lost?” How does equipment get de-commissioned? Who services equipment and how is it upgraded? The answer(s) to the question, “who has access to a piece of equipment during the life of that equipment and what can they do with it?” will help drive an organization’s decision process.
Below are key security topics to consider:
Manufacturing - Build the PCB board, assemble, and test.
- During the programming of any non-volatile device are companies using hashed and signed images? Is there an auditable log of what’s been provisioned, number of boards that have been provisioned, and number of boards that have failed outgoing tests? Are these logs hashed and signed?
- Are debug ports disabled?
Shipping to customers
- Can an organization account for units shipped versus units received by the customer? Most customers will say right away “Hey were short one!” But what if the customer missed one, for any reason? The company would have to assume it has a piece of equipment in the wild.
- Can a company and its customers verify the integrity of the equipment shipped? Can they verify that it hasn’t been tampered with in transit?
Deployed equipment
- Are there anti-tamper seals on the equipment?
- Are only authorized technicians allowed to service equipment?
- Are remote updates allowed?
- If so, are the images verified to be intact and authentic?
- Are there mechanisms in place to prevent roll backs?
- When equipment is de-commissioned is it zeroized? Made inoperable? Destroyed?
If the answer is “no” to any of the above, then an organization should strongly consider semiconductors that have anti-tamper countermeasures built-in so they can tailor their tamper responses to the risk scenarios a piece of equipment is likely to see during its life cycle. For example, an FPGA product should have multiple anti-tamper features that can be used to customize a threat response (Fig. 1). Examples include:
- A sufficient number of digital tamper flags.
- Multiple analog windowed voltage detectors giving you high and low trip points for each critical supply (Vdd, Vdd18, Vdda25).
- A digital windowed temperature providing you a high and low die temperature.
- Raw voltage and temperature values from the built-in temperature detector.
- A system controller slow clock indicating a system controller brownout condition.
- A digital bus (at least 5 bit) indicating the source of a device reset (DEVRST pin, tamper macro input, system controller watchdog, security lock tamper detectors have fired, any other reset).
Fig. 1: Design and data security attributes of the Microchip PolarFire FPGA and PolarFire SoC FPGA devices.
Tamper Detection and Response
There are many types of tamper flags that should be available when instantiating an FPGA design’s tamper macro. Each has its own purpose:
Flags[31:0] |
Flag Name |
Description |
1 |
MESH_ERROR |
Active Mesh Tamper Flag. This flag is asserted whenever the active security mesh observes a mismatch between the actual metal mesh output and the expected output. This allows protection against invasive attacks, such as the cutting and probing of traces using focused ion beam (FIB) technology with an active metal mesh on one of the higher metal layers. |
2 |
CLOCK_MONITOR_GLITCH |
Asserted whenever the clock glitch monitor detects a pulse width violation |
3 |
CLOCK_MONITOR_FREQUENCY |
Asserted whenever the clock frequency monitor observes a frequency mismatch between the 160 MHz and 2 MHz RC oscillators. |
4 |
LOW_1P05 |
Asserted when the 1.05 V supply (VDD) is below the low threshold of the System Controller 1.05 V detector |
5 |
HIGH_1P8 |
Asserted when the 1.8 V supply (VDD18) is above the high threshold of the System Controller 1.8 V detector |
6 |
HIGH_2P5 |
Asserted when the 2.5 V supply (VDD25) is above the high threshold of the System Controller 2.5 V detector. |
7 |
Reserved |
Reserved |
8 |
SECDED |
Asserted when a 2-bit error occurs in the System Controller's internal memory. This is a fatal condition which results in a POR. |
9 |
SCB_BUS_ERROR |
Asserted when an error has been detected on the System Controller bus. |
10 |
WATCHDOG |
Asserted when the System Controller's watchdog reset is about to fire. |
11 |
LOCK_ERROR |
Asserted when a single- or double-bit error is detected in the continuously monitored security lock segments. |
12 |
Reserved |
Reserved |
13 |
DIGEST |
Asserted when a requested digest check is failed. |
14 |
INST_BUFFER_ACCESS |
The flag is asserted when read/write access is performed to system controller’s shared buffer using JTAG/SPI interface. |
15 |
INST_DEBUG |
Asserted when debug instruction executed. |
16 |
INST_CHECK_DIGESTS |
Asserted when an external digest check has been requested. |
17 |
INST_EC_SETUP |
Asserted when elliptic curve slave instructions have been used. |
18 |
INST_FACTORY_PRIVATE |
Asserted when factory JTAG/SPI instruction is executed. |
19 |
INST_KEY_VALIDATION |
Asserted when key validation protocol is requested. |
20 |
INST_MISC |
Asserted when uncategorized SPI slave instruction executed. |
21 |
INST_PASSCODE_MATCH |
Asserted when an attempt has made to match a passcode. |
22 |
INST_PASSCODE_SETUP |
Asserted when the one-time-passcode protocol is initiated. |
23 |
INST_PROGRAMMING |
Asserted when an external programming instruction has been used. |
24 |
INST_PUBLIC_INFO |
Asserted when a request for device public information is issued. |
25 |
Reserved |
Reserved |
26 |
INST_PASSCODE_FAIL |
Asserted when the passcode match fails. |
27 |
INST_KEY_VALIDATION_FAIL |
Asserted when the key validation fails. |
28 |
INST_UNUSED |
Asserted when the unused instruction opcode is executed. |
29 |
BITSTREAM_AUTHENTICATION_FAIL |
Asserted when the bitstream authentication fails. |
30 |
IAP_AUTO_UPDATE |
Asserted if an IAP update occurs (either by IAP system service or auto-update at device boot). |
31 |
IAP_AUTO_RECOVERY |
Asserted if the IAP recovery procedure occurs. |
Response is as important as detection. Once a company has decided to act due to unauthorized tampering during a single event, a series of events, or any combination therein, the response should be tailored to events over time. Or the organization can drop the hammer and brick the part. Examples include:
IO Disable
Disables all user IOs. IOs are reset to the state defined by their SEU immune configuration bits. Dedicated (JTAG, SPI, XCVRs, etc), or IO not configured by configuration bits are excluded. IOs are disabled as long IO_DISABLE is asserted
Security Lockdown
All user locks are set to their lock state.
Reset
Send a reset signal to the System Controller to initiate a power-down and a power-up cycle
Zeroization
Clear and verify any or all configuration storage elements. Internal volatile memories such as LSRAMs, uSRAMs, and System Controller RAMs are cleared and verified. Once the zeroization is complete, a zeroization certificate can be retrieved using a JTAG/SPI slave instruction to confirm that the zeroization process is successful. This tamper response is not available when the System Controller Suspend mode is enabled. Users can choose to zeroized into 2 different states :
- Like new – the device reverts to the state it was in before it was shipped.
- Unrecoverable. Even companies can’t gain access to the internals of the device.
Once Zeroization is complete, a zeroization certificate can be exported over the dedicated JTAG/SPI ports providing assurance to an external entity that the device is indeed zeroized.
Cybersecurity is not enough in today’s highly competitive environment. The equipment a company makes will fall into the hands of its competitors and bad actors. Semiconductor products must have a variety of built-in anti-tamper features that organizations can use to customize their response to these threats.