TY - GEN
T1 - Hardware trojan horses in cryptographic IP cores
AU - Bhasin, Shivam
AU - Danger, Jean Luc
AU - Guilley, Sylvain
AU - Ngo, Xuan Thuy
AU - Sauvage, Laurent
PY - 2013/12/9
Y1 - 2013/12/9
N2 - Detecting hardware trojans is a difficult task in general. In this article we study hardware trojan horses insertion and detection in cryptographic intellectual property (IP) blocks. The context is that of a fabless design house that sells IP blocks as GDSII hard macros, and wants to check that final products have not been infected by trojans during the foundry stage. First, we show the efficiency of a medium cost hardware trojans detection method if the placement or the routing have been redone by the foundry. It consists in the comparison between optical microscopic pictures of the silicon product and the original view from a GDSII layout database reader. Second, we analyze the ability of an attacker to introduce a hardware trojan horse without changing neither the placement nor the routing of the cryptographic IP logic. On the example of an AES engine, we show that if the placement density is beyond 80%, the insertion is basically impossible. Therefore, this settles a simple design guidance to avoid trojan horses insertion in cryptographic IP blocks: have the design be compact enough, so that any functionally discreet trojan necessarily requires a complete replace and re-route, which is detected by mere optical imaging (and not complete chip reverse-engineering).
AB - Detecting hardware trojans is a difficult task in general. In this article we study hardware trojan horses insertion and detection in cryptographic intellectual property (IP) blocks. The context is that of a fabless design house that sells IP blocks as GDSII hard macros, and wants to check that final products have not been infected by trojans during the foundry stage. First, we show the efficiency of a medium cost hardware trojans detection method if the placement or the routing have been redone by the foundry. It consists in the comparison between optical microscopic pictures of the silicon product and the original view from a GDSII layout database reader. Second, we analyze the ability of an attacker to introduce a hardware trojan horse without changing neither the placement nor the routing of the cryptographic IP logic. On the example of an AES engine, we show that if the placement density is beyond 80%, the insertion is basically impossible. Therefore, this settles a simple design guidance to avoid trojan horses insertion in cryptographic IP blocks: have the design be compact enough, so that any functionally discreet trojan necessarily requires a complete replace and re-route, which is detected by mere optical imaging (and not complete chip reverse-engineering).
KW - CUR
KW - ECO P/R
KW - Hardware trojan detection & insertion
KW - optical vs GDSII comparison
U2 - 10.1109/FDTC.2013.15
DO - 10.1109/FDTC.2013.15
M3 - Conference contribution
AN - SCOPUS:84889030791
SN - 9780769550596
T3 - Proceedings - 10th Workshop on Fault Diagnosis and Tolerance in Cryptography, FDTC 2013
SP - 15
EP - 29
BT - Proceedings - 10th Workshop on Fault Diagnosis and Tolerance in Cryptography, FDTC 2013
T2 - 10th Workshop on Fault Diagnosis and Tolerance in Cryptography, FDTC 2013
Y2 - 20 August 2013 through 20 August 2013
ER -