docTélécharger le PDF
download 
Plainte Transcription
Télécharger le PDF
Lilian Bossuet Université de Saint-Etienne Laboratoire Hubert Curien GDR SoC-SiP – Journée « Sécurité des systèmes embarqués » Contrefaçons, PUF et Trojans Paris, le 27 novembre 2012 Sécurité de la conception et protection de la propriété intellectuelle – état de l’art Lutte contre le vol, la copie illégale, le reverseengineering et la contrefaçon de circuits intégrés Lilian Bossuet – GDR SoC-Sip – Journée Sécurité des Systèmes Embarqués – Paris - 27 novembre 2012 – 1/34 Sommaire I. Introduction – Le marché des semi-conducteurs – Modèle de menaces II. Les contre-mesures passives – – – – L’authentification Le watermarking La détection de recyclage L’obfuscation III. Les contre-mesures actives – – – – – – Activation de circuits intégrés Chiffrement de la logique Obfuscation /chiffrement de FSM Chiffrement de routage Chiffrement de configuration (FPGA) Blocage fonctionnel IV. Conclusions – SalWare vs MalWare – Perspectives Lilian Bossuet – GDR SoC-Sip – Journée Sécurité des Systèmes Embarqués – Paris - 27 novembre 2012 – 2/34 Situation macro Evolution dans l’industrie microélectronique – Marché en progression • +3.7% en 2011 • Prévision de 6 à 7% en 2012 (>250 milliards €) – Augmentation des coûts de conception des SoC • 40% pour le passage 32nm=>28nm (130 M€) • Limitée à 30% si wafer 450mm (source ITRS 2011) • Investissement du G450c : 4.4 milliards de $ – Délocalisation (vers l’Asie) de la fab et de la R&D – Augmentation du nombre de sociétés Fabless – Augmentation de la complexité des SoC et de la valeur ajoutée Taiwan Semiconductor Manufacturing Co., Ltd. F. Koushanfar 2011 Caractéristiques propres aux produits contrefaits – Produits à très forte valeur ajoutée – Obsolescence fonctionnelle rapide des produits électroniques (un nouvel iPhone tout les ans !) – Délais de conception longs – Outils et circuits bon marché pour le contrefacteur – Risques limités pour le contrefacteur Gravure Nombre de Transistors Coûts de conception 130 nm 9 millions 9 millions € 90 nm 16 millions 18 millions € 65 nm 30 millions 46 millions € Rapport Saunier, 2008 Lilian Bossuet – GDR SoC-Sip – Journée Sécurité des Systèmes Embarqués – Paris - 27 novembre 2012 – 3/34 Menaces dans les chaines de fabrication et d’approvisionnement Illegal device copy/clone Illegal Fab Netlist / IP theft Mask P theft Fabless Fabless Designer Designer Fab Fab IC Netlist Netlist IC Overbulding chip Wafer Wafer Untested Device theft Chip Chip Mask WaferMask test Wafer test Production Production Bond Bond & & Package Package Discarded device (scrapheap) Device Device Broker // Stockist Stockist Broker Device Device Device test test Device (not trusted) trusted) (not Device Device Legal Fab Fab (not (not trusted) trusted) Legal eit nterf Cou ice v e D Compertitor’s Device Old-fashioned device Illegal Fab Repakaging Relabeling Distribution Distribution Competitor designer + Fab Reverse Engeenering Les principales menaces – – – – – – – Device Device Use life Relabeled / repakaged falsifyed device Like-new device Illegal Fab Refurbishing End-of-life End-of-life device device Le vol de propriété intellectuelle Le vol de masques, puces et circuits (overbuilding) La copie / le clonage illégal La contrefaçon La rénovation illégale Le reverse engineering La modification de fonctionnalités (déblocage, DRM) Lilian Bossuet – GDR SoC-Sip – Journée Sécurité des Systèmes Embarqués – Paris - 27 novembre 2012 – 4/34 La contrefaçon de produits électroniques Les chiffres (???) – Estimation de la contrefaçon à 10 % du marché mondiale • Coût : 200 milliards de $ par an aux USA • Impact : 250 000 emplois perdu par an aux USA – En 2008 la douane Européenne a saisie 178 million de produits contrefaits (montres, maroquinerie, habits, médicaments, tabac, produits électroniques) – Estimation de la contrefaçon à 7% du marché des semi-conducteurs [1] • Pertes de 10 milliards de $ par an – Entre 2007 et 2010 la douane Américaine a saisie 5.6 million de produits électroniques contrefaits [2] – De nombreux cas pour des composants militaires et aéronautiques [3,4] [1] M. Pecht, S. Tiku. Bogus! Electronic manufacturing and consumers confront a rising tide of counterfeit electronics. IEEE Spectrum, May 2006 [2] AGMA, Alliance for Gray Markets and Counterfeit Adatement, http://www.agmaglobal.org [3] S. Maynard. Trusted Foundry – Be Safe. Be Sure. Be Trusted Trusted Manufacturing of Integrated Circuits for the Department of Defenses. NDIA Manufacturing Division Meeting, October 2010 www.trustedfoundryprogram.or [4] C. Gorman. Counterfeit Chips on the Rise. IEEE Spectrum, June 2012 Lilian Bossuet – GDR SoC-Sip – Journée Sécurité des Systèmes Embarqués – Paris - 27 novembre 2012 – 5/34 Evolution de la contrefaçon de circuits intégrés Evolution de la contrefaçon et cibles – Recensement USA • Estimation : « pour 1 contrefaçon signalée => 35 non signalées» [1] Représente un marché de 137 milliards de € / 250 milliards du marché des semiconducteurs [2] 1500 1363 Circuits intégrés analogiques (29% sans fil) Nombre de références saisies 1200 25.2% 13.4% 900 13.1% 600 Microprocesseurs (85% informatique) Mémoires (53% informatique) 8.3% Logiques programmables (30 % industrie) 7.6% Transistors (25% grand public) Autres 300 32.4% 0 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 [1] C. Gorman. Counterfeit Chips on the Rise. IEEE Spectrum, June 2012 [2] IHS-ERAI http://www.ihs.com/info/sc/a/combating-counterfeits/index.aspx Lilian Bossuet – GDR SoC-Sip – Journée Sécurité des Systèmes Embarqués – Paris - 27 novembre 2012 – 6/34 Exemple de contrefaçon Source : EE Times, August 2007 Lilian Bossuet – GDR SoC-Sip – Journée Sécurité des Systèmes Embarqués – Paris - 27 novembre 2012 – 7/34 Quelques faits marquants Fausse usine NEC – Découverte en 2006 [1,2] – 50 références de produits • Home-cinéma, lecteur MP3, lecteur de DVD, clavier d’ordinateur … VisonTech (USA) – De 2006 à 2010 ce courtier américain à vendu plus de 60 000 contrefaçons de circuits intégrés [3] – Parmi ses clients : US Navy, Raytheon Missile System … [1] Next Step for Counterfeiters: Faking the Whole Compagny, New York Times, May 2006 http://www.nytimes.com/2006/05/01/technology/01pirate.html?pagewanted=all [2] Fake NEC compagny, says report, EE Times, April 2006 http://www.eetimes.com/electronicsnews/4060352/Fake-NEC-company-found-says-report [3] http://eetimes.com/electronics-news/4229964/Chip-counterfeiting-case-exposes-defensesupply-chain-flaw Lilian Bossuet – GDR SoC-Sip – Journée Sécurité des Systèmes Embarqués – Paris - 27 novembre 2012 – 8/34 La contrefaçon de produits électroniques Les conséquences … – Pertes de marchés (conséquences sociales : pertes d’emplois) – Insatisfaction des consommateurs et dommage sur l’image de marque – Non garantie de sécurité (données / systèmes sensibles) – Non garantie de la fiabilité opérationnelle des équipements – Coût de diagnostic/réparation • Ex: 2.7 million $ pour système de missiles américain – Potentielle pollution non maitrisée – Sensibilité aux malwares (hardware trojan) Il est nécessaire de lutter – Projets mixtes académiques/industriels – Support de l’industrie microélectronique – Prise de conscience nécessaire du législatif (national/européen) • Le U.S. National Defense Authorization Act (NDAA - 2012) spécifie des règles strictes pour les fournisseurs du DoD Lilian Bossuet – GDR SoC-Sip – Journée Sécurité des Systèmes Embarqués – Paris - 27 novembre 2012 – 9/34 Sommaire I. Introduction – Le marché des semi-conducteurs – Modèle de menaces II. Les contre-mesures passives – – – – L’authentification Le watermarking La détection de recyclage L’obfuscation III. Les contre-mesures actives – – – – – – Activation de circuits intégrés Chiffrement de la logique Obfuscation /chiffrement de FSM Chiffrement de routage Chiffrement de configuration (FPGA) Blocage fonctionnel IV. Conclusions – SalWare vs MalWare – Perspectives Lilian Bossuet – GDR SoC-Sip – Journée Sécurité des Systèmes Embarqués – Paris - 27 novembre 2012 – 10/34 Authentification de circuits intégrés Silicon Physical Unclonable Function (PUF) – Objectif : authentifier de façon sure un circuit intégré comme une empreinte digitale – Concept : utilisation du bruit lié à la variation de process CMOS (variabilité) – Fonctionnement : pour une entrée sur N bits (CHALLENGE) le PUF donne une valeur unique et non prévisible sur K bits (REPONSE) PUF1 Challenge Response 110101 1000XX 100100 1101XX … … PUF2 Challenge Response 100001 1110XX 100100 0101XX … … PUF3 Challenge Response 110111 0000XX 111100 0101XX … … Voir la présentation de Jean-Luc Danger – Journée sécurité des systèmes embarqués du GDR SoC-SiP, 27/11/2012 Lilian Bossuet – GDR SoC-Sip – Journée Sécurité des Systèmes Embarqués – Paris - 27 novembre 2012 – 11/34 Détection de copie par marquage (watermarking) La contrefaçon peut intervenir lors de la conception – Objectif : détecter un vol ou une copie de silicium (IP / circuit intégré) – Idée : insérer une marque lors du développement Marked illegal device copy/clone Illegal Fab M Netlist / IP theft Mask P theft Watermarking Overbulding chip Untested Device theft Discarded device (scrapheap) M Wafer Fabless Designer Fab M Chip WaferMask test Production Bond & Package Broker / Stockist Device Device Device test (not trusted) M IC Netlist Legal Fab (not trusted) M eit nterf Cou ice v De Compertitor’s Device Propriétés de la marque (contraintes) – – – – – – Pas d’impact sur les performances Facile à vérifier Difficile à détecter Pas de possibilité de changer ou supprimer Information suffisante Surcoûts faibles (surface, power etc..) Distribution Device M M M M M M M M Lilian Bossuet – GDR SoC-Sip – Journée Sécurité des Systèmes Embarqués – Paris - 27 novembre 2012 – 12/34 Trois niveaux de watermaking dans un flot de conception matériel a) Pre-processing Watermarking Application Specifications Watermarking Synthesis Process Watermarked Intellectual Property b) In-process Watermarking c) Post-processing Watermarking Application Specifications Application Specifications Synthesis Process and Watermarking Synthesis Process Watermarking Watermarked Intellectual Property Watermarked Intellectual Property B. Le Gal, L. Bossuet. Automatic low-cost IP watermarking technique based on output mark insertion. Design Automation for Embedded System, Springer, 2012 Lilian Bossuet – GDR SoC-Sip – Journée Sécurité des Systèmes Embarqués – Paris - 27 novembre 2012 – 13/34 Au niveau algorithme a) Pre-processing Watermarking Application Specifications Watermarking Il s’agit de modifier légèrement l’application au niveau de l’algorithme pour la marquer Synthesis Process Watermarked Intellectual Property – Particulièrement adapté aux applications du traitement du signal (modification des coefficients) – Marquage facile mais détection difficile Il peut y avoir de légères modifications de l’architecture A. Rashid, J. Asher, W.H. Mangione-Smith, M. Potkonjak. Hierarchical Watermarking for Protection of DSP Filter Cores. In Proc. IEEE custom Integrated Circuits Conference, 1999 Lilian Bossuet – GDR SoC-Sip – Journée Sécurité des Systèmes Embarqués – Paris - 27 novembre 2012 – 14/34 b) In-process Watermarking c) Post-processing Watermarking Application Specifications Application Specifications Synthesis Process and Watermarking Synthesis Process Watermarking Watermarked Intellectual Property Watermarked Intellectual Property Au niveau synthèse a) Pre-processing Watermarking Application Specifications Watermarking Modification du graphe de l’algorithme lors de la synthèse comportementale de haut niveau – – – – Synthesis Process Watermarked Intellectual Property Méthode pré-synthèse comportementale Ajout d’arcs dans un graph Marque dans registre d’allocation Réduction des optimisations dues à la synthèse F. Koushanfar, I. Hong,M. Potkonjak, Behavioral synthesis techniques for intellectual property protection”, ACM Transactions on Design Automation of Electronic Systems 10/3, 2005, 523–545. Modification de l’étape de synthèse logique – Méthode post-synthèse logique – Certaines sorties de portes logiques sont choisies aléatoirement et envoyées vers une logique additionnelle non fonctionnelle (dummy logic) – Facilement détectable, surcoût logique D. Kirovski, Y. Hwang, M. Potkonjak, J. Cong. Intellectual property protection by watermarking conditional logic synthesis solutions. In International Conference of Computer Aided Design, 1998,pp. 194-198, Lilian Bossuet – GDR SoC-Sip – Journée Sécurité des Systèmes Embarqués – Paris - 27 novembre 2012 – 15/34 b) In-process Watermarking c) Post-processing Watermarking Application Specifications Application Specifications Synthesis Process and Watermarking Synthesis Process Watermarking Watermarked Intellectual Property Watermarked Intellectual Property Au niveau synthèse a) Pre-processing Watermarking Application Specifications Watermarking Insertion une marque à très bas coût dans un IP de traitement du signal – Idée : créer automatiquement une marque sous forme de fonctions mathématiques dont les résultats s’insèrent dans les valeurs de sortie aux instants propices Synthesis Process Watermarked Intellectual Property B. Le Gal, L. Bossuet. Automatic low-cost IP watermarking technique based on output mark insertion. Design Automation for Embedded System, Springer, 2012 http://www.springerlink.com/content/100255/?Content+Status=Accepted Lilian Bossuet – GDR SoC-Sip – Journée Sécurité des Systèmes Embarqués – Paris - 27 novembre 2012 – 16/34 b) In-process Watermarking c) Post-processing Watermarking Application Specifications Application Specifications Synthesis Process and Watermarking Synthesis Process Watermarking Watermarked Intellectual Property Watermarked Intellectual Property Résultats d’implantation a) Pre-processing Watermarking Application Specifications Watermarking Résultat obtenus en ciblant un FPGA Xilinx Virtex-5 Synthesis Process – Outils : GraphLab-M + Xilinx ISE – Augmentation en surface < 1% - Réduction de la vitesse < 1% contraintes description comportementale Application FIR 64ème initial - 6612 marqué 37 6667 initial - Type ordre DCT 1-D 8 points DCT 2-D 8x8 points SSD 2-D 16x16 points FFT 64 points compilation Longueur marque (bits) paramètres de marquage Surface fmax (Slices V5) du graphe (MHz) analyse sélection 68.4 68.7 8818 allocation65.8 modèle Interne marqué 56 8906 65.9 initial - 31428 57.9 marqué 584 31460connexion58.3 initial optimisation - 3193compilation63.7 marqué 80 3222 - 51086 600 51208 description initial RTL marquée M marqué Watermarked Intellectual Property librairies matérielles Surcoût Surface (%) Réduction fmax (%) + 0.83 + 0.53 + 1.00 + 1.13 + 1.02 + 0.75 + 0.91 + 0.25 ordonnancement 63.8 marque 57.9 57.9 Flot+ de HLS+ 0,01 0,24 GraphLab-M B. Le Gal, L. Bossuet. Automatic low-cost IP watermarking technique based on output mark insertion. Design Automation for Embedded System, Springer, 2012 http://www.springerlink.com/content/100255/?Content+Status=Accepted Lilian Bossuet – GDR SoC-Sip – Journée Sécurité des Systèmes Embarqués – Paris - 27 novembre 2012 – 17/34 b) In-process Watermarking c) Post-processing Watermarking Application Specifications Application Specifications Synthesis Process and Watermarking Synthesis Process Watermarking Watermarked Intellectual Property Watermarked Intellectual Property Comparaison des méthodes au niveaux synthèse Comparaison à partir des données publiées – Application : DCT 2D Surcoût en surface Surcoût en débit Nombre de marques possibles Chaine de marquage Modifications apportées Longueur de marque (bits) 1- Foushanfar et al. – 2005 18 170 arcs ajoutés au graphe 2047 - - 21E25 2 - Kirovski et al. – 1998 273 réseaux logiques + glue 256 4.40% - 21E637 3 - Le Gal, Bossuet – 2012 (cost-less) Registre de sortie FSM 584 0.02% 0.2% 2584 4 - Le Gal, Bossuet – 2012 (low-cost) Chemin de données 584 1.02% 0.75% 21,5E3 Eléments de synthèse – Compromis surcoûts en surface et débit vs nombre de marques possibles – Analyse en sécurité => mieux vaut une diffusion de la marque dans le layout (1 & 4) – Remarque : l’ajout de moyens cryptographiques n’augmente pas la sécurité Lilian Bossuet – GDR SoC-Sip – Journée Sécurité des Systèmes Embarqués – Paris - 27 novembre 2012 – 18/34 Au niveau hard a) Pre-processing Watermarking Application Specifications Watermarking Synthesis Process Utilisation des LUT/Blocs mémoires non utilisés dans le FPGA Watermarked Intellectual Property – Mémorisation directe de la marque (configuration des LUT/mémoires) – Modification directe du layout (ajout de lignes par exemple) – Marquage difficile (manuel) mais détection facile J. Latch, W. Mangione-Smith, M. Potkonjak. Robust FPGA intellectual property protection through multiple small watermarks. In International DAC 1999 Lilian Bossuet – GDR SoC-Sip – Journée Sécurité des Systèmes Embarqués – Paris - 27 novembre 2012 – 19/34 b) In-process Watermarking c) Post-processing Watermarking Application Specifications Application Specifications Synthesis Process and Watermarking Synthesis Process Watermarking Watermarked Intellectual Property Watermarked Intellectual Property Détection de contrefaçon Quelques moyens industriels de détection de contrefaçon – Nettoyage, « grattage » du circuit, inspection visuelle Avant Après Faux Atmel Faux Motorola – Inspection microscopique (reverse) – Inspection rayon X Lilian Bossuet – GDR SoC-Sip – Journée Sécurité des Systèmes Embarqués – Paris - 27 novembre 2012 – 20/34 L’obfuscation L’obfuscation – Synonymes : assombrissement, opacification, obscurcissement – Définition : Opération qui consiste à transformer une section de code ou un programme, de manière à le rendre totalement incompréhensible à un lecteur humain, même aidé d'outils informatiques – Objectif : empêcher le reverse engineering (utilisé par exemple en virologie) et la modification fonctionnelle illégale (DRM, licence d’utilisation) – Caractéristiques : va à l’encontre des règles de l’art dans le domaine de la programmation logiciel, transforme un message (programme) clair (exécutable) en un autre message clair. – Exemples de méthodes : optimisation de code, modification des appels de fonctions, entrelacement, redondance, code « mort », déstructuration, déroulage de boucle, fusion de boucle, entrelacement de boucle, insertion de branchement conditionnel, dégénérescence du flux de contrôle (modification de branches statiques en dynamiques)… – Coûts : taille du code, durée de développement – Résistance : mesurée par la complexité et les performances de l’outil de désobfuscation Au niveau matériel – Cible : bloc IP, ASIC – Niveau : VHDL / netlist Lilian Bossuet – GDR SoC-Sip – Journée Sécurité des Systèmes Embarqués – Paris - 27 novembre 2012 – 21/34 L’obfuscation au niveau matériel L’obfuscation au niveau VHDL (existe pour Verilog) – Quelques exemples a_reg : shift_reg_word port map ( clk => clk, load => load, shift => shift, clr => tied_0, d => multiplicand, d_s => p_to_a, q => product_low, q_s => open ); b_reg : reg_word port map ( clk => clk, load => load, d => multiply_by, q => b ); Y<=a+b; Function Outline ll111: O00IIIIIII port map (a, b ,y); Ou Y<=O0II10OO01(a,b); Layout obfuscation (zero-cost) ll111: O00 port map (clk => clk,load => load,lll1 => lll1,OOO0 => l1l11,OO0 => multiplicand,l1l1 => lll11,l11 => product_low,O0O0 => open ); OO000: ll11 port map (clk => clk,load => load,OO0 => multiply_by,l11 => O000); Original VHDL; Obfuscated VHDL; http://www.eng.fsu.edu/~umb/o4.htm Change of encoding (splitting boolean into 4 integres) s<= a xor b; c<= a and b; M. Brzozowski, V. Yarmolik. Obfuscation as Intellectual Rights Protection in VHDL Language. In CISIM 2007 Signal a1, a2, b1, b2, ci, si, s1, s2, c1, c2: integer; BEGIN a1<=1; a2<=0 when a=‘1’ else 1; b1<=0; b2<=0 when b=‘1’ else 0; si<=IEXOR(a1*2+a2,2*b1+b2); S1<=si/2; s2<=si-2*(si/2); S<=VAL(s1,s2); Ci<=IAND(a1*2+a2,2*b1+b2); Ci<=ci/2; c2<=ci-2*(ci/2); C<=‘0’ when c1=c2 else ‘1’; END; U. Meyer-Baese, E. Castillo, G. Botella, L. Parrilla, A. Garcia. Intellectual Property Protection (IPP) usign Obfuscation in C, VHDL, and Verilog Coding. In Proceedings of SPIE 2011 Lilian Bossuet – GDR SoC-Sip – Journée Sécurité des Systèmes Embarqués – Paris - 27 novembre 2012 – 22/34 Sommaire I. Introduction – Le marché des semi-conducteurs – Modèle de menaces II. Les contre-mesures passives – – – – L’authentification Le watermarking La détection de recyclage L’obfuscation III. Les contre-mesures actives – – – – – – Activation de circuits intégrés Chiffrement de la logique Obfuscation /chiffrement de FSM Chiffrement de routage Chiffrement de configuration (FPGA) Blocage fonctionnel IV. Conclusions – SalWare vs MalWare – Perspectives Lilian Bossuet – GDR SoC-Sip – Journée Sécurité des Systèmes Embarqués – Paris - 27 novembre 2012 – 23/34 Activation de circuits intégrés L’activation est réalisée (à distance) en fin de process de fabrication – Un circuit volé/copié avant activation n’est pas utilisable – Nécessite un protocole cryptographique – Couplée à un blocage fonctionnel • Chiffrement de la logique /FSM • Chiffrement du chemin de données (BUS, NoC) Illegal device copy/clone of locked device Unexploitable Illegal Fab device Netlist / IP theft Remote IC activation system Mask P theft Overbulding chip Wafer Fabless Designer Fab IC Netlist Untested Device theft Locked chip WaferMask test Production Bond & Package Discarded device (scrapheap) Locked device Locked device Device test Post-fab IC activation Legal Fab (not trusted) Autorized trusted activator Unlocked device Distribution Lilian Bossuet – GDR SoC-Sip – Journée Sécurité des Systèmes Embarqués – Paris - 27 novembre 2012 – 24/34 Chiffrement de la logique / du contrôle Logic encryption, FSM obfuscation inputs inputs LOGIC 1LOGIC outputs M1 outputs LOGIC 2 M2 UC FSM FSM FSM obfuscation M R. S. Chakrabotry, S. Bhunia. Security Through Obscurity: An Approach for Protecting Register Transfert Level Hardware IP. In Proceedings of HOST 2009 Y. A. Alkabani, F. Koushanfar. Active Hardware Metering for Intellectual Property Protection Scheme. USENIX 2007 J. Rajendran, Y. Pino, O. Sinanoglu, R. Karri. Logic Encryption: A Fault Analysis Perspective. DATE 2012 Problème : il est très difficile d’avoir autant de clé que de circuit Lilian Bossuet – GDR SoC-Sip – Journée Sécurité des Systèmes Embarqués – Paris - 27 novembre 2012 – 25/34 Chiffrement de la logique / du contrôle FSM obfuscation – output encryption – Chiffrement de la sortie de la FSM – Utilisation d’une clé de déblocage – Utilisation d’un PUF pour l’unicité de la clé de déblocage (chaque circuit a sa clé) inputs inputs LOGIC 1LOGIC outputs M1 outputs LOGIC 2 M2 UC key KEY FSM FSM FSM obfuscation M PUF J. Rajendran, Y. Pino, O. Sinanoglu, R. Karri. Logic Encryption: A Fault Analysis Perspective. DATE 2012 J. bringer, H. Chabanne, T. Icart. On Physical Obfuscation of cryptographic Algorithlms. INDOCRYPT 20009 Y. Alkabani, F. Koushanfar, M. Potkonjak. Remote Activation of Ics for Piracy Prevention and Digital Right Managment. ICCAD 2007 Lilian Bossuet – GDR SoC-Sip – Journée Sécurité des Systèmes Embarqués – Paris - 27 novembre 2012 – 26/34 Chiffrement du chemin de données Utilisation de « barrière » logique configurable – Les barrières logiques sont des LUT • Reconfigurables « firewall » => chaque circuit a sa propre clé (on peut ajouter une PUF si nécessaire) • Permettent toutes les fonctions logiques (pas que XOR) – Placement de la barrière logique • Choix fait par heuristique • Réduction d’un fonction d’observabilité (attention aux chemins critiques) A. Baumgarten, A. Tyagi, J. Zambreno. Preventing IC Piracy Using Reconfigurable Logic Barriers. IEEE Design & Test of Computers, January/February 2010 Lilian Bossuet – GDR SoC-Sip – Journée Sécurité des Systèmes Embarqués – Paris - 27 novembre 2012 – 27/34 Chiffrement de la configuration des FPGA SRAM Chiffrement dynamique du bitstream (données de configuration) – – – – Objectif : confidentialité du lien Mémoire de configuration => FPGA Menaces : probing / replay /denial Contraintes : flexibilité (choix du chiffrement) et bas coûts (surface) Idée : déchiffrement en interne, partitionnement et auto-reconfiguration partielle Voir la présentation de Lionel Torres – Journée sécurité des systèmes embarqués du GDR SoC-SiP, 07/12/2010 Lilian Bossuet – GDR SoC-Sip – Journée Sécurité des Systèmes Embarqués – Paris - 27 novembre 2012 – 28/34 Blocage fonctionnel Actions de blocage dans un SoC – – – – – Contrôleur (FSM / interruption / mémoire) Réseaux de communications internes : bus de données / Cross Bar / NoC Mémoires RAM (bus @ / bus data) Paramétrage/calibration (bloc analogique et mixte) Configuration (eFPGA / multi-mode-IP) Source STMicroelectronics – STW22000 microcontroller Lilian Bossuet – GDR SoC-Sip – Journée Sécurité des Systèmes Embarqués – Paris - 27 novembre 2012 – 29/34 Quelques règles S’appuyer sur des protocoles cryptographiques surs – Protection contre les attaques « man-in-the-middle » – Pour la reconfiguration/mises à jour => attention aux attaques en rejeu Utiliser une clé d’activation par circuit – L’utilisation de tag ou de PUF sont des solutions intéressantes Le système de blocage fonctionnel doit être très bas coûts – Utiliser peu de fois dans la vie du circuit – Eviter de charger les chemins critiques ou les fonctions critiques Protection vis-à-vis des attaques matériels – – – – Attaques en fautes sur l’activation Attaques par canaux cachés des chiffreurs/déchiffreurs Attaques par les canaux de test (scan chain) Trojan Coupler les protections – Activation / obfuscation / marquage / chiffrement Lilian Bossuet – GDR SoC-Sip – Journée Sécurité des Systèmes Embarqués – Paris - 27 novembre 2012 – 30/34 Sommaire I. Introduction – Le marché des semi-conducteurs – Modèle de menaces II. Les contre-mesures passives – – – – L’authentification Le watermarking La détection de recyclage L’obfuscation III. Les contre-mesures actives – – – – – – Activation de circuits intégrés Chiffrement de la logique Obfuscation /chiffrement de FSM Chiffrement de routage Chiffrement de configuration (FPGA) Blocage fonctionnel IV. Conclusions – SalWare vs MalWare – Perspectives Lilian Bossuet – GDR SoC-Sip – Journée Sécurité des Systèmes Embarqués – Paris - 27 novembre 2012 – 31/34 Salware / Malware Salutary Hardware vs Malicious Hardware – – – – Salutary Hardware : watermarking, activation à distance, PUF … Malicious Hardware : hardware trojan, backdoor, ghost circuit … Procédés proches pour un objectif opposé Etudier les deux contextes simultanément Infor ma (side tion leak chan nel) Hiden remote access IP watermark (side channel) backdoor M spy Trojan (switch) PUF IC-ID activation Secure remote access Lilian Bossuet – GDR SoC-Sip – Journée Sécurité des Systèmes Embarqués – Paris - 27 novembre 2012 – 32/34 Perspectives Etudier la réalisation d’un TPM bas-coût, normalisé et multi-applications – – – – – Secure by design Activation à distance d’IP/fonctionnalités Protection de la configuration Protection du code source Support de sécurité pour thrid-party IP Normaliser la caractérisation des PUFs et des systèmes d’authentification – AIS / FIPS etc. Mettre à disposition des concepteurs des outils de CAO – Marquage automatique d’IP – Insertion de blocs de protection (TPM) Garantir une chaine de confiance du matériel au logiciel Etudier la fabrication au niveau sécurité – Split manufacturing (AMD, IARPA) – 3D … Lilian Bossuet – GDR SoC-Sip – Journée Sécurité des Systèmes Embarqués – Paris - 27 novembre 2012 – 33/34 Lilian Bossuet Université de Saint-Etienne Laboratoire Hubert Curien GDR SoC-SiP – Journée « Sécurité des Systèmes Embarqués » Contrefaçons, PUF et Trojans Paris le 27 novembre 2012 Sécurité de la conception et protection de la propriété intellectuelle Lutte contre le vol, la copie illégale, le reverseengeenering et la contrefaçon de circuits intégrés Lilian Bossuet – GDR SoC-Sip – Journée Sécurité des Systèmes Embarqués – Paris - 27 novembre 2012 – 34/34 GDR SoC SiP PUF and Trojans Delay PUF overview 27 Novembre 2012 Jean-Luc Danger page 1 Télécom ParisTech GDR SoC SiP Table of Contents PUF overview Delay PUF structures Security and reliability page 2 Télécom ParisTech GDR SoC SiP PUF Concept Function returning a signature of the device • Unclonable : not a mathematical function but • Physical function linked to material randomness • Introduced by Pappu in 2001 Optical PUF : Ravikanth S. Pappu. Physical One-Way Functions. PhD thesis, Massachusetts Institute of Technology, March 2001. Basic applications • Lightweight authentication Challenge-Response Pair (CRP) Protocol • Private Key generation Phases of use • Enrollment (to do once) • Measurement or reconstruction page 3 Télécom ParisTech GDR SoC SiP PUF properties Uniqueness • Each circuit has a unique signature Steadiness • The PUF response is always the same, whatever the noise and environment Security • Mathematically unclonable and unpredictable • Not sensitive to physical attacks (invasive, sidechannel, fault injection) Cost • Not only the core but • Extra structure to make it steady and secure page 4 Télécom ParisTech GDR SoC SiP This talk PUF Taxonomy Non silicon PUF Silicon PUF Optical PUF Delay PUF Glitch PUF RF DNA Coating PUF Memory PUF Blaise Gassend, Dwaine E. Clarke, Marten van Dijk, and Srinivas Devadas. “Silicon physical random functions”. In ACM Conference on Computer and Communications Security, pages 148–160, 2002. Ravikanth S. Pappu. Physical One-Way Functions. PhD thesis, Massachusetts Institute of Technology, March 2001 Tuyls P., Schrijen G.J., Skori B., Van Geloven J., Verhaegh N., Wolters, R.: “Read-proof hardware from protective coatings”. In: Cryptographic Hardware and Embedded Systems Workshop, LNCS, vol. 4249, pp. 369–383. Springer, 2006 Su Y., Holleman J., Otis B.: “A 1.6pj/bit 96% stable chip-id generating circuit using process variations”. In:. ISSCC 2007. Digest of Technical Papers. IEEE, pp. 406-611, 2007 Gerald DeJean and Darko Kirovski. Rf-dna: Radio-frequency certificates of authenticity. In CHES 2007, 9th International Workshop,Vienna, Austria, September 10-13, 2007, Proceedings, volume 4727 of LNCS, pages 346–363. Springer, 2007. page 5 Télécom ParisTech GDR SoC SiP Daisuke Suzuki and Koichi Shimizu. 2010. The glitch PUF: a new delay-PUF architecture exploiting glitch shapes. In Proceedings of the CHES'10. Springer-Verlag, Berlin, Heidelberg, 366-382 Other PUF classification Intrinsic vs non-intrinsic (1)(2) , intrinsic if: • Measurements are internal • Randomness comes from the manufacturing process Strong vs weak (2) , strong if: • Many challenges and • No possibility to build a model (1). Jorge Guajardo, Sandeep S. Kumar, Geert Jan Schrijen, and Pim Tuyls. FPGA Intrinsic PUFs and Their Use for IP Protection. In Pascal Paillier and Ingrid Verbauwhede, editors, CHES, volume 4727 of Lecture Notes in Computer Science, pages 63–80. Springer, 2007. (2) R. Maes. Physically Unclonable Functions: Constructions, Properties and Applications. PhD thesis, KU Leuven, 2012. page 6 Télécom ParisTech GDR SoC SiP SILICON PUF structures Main Principles • Delay measurement : Delay PUF • Memory state : Memory PUF • Propagation of glitches : Glitch PUF page 7 Télécom ParisTech GDR SoC SiP Delay PUF Principle: Differential Delay measurement Blaise Gassend, Dwaine E. Clarke, Marten van Dijk, and Srinivas Devadas. “Silicon physical random functions”. In ACM Conference on Computer and Communications Security, pages 148–160, 2002. page 8 Télécom ParisTech GDR SoC SiP Delay PUF Pros • Good uniqueness • No technology constraints • Many challenges with controled delay elements Cons • Effort at P/R for a perfect balance Of the two delay lines Of the measurement element • Sensitive to Machine Learning attack To Build the PUF model from a set of Challenge-Response Rührmair et al. : Modeling Attack by Logistic regression* • Sensitive to noise and environment * Ulrich Rührmair, Frank Sehnke, Jan Sölter, Gideon Dror, Srinivas Devadas, and Jürgen Schmidhuber. “Modeling attacks on physical unclonable functions”. In Proceedings of the 17th ACM page 9 Télécom ParisTech GDR SoC SiP Memory PUF More details given in the Talk of Vincent Van der Leest from INTRINSIC-ID Principle • Convergence towards a steady state from an unstable state : Metastable Power on What happens when Reset goes to ‘0’ ? Su Y., Holleman J., Otis B.: “A 1.6pj/bit 96% stable chip-id generating circuit using process variations”. In:. ISSCC 2007. Digest of Technical Papers. IEEE, pp. 406-611, 2007 page 10 Télécom ParisTech GDR SoC SiP Memory PUF Pros • Good uniqueness • Implementable in any technology with Non initialized SRAM DFF, latches Bus keepers • No ML attack Cons • Few challenges • Sensitive to noise and environment page 11 Télécom ParisTech GDR SoC SiP Glitch PUF Exploits the glitches of a non-linear Boolean function Main drawback • Glitches hard to extract (lot of buffers + DFF) Daisuke Suzuki and Koichi Shimizu. 2010. The glitch PUF: a new delay-PUF architecture exploiting glitch shapes. In Proceedings of the CHES'10. Springer-Verlag, Berlin, Heidelberg, 366-382 page 12 Télécom ParisTech GDR SoC SiP Brief comparison Pros Cons page 13 Delay PUF Memory PUF Glitch PUF • Unique • Many challenges • Implementable in any technology • Unique • Implementable in DFF or non intialized memory • Unique • Sensitive to modeling attack • Needs effort at P/R • Not steady Télécom ParisTech • Few challenges • Not steady GDR SoC SiP • Not yet mature • Need complex hardware to extract glitches • Not steady Table of Contents PUF overview Delay PUF structures Security and reliability page 14 Télécom ParisTech GDR SoC SiP Delay PUF: Arbiter PUF The first silicon PUF (Gassend et al.) • Special care needed at P/R • Many derivatives to enhance security XOR , Lightweight PUF, FF-PUF B. Gassend, D. Lim, D. Clarke, M. Van Dijk, and S. Devadas. Identification and authentication of integrated circuits. Concurrency and Computation: Practice & Experience, 16(11):1077–1098, 2004 page 15 Télécom ParisTech GDR SoC SiP XOR arbiter PUF Proposed by Suh et al. to avoid ML attack • N Arbiter PUF Xored G. Edward Suh and Srinivas Devadas. “Physical unclonable functions for device authentication and secret key generation”. In DAC, pages 9–14, 2007. page 16 Télécom ParisTech GDR SoC SiP Lightweight secure PUF Proposed by Majzoobi et al. to increase robustness • N arbiter PUF with specific challenge mapping Mehrdad Majzoobi, Farinaz Koushanfar, and Miodrag Potkonjak. “Lightweight secure pufs”. In Proceedings of the 2008 IEEE/ACM International Conference on Computer-Aided Design, ICCAD ’08, pages 670–673, Piscataway, NJ, USA, 2008. IEEE Press. page 17 Télécom ParisTech GDR SoC SiP Feed-Forward PUF Proposed by Gassend et al. to fight ML attacks • Some challenge bits are generated by intermediate arbiters B. Gassend, D. Lim, D. Clarke, M. Van Dijk, and S. Devadas. “Identification and authentication of integrated circuits”. Concurrency and Computation: Practice & Experience, 16(11):1077–1098, 2004. page 18 Télécom ParisTech GDR SoC SiP Ring Oscillator PUF Introduced by Suh et al • Identical Ring Oscillators are compared pairwise G. Edward Suh and Srinivas Devadas. “Physical unclonable functions for device authentication and secret key generation”. In DAC, pages 9–14, 2007. page 19 Télécom ParisTech GDR SoC SiP ASYNC PUF RO-PUF with better stability of the RO • Self-synchronization (by C-element) limits the jitter propagation which accumulates in a classical ring oscillator J. Murphy, A. Dziech, A.Czyżewski, "Asynchronous Physical Unclonable Functions ASYNC PUF", Multimedia Communications, Services and Security; Krakow 2012 page 20 Télécom ParisTech GDR SoC SiP Loop PUF Multidimensionnal measurements (N>2) • Many more challenges : very « strong » PUF Easy to design • Copy and paste the chain N times Zouha Cherif, Jean-Luc Danger, Sylvain Guilley et Lilian Bossuet, (2012), An Easy-to-Design PUF based on a Single Oscillator: the Loop PUF, "DSD", Izmir. page 21 Télécom ParisTech GDR SoC SiP Table of Contents PUF overview Delay PUF structures Security and reliability page 22 Télécom ParisTech GDR SoC SiP PUF Reliability (or steadiness) Intra and inter variation • PUF sensitive to Noise Environment T°C, Vdd Attacks Problem : noise OK : process variability Need a correction circuit to enhance the reliability page 23 Télécom ParisTech GDR SoC SiP PUF reliability Results from the UNIQUE European project Katzenbeisser, S., Kocabas, Ü., Roži´c, V., Sadeghi, A.R., Verbauwhede,I.,Wachsmann, C.: PUFs: Myth, fact or busted? A security evaluation of physically unclonable functions (PUFs) cast in silicon. In: CHES 2012. Springer (2012) page 24 Télécom ParisTech GDR SoC SiP Enhancing the steadiness Secured sketch: Use of a witness and Error correcting code Yevgeniy Dodis, Rafail Ostrovsky, Leonid Reyzin, and Adam Smith. “Fuzzy Extractors: How to Generate Strong Keys from Biometrics and Other Noisy Data”. SIAM J. Comput., 38(1):97–139, 2008. page 25 Télécom ParisTech GDR SoC SiP Reliable Key generation Fuzzy extraction • Key extracted by means of Secure Sketch and Hash function page 26 Télécom ParisTech GDR SoC SiP PUF Attacks 1/2 Brute force • To save every Challenge/Response (CRP) • Physical access to the PUF is required Replay • Sniffing CRPs and play them back Modeling attack (or Machine Learning attack) • Take advantage of relationships between the challenge / response • Methods based on machine learning to build a model by trial and error • Set of CRP needed to train ML algorithm • Very powerful to attack delay-based PUF page 27 Télécom ParisTech GDR SoC SiP ML attack on delay PUFs Modeling Attacks by Machine Learning (Rührmair et al) • Logistic Regresion technique : success rate Arbiters 99.9% using 18K CRPs in 0.6 sec. (64 taps) XOR Arbiter 99% using 12K CRPs in 3 min 42 secs (4 XOR, 64 taps). Lightweight Arbiters 99% using 12K CRPs in 1 hour and 28 mins (4 XORs, 64 taps). Feed-forward Arbiters 99% using 5K CRPs in 47 mins and 7 secs (7 FF, 64 taps). Ring Oscillators 99% using 90K CRPs (1024 bit value)¤. page 28 Télécom ParisTech GDR SoC SiP PUF Attack 2/2 Side-Channel • Mainly focus on the Fuzzy extractor (1) Simple Power Analysis has been carried out on a FE with error correcting code using conditional branches. Template attacks have been implemented on error correcting codes (w/o conditional branches) Could target the RO-based PUFs (2) • The frequency can be lock on external EM carrier injection (rather Fault injection attack than sidechannel) (1) Karakoyunlu, D.; Sunar, B.; , "Differential template attacks on PUF enabled cryptographic devices," Information Forensics and Security (WIFS), 2010 IEEE International Workshop on , vol., no., pp.1-6, 12-15 Dec. 2010 (2) François Poucheret, « Injections Electromagnétiques : Développement d’Outils et Méthodes pour la Réalisation d’Attaques Matérielles », Thèse soutenue le 23 novembre au LIRMM page 29 Télécom ParisTech GDR SoC SiP Countermeasures Brute Force Attack • Too long : For a (n, k)−PUF (n input bit, k output bit) : 2^n query and 2^n * k bits memory. Replay attack Protocol normally forbid to reuse played Challenge Impossible in the case of generating internal secret ML attack • Cipher the challenges or the responses, as the adversary needs both. • Cryptography is generally present near the PUF Side-Channel Attack • FE : Masking (as ECC is linear) page 30 Télécom ParisTech GDR SoC SiP Conclusions PUF is an elegant solution to generate an identification • Unique Signature generated by the device itself But need extra hardware • To enhance the steadiness Secure Sketch with ECC • To enhance the security protection against SCA and modeling attacks (for the delay PUF) And can be costly • Because of extra Hardware for security and steadiness page 31 Télécom ParisTech GDR SoC SiP Hardware Intrinsic Security, from theory to practice Vincent van der Leest Intrinsic-ID, Eindhoven, The Netherlands [email protected] 1 Table of Contents • • • • Introduction PUF type analysis Use case for PUF technology Testing of PUF behavior • PUF Reliability • PUF Uniqueness • Additional PUF research examples at Intrinsic-ID 2 Introduction PUF = Function embodied in a physical structure that consists of many random characteristics originating from uncontrollable process variations during manufacturing In other words: “Fingerprint” based on hardware intrinsic properties that vary due to manufacturing process variations Should be: • Easy to evaluate / measure • Inseparably bound to the object • Not reproducible by manufacturer 3 Introduction Timeline • • • • • …… : Preliminary work on PUF-like technologies 2001: First publication of PUFs by Pappu 2001: Start of PUF research Philips Research 2002: Introduction of silicon based PUFs 2006: PUF technology promising enough for Philips to start “business unit” • 2008: Successful spin-out Intrinsic-ID from Philips 4 Table of Contents • • • • Introduction PUF type analysis Use case for PUF technology Testing of PUF behavior • PUF Reliability • PUF Uniqueness • Additional PUF research examples at Intrinsic-ID 5 Optical PUF PUF Speckle pattern Laser beam scatterers Pro’s Con’s Huge set of C/R-pairs Difficult to integrate in IC 6 Coating PUF coating Al Al passivation insulation (Si) substrate Pro’s Con’s Part of IC Expensive to produce Limited set of C/R-pairs 7 Delay based PUFs Challenge Combinatorial circuit Pro’s Con’s Part of IC Place and Route constraints due to non-standard components Relatively large set of C/R-pairs Susceptible to modeling attacks 8 Memory based PUFs Pro’s Con’s Constructed from standard CMOS components Limited set of C/R-pairs 9 Example: SRAM memory cell (6T) 10 SRAM startup behavior VDD 0 VT> VT< 11 SRAM Uniqueness Device 1 Device 2 ~ 50% difference 12 SRAM Noise ~ 10% errors 13 Table of Contents • • • • Introduction PUF type analysis Use case for PUF technology Testing of PUF behavior • PUF Reliability • PUF Uniqueness • Additional PUF research examples at Intrinsic-ID 14 Application: Secure Key Storage Known key storage options: Fuses, E(E)PROM, Flash, Battery backed RAM, ROM, etc. Problems of these methods: - Security - Costs - Availability - Time to Market 15 Hardware Intrinsic Security (HIS) 0.8 5 0.6 0.4 10 0.2 15 0 -0.2 0.8 -0.4 0.6 -0.6 0.4 -0.8 0.2 5 20 10 25 15 30 5 0 10 15 20 25 30 -0.2 20 -0.4 -0.6 25 -0.8 30 5 10 15 20 25 30 Due to deep sub-micron process variations ICs are intrinsically unique Start–up SRAM values establish a unique and robust fingerprint The electronic fingerprint is turned into a secure secret key, which is the foundation of enhanced security 16 Security advantages of HIS In order to protect keys against physical attacks: 1. Do not permanently store a key in non-volatile memory 2. Generate the key only when needed from a Physical Unclonable Function (PUF) in the IC 3. Delete the key 17 Key Storage With PUFs Enrollment C PUF Helper Data Algorithm R W Key One-Time Process Reconstruction C PUF In the field I(W,Key)<ε Helper Data Algorithm R’ Key W P[Key not Correct]<δ 18 QuiddikeyTM Product, Key Programming • Functionality • Storage of unique device keys • Storage of user keys • Key storage for AES, RSA, ECC SRAM Quiddikey 2 1 3 Activation Code • Requirements • Uninitialized SRAM • Storage for deviceunique activation code 19 QuiddikeyTM Product, Key Reconstruction • Functionality • Storage of unique device keys • Storage of user keys • Key storage for AES, RSA, ECC SRAM Quiddikey 1 2 Activation Code 3 • Requirements • Uninitialized SRAM • Storage for deviceunique activation code 20 Anti-cloning property SRAM Quiddikey Activation Code 1 Device 1 COPY SRAM Quiddikey Activation Code 1 Device 2 21 Confidentio™-SC • Integrated security processing unit: • Secure key storage • Content / data encryption • Randomness generation • Root of trust for mobile apps • Targets SIM/SmartCard, Secure Digital (SD-) card or embedded Secure Element • Complementary to • ARM TrustZone • GlobalPlatform Trusted Execution Environment (TEE) Confidentio-SC SRAM iRNG Quiddikey AES Random bytes generation Activation Code Encryption/ Decryption 22 Table of Contents • • • • Introduction PUF type analysis Use case for PUF technology Testing of PUF behavior • PUF Reliability • PUF Uniqueness • Additional PUF research examples at Intrinsic-ID 23 SRAM PUF test results • Evaluation properties: • Reliability: when PUF responses are measured, the reference measurement should be recognized which was taken at enrollment • Uniqueness: PUF responses of a specific device are random and unpredictable, even given all PUF responses of other devices • Studied SRAM instances from different technology nodes and vendors. Each SRAM memory was evaluated using the following tests: • Temperature Test (reliability) • Voltage Variation Test (reliability) • Hamming Weight Test (uniqueness) • Between-Class Uniqueness Test (uniqueness) • Secrecy Rate & Compression Test (reliability + uniqueness) • Publication: “Comparative analysis of SRAM memories used as PUF primitives”, published at DATE 2012 (March 2012) 24 Temperature Test • Study stability of start-up values at different temperatures • ICs measured under varying ambient temperature • Measurement at 20˚C has been used as reference 25 Voltage Variation Test • Study stability of start-up values under variations of power supply voltage level • Measurement at Vdd has been used as reference • Hamming Distance during test very low and constant 26 Hamming Weight Test • Study uniqueness based on Hamming weight as well as stability at different temperatures • ICs measured under varying ambient temperature • Hamming weight during test around 50% and constant over temperature for most devices 27 Between-class Uniqueness Test • Study uniqueness based on between-class HD distributions • Hamming Distances should be Gaussian distribution with mean at 0.5 and small standard deviation • Results very good for devices that also had good results in Hamming Weight Test, less for devices with bias 28 Secrecy Rate & Compression Test • Direct CTW compression test indicates that worst-case there is only small amount of non-randomness in PUF responses (compression to 98.2%) • Context-Tree Weighting (CTW) algorithm was used to estimate the mutual information between PUF responses: I(X) = H(X) – H(X | X’) • Mutual information provides maximum achievable secrecy rate, which determines amount of compression needed for privacy amplification • Worst-case mutual information found is 0.38 (Virage HP SRAM) • Worst-case required compression factor is therefore 1/0.38 = 2.6 29 Fuzzy Extractor Design • Design goal: derive 128-bit cryptographic key with failure rate <10-9, using worst-case secrecy rate (0.38) and noise (21%) assumptions • Amount of secret bits required = 128/0.38 = 337 • Concatenated error-correcting code design that achieves failure rate < 10-9 assuming 21% noise: • Inner code: 3x BCH-code [n,k,d]=[255,115,43] • Outer code: 765x Repetition-11 code • This design requires 1.03KB of SRAM memory 30 Reliability tests performed at Intrinsic-ID Tested: 180, 150, 130, 90, 65 nm Temperature cycle / temperature ramp Endurance low temperature: IEC 60068-2-1 Endurance high temperature: IEC 60068-2-2 Radio frequency electromagnetic field: IEC 61000-4-3 Ambient electromagnetic fields immunity: EMC: EN55020 Electromagnetic compatibility Humidity Voltage ramp-up Data retention voltage Accelerated lifetime Extensive End customer validation Photo: Philips Innovation Services Millions of measurements performed 31 Table of Contents • • • • Introduction PUF type analysis Use case for PUF technology Testing of PUF behavior • PUF Reliability • PUF Uniqueness • Additional PUF research examples at Intrinsic-ID 32 European research projects • PUFFIN • Providing intrinsic and long-wanted basis for security in everyone's most common computing platforms: PCs and mobile devices • RELY • Targeting reliability as parameter throughout chip development • UNIQUE (finalized in 2012) • Tackling counterfeiting of and tampering with Integrated Circuits • RATE • Dutch project focused on modeling impact of process variations, environmental parameters and ageing on SRAM PUFs 33 Some selected papers from Intrinsic-ID • Using PUF noise for random number generation • “Efficient Implementation of True Random Number Generator based on SRAM PUFs” in Cryptography & Security: From Theory to Applications, 2012 • Soft decision error correction (decreasing required SRAM) • “Soft Decision Error Correction for Compact Memory-Based PUFs using a Single Enrollment” at CHES 2012 conference • New type of memory based PUF: Buskeepers • “Buskeeper PUFs, a Promising Alternative to D Flip-Flop PUFs” at HOST 2012 workshop • Re-usable PUF: Logically Reconfigurable PUF • “Recyclable PUFs: Logically Reconfigurable PUFs” in Journal of Cryptographic Engineering, November 2011 and at CHES 2011 conference • “Logically Reconfigurable PUFs: Memory-Based Secure Key Storage” at ACM STC 2011 workshop 34 35 Hardware Trojans in Processor Based Circuit: from Design to Countermeasures David Hély, Laboratoire LCIS, Grenoble INP [email protected] GDR SoC-SiP – Journée « Sécurité des systèmes embarqués » Contrefaçons, PUF et Trojans Paris, le 27 novembre 2012 Outline Hardware Trojans Hardware Trojan in Processor based Design Hardware Trojans Design Experiences Information leakage Trojan Instruction Modification Trojan Hardware Trojan Countermeasures Detection Methods overview Run time Detection: the PPU example Conclusions 2 Hardware Trojans: Definitions Some definitions: Hardware Trojan : malicious modification of an integrated circuit in order to offer advantage to an adversary Trigger: Activation mechanism of the Trojan Payload: Effect of the modification (deny of service, secret leakage…) 3 Insertion Scenario When and by who a Hardware Trojan can be inserted? Different tasks of the design process From Architecture to fabrication Different level of abstraction RTL, gate, layout Different stake-holders IP Providers, Fabrication facilities 4 Karri et Al « Trustworthy Hardware : Identifying and Classifying Hardware Trojans » IEEE Computer 2010 Implanting Stage Soft IP core RTL1 cells lib Soft RTLN IP core based Design • When can be the Trojan implanted? • By who? Synthes is + dft Firm IP cores GL Layout + sta Hard IP cores GDSII System Integration manufacturing ASIC manufacturer Credit: Hardware Trojan Detection Solutions and Design-for5 Trust Challenges, Tehranipoor et al. Implanting stage Soft IP core RTL1 cells lib Soft RTLN IP core based Design Synthes is + dft • When can be the Trojan implanted? • Within an IP • By who? • IP provider • Malicious Designer Firm IP cores GL Layout + sta Hard IP cores GDSII System Integration manufacturing ASIC manufacturer Credit: Hardware Trojan Detection Solutions and 6 Design-for-Trust Challenges, Tehranipoor et al. Implanting stage Soft IP core RTL1 cells lib Soft RTLN IP core based Design Synthes is + dft Firm IP cores • When can be the Trojan implanted? • During the design flaw • By who? • Malicious tool • Malicious System Designer GL Layout + sta Hard IP cores GDSII System Integration manufacturing ASIC manufacturer Credit: Hardware Trojan Detection Solutions and 7 Design-for-Trust Challenges, Tehranipoor et al. Implanting stage Soft IP core Soft RTL1 cells lib RTLN IP core based Design Synthes is + dft • When can be the Trojan implanted? • During the fabrication • By who? • Test Engineer • Process engineer Firm IP cores GL Layout + sta Hard IP cores GDSII System Integration manufacturing ASIC manufacturer 8 Credit: Hardware Trojan Detection Solutions and Designfor-Trust Challenges, Tehranipoor et al. Outline Hardware Trojans Hardware Trojan in Processor based Design Hardware Trojans Design Experiences Information leakage Trojan Instruction Modification Trojan Hardware Trojan Countermeasures Detection Methods overview Run time Detection: the PPU example Conclusions 9 Experiences in Hardware Trojan Design CSAW 2011: Embedded Systems Challenge Student Competition focusing on hardware Trojan Design within an 8051 based circuit running RC5 encryption 10 Hardware Trojan in a 8051 Scenario: Full control on the HDL Malicious Designer… Purposes of the design modifications Leak secret information via side channel Denial of service Untrusted software computing 11 “Key Emission via Hardware Trojan”, ICCD 2012 Information Leakage Trojan Detect any RC5 encryption starts Store the data under attack Leak secret information (i.e. key) via the communication line 12 The Trigger Purpose: Detect any RC5 encryption Based on the RC5 algorithm Detect access to the extended key (pattern matching) Look for instruction byte corresponding to a move followed by an add. Pros Cons Low cost design Specific to the platform architecture Risk of false positive 13 Storing the secret information Goal: storing the extended key Several options: Dedicated registers Reuse of processor memory 14 Storing the secret information Purpose: storing the extended key Several options: Dedicated registers Reuse of processor memory Pros Cons Low cost circuitry control Additional Flip-flops 15 Storing the secret information Purpose: storing the extended key Several options: Dedicated registers Reuse of processor memory Pros Cons Low area overhead Control circuitry 16 Data Transmission Principle: Reuse of the serial link1 Constraints: Data reconstruction must be easy No perturbation of the original link Options Encode data using protocol parameters2 Add a high frequency signal 1 Baumgarten et al “Case Study in Hardware Trojan Design and Implementation", International Journal of Information Security 2011 2 Jin et al, “Hardware Trojans in wireless cryptographic integrated circuits”, Design and Test of Computers 2009 17 Data Transmission Principle: Reuse of the serial link1 Constraints: Data reconstruction must be easy No perturbation of the original link Options Encode data using signal parameters2 Add a high frequency signal 1 Baumgarten et al “Case Study in Hardware Trojan Design and Implementation", International Journal of Information Security 2011 2 Jin et al, “Hardware trojans in wireless cryptographic integrated circuits”, Design and Test of Computers 2009 18 Data Transmission Data encoding and Preamble 19 Data Transmission 20 Hardware Trojan Architecture Area overhead: 2% 21 Side Channel Trojan Information leakage without degradations of the system performance Information is hidden in the original signal Functionality of the digital part is not changed Processor based design offers many trigger opportunity based on instructions sequence (pattern matching) Defense against such Trojan: Advanced statistical analysis of the transmission signal may reveal the Trojan 22 Jin et al, “Hardware Trojans in wireless cryptographic integrated circuits”, Design and Test of Computers 2009 Instruction Set Modification Modification of the instruction set: Malicious code execution via Instruction replacement Unused instruction Instruction modification Interrupt routing Jin et al « Exposing Vulnerabilities of Untrusted 23 Computing Platform », ICCD 2012 Instruction Modification LCALL -> ACALL transformation Minimum modification in the rtl description IC_ACALL when s_command = LCALL and (trojan_en=‘1’) IC_LCALL when s_command = LCALL and (trojan_en=‘0’) And If (prev_instruction = RET) then trojan_en <=‘0’; else trojan_ <=‘1’; end if; Jin et al « Exposing Vulnerabilities of Untrusted 24 Computing Platform », ICCD 2012 Instruction Modification Attacking scenario: Decrement stored PC in the stack (ACALL is a two byte instruction) Execute the malicious code at the jump of the ACALL LCALL encoding ACALL encoding The jump address is PC<15:11>addr15addr8 Jin et al « Exposing Vulnerabilities of Untrusted 25Computing Platform », ICCD 2012 Instruction Modification LCALL->ACALL When the LCALL is fetched: 1. ACALL is executed 2. Malicious code is called 3. LCALL is executed Software runs its full original sequence The Trojan payload can be very complex Timing performance overhead 26 Outline Hardware Trojans Hardware Trojan in Processor based Design Hardware Trojans Design Experiences Information leakage Trojan Instruction Modification Trojan Hardware Trojan Countermeasures Detection Methods overview Run time Detection: the PPU example Conclusions 27 Securing the Design Against HT Still the same question Against who? Untrusted IP, Untrusted designer Untrusted fab Countermeasures are then different according the availability of a golden model: Check the design against a golden model Try to find an “out of spec” behavior via testing Use runtime check to prevent “out of spec” behavior 28 Detection via Side Chanel Analysis Purpose: compare side channel signature of the circuit against the golden model Golden chip Side Channel Measurement EM, power, Delay Chip under test 29 Piroux et al “Trojan Detection via EM Analsysis” Esisar Team CSAW 2012 Functionnal Testing A new set of pattern is added to the test set in addition to the defect testing patterns: Trojan testing patterns targeting hardware Trojan May be equivalent to looking for a needle into a haystack due to the large input space Trojan Vectors (Wolf et al 2008) Identify rare events and generate test vectors that trigger them Dummy flip-flops (Salmani et al 2009) Increase the probability of rarely activate events by insertion of dummy flip-flops. 30 Run Time Protections Side Channel Analysis requires to have a golden model Other methods detection requires to activate the Trojan Difficult for processor based design, the trigger may depend of a sequence of instructions Run-Time protection does not care of trigging the Trojan Must just be able to detect abnormal behavior Analog to safety 31 The Processor Protection Unit* Motivations: Trusted IP should monitor untrusted IP be resilient to HT insertion Processor monitoring against smart Trojans modifying the CPU behavior Does not protect against DoS or side channel Trojans *Master Thesis of Jérémy Dubeuf (Poly NY, Grenoble INP) 32 Processor Protection Unit The PPU verifies: Opcode value Instructions cycles FSM sequence Processor internal signals 33 Processor Protection Unit The PPU verifies: Opcode value: Against insertion 34 instruction Processor Protection Unit The PPU verifies: # cycles per instruction: Instruction modification 35 Processor Protection Unit The PPU verifies: FSM sequence # of cycles does not change but the operation does 36 Processor Protection Unit The PPU verifies: Internal signals No extra operations 37 Trust in the PPU What about a Trojan within the PPU? 1. The design must be as simple as possible to increase its testability 2. The architecture must be resilient against malicious modifications 38 Trojan in the PPU A Trojan always active in the PPU may be detected by functional validation since the PPU is a table The hazards come from Trojan trigged by a sequence of instructions The Trojan is in both the PPU and the processor => The PPU must break the software sequences 39 Hardenning the PPU Breaking the sequence Instructions are stored in a Random memory The information are stored in a random order Information stored: Instruction+ processor data 40 Hardenning the PPU What about a HT within the random memory? Data in the memory can be corrupted: Replacing illegal data by legal ones Removing illegal activities Data stored in memory must be hardly exploitable 41 Hardenning the PPU Data Scrambling A trojan inside the random memory can hardly exploit the data 42 PPU Final Architecture Verification space is reduced to: The scrambler The random address generation The interfaces between the PPU and the CPU 43 PPU Final Architecture Results: All the CSAW 2011 Trojans are detected The area overhead is 15 per cent of the CPU 44 Outline Hardware Trojans Hardware Trojan in Processor based Design Hardware Trojans Design Experiences Information leakage Trojan Instruction Modification Trojan Hardware Trojan Countermeasures Detection Methods overview Run time Detection: the PPU example Conclusions 45 Conclusions Processor based circuit are vulnerable Computing offers many possibilities for: Smart trigger Complex payload IP based design is a potential threat No golden model Run time detection may be a solution On going work PPU enhancement Design of specified Hardware Trojan Hardware Trojan in RFID IC 46 Hardware Trojans in Processor Based Circuit: from Design to Countermeasures David Hély, Laboratoire LCIS, Grenoble INP [email protected] GDR SoC-SiP – Journée « Sécurité des systèmes embarqués » Contrefaçons, PUF et Trojans Paris, le 27 novembre 2012 DEFENDING WORLD SECURITY Construction d’un banc d’expérimentation pour les Hardware Trojans - GdR SoC-SiP Julien FRANCQ, Florian FRICK 27/11/2012 Introduction aux Hardware Trojans et à HOMERE Construction d’un banc d’expérimentations Nos objectifs Utilisation de SASEBO Comment déclencher un HT ? Analyse par canaux auxiliaires Scenarii de tests Présentation d’un cas d’étude : contrôle d’accès Présentation Injecter/tester un HT combinatoire Autres Hardware Trojans Conclusion et perspectives Banc pour Hardware Trojans | Julien FRANCQ, Florian FRICK | 27/11/2012 | Page 2 / 43 c 2012 CASSIDIAN CYBERSECURITY - All rights reserved Introduction aux Hardware Trojans et à HOMERE Construction d’un banc d’expérimentations Nos objectifs Utilisation de SASEBO Comment déclencher un HT ? Analyse par canaux auxiliaires Scenarii de tests Présentation d’un cas d’étude : contrôle d’accès Présentation Injecter/tester un HT combinatoire Autres Hardware Trojans Conclusion et perspectives Banc pour Hardware Trojans | Julien FRANCQ, Florian FRICK | 27/11/2012 | Page 3 / 43 c 2012 CASSIDIAN CYBERSECURITY - All rights reserved Hardware Trojan (HT) Modification frauduleuse d’un circuit intégré à n’importe quelle étape de sa fabrication Banc pour Hardware Trojans | Julien FRANCQ, Florian FRICK | 27/11/2012 | Page 4 / 43 c 2012 CASSIDIAN CYBERSECURITY - All rights reserved Contexte Délocalisation de la fabrication des circuits intégrés Difficile d’assurer la confiance Banc pour Hardware Trojans | Julien FRANCQ, Florian FRICK | 27/11/2012 | Page 5 / 43 c 2012 CASSIDIAN CYBERSECURITY - All rights reserved Les partenaires du projet HOMERE FUI14 (2012-2015) : projet HOMERE (Hardware trOjans : Menaces et robustEsse des ciRcuits intEgrés) Grands groupes Cassidian CyberSecurity, Gemalto PME Secure-IC Académiques ARMINES, CEA-LETI, LIRMM, Télécom ParisTech Gouvernemental ANSSI, (DGA) Banc pour Hardware Trojans | Julien FRANCQ, Florian FRICK | 27/11/2012 | Page 6 / 43 c 2012 CASSIDIAN CYBERSECURITY - All rights reserved Méthodes de détection dans HOMERE Aucune méthode n’est pleinement satisfaisante aujourd’hui Banc pour Hardware Trojans | Julien FRANCQ, Florian FRICK | 27/11/2012 | Page 7 / 43 c 2012 CASSIDIAN CYBERSECURITY - All rights reserved Introduction aux Hardware Trojans et à HOMERE Construction d’un banc d’expérimentations Nos objectifs Utilisation de SASEBO Comment déclencher un HT ? Analyse par canaux auxiliaires Scenarii de tests Présentation d’un cas d’étude : contrôle d’accès Présentation Injecter/tester un HT combinatoire Autres Hardware Trojans Conclusion et perspectives Banc pour Hardware Trojans | Julien FRANCQ, Florian FRICK | 27/11/2012 | Page 8 / 43 c 2012 CASSIDIAN CYBERSECURITY - All rights reserved Nos objectifs On veut pouvoir : Comprendre le processus de développement d’un HT, Liste de HTs candidats, Implanter ces HTs, Vérifier que les HTs insérés peuvent être déclenchés. On veut un banc d’analyse par canaux auxiliaires : le plus générique possible, permettant de tester différents circuits... ...infectés par différents HTs, utiliser différentes méthodes statistiques. Side-chAnnel Standard Evaluation BOard (SASEBO) Banc pour Hardware Trojans | Julien FRANCQ, Florian FRICK | 27/11/2012 | Page 9 / 43 c 2012 CASSIDIAN CYBERSECURITY - All rights reserved Vue d’ensemble de SASEBO Ethernet USB SASEBO Board CTRL CUT FPGA FPGA Trigger Signal 2 FPGAs : 1 pour le circuit testé (Circuit Under Test, CUT), 1 pour le contrôle (utilisable pour différents CUTs). Connection USB entre le PC et SASEBO Banc pour Hardware Trojans | Julien FRANCQ, Florian FRICK | 27/11/2012 | Page 10 / 43 c 2012 CASSIDIAN CYBERSECURITY - All rights reserved Méthodes de déclenchement d’un HT Actif tout le temps Condition combinatoire Condition séquentielle Time-bomb Conditions physiques Conditions internes/externes Banc pour Hardware Trojans | Julien FRANCQ, Florian FRICK | 27/11/2012 | Page 11 / 43 c 2012 CASSIDIAN CYBERSECURITY - All rights reserved Analyse par canaux auxiliaires Littérature pas assez précise On ne sait pas où chercher Durée de la mesure ? Résolution ? ⇒ Approche adaptative Vecteurs d’entrées à envoyer potentiellement à chaque cycle Synchronisation Banc pour Hardware Trojans | Julien FRANCQ, Florian FRICK | 27/11/2012 | Page 12 / 43 c 2012 CASSIDIAN CYBERSECURITY - All rights reserved Analyse par canaux auxiliaires Attaque (pour trouver des clés) 6= Analyse (pour trouver des HTs) Set Input Phase Side Channel Attack key data Run Phase Read Output Phase key1 data1 result res start running clock Side Channel Analysis t Input 1 Input 2 Input 3 Output start running Input Vector Banc pour Hardware Trojans | Julien FRANCQ, Florian FRICK | 27/11/2012 | Page 13 / 43 c 2012 CASSIDIAN CYBERSECURITY - All rights reserved Leçons à tirer pour notre banc En général : il faut générer des séquences de vecteurs complexes, on doit pouvoir acquérir des sorties intermédiaires, données (I/O) manipulables en temps réel. Pour déclencher un HT, et donc pour le détecter, on a donc besoin d’attendre longtemps, de réagir suivant l’état du circuit testé. Pour les canaux auxiliaires : Déclenchement dynamique des mesures Banc pour Hardware Trojans | Julien FRANCQ, Florian FRICK | 27/11/2012 | Page 14 / 43 c 2012 CASSIDIAN CYBERSECURITY - All rights reserved Déroulement des opérations Test Scenario Definition Parameter Setup Parameter Setup Scenario Download Wait on Trigger Commands Data Acquisition Outputvectors Read Back Data Read Back Measurement Equipment SASEBO Board Simulation Compare Outputs (Simulation vs Actual) Different Outputs Perform SCA Potential Anomalies Refine Scenario Obvious Anomalies Nothing Suspicious Design OK HT found Banc pour Hardware Trojans | Julien FRANCQ, Florian FRICK | 27/11/2012 | Page 15 / 43 c 2012 CASSIDIAN CYBERSECURITY - All rights reserved Description d’un scénario de test Communication via USB du fichier du scénario de test Il sera stocké dans la mémoire (BRAM) du FPGA de contrôle CTRL FPGA Commands and Parameters USB Controller Inter CUT Memory Scenario and Output Vectors FPGA Controller 38 Bus Ext. Trigger 3 options pour l’envoi du prochain vecteur d’entrée Immédiat Condition sur le temps Condition sur les sorties Indicateur de déclenchement externe Quel format de données adopter ? Banc pour Hardware Trojans | Julien FRANCQ, Florian FRICK | 27/11/2012 | Page 16 / 43 c 2012 CASSIDIAN CYBERSECURITY - All rights reserved Format des données 37 0 IV 0 TC ET 15 D 0 37 38 39 40 55 37 56 OC 0 37 93 94 OM 0 reserved 131 132 143 IV: Input Vector , TC: Transition Condition, conditions sur le temps ou sur la sortie pour envoyer le prochain IV, ET: External Trigger , envoie l’ordre à l’oscilloscope de lancer la mesure, D: Delay : nombre de cycles d’horloge pour retarder le prochain IV, OM: Output Mask : quels bits regarde-t-on ? OC: Output Condition : valeurs de ces bits pour passer au prochain IV. Banc pour Hardware Trojans | Julien FRANCQ, Florian FRICK | 27/11/2012 | Page 17 / 43 c 2012 CASSIDIAN CYBERSECURITY - All rights reserved Format d’un scénario de test Scenario Description Attributes Parameters Parameter 1 Value 1 Name Scenario Name Parameter 2 Value 2 Version Definition Version ... ... ... Input Profile 1 IV TC ET D OC OM reserved 2 IV TC ET D OC OM reserved 3 IV TC ET D OC OM reserved ... n ... IV ... TC ET ... D ... OC ... OM reserved Commands Command 1 Command 2 ... ... ... Paramètres : tristate mask Contrôleur supportant ce format implanté Banc pour Hardware Trojans | Julien FRANCQ, Florian FRICK | 27/11/2012 | Page 18 / 43 c 2012 CASSIDIAN CYBERSECURITY - All rights reserved Introduction aux Hardware Trojans et à HOMERE Construction d’un banc d’expérimentations Nos objectifs Utilisation de SASEBO Comment déclencher un HT ? Analyse par canaux auxiliaires Scenarii de tests Présentation d’un cas d’étude : contrôle d’accès Présentation Injecter/tester un HT combinatoire Autres Hardware Trojans Conclusion et perspectives Banc pour Hardware Trojans | Julien FRANCQ, Florian FRICK | 27/11/2012 | Page 19 / 43 c 2012 CASSIDIAN CYBERSECURITY - All rights reserved Étude de cas : contrôle d’accès Buts de cette étude de cas : Montrer la fonctionnalité de l’environnement de test Montrer comment un circuit peut être infecté Pris volontairement simple Banc pour Hardware Trojans | Julien FRANCQ, Florian FRICK | 27/11/2012 | Page 20 / 43 c 2012 CASSIDIAN CYBERSECURITY - All rights reserved Cas d’étude public secure connection to the magnetic lock wall blinking LED locked / open LED LED1 FPGA +1 LED2 8 code input counter for blinking LED code unlock I0 lock ”lock” button 5 locked I1 O1 unlock and key = 10100000 lock ”open” button open O2 O3 test-logic pins test logic lock logic Code d’accès 8 bits, 2 boutons de contrôle, LED clignotante (implanté avec un compteur 8 bits), 2 pins de test Banc pour Hardware Trojans | Julien FRANCQ, Florian FRICK | 27/11/2012 | Page 21 / 43 c 2012 CASSIDIAN CYBERSECURITY - All rights reserved Scénario d’attaque But de l’attaquant : ouvrir la porte sans la clé ! Note : 8 bits insuffisants dans la réalité “Toy example” Accès public à l’interface, aux boutons et aux LEDs On considère dans notre cas d’étude que les 2 pins de test sont accessibles But initial : test fonctionnel Banc pour Hardware Trojans | Julien FRANCQ, Florian FRICK | 27/11/2012 | Page 22 / 43 c 2012 CASSIDIAN CYBERSECURITY - All rights reserved HT1 (combinatoire) Idée : ouvrir la porte en utilisant les pins de test Changer le circuit de telle sorte que si les deux signaux sont égaux à 1, la porte s’ouvre lock state locked lock lock I0 I1 open I0 and I1 unlock unlock and key = 10100000 code Très simple à concevoir et à activer mais facile à détecter pendant le test fonctionnel ou l’implantation du système Banc pour Hardware Trojans | Julien FRANCQ, Florian FRICK | 27/11/2012 | Page 23 / 43 c 2012 CASSIDIAN CYBERSECURITY - All rights reserved Implantation de HT1 Peut être faite à un haut niveau (ex. : VHDL) Mais cela peut causer des changements majeurs dans le layout final Au niveau configuration du FPGA (via FPGA Editor) Contenu des LUTs Routage Configurations (FFs or LATCH, IBUF delays in IOB, etc.) On travaille sur une information équivalente au bitstream Une telle attaque peut être effectuée si le système est livré en boîte noire Banc pour Hardware Trojans | Julien FRANCQ, Florian FRICK | 27/11/2012 | Page 24 / 43 c 2012 CASSIDIAN CYBERSECURITY - All rights reserved HT1 en RTL key k lock state lock state unlock lock key k lock state unlock lock state lock I0 I1 Banc pour Hardware Trojans | Julien FRANCQ, Florian FRICK | 27/11/2012 | Page 25 / 43 c 2012 CASSIDIAN CYBERSECURITY - All rights reserved Schéma d’une slice d’un Virtex-5 50T A6 A5 A4 A3 A2 A1 A6 A5 A4 A3 A2 A1 A6 A5 A4 A3 A2 A1 A6 A5 A4 A3 A2 A1 Q6 LUT D D DQ Q6 = A1..... Q6 LUT C C CQ Q6 = A1..... B LUT B BQ Q6 = A1..... A LUT A AQ Q6 = A1..... Banc pour Hardware Trojans | Julien FRANCQ, Florian FRICK | 27/11/2012 | Page 26 / 43 c 2012 CASSIDIAN CYBERSECURITY - All rights reserved La même sur FPGA Editor Banc pour Hardware Trojans | Julien FRANCQ, Florian FRICK | 27/11/2012 | Page 27 / 43 c 2012 CASSIDIAN CYBERSECURITY - All rights reserved Circuit non-infecté A6 key(3) A5 A4 key(2) key(6) A3 A2 key(0) key(4) A1 key(1) A6 unlock A5 A4 lock state key(7) A3 A2 lock key(0) A1 N2 Q6 D LUT D N2 DQ Q6 = ( A5*( A2*( A3*( A4*( A1* A6))))) Q6 C LUT C lock state CQ lock state Q6 = (( A2*((A5*(A3*(A1*A6)))+A4))+ (A2*(A5*(A3*(A1*( A4*A6)))))) A6 A5 A4 A3 A2 A1 A6 A5 A4 A3 A2 A1 B LUT B BQ Q6 = A1..... A LUT A AQ Q6 = A1..... Banc pour Hardware Trojans | Julien FRANCQ, Florian FRICK | 27/11/2012 | Page 28 / 43 c 2012 CASSIDIAN CYBERSECURITY - All rights reserved Circuit non-infecté Banc pour Hardware Trojans | Julien FRANCQ, Florian FRICK | 27/11/2012 | Page 29 / 43 c 2012 CASSIDIAN CYBERSECURITY - All rights reserved Circuit infecté par HT1 A6 key(3) A5 A4 key(2) key(6) A3 A2 key(0) key(4) A1 key(1) A6 unlock A5 A4 lock state key(7) A3 A2 lock key(0) A1 N2 Q6 D LUT D N2 DQ Q6 = ( A5*( A2*( A3*( A4*( A1* A6))))) Q6 C LUT C NET 0 CQ Q6 = (( A2*((A5*(A3*(A1*A6)))+A4))+ (A2*(A5*(A3*(A1*( A4*A6)))))) NET 0 I1 I0 A6 A5 A4 A3 A2 A1 A6 A5 A4 A3 A2 A1 B LUT B lock state BQ lock state Q6 = (A6+(A5*A4)) A LUT A AQ Q6 = A1..... Banc pour Hardware Trojans | Julien FRANCQ, Florian FRICK | 27/11/2012 | Page 30 / 43 c 2012 CASSIDIAN CYBERSECURITY - All rights reserved Circuit infecté par HT1 Banc pour Hardware Trojans | Julien FRANCQ, Florian FRICK | 27/11/2012 | Page 31 / 43 c 2012 CASSIDIAN CYBERSECURITY - All rights reserved Port Map dans SASEBO Bidirectional Interface 0 1 2 3 4 5 6 7 8 9 10 CTRL 11 12 LOGIC 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 CTRL FPGA clk CUT FPGA I0 I1 unlock lock key CUT LOGIC O1 O2 O3 lock state counter rst clk Banc pour Hardware Trojans | Julien FRANCQ, Florian FRICK | 27/11/2012 | Page 32 / 43 c 2012 CASSIDIAN CYBERSECURITY - All rights reserved Validation du fonctionnement cycle 0 1 2 3 4 5 6 unlock 0 1 0 0 0 0 0 lock 0 0 1 0 0 0 0 Input key 0 160 0 0 0 0 0 TP1 1 0 0 0 1 0 0 TP2 0 1 0 0 1 0 0 state locked locked locked open locked locked locked Output TO1 TO2 TO3 0 0 0 1 0 1 0 0 1 0 0 0 0 0 0 1 1 1 0 0 0 counter 0 1 2 3 4 5 6 Banc pour Hardware Trojans | Julien FRANCQ, Florian FRICK | 27/11/2012 | Page 33 / 43 c 2012 CASSIDIAN CYBERSECURITY - All rights reserved Validation du fonctionnement cycle 0 1 2 3 4 5 6 unlock 0 1 0 0 0 0 0 lock 0 0 1 0 0 0 0 Input key 0 160 0 0 0 0 0 TP1 1 0 0 0 1 0 0 TP2 0 1 0 0 1 0 0 state locked locked locked open locked locked open Output TO1 TO2 TO3 0 0 0 1 0 1 0 0 1 0 0 0 0 0 0 1 1 1 0 0 0 counter 0 1 2 3 4 5 6 Fonctionne en simulation et sur notre banc Banc pour Hardware Trojans | Julien FRANCQ, Florian FRICK | 27/11/2012 | Page 34 / 43 c 2012 CASSIDIAN CYBERSECURITY - All rights reserved Circuit original Banc pour Hardware Trojans | Julien FRANCQ, Florian FRICK | 27/11/2012 | Page 35 / 43 c 2012 CASSIDIAN CYBERSECURITY - All rights reserved Circuit infecté “manuellement” Banc pour Hardware Trojans | Julien FRANCQ, Florian FRICK | 27/11/2012 | Page 36 / 43 c 2012 CASSIDIAN CYBERSECURITY - All rights reserved Circuit infecté en VHDL if ((unlock = 1) and (key = 10100000)) or ((TL1 = 1) and (TL2 = 1)) then lock_open <= 1; end if; Banc pour Hardware Trojans | Julien FRANCQ, Florian FRICK | 27/11/2012 | Page 37 / 43 c 2012 CASSIDIAN CYBERSECURITY - All rights reserved HT2 (combinatoire) Ajouter une clé maître qui marchera tout le temps lock state lock lock unlock open unlock and key = 11111111 locked unlock and key = 10100000 Code Dans le cas d’un code 8 bits, facile à détecter lors du test fonctionnel “Toy example” Banc pour Hardware Trojans | Julien FRANCQ, Florian FRICK | 27/11/2012 | Page 38 / 43 c 2012 CASSIDIAN CYBERSECURITY - All rights reserved HT3 (séquentiel) Utiliser les pins de test (ou peut-être le bouton de fermeture de la porte) pour contrôler une petite machine à états finis Si une certaine combinaison est entrée, cela ouvre la porte I0 and not I1 I0 not I0 and I1 HT1 HT2 HT3 active HT6 HT5 I0 and I1 I1 I0 and not I1 not I0 and I1 HT Active lock state locked lock lock open HT Active unlock unlock and key = 10100000 code Banc pour Hardware Trojans | Julien FRANCQ, Florian FRICK | 27/11/2012 | Page 39 / 43 c 2012 CASSIDIAN CYBERSECURITY - All rights reserved HT4 Réutiliser le compteur de la LED Récupérer son état en observant le signal de la LED Le coupler avec une condition séquentielle simple lock and counter value = 123 idle HT1 4 else lock active co n un ot te lo r ck va a lu nd e = 12 counter value HT Active lock state locked lock lock open HT Active unlock unlock and key = 10100000 code Banc pour Hardware Trojans | Julien FRANCQ, Florian FRICK | 27/11/2012 | Page 40 / 43 c 2012 CASSIDIAN CYBERSECURITY - All rights reserved Introduction aux Hardware Trojans et à HOMERE Construction d’un banc d’expérimentations Nos objectifs Utilisation de SASEBO Comment déclencher un HT ? Analyse par canaux auxiliaires Scenarii de tests Présentation d’un cas d’étude : contrôle d’accès Présentation Injecter/tester un HT combinatoire Autres Hardware Trojans Conclusion et perspectives Banc pour Hardware Trojans | Julien FRANCQ, Florian FRICK | 27/11/2012 | Page 41 / 43 c 2012 CASSIDIAN CYBERSECURITY - All rights reserved Conclusion Preuve de concept de notre banc fonctionne avec un cas d’étude simple Architecture flexible L’infection d’un circuit par des HTs par la manipulation de la configuration d’un FPGA est possible... ...et modifications limitées (proche de la réalité) Side-Channel Analysis 6= Side-Channel Attack Plusieurs trojans trouvés sur un cas simple... Approche sur SASEBO transposable aux ASICs Commandes pour l’oscilloscope Approche adaptative ? Banc pour Hardware Trojans | Julien FRANCQ, Florian FRICK | 27/11/2012 | Page 42 / 43 c 2012 CASSIDIAN CYBERSECURITY - All rights reserved Je vous remercie de votre attention. Avez-vous des questions ? Credits: Snort Banc pour Hardware Trojans | Julien FRANCQ, Florian FRICK | 27/11/2012 | Page 43 / 43 c 2012 CASSIDIAN CYBERSECURITY - All rights reserved Journée sécurité numérique _ GDR SoC-SiP MISE EN ŒUVRE D'UNE MÉTHODE DE DÉTECTION DE « TROJANS » MATÉRIELS SUR CIRCUITS AES. Exurville Ingrid Jacques Fournier & Jean Max Dutertre 27/11/2012 SOMMAIRE Introduction Méthode de caractérisation d’un Cheval de Troie Matériel par mesure de temps de chemin de propagation Mesure des temps de chemin de propagation sur l’AES Mise en œuvre, premières observations Perspectives PRESENTATION GDR SoC-SiP | 27 NOVEMBRE 2012 | PAGE 2 Introduction Méthode de caractérisation d’un CTM par mesure de temps de chemin de propagation Mesure des temps de chemin de propagation sur l’AES Mise en œuvre, premières observations Perspectives PRESENTATION GDR SoC-SiP | 27 NOVEMBRE 2012 | PAGE 3 INTRODUCTION Cheval de Troie Matériel Ajout / modification d’un circuit pouvant transmettre des informations confidentielles à l'insu de l'utilisateur, désactiver/détruire certains composants de la puce… Approche d’une mesure de temps de chemin de propagation des bits d’un algorithme de chiffrement symétrique par blocs représentés en matrices 4*4 : l’AES. Hypothèse de travail L’ajout d’un CTM modifie le temps de propagation des bits. PRESENTATION GDR SoC-SiP | 27 NOVEMBRE 2012 | PAGE 4 Introduction Méthode de Caractérisation d’un CTM par mesure de temps de chemin de propagation Mesure des temps de chemin de propagation sur l’AES Mise en œuvre, premières observations Perspectives PRESENTATION GDR SoC-SiP | 27 NOVEMBRE 2012 | PAGE 5 CONTRAINTE TEMPORELLE DES CIRCUITS SYNCHRONES n Dffi data clk 1 Dffi+1 Logique Qi Di m DclkQ 1 combinatoire 1 Di+1 Qi+1 1 DpMax Tclk + Tskew - su Temps de propagation des données = DclkQ + DpMax Temps requis par les données = Tclk + Tskew - su Tclk > DclkQ + DpMax - Tskew + su PRESENTATION GDR SoC-SiP | 27 NOVEMBRE 2012 6 LE GLITCH D’HORLOGE Le « glitch » d’horloge est une modification locale d’une période. Le choix du cycle d’injection est possible. Tour n-2 Tour n-1 Tour n Tour n+1 Tour n+2 Tclk clk DpMax + su clk’ T = 35 ps Tclk - T T = 35 ps Tclk > DclkQ + su + DpMax - Tskew PRESENTATION GDR SoC-SiP | 27 NOVEMBRE 2012 7 LE GLITCH D’HORLOGE Fonctionnement normal set-up hold Tclk’ Clk’ DclkQ Qi DpMax D i+1 logic glitches DclkQ Q i+1 PRESENTATION GDR SoC-SiP | 27 NOVEMBRE 2012 8 LE GLITCH D’HORLOGE Violation du temps de setup set-up hold Tclk’-T Clk’ DclkQ Qi DpMax D i+1 logic glitches Q i+1 Métastabilité (non-déterministe) DclkQ ‘1’ ou ‘0’ ? PRESENTATION GDR SoC-SiP | 27 NOVEMBRE 2012 9 LE GLITCH D’HORLOGE Faire une faute revient à faire une mesure du temps de propagation des bits connaissant le nombre de T. Glitch Au tour n°10 Avec Tclk – N*T Message : 0100011100011110010… Chiffré en sortie : AES 1000110111010101010… Chiffré attendu : 0000110111010101010… PRESENTATION GDR SoC-SiP | 27 NOVEMBRE 2012 10 PRINCIPE DE DÉTERMINATION DU TEMPS DE PROPAGATION DES BITS Diminution de la période par pas de T=35ps Seuil critique Pas de faute D1 D2 Octet n°7 D3 D4 D5 D6 D7 D8 3 bits fautés 0 ns ≈ Tclk – 170*ΔT 2 bits fautés 1er bit fauté ≈ Tclk – 95*ΔT Tclk = 10 ns Période (en ns) ≈ Tclk – 125*ΔT ≈ Tclk – 135*ΔT PRESENTATION GDR SoC-SiP | 27 NOVEMBRE 2012 | PAGE 11 PRINCIPE DE DÉTERMINATION DU TEMPS DE PROPAGATION DES BITS Diminution de la période par pas de T=35ps Seuil critique ΔH : causé par le trojan D1 D2 Octet n°7 D3 D4 D5 ΔV : Variabilité inter maquette D6 D8 0 ns ≈ Tclk – 170*ΔT D7 Tclk = 10 ns Période (en ns) • Si ΔT << ΔH : on peut mesurer l’effet du CTM. • Si ΔV << ΔH : La présence du CTM n’est pas masquée par la variabilité. PRESENTATION GDR SoC-SiP | 27 NOVEMBRE 2012 | PAGE 12 PROTOCOLE EXPÉRIMENTAL Mise en place du glitch d’horloge : PRESENTATION GDR SoC-SiP | 27 NOVEMBRE 2012 | PAGE 13 Introduction Méthode de caractérisation d’un CTM par mesure de temps de chemin de propagation Mesure des temps de chemin de propagation sur l’AES Mise en œuvre, premières observations Perspectives PRESENTATION GDR SoC-SiP | 27 NOVEMBRE 2012 | PAGE 14 INFLUENCE SUR LA MESURE DES TEMPS DE CHEMINS CRITIQUES SUR L’AES Option de Synthèse Texte clair Clé Facteurs FPGA Bitstream Environnement extérieur Code VHDL PRESENTATION GDR SoC-SiP | 27 NOVEMBRE 2012 | PAGE 15 ETUDE DE LA VARIABILITÉ POUR PLUSIEURS BITSTREAMS SUR UNE MÊME MAQUETTE Trois synthèses distinctes sont effectuées pour en récupérer trois bitstreams. 1400 Etude du bit n°3 1200 Nombre d'occurrences 1000 800 bitstream 1 600 bitstream 2 bitstream 3 400 200 0 6465 6430 6395 6360 6325 6290 6255 6220 6185 6150 6115 6080 Valeur du chemin critique (en ps) Texte clair et clé constants PRESENTATION GDR SoC-SiP | 27 NOVEMBRE 2012 | PAGE 16 ETUDE DE LA VARIABILITE POUR TROIS MAQUETTES FPGA AVEC UN MEME BITSTREAM Même code, même bitstream, trois maquettes Texte clair et clé constants. ΔV =175 ps Etude du bit n°3 1600 1400 1200 Maquette n° 1 1000 Nombre d'occurrences Maquette n° 2 800 Maquette n° 3 600 400 200 0 6535 6500 6465 6430 6395 6360 6325 6290 6255 6220 6185 6150 6115 6080 Valeur du chemin critique (en ps) PRESENTATION GDR SoC-SiP | 27 NOVEMBRE 2012 | PAGE 17 ETUDE DE LA RÉPARTITION DE TEMPS DE CHEMINS CRITIQUES Assimilation à une Gaussienne Nombre d'occurrences de fautes le bit n°3 pour les 4000 essais Histogramme des données mesurées Gaussienne générée par Octave Nombre de ΔT suffisants pour fauter le bit n°3 pour les 4000 essais Cette méthode permet une certaine formalisation de la base de données des valeurs, et ainsi manipuler les données plus facilement. PRESENTATION GDR SoC-SiP | 27 NOVEMBRE 2012 | PAGE 18 ETUDE DE LA VARIABILITE POUR QUATRE MAQUETTES FPGA AVEC UN MEME BITSTREAM Comparaison des temps de propagation pour quatre maquettes pour les bits [100-128] PRESENTATION GDR SoC-SiP | 27 NOVEMBRE 2012 | PAGE 19 OPTION DE SYNTHÈSE « KEEP HIERARCHY » Comparaison option de synthèse « Keep hierarchy » pour les bits [100-128] (En noir : sans « Keep hierarchy » , en bleu : avec « Keep hierarchy » ) PRESENTATION GDR SoC-SiP | 27 NOVEMBRE 2012 | PAGE 20 Introduction Caractérisation d’un CTM par mesure de temps de chemin de propagation Mesure des temps de chemin de propagation sur l’AES Mise en œuvre, premières observations Perspectives PRESENTATION GDR SoC-SiP | 27 NOVEMBRE 2012 | PAGE 21 OPTION DE SYNTHÈSE SANS « KEEP HIERARCHY » Distribution des temps de propagation des 128 bits de l’AES PRESENTATION GDR SoC-SiP | 27 NOVEMBRE 2012 | PAGE 22 OPTION DE SYNTHÈSE SANS « KEEP HIERARCHY » Comparaison sans CTM/ CTM n°1/ CTM n°2 pour les bits [100-128] (En noir : sans CTM) Repartition des temps de chemins critiques 8000 7500 7000 6500 6000 5500 5000 4500 4000 3500 100 105 110 115 120 125 130 Numero de bit de la matrice d'etat de l'AES PRESENTATION GDR SoC-SiP | 27 NOVEMBRE 2012 | PAGE 23 OPTION DE SYNTHÈSE SANS « KEEP HIERARCHY » Comparaison sans CTM/ CTM n°1/ CTM n°2 pour les bits [100-128] (en noir : sans CTM, en rouge : CTM n°1) Repartition des temps de chemins critiques 8000 7500 7000 6500 6000 5500 5000 4500 4000 3500 100 105 110 115 120 125 130 Numero de bit de la matrice d'etat de l'AES PRESENTATION GDR SoC-SiP | 27 NOVEMBRE 2012 | PAGE 24 OPTION DE SYNTHÈSE SANS « KEEP HIERARCHY » Comparaison sans CTM/ CTM n°1/ CTM n°2 pour les bits [100-128] (en noir : sans CTM, en rouge : CTM n°1, en bleu : CTM n°2) Repartition des temps de chemins critiques 8000 7500 7000 6500 6000 5500 5000 4500 4000 3500 100 105 110 115 120 125 130 Numero de bit de la matrice d'etat de l'AES PRESENTATION GDR SoC-SiP | 27 NOVEMBRE 2012 | PAGE 25 PERTINENCE DE L’OPTION « KEEP HIERARCHY » Comparaison sans CTM/ CTM n°1/ CTM n°2 pour les bits [60-80] (en noir : sans CTM, en rouge : CTM n°1, en bleu : CTM n°2) Repartition des temps de chemins critiques 8000 7500 7000 6500 6000 5500 5000 4500 4000 3500 100 105 110 115 120 125 130 Numero de bit de la matrice d'etat de l'AES PRESENTATION GDR SoC-SiP | 27 NOVEMBRE 2012 | PAGE 26 Introduction Caractérisation d’un CTM par mesure de temps de chemin de propagation Mesure des temps de chemin de propagation sur l’AES Mise en œuvre, premières observations Perspectives PRESENTATION GDR SoC-SiP | 27 NOVEMBRE 2012 | PAGE 27 PERSPECTIVES Caractérisation un AES grâce à la distribution des temps associé à chaque bit de l’AES. Le rajout d’un CTM a une influence sur la distribution de temps de chemins critiques. Les variations dues à certains facteurs (changement de FPGA, d’option, etc.) ont une influence sur le temps de chemins critiques, mais ne remettent pas en cause la validation de l’outil. Cette étude a permis de nouvelles approches quant à la détection de CTM. On distingue des nouveaux critères d’analyses : • La liste des bits non détectés • L’ordre des bits détectés • Le nombre de bits détectés Possibilité de détecter une resynthèse. Limites : CTM placé dans un chemin « non-critique court ». PRESENTATION GDR SoC-SiP | 27 NOVEMBRE 2012 | PAGE 28 | PAGE 29 PRESENTATION GDR SoC-SiP | 27 NOVEMBRE 2012 Commissariat à l’énergie atomique et aux énergies alternatives Centre de Saclay | 91191 Gif-sur-Yvette Cedex Etablissement public à caractère industriel et commercial | RCS Paris B 775 685 019
