These days, there are fewer and fewer aspects of our lives that don’t rely to some degree on technology. Chips are pretty much everywhere, and some of the everywhere situations they’re in are life and death ones. And/or they’re applications that are devouring data (often highly personal) with a voraciousness that make Pacman seem close-mouthed. These factors raise a chip’s inherent risk level. While it may not
have happened (yet) in real life, a decade ago, those of us who watched Homeland saw the American vice president assassinated when terrorists hacked his heart defibrillator. On the data end, the vulnerabilities of information manipulation and theft are likely to be at the application level, not the chip level. Still, those chips contain data that is exceedingly valuable – and vulnerable to security attacks.
Writing on EDN, Joshua Norem recently offered his thoughts on the matter in “A primer on security in the key stages of IC manufacturing lifecycle.” This article (the first in a two-part series) focused specifically on the IC production lifecycle (fabrication through package test). The second part (not yet published) will concentrate on security risks that are specific to end-product manufacturers (board assembly and board test). So far, it’s an interesting and useful read for anyone involved in the chip lifecycle.
Norem describes the security threats present at each stage.
Fabrication: At this step, the IC’s ROM is programmed. While he views attacks at this stage as unlikely. They’re high cost, require considerable expertise, and provide attackers with “no way of knowing which devices will end up in which end-products.” Still, the stage is not without risks in certain arenas.
A private key in ROM, or hard-coded into a hardware register, could be extracted, putting an end-product at risk. Norem advises that the way to get around this potential problem is to design products so that they “never include secret information.”
Logic changes, through which a foundry introduces an “exploitable defect,” an unauthorized modification that alters device behavior, is seen by Norem as a more likely threat avenue. The best way around this is sample testing “to verify the contents of ROM, verify the logic, and test other functions.”
A foundry may also be a bad actor that overproduces devices with modified ROM, get around testing requirements (because the devices aren’t part of the legitimate run), make an end-run around the supply chain, and pass them on to an unsuspecting OEM, which is now producing end-products with a rogue (and vulnerable) IC. “The best way to prevent overproduction is to provision cryptographic credentials at package test. OEMs can then check these credentials to ensure they received a genuine device from that vendor.”
The final fabrication threat Norem sees is when ICs are produced in an unsecured environment.
Probe test: Threats can be introduced at this stage if the test (or tester) is compromised, and an attacker tries to inject malicious code. Norem doesn’t see a threat here as all that feasible, largely because they’ll be caught at the package test level. Still, if a production line is shoddy, it can occur.
Package assembly: At this stage, outright theft can occur.
have happened (yet) in real life, a decade ago, those of us who watched Homeland saw the American vice president assassinated when terrorists hacked his heart defibrillator. On the data end, the vulnerabilities of information manipulation and theft are likely to be at the application level, not the chip level. Still, those chips contain data that is exceedingly valuable – and vulnerable to security attacks.The goal in stealing blank devices is to obtain open samples, configure them in a way advantageous to the attacker, and then deliver them to a target OEM as legitimate devices. This strategy allows a specific OEM or product to be targeted and bypasses the vendor’s final test, which would otherwise overwrite or detect the modifications.
The way to avoid this is through incorporating cryptographic credentials in a device.
Hackers who can get their hands on a device may not steal, manipulate, and deliver bad devices. They may just make off with a few devices and figure out what vulnerabilities there are to exploit. Among the methods used to mitigate this risk is to improve your process, by “including audits of assembly contractors’ processes and procedures, tracking any open devices used internally for development, and destruction of open samples when no longer needed.”
Package test: This is the final stage in the IC production cycle before the device is completely given over to the OEM doing end-product development. For starters, Norem recommends good security hygiene at the testing site: access restrictions, log controls, standard network and PC security practices. He then offers some specific ways to counter the threats of malicious code injection, extraction of confidential information, and device analysis. Lots of good suggestions in there, including close collaboration with OEMs.
I haven’t seen part two of this series yet, but I’ll be keeping my eye out for it. Security is (or should be) paramount throughout the IC lifecycle. This article was a helpful reminder of just how critical it is.