Télécharger le PDF

Commentaires

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
DclkQ
1
combinatoire
1
Di+1 Qi+1
1
DpMax
Tclk + Tskew - su
Temps de propagation des données = DclkQ + DpMax
Temps requis par les données = Tclk + Tskew - su
Tclk
>
DclkQ + 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
>
DclkQ + su + DpMax - Tskew
PRESENTATION GDR SoC-SiP | 27 NOVEMBRE 2012 7
LE GLITCH D’HORLOGE
 Fonctionnement normal
set-up
hold
Tclk’
Clk’
DclkQ
Qi
DpMax
D i+1
logic glitches
DclkQ
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’
DclkQ
Qi
DpMax
D i+1
logic glitches
Q i+1
 Métastabilité (non-déterministe)
DclkQ
‘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=35ps
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=35ps
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

Documents pareils