IEEE’s 1735 Encryption May Allow Oracle Attacks, Trojan Hardwares, and Licensing Modifications

Researchers at the University of Florida have discovered flaws in the IEEE 1735 encryption standard used to protect intellectual property (IP) on SoCs. This standard is used by many major semiconductor companies including Xilinx and Synopsys.

IP licensing typically involves three parties: the IP author, the IP user, and the IP tools. The IP author licenses their product in order to recoup the cost of development, the IP user pays for licenses in order to use already existing solutions in custom SoCs, and the IP tool ensures that there is compliance in the protection of the IP through encryption.

In the case of IEEE 1735, even though the tools for Electronic Design Assurance (EDA) being used weren’t flawed, themselves, the encryption scheme was. This allowed for a range of consequences, from IPs being accessed via plaintext to the capability of making malicious and unauthorized modifications that could lead to hardware trojans being implemented. 

With the standard being widely adopted and used, designers of SoCs will need to reconsider their security protocols for IPs.

Below is some background information on the IEEE 1735 standard, as well as the flaws discovered by the University of Florida team.

What’s in a Standard

IEEE, the largest professional association in the world, publishes standards for information technology, robotics, telecommunication, biomedical and healthcare technologies, and information assurance. Technical experts from around the world provide their input into the development of standards via working groups, and eventually most vote and reach a consensus before it is finalized. Standards are used to describe procedures and specifications that increase reliability and compatibility of products or services. 

IEEE 1735-2014, also known as "IEEE Recommended Practice for Encryption and Management of Electronic Design Intellectual Property" (PDF) was sponsored by the Design and Automation Committee of
the IEEE Computer Society. The standard was approved in December 2014 by the IEEE SA-Standards Board. IEEE 1735 addresses how manufacturers and developers can protect their proprietary property when selling or licensing their products. It lists the practices and standards for handling IPs throughout design, integration, and manufacturing processes with licensed property.

It has become a common practice for designers to pay for a license to use an already existing and reusable solution, and combine it with their own work, such as encoders, decoders. Throughout the design process, the licensing company can expect that their IP won’t be reversed engineered or stolen.

Licensing IPs helps reduce cost and time to bring a product to market, and facilitates collaboration with both the consumer and distributor feeling more secure in their exchange. Examples of IPs that fall under the IEEE 1735 standard include electronic system designs, test benches, netlists, fabrication instructions, physical layouts, and design specifications.

The standard outlines the trust model, key management, rights management, license management, visibility management, and interoperability of IPs.

The 90-paged standards document can be accessed here (PDF).

Flaws in IEEE 1735

The team to discover the IEEE 1735 flaws used the Synopsys Synplify Premier EDA tool (Version L-2016.09) for demonstration. The team emphasized in their publication that the vulnerability is no fault of the tool, but of the encryption protocol. Seven different types of flaws were discovered, resulting in three different types of vulnerabilities and areas of attack: oracle attacks, trojan hardware attacks, and licensing/rights attacks. 

 

Padded Oracle Attack (POA)

The IEEE 1735 standard doesn’t specify the type of padding scheme to be used in its encryption standard, although symmetric CBC-mode encryption is used, requiring strings that are the length of the blockciphers.

The Synopsys EDA tool in the demonstration uses PKCS#7 padding, in which the end of a string is padded with the number of blocks that it is short by. (The example used is that, if there are two blocks that need to be padded, then it is padded using 0x02 0x02). If a decryption error occurs because of a padding error, a 1 is returned; otherwise, a 0 is returned.

The team demonstrated it was possible to use this to guess the last ciphertext block with 256x16xN guesses, a complexity of O(N²), and work backwards to guess the entire ciphertext.

The recommended solution is to use a scheme in which decryption doesn’t fail due to incorrect padding, such as AByte or OZ padding, or AES-CTR mode which requires no padding.

 

Image courtesy of the University of Florida.

 

Syntax Oracle Attack (SOA)

Similar to the Padded Oracle Attack, the Syntax Oracle Attack instead takes advantage of error messages received from bad syntax. Unlike POA, SOA can be used to guess any character of any block in the ciphertext.

The demonstration the team used was the ‘ symbol used in Verilog as a directive for define, ifdef, and include macros. If this syntax was used incorrectly, the EDA tool would return a syntax error. This feature could be used in a similar way to POA to guess the content of a cyphertext, and is possible within 256x16xN guesses.

The team was able to optimize this method to make it more efficient (for a typical industrial IP, this method would take 40 months to successfully guess an entire IP). Three different ways to optimize both oracle attacks was able to reduce attack time even further, and down to 128x16xNx(N-4) guesses. However, the optimization methods reduce accuracy.

 

Image courtesy of the University of Florida.

 

Hardware Trojans

In two different attacks, the team demonstrates that the integrity of the IP is not assured and does not check or validate the identity of the IP author.

In the first demonstration, the team was able to use either POA or SOA to access the ciphertext in plaintext. It then modifies the RTL of the IP block by inserting comment lines and adding in other Verilog code. Using this method, it was possible to acquire the encryption key for the IP.

In the second demonstration, the plaintext is replaced by the trojan text and encrypted with a random session key, and encrypt the new ciphertext to get the encrypted Data Block. The session key is then encrypted with the public key, and the Key Block is then acquired. These together provide the Digital Envelope.

Applying authentication of IP authors would help mitigate some of the hardware trojan vulnerabilities.

 

Image courtesy of the University of Florida.

 

Licensing and Rights

The team also demonstrated that the protocol used to verify and validate licenses could also be compromised through a man-in-the-middle attack. Since the length of encrypted messages can be found in plaintext, it is possible to cause truncation or extension attacks to make changes to the licensing messages and has no integrity checking.

The licensing validation not only checks that a user has the license to use the IP but also checks what kind of output or other access is available. The team demonstrated it was possible to manipulate the ciphertexts used with licensing validation to change the granting or denial of a license.

Conclusion

The team describes these vulnerabilities as "disappointing" coming from an organization like IEEE. The IEEE 1735 standard clearly needs to be reviewed, and possibly completely revamped.