Boffins tear into IEEE's tissue-thin anti-hacker chip blueprint crypto
This kind of security should keep the likes of the NSA and pirates out, but doesn't
Several large gaps have been found in the IEEE's P1735 cryptography standard that can be exploited to unlock or tamper with encrypted system-on-chip blueprints.
The P1735 scheme was designed so that chip designers could, ideally, shield their intellectual property from prying eyes.
When you're creating a system-on-chip processor, you typically won't want to craft it completely from scratch. You'll most likely license various complex pieces – such as video encoders and decoders, wireless communications electronics, and USB controllers – and slot them onto your final die design alongside your own logic and CPU cores.
These licensed components are quite valuable to their designers, though. As such they'll want to protect them from being reverse engineered and cloned to be used for free by pirates. As such, the IEEE developed P1735, a standard for encrypting hardware designs to keep them confidential throughout the manufacturing process. This requires you use P1735-compliant engineering software to import the ciphered blocks and integrate them with your own logic before taping out your chip.
That should keep everyone happy: the video decoder or USB controller developer gets to license their technology for money and keep the blueprints secret, and you get to market faster with your custom system-on-chip.
However, according to a team at the University of Florida in the US this month, the standard is broken and potentially dangerous. It is possible to decrypt blueprints protected by P1735, and alter them to inject hidden malware.
"We find a surprising number of cryptographic mistakes in the standard," the research crew said.
"In the most egregious cases, these mistakes enable attack vectors that allow us to recover the entire underlying plaintext IP [intellectual property]. Some of these attack vectors are well-known, e.g. padding-oracle attacks. Others are new, and are made possible by the need to support the typical uses of the underlying IP."
The main flaw lies in the standard's use of AES-CBC mode, the bedrock of its encryption system. Because the standard makes no recommendation for any specific padding scheme, developers of P1735-compliant engineering tools often pick the wrong scheme. This makes it possible to decrypt the blueprints without the necessary key using a classic padding-oracle technique.
There is a fix for this weakness, we're told: toolchain programmers should switch to an AByte or OZ padding scheme, which is secure, or encrypt designs using AES-CTR mode. That will keep the data confidential, which should please technology licensors, but it doesn't protect the blueprints' integrity, which is not good news for you, the system-on-chip designer.
It's one thing to prevent miscreants from decrypting the licensed schematics or hardware design code; it's another to prevent them from silently modifying bits and bytes to maliciously change the operation of the actual resulting chip. P1735 ought to prevent that, but doesn't.
The encryption scheme is vulnerable to so-called syntax-oracle attacks. It is possible to modify a byte within the encrypted data so that when it is decrypted and processed by the engineering software tools, it triggers an error message that gives away the kind of data altered. For example, if you tweak a character in the ciphered design, and see something like “expecting identifier immediately following back-quote,” or "unknown macro" in the toolchain's log output, you can start to get a sense of what the plaintext was.
Over enough iterations, an attacker, with access to an encrypted design and the necessary engineering toolchain, can eventually work out what's what inside the ciphered blueprint from the syntax errors, and alter it to add an invisible backdoor hidden in the physical circuits of the chip. The IEEE's P1735 approach does not do enough to prevent this.
Suffice to say, if someone can tamper with a licensed block to embed secret security vulnerabilities, and then somehow smuggle it into your manufacturing process, you have way bigger problems on your hands. However, it would be nice if the institute's standard could alert you straight away to any mystery alterations in the supplied blueprints.
It is also possible, it appears, to alter the metadata within an encrypted block to, for example, use the design without a valid technology license.
To demonstrate the flaws in the standard, the Florida team crafted a hardware trojan and slipped it into an encrypted system-on-chip block, where it remained virtually undetectable. We can imagine the NSA being interested in this kind of thing to compromise chip designs.
"While the confidentiality attacks can reveal the entire plaintext IP, the integrity attack enables an attacker to insert hardware trojans into the encrypted IP," the boffins concluded. "This not only destroys any protection that the standard was supposed to provide, but also increases the risk premium of the IP."
A full list of the flaws is below:
- CVE-2017-13091: improperly specified padding in CBC mode allows use of an EDA tool as a decryption oracle.
- CVE-2017-13092: improperly specified HDL syntax allows use of an EDA tool as a decryption oracle.
- CVE-2017-13093: modification of encrypted IP cyphertext to insert hardware trojans.
- CVE-2017-13094: modification of the encryption key and insertion of hardware trojans in any IP.
- CVE-2017-13095: modification of a license-deny response to a license grant.
- CVE-2017-13096: modification of Rights Block to get rid of or relax access control.
- CVE-2017-13097: modification of Rights Block to get rid of or relax license requirement.
US CERT has alerted vendors using the P1735 scheme in an insecure manner, and has published a list of manufacturers and developers contacted. These include AMD, Cisco, IBM, Intel, Qualcomm, Samsung, Synposys, Mentor Graphics, Cadence Design Systems, Marvell, NXP, and Xilinx, all potentially at risk but so far unconfirmed. ®
PS: P1735 uses one-time session keys and public-private key pairs to encrypt designs in transit and at rest. However, how the standard keeps a blueprint out of the hands of a miscreant once the design is decrypted in memory by the engineering toolchain for processing is unclear....