Conception Et Mise en Oeuvre Des Méthodes de

Cycle de formation des ingénieurs en Télécommunications
Option :
Architecture des Systèmes des Télécommunications
Rapport de projet de fin d’étude
Thème :
Conception et mise en œuvre des méthodes de

protection matérielles d’IP pour les cibles
logicielles ou matérielles
Réalisé par :
Zeinab Bouchehioua
Encadrée par :
M. Lilian BOSSUET
M. Chiheb REBAI
Travail proposé et réalisé en collaboration avec le laboratoire IMS, Bordeaux
Année universitaire : 2006/2007
I
Remerciements
Le travail présenté dans ce rapport a été effectué dans le cadre de mon projet de fin d’études
d’ingénieur en télécommunications, option Architecture des Systèmes des Télécommunications
(AST) à l’école supérieure des communications de Tunis (Sup’Com).
Ce projet a été réalisé en collaboration avec le laboratoire de l'Intégration du Matériau au Système

(IMS) au sein de l’équipe « circuit et système numérique ».
Les travaux de ce projet concernent la conception et mise en œuvre des méthodes de protection
matérielles d’IP pour des cibles logicielles ou matérielles.
Au terme de ce travail, je voudrais exprimer mes remerciements à mes encadrants:
Mr. Lilian Bossuet, maître de conférences à l’Ecole Nationale Supérieure d’Electronique,

Informatique et Radiocommunications de Bordeaux (ENSEIRB), pour son encadrement, son
aide, sa disponibilité permanente, sa bonne humeur et surtout sa gentillesse…Si j’en dis encore
plus, vous aller vous dire que je dis tout ca pour avoir une bonne appréciation mais
malheureusement c’est la dure réalité.
Mr. Rebai Chiheb, maître assistant à Sup’Com, pour m’avoir donné l’opportunité d’effectuer ce
projet au sein du laboratoire IMS, pour son encadrement attentif, son soutient et ses précieux
conseils.
Mes remerciements s’adressent aussi à Dominique Dallet, Professeur à l’ENSEIRB, pour son
accueil chaleureux, sa joie, sa bonne humeur et surtout pour les gâteaux qu’il nous ramène
régulièrement.
Un grand merci à Bertrand Le Gal, Maître de Conférences à l’ENSEIRB, pour m’avoir consacré
de son temps à chaque fois que je viens l’ennuyer avec mes nombreuses questions.
Merci à Maher Jridi, ingénieur diplômé de Sup’Com et doctorant à l’IMS pour son aide logistique
et surtout pour sa joie de vivre et son sourire qui m’encourage chaque matin à terminer cette
longue journée.
I
Remerciements
Merci à Nicolas Méchouk, doctorant à l’IMS pour son aide et pour son attention.
Je tiens à remercier tous ce qui m’ont soutenu durant ce projet, je parle bien sur de ma famille
que j’embrasse et de mon ange Issam avec qui j’ai passé des moments inoubliables durant mes
week end à Paris.
Je tiens à remercier tous mes amis à bordeaux, surtout Haïfa avec qui j’ai fait quelques folies et
bien rigolé. Je la remercie pour les bons plats qu’elle m’a concoctés.
Je remercie aussi Yosra pour sa gentillesse et son soutien.
II
Résumé et mots clés
Les travaux présentés dans ce document sont dans le cadre d’un projet pour l’entreprise SAFT
qui veut garantir les clauses de confidentialité de sa propriété intellectuelle avec ses sous traitants.
Pour répondre à l’attente de cette entreprise, nous allons travailler sur le choix d’une solution qui
répondra aux critères imposés par l’entreprise SAFT.
Nous allons exposer la problématique de l’entreprise SAFT et répondre à cette problématique par
des solutions bien choisies.
Nous commencerons par étudier une solution sur les microcontrôleurs 16 bits de Microchip à
savoir le CodeGuard Security. Nous allons mettre en œuvre cette solution sur un dsPIC33F et
effectuer un certains nombres de tests. Au terme de ce travail, nous avons effectué une formation
pour l’entreprise SAFT un document de type tutorial leur sera livré. Puis nous étudierons les
solutions de sécurité matérielles reconfigurables sur les FPGA Flash et SRAM.
Même si les deux solutions présentées répondent à la problématique de l’entreprise SAFT, nous
proposerons une solution hybride : implémenter le concept du CodeGuard sur FPGA.
Mots clé :
IP, microcontrôleur, PIC, sécurité, CodeGuard, FPGA, systèmes embarqués.
III
Glossaire
A I
AES: Advanced Encryption Standard IP: Intellectual Property
AIVT: Alternate Interrupt Vecteur Table
R
C RAM: Random Access Memory
CEM : Compatibilité électromagnétique
CPU: Central Process Unit
CSoC : Configurable System on Chip P
PIC: Peripheral Interface Controller
D
DES: Data Encryption Standard S
DMA: Direct Memory Access
SFR: Special Function Register
DSP: Digital Signal Procesing
SRAM: Static Random Access Memory
dsPIC: digital signal PIC
F
FB: Flash Memory Blocks
Flash: Flash-erase EPROM
FPGA: Field Programmable Gate Array
K
KO: Kilos Octets
IV
Table des matières
Remerciements.............................................................................................................................................. I
Résumé et mots clés................................................................................................................................. III
Introduction générale...................................................................................................................................1
Chapitre I
Contexte et problématique ...................................................................................................3
1. Problématique de la société SAFT ....................................................................................4
2. Introduction à la sécurité ..................................................................................................6
2. 1. La notion de sécurité...........................................................................................................................................................6
2. 2. Objectifs de la sécurité .......................................................................................................................................................6
2. 3. Cibles de la sécurité.............................................................................................................................................................7
3. Les solutions de protection des IP....................................................................................8
3. 1. Solutions software (Watermarking et Fingerprinting)...................................................................................................8
3. 2. Protection hardware pour une cible software.................................................................................................................9
3. 3. Solution avec protection hardware reconfigurable sur FPGA ..................................................................................11
3. 4. Choix des solutions à étudier...........................................................................................................................................12
4. Conclusion....................................................................................................................... 13
Chapitre II
Solution software avec protection hardware : CodeGuard Security ................................... 15
1. CodeGuard Security......................................................................................................... 15
1.1. Définition du principe de CodeGuard............................................................................................................................15
1. 2. Les différents types d’implémentation du CodeGuard Security ...............................................................................16
1. 3. Les niveaux de sécurité du CodeGuard Security..........................................................................................................17
1. 4. Organisation de la mémoire programme.......................................................................................................................19
1. 5. Organisation de la mémoire de données .......................................................................................................................20
1. 6. Les registres de configurations ........................................................................................................................................21
2. Allocation des segments.................................................................................................. 21
2. 1. Le boot segment ................................................................................................................................................................21
2. 2. Le secure segment .............................................................................................................................................................24
2. 3. Le general segment............................................................................................................................................................26
V
Table des matières
3. Choix du composant .......................................................................................................27

4. Caractéristiques des dsPIC .............................................................................................28
II. 4. 1. Architecture Harvard :.................................................................................................................................................28
4. 2. Mémoire programme ........................................................................................................................................................28
4. 3. Mémoire RAM ...................................................................................................................................................................29
4. 4. Présentation de la carte.....................................................................................................................................................30
5. Résultats d’implémentation ............................................................................................ 31
5. 1. Description d’un scénario entre trois utilisateurs.........................................................................................................31
5. 2. Inconvénients du CodeGuard Security..........................................................................................................................38
6. Conclusion.......................................................................................................................38
Chapitre III
Système matériel reconfigurable sécurisé ..........................................................................39
1. Problème de protection du bitstream pour FPGA SRAM et Flash ................................40
2. Les FPGA SRAM............................................................................................................. 41
2. 1. Problème de protection du bitstream ...........................................................................................................................41
2. 2. La solution de Xilinx........................................................................................................................................................41
2. 3. La solution d’Altera..........................................................................................................................................................42
3. Les FPGA Flash ..............................................................................................................43
3. 1. Problème de protection du bitstream ............................................................................................................................43
3. 2. ACTEL fusion....................................................................................................................................................................44
4. Résultats ..........................................................................................................................47
4. 1. FPGA d’ACTEL................................................................................................................................................................47
4. 2. FPGA de Xilinx .................................................................................................................................................................47
5. Conclusion.......................................................................................................................47
Conclusions et perspectives................................................................................................48
Annexe .........................................................................................................................................................51
Bibliographie ...............................................................................................................................................63
VI
Liste des figures
Figure 1: Communication entre les différents IPs...................................................................................5

Figure 2: Sécurité en électronique. .............................................................................................................6
Figure 3: Sécurisation des données avec trois circuits. ...........................................................................9
Figure 4: Segmentation de la mémoire....................................................................................................10
Figure 5: Transfert sécurisé du bitstream dans un FPGA SRAM.......................................................12
Figure 6: Principe du CodeGuard Security.............................................................................................15
Figure 7: Organisation de la mémoire programme et de la mémoire de données............................17
Figure 8: Organisation de la mémoire pour un niveau de sécurité élevée..........................................17
Figure 9 : les accès qui génèrent le security reset...................................................................................18
Figure 10 : Les accès autorisés dans le cas d’un niveau de sécurité standard. ...................................18
Figure 11: Organisation de la mémoire programme. ............................................................................20
Figure 12: Organisation de la RAM.........................................................................................................20
Figure 13: Accès à la mémoire RAM à partir de la mémoire Flash. ...................................................21
Figure 14: Le registre FBS de configuration du boot segment............................................................22
Figure 15 : Emplacement du boot segment RAM dans la mémoire de donnée. ..............................23
Figure 16: Le registre BSRAM..................................................................................................................24
Figure 17: Registre de configuration FSS du secure segment..............................................................24
Figure 18: Emplacement du secure segment RAM dans la mémoire.................................................25
Figure 19: Le registre SSRAM. .................................................................................................................26
Figure 20: Le registre FGS. .......................................................................................................................27
Figure 21: Architecture de harvard du dsPIC33F..................................................................................28
Figure 22: Organisation de la mémoire programme. ............................................................................29
Figure 23: Organisation de la mémoire RAM. .......................................................................................30
Figure 24: La carte explorer 16.................................................................................................................30
Figure 25: Connexion du MPLAB ICD2 à la carte et au PC...............................................................31
Figure 26: Scenario avec trois utilisateurs. ..............................................................................................31
Figure 27: Les accès autorisés entre les différents segments................................................................32
Figure 28: Déroulement du scénario avec trois personnes. .................................................................33
VII
Liste des figures
Figure 29: Les accès qui génèrent le security reset. ...............................................................................34

Figure 30: Configuration du niveau de sécurité du boot segment. .....................................................35
Figure 31: Security reset.............................................................................................................................35
Figure 32: Valeur du registre RCON pour un accès autorisé. .............................................................36
Figure 33: Flot de conception d’un FPGA: du VHDL au bitstream..................................................40
Figure 34: Transfert du fichier de configuration dans un FPGA SRAM...........................................41
Figure 35 : La solution de Xilinx pour un Virtex 4. ..............................................................................42
Figure 36: Cryptage/décryptage du bitstream pour un FPGA Stratix III. ........................................43
Figure 37: Interception du fichier de configuration lors des mises à jour. ........................................43
Figure 38: Cryptage/décryptage du bitstream........................................................................................44
Figure 39: Trois scenarios de cryptage/décryptage du bitstream........................................................45
Figure 40 : Exemple de programmation du FPGA dans un environnement extérieur. ..................46
VIII
Liste des tableaux
Tableau 1 : Type d’implémentation du CodeGuard..............................................................................12

Tableau 2: Type d’implémentation du CodeGuard suivant le composant. .......................................12
Tableau 3 : Les opérations possibles entre les différents segments suivant le niveau de sécurité
choisi. ...........................................................................................................................................................13
Tableau 4 : Les différentes combinaisons possibles pour les bits BSS (2 :0).....................................17
Tableau 5 : Les différentes configurations du RBS pour le choix de la taille de la RAM................18
Tableau 6: Valeur du SSS suivant la taille et le niveau de sécurité du secure segment.....................20
Tableau 7: Détermination de la taille de la RAM...................................................................................21
Tableau 8: Description des combinaisons de valeurs que peut prendre le registre SSRAM...........21
Tableau 9: Choix du microcontrôleur. ....................................................................................................23
Tableau 10: Type de configuration des trois segments.........................................................................28
Tableau 11: Valeur du registre RCON. ...................................................................................................31
Tableau 12: Exemples de quelques tests effectués sur la carte............................................................33
Tableau 13 : Les niveaux de sécurité possible avec le FPGA fusion. .................................................42
IX
Introduction générale
Contexte de l’étude
Aujourd’hui la conception d’un système numérique devient de plus en plus complexe et demande
l’interaction de plusieurs intervenants (société de services, sous-traitants, clients). Les relations
donneur d’ordre/sous traitants et fournisseurs/clients, sont complexes et souvent liés. C’est dans
ce contexte que l’entreprise SAFT réalise des batteries pour des marchés principalement
industriels et des applications dans le domaine du transport (automobile, transport en commun,
aéronautique…) puisqu’elle fait appel à un sous traitant pour effectuer des tâches qui ne font pas
partie de son domaine de compétence.
Objectif de l’étude
L’objectif de ce projet est de répondre aux attentes de l’entreprise SAFT qui veut protéger sa
propriété intellectuelle. Celle-ci se traduit par un algorithme qui s’occupe de la gestion des
batteries. Parmi les contraintes imposées ; l’entreprise SAFT veut une solution dont la mise en
œuvre n’implique pas des coûts exorbitants, la solution ne doit pas être encombrante et doit
pouvoir bénéficier d’une faible consommation d’énergie.
Nous allons tout au long de ce rapport proposer des solutions et étudier les plus pertinentes qui
répondent aux contraintes imposées par l’entreprise SAFT.
Plan de travail
Le travail présenté dans ce rapport est subdivisé en trois parties : dans la première partie nous
poserons le problème que nous devons résoudre pour l’entreprise SAFT et qui consiste en la
protection de sa propriété intellectuelle. Nous proposerons un certains nombres de solutions
pour y répondre et nous choisirons les plus adéquates à l’application de l’entreprise SAFT.
Dans la deuxième partie de ce rapport, nous détaillerons une des solutions proposées,
CodeGuard Security, qui permet la protection hardware d’une cible software (microcontrôleurs).
Dans la troisième partie, les solutions sur les systèmes matériels reconfigurables (FPGA) seront
1
Introduction générale
étudiées; pour répondre au problème de protection du fichier de configuration. L’étude sera

basée sur les FPGA d’ACTEL, Xilinx et ALTERA.
Enfin, des perspectives possibles aux deux solutions présentées précédemment seront présentées
dans le chapitre des perspectives et conclusion. Nous proposerons une solution « hybride » du
concept de CodeGuard sur FPGA. Ce travail sera achevé durant le mois de juillet.
2
Chapitre I
Contexte et problématique
La gestion de la confidentialité des données et de la sécurité des informations contenues dans un système
électronique sensible s’appuie sur l'état de l'art technologique du moment et doit être pris en compte dès les
premières étapes de l'intégration matérielle des systèmes numériques intégrés programmables ou
configurables tel que les FPGA, microcontrôleurs ou ASIC.
Nous commencerons ce chapitre en posant la problématique de l’entreprise SAFT qui veut garantir la
confidentialité de ses données quand elle fait appel à des sous-traitants ou à ses clients. Pour pouvoir
répondre à cette problématique, des notions générales sur la sécurité seront étudiées en début de ce chapitre.
Puis un certains nombres de solutions, répondant à l’attente de l’entreprise SAFT, seront énumérés. Nous
commencerons par les solutions software tel que le watermarking et le fingerprinting, puis des solutions
hardware sur microcontrôleur et sur FPGA seront introduites. A la fin de ce chapitre, nous choisirons les
solutions qui seront étudiées dans les prochains chapitres.
3
Chapitre1-Contexte et problématique
1. Problématique de la société SAFT

L’entreprise SAFT* est spécialisée dans la conception et la production de batteries de haute
technologie. Les batteries produites par cette entreprise sont utilisées dans les applications de
haute performance, notamment dans les infrastructures et processus industriels, le transport, la
défense et l’espace. Le domaine de spécialisation de cette entreprise est donc la chimie et les
matériaux. Cependant, une batterie dans son environnement de fonctionnement où elle assure
l’alimentation en énergie du système hôte, nécessite un système embarqué pour sa gestion. Ce
système de gestion de batterie collabore avec les autres fonctions enfouies dans le système hôte.
Par exemple dans une automobile, le système de gestion de la batterie peut être couplé au
contrôle moteur, ou à d’autres fonctions. Pour développer ce système embarqué de gestion de la
batterie, la société SAFT ne dispose que d’une équipe et de compétences très limitées étant
données que la conception de systèmes embarqués ne correspond pas à son cœur de métier.
Pour réaliser son système de gestion de batterie, la société SAFT a donc deux solutions qu’elle
utilise suivant le cadre commerciale du marché :
Première solution : la société SAFT fait appel à un sous-traitant spécialisé dans la
conception de système embarqué.
Deuxième solution : la société SAFT donne au client (par exemple un équipementier
automobile) les spécifications nécessaires à l’intégration de la gestion batterie dans le
système hôte.
Dans les deux cas, la société SAFT est contrainte de donner les algorithmes de gestion de la
batterie qu’elle a développés. Ceux-ci sont d’une complexité réduite mais ils reposent sur
l’utilisation de paramètres (sous forme de constantes) liés à la batterie utilisée. Ces paramètres
nécessitent une connaissance très fine de la batterie que seule la société SAFT peut avoir. Ainsi
celle-ci souhaite fortement que ces paramètres et l’algorithme ne soit pas divulgués dans les deux
solutions, c'est-à-dire aux sous-traitants comme aux clients.
La société SAFT a donc besoin d’un système de protection de sa propriété intellectuelle qui lui
permette tout de même de laisser à d’autres le soin de réaliser le système final. Dans celui-ci
plusieurs parties peuvent travailler en parallèle et inter-communiquer.
Nous voyons donc que le système de protection requis doit respecter un certain nombre de
contraintes que voici énumérées :
L’algorithme de SAFT doit pouvoir communiquer avec les autres applications qui se
trouvent dans le système final (l’entreprise SAFT veut protéger son algorithme et des
constantes qui lui permettent d’effectuer des mesures sur la batterie à des intervalles de
*www.saft.com 4
Chapitre I-Contexte et problématique
temps régulier et de fournir des résultats sur l’état de la batterie tel que la puissance
consommée, l’autonomie). Donc par exemple, l’application de X (figure 1) veut utiliser les
résultats fournit par l’application de SAFT, c’est pour cela qu’il faut assurer l’interaction entre
les différentes applications.
Application de Application de
SAFT X
Application de
Y
Figure 1: Communication entre les différents IPs.
Pour mieux comprendre la figure 2, nous allons prendre un exemple plus concret.
L’entreprise SAFT possède une application qui permet la gestion de la batterie pour une
voiture et son application doit fournir des résultats pour l’application de l’utilisateur X.
L’application de ce dernier s’occupe du contrôle de l’énergie consommée ; elle récupère la
valeur de la puissance consommée par la batterie fournit par l’application de SAFT pour
déterminer si la consommation est normale et ne dépasse pas le seuil maximal de la
consommation. L’application de l’utilisateur Y s’occupe de la distribution de l’énergie
dans la voiture. Cette application utilise des résultats fournis par l’application de SAFT tel
que l’autonomie de la batterie pour optimiser la consommation de cette dernière.
L’exemple présenté montre que plusieurs applications communiquent entre elles dans un
même système c’est pour cela qu’il faut assurer l’interaction entre les différentes
applications.
La société SAFT veut un composant à faible consommation. Pour la gestion de batterie,
le composant qui sera choisit ne doit fonctionner que durant les périodes de mesures sur
la batterie. C'est-à-dire qu’il fonctionne quand l’application de SAFT effectuera des
mesures sur la batterie et se mettra en mode veille quand il n’y a pas de calculs à effectuer.
Donc le composant doit bénéficier du mode veille pour minimiser la consommation
d’énergie.
L’entreprise SAFT impose des restrictions de coût puisqu’elle veut une solution à faible
coût (ne dépassant pas les 10 euros).
5
L’algorithme à protéger est de petite taille donc il n’y a pas de contraintes de mémoire. Le
composant qui sera choisit ne doit pas nécessairement avoir une mémoire de grande
capacité et le code de leur application ne sera pas compresser pour alléger les contraintes
sur la mémoire.
Le système final ne doit pas être encombrant c'est-à-dire qu’il ne doit pas occuper une
grande surface puisque, ne l’oublions pas, l’application de SAFT est une application
embarquée et doit répondre aux contraintes d’un système embarqué (en éliminant la
contrainte temps réel).
Pour la protection de son algorithme, l’entreprise SAFT n’impose pas de contrainte de
temps. Les mesures qui s’effectuent sur la batterie se font à intervalle de temps réguliers
et à faibles fréquences.
Pour répondre au problème de protection de propriété intellectuelle de l’entreprise SAFT en
respectant le cahier de charge présenté dans le paragraphe précédent, nous allons tout d’abord
rappeler quelques notions de sécurité.
2. Introduction à la sécurité
2. 1. La notion de sécurité
La sécurité en électronique peut être divisée en trois parties (la sécurité des données, la sécurité
d’un système et la sécurité de la conception (Figure 2)) et a quatre objectifs : l’intégrité, la
confidentialité, la disponibilité et l’authentification.
Figure 2: Sécurité en électronique.
2. 2. Objectifs de la sécurité
La sécurité électronique vise généralement quatre objectifs [1] principaux :
L’intégrité : c’est garantir que les données sont bien celles que l’on croit être ; vérifier
l’intégrité des données consiste à déterminer si les données n’ont pas été altérées.
6
La confidentialité : c’est assurer que seules les personnes autorisées aient accès aux
ressources échangées ; la confidentialité consiste à rendre l’information inintelligible à
d’autres personnes que les seuls acteurs de la transaction.
La disponibilité : c’est maintenir le bon fonctionnement de l’accès au système; l’objectif
de la disponibilité est de garantir l’accès aux ressources.
L’authentification : c’est assurer que seules les personnes autorisées aient accès aux
ressources; l’authentification consiste à assurer l’identité d’un utilisateur. Un contrôle
d’accès peut permettre (par exemple par le moyen d’un mot de passe qui devra être
crypté) l’accès à des ressources uniquement aux personnes autorisées.
2. 3. Cibles de la sécurité
Pour garantir les objectifs de la sécurité cités dans le paragraphe précédent, il faut définir les
champs d’application de la sécurité :
Sécurité des données : elle équivaut à la sécurité des informations confidentielles
contenues dans le système, comme une clé cryptographique ou des données
confidentielles.
Sécurité du système : elle consiste en la sécurisation du système physique. Elle permet
d’éviter que quelqu’un essaies de le contrôler afin d’effectuer des opérations malveillantes,
changer son comportement ou le détruire.
Sécurité de la conception : consiste en la sécurisation de la propriété intellectuelle. En
d’autres termes, il ne faut pas sécuriser la fonction du système, mais l’implémentation de
cette fonction. Cette protection doit se faire pour les différents types de composants
virtuels.
Comme nous l’avons vu dans la première partie de ce chapitre, l’entreprise SAFT veut protéger
sa propriété intellectuelle donc dans le reste de ce chapitre nous traiterons essentiellement de la
sécurité de la conception pour répondre à la problématique posée. Dans ce cadre, nous allons
proposer un ensemble de solutions de sécurisation de l’algorithme pour l’entreprise SAFT. Cette
entreprise veut garantir la confidentialité de son application, elle veut que cette dernière soit pour
le sous-traitant ou le client une boite noire qui possède un certains nombres d’entrées et retourne
des résultats. Protéger l’application de l’entreprise SAFT revient en quelque sorte à la protection
d’un IP (Intellectual Property). Nous allons donc étudier différentes solutions de protections des
IP afin de voir si certaines d’entres elles correspondent aux besoins de l’entreprise SAFT.
7
3. Les solutions de protection des IP

A l’inverse des composants en boîtiers pour lesquels il faut acheter un exemplaire pour chaque
produit, les composants virtuels ou IP sont distribués sous la forme de fichiers qui peuvent être
réutilisés à volonté. Construire une copie conforme d’un composant discret nécessite un effort
significatif puisque les détails de l’implantation sont masqués à l’utilisateur. Un composant
virtuel, au contraire, peut être dupliqué et revendu sans qu’une compréhension de son
architecture soit nécessaire [2]. Ainsi, la protection de la propriété intellectuelle est un problème
majeur dans le système d’échange de composants virtuels.
Pour protéger son IP, trois types de protections sont possibles :
La prévention : utiliser des moyens légaux (brevet, droit d’auteur, contrat et procès).
La protection : empêcher l’utilisation non autorisée (demande de licence, cryptage).
La détection: détecter et tracer une utilisation frauduleuse (watermarking,
fingerprinting).
Dans le prochain paragraphe, nous nous intéresserons aux solutions de protection qui permettent
la détection d’une utilisation frauduleuse d’un IP.
3. 1. Solutions software (Watermarking et Fingerprinting)

L’objectif de cette partie est la familiarisation avec les solutions qui permettent de détecter et
tracer une utilisation frauduleuse d’un composant virtuel.
a. Watermarking
Une marque est un mécanisme pour introduire de l’information supplémentaire dans un texte,
une image, un son, une vidéo ou dans un composant virtuel. Les premières sont apparues pour
marquer les images et le son. Ces marques exploitent les imperfections de la vision ou de
l’audition humaine, mais l’objet original est modifié. Par contre, le marquage d’un composant
virtuel impose une contrainte plus forte, il doit rester fonctionnellement correct. L’efficacité
d’une technique de marquage (watermarking ou fingerprinting) [3] repose sur quatre critères :
Une marque doit être difficile à modifier ou à supprimer.
Il doit être difficile d’ajouter une marque à un composant une fois qu’il a été délivré.
Une marque doit être indétectable par l’utilisateur.
Une marque doit préserver la fonctionnalité du composant et son influence sur les
performances du composant doivent être négligeable.
Il est possible de marquer un composant virtuel à différents niveaux de sa conception. Plus le
niveau choisi pour marquer un composant virtuel est bas, plus cette marque doit être robuste par
8
rapport aux différentes opérations restant à exécuter pour obtenir le produit fini. Une marque
peut être une séquence de bits aléatoires, ou une chaîne de caractères en ASCII qui peut être ou
non cryptée, la version cryptée étant plus robuste.
b. Fingerprinting
C’est une signature unique qui identifie, à la fois le propriétaire et l’utilisateur d’un composant
virtuel [4]. Elle doit répondre aux mêmes critères que les watermarks en prenant en compte de
nouvelles contraintes :
Un protocole de fingerprinting doit pouvoir générer des signatures client suffisamment
différentes les unes des autres pour ne pas les confondre.
Un protocole de fingerprinting doit pouvoir générer un grand nombre de signatures client
rapidement.
Les algorithmes et les protocoles cryptographiques introduisent des pertes significatives de
performance, c’est pour cela qu’une étude sur la sécurisation matérielle des composants sera
effectuée dans la suite.
3. 2. Protection hardware pour une cible software

Pour garantir la protection des applications, les concepteurs ont essayé de renforcer la sécurité
des supports d’exécution. Puisque la sécurisation hardware est plus sûre que la protection
software, nous étudierons rapidement une solution qui est utilisée pour la protection matérielle
des données dans le cas où il y a plusieurs applications de différents utilisateurs sur un même
composant (figure 3).
Figure 3: Sécurisation des données avec trois circuits.
9
L’exemple de la figure 3 décrit un scénario entre trois utilisateurs. Chaque utilisateur sécurise son
application en utilisant un composant qui lui est propre. Prenons l’exemple où l’utilisateur 1 est
l’entreprise SAFT, elle enregistre son application qui permet la gestion de la batterie dans le
composant 1 et la sécurise, l’utilisateur 2 est le sous traitant qui s’occupe du contrôle de la
consommation. Ce dernier stocke son application dans un autre composant (2) pour garantir la
confidentialité de son application. Et considérons que l’utilisateur 3 est un autre sous traitant qui
s’occupe de la distribution de l’énergie, et il protège ses données via un troisième composant. Au
final nous aurons une cartes avec trois circuits intégrés spécifiques pour chaque utilisateur. Une
telle architecture, induit des inconvénients tels que des coûts élevés, une occupation de silicium,
une consommation d’énergie élevée puisqu’il y a au sein de la même carte trois composants, sans
oublier la difficulté à gérer la communication entre ces trois composants et les problèmes de
CEM (Compatibilité électromagnétique) engendré par les composants.
Pour répondre à tous ces inconvénients, au lieu de partitionner le système sur plusieurs circuits
intégrés, il est possible d’imaginer une architecture avec un unique circuit programmable dont la
mémoire est segmentée, c’est ce que présente la figure 4. A cette segmentation sont ajoutés des
privilèges en lecture et/ou en écriture aux différents utilisateurs.
Figure 4: Segmentation de la mémoire.
Dans le cas de la figure 4, l’utilisateur 1 enregistre son application dans la première partie de la
mémoire programme (segment 1), puis il fournit à l’utilisateur 2 le composant. Ce dernier
enregistrera son application dans le deuxième segment de la mémoire et fournit le composant
pour le dernier utilisateur qui stockera ses données dans le segment 3. Les trois segments
possèdent des niveaux de sécurité hiérarchisés : chaque segment possède des privilèges d’accès
aux autres segments. Prenons l’exemple où l’utilisateur 1 permet seulement à l’utilisateur 2
d’accéder à son segment et de bénéficier de privilèges d’accès en lecture et/ou en écriture. Si
10
l’utilisateur 3, qui ne possède pas les privilèges d’accès en lecture et/ou écriture au segment 1,
tente d’accéder à ce dernier. Le système générera une interruption (non masquable) matérielle ou
un reset pour arrêter la tentative d’accès et par suite, l’instruction de l’utilisateur 3 ne sera pas
effectuer.
La solution présentée a de nombreux avantages [5] dont les principaux sont ceux cités ci
dessous :
Permet à plusieurs personnes de protéger leurs codes en n’utilisant qu’un seul composant,
Permet de réduire les coûts de protection de l’IP (un composant est utilisé à la place des
trois prévus),
Permet de réduire les risques de perte de la confidentialité des données (protection
matérielle),
Permet une intégration plus facile du composant,
Gain en rapidité d’exécution.
Cette solution parait intéressante pour notre étude, nous allons étudier dans le deuxième chapitre
une solution basée sur le même principe. Elle est commercialisée par Microchip et mise en œuvre
sur les microcontrôleurs 16 bits : CodeGuard Security.
3. 3. Solution avec protection hardware reconfigurable sur FPGA

La solution présentée dans le paragraphe précédent répond bien au cahier de charge de
l’entreprise SAFT, mais cette dernière est limitée en performance de rapidité de calcul. Même si la
rapidité de calcul n’est pas une contrainte pour l’entreprise SAFT, nous allons tout de même faire
une étude sur les systèmes matériels reconfigurables pour élargir notre étude et répondre à une
problématique future. L’étude dans cette partie sera basée sur trois technologies de FPGA à
savoir les FPGA anti-fusible, les FPGA SRAM et les FPGA Flash.
Les FPGA anti-fusible [6] sont les plus sécurisés mais ils ne sont configurable qu’une seule fois.
Ce qui empêche d’effectuer des mises à jour et par suite la solution devient figé. Pour répondre
au problème de reconfigurabilité c'est-à-dire des mises à jour du FPGA, nous allons étudier les
FPGA SRAM et Flash.
Les FPGA SRAM [7] (Static Random Access Memory) disposent d’une mémoire de
configuration interne volatile et d’une mémoire externe non volatile dans laquelle sera stockée le
fichier de configuration du FPGA. A chaque mise sous tension, il faut charger ce fichier dans la
mémoire SRAM ce qui constitue une faille de sécurité puisque ce dernier peut être intercepté par
un tiers. Pour éviter ceci et protéger le transfert du bitstream, ce dernier sera crypté (cryptage
symétrique ; la clé du cryptage et du décryptage est la même) comme le présente la figure 5.
11
Figure 5: Transfert sécurisé du bitstream dans un FPGA SRAM.
Dans la figure 5, à chaque mise sous tension du FPGA, le fichier de configuration est transféré de
la mémoire externe (Flash) vers la SRAM du FPGA. Puis un circuit de décryptage va assurer le
décryptage du bitstream pour ensuite configurer le FPGA.
Le problème du transfert du bitstream ne se pose pas pour les FPGA Flash [7] sauf pour le cas
des mises à jour. Puisque ce type de FPGA possède une mémoire non volatile (Flash).
Néanmoins, ces FPGA possède une faille de sécurité et leur mémoire Flash doit être protégé en
lecture et écriture.
3. 4. Choix des solutions à étudier

Les solutions software de protection de l’IP ne vont pas être étudiées car elles ne protègent pas le
contenu de l’application, elles protègent contre les copies illicites et permettent d’intenter des
poursuites judiciaires contre les personnes qui ont fait la copie. Ces solutions ne protègent pas les
données puisque ces dernières sont en clair et peuvent être exploitées par un tiers dans le but de
produire la même application ou en fournir une version améliorée. Ce type de solution ne répond
donc pas à la problématique de l’entreprise SAFT qui veut protéger son application.
Par contre, la deuxième solution proposée, la protection hardware pour une cible software,
répond aux contraintes imposées par l’entreprise SAFT. L’étude de cette solution et en particulier
du CodeGuard Security sera effectuée dans le chapitre suivant.
La troisième solution, même si elle ne répond pas à toutes les contraintes de l’entreprise SAFT,
est intéressante et sera approfondie dans le troisième chapitre.
12
4. Conclusion
Dans ce chapitre introductif, la problématique de l’entreprise SAFT a été posée, qui est de
garantir la protection de son application qui permet la gestion de la batterie. Nous allons, après
avoir choisit les solutions les plus adéquates c'est-à-dire celles qui répondent (même en partie) à la
problématique de l’entreprise SAFT, étudier dans un premier temps, la solution de sécurisation
des données proposée par Microchip : CodeGuard Security. Cette solution consiste en la
segmentation de la mémoire, chaque segment possède un niveau de sécurité offrant des privilèges
de lecture et/ou écriture de la mémoire aux différents utilisateurs. Puis nous verrons dans le
troisième chapitre les solutions reconfigurables sur FPGA car ces dernières offrent des capacités
de calculs et de reconfigurabilités répondant aux besoins actuels même si ça ne répond qu’en
partie aux contraintes imposées par le cahier de charge de l’entreprise SAFT. Nous étudierons le
cas des FPGA SRAM de Xilinx et d’Altera qui possèdent le problème de transfert du bitstream.
Pour remédier à ce problème, nous verrons les FPGA Flash d’Actel qui n’ont pas de problème
avec le transfert du fichier de configuration puisque ce dernier se trouve dans la Flash qui est
interne au FPGA. Mais la faille de ce type de FPGA est qu’il faut protéger la mémoire Flash en
lecture et écriture.
13
Chapitre II
Solution software avec protection

hardware : CodeGuard Security
Dans le chapitre précédent, la problématique de l’entreprise SAFT a été posée ainsi que différentes
solutions y répondant que ce soit des solutions sur des microcontrôleurs ou sur FPGA. Dans ce chapitre,
nous allons répondre à cette problématique en étudiant le concept de sécurisation avec CodeGuard; l’utilité
d’utiliser cette méthode sera posée en première partie. Puis le principe de fonctionnement du CodeGuard
sera présenté avec les différents niveaux de sécurité possibles. Dans une seconde partie, l’implémentation de
cette solution sur un microcontrôleur bien choisi et un certain nombre de tests seront effectués pour vérifier
les différents concepts présentés au début de ce chapitre.
Enfin dans le dernier volet de ce chapitre, les inconvénients d’une telle architecture seront exposés ainsi que
des solutions pour y remédier.
14
Chapitre II- Solution software avec protection hardware: CodeGuard Security
1. CodeGuard Security
1.1. Définition du principe de CodeGuard
Le principe du CodeGuard Security est d’organiser la mémoire flash en trois segments [8] qui
peuvent contenir du code comme le montre la figure 6.
Figure 6: Principe du CodeGuard Security.
Dans la figure précédente, nous avons pris un exemple avec trois parties. Par exemple, un
vendeur d’IP enregistre son application dans le boot segment qui constitue la partie la plus
sécurisée car l’accès à ce segment est restreint pour les deux autres segments. Après avoir
enregistré son IP dans ce segment, le vendeur d’IP fournit le microcontrôleur au sous-taitant 1
qui va stockée son application dans le second segment : le secure segment. Le deuxième
intervenant est le sous traitant 1, il enregistre son application dans ce segment et il bénéficie d’un
niveau de sécurité inférieur à celui du boot segment mais supérieur à celui du general segment.
L’accès au secure segment est restreint au general segment. Le sous traitant 2 enregistre son
application dans le dernier segment qui est le general segment. C’est le segment le moins sécurisé
car il n’y a pas de restrictions d’accès pour ce dernier.
Chaque segment comme nous venons de le voire à un niveau de sécurité bien précis :
Le boot segment : il bénéficie du plus haut niveau de sécurité ; il a un accès illimité (sans
restriction) aux autres segments. C’est dans ce segment où peut être enregistré les parties
les plus sécurisées tels que les bootloader, clé de cryptage/décryptage…
Le secure segment : c’est le segment qui se trouve juste après le boot segment et qui
possède le deuxième niveau de sécurité après le boot segment. L’accès à ce segment est
seulement restreint au general segment. On y trouve stocké des algorithmes propriétaires,
des petites look up table…
15
Le general segment : c’est le segment le moins sécurisé, nous pouvons y trouver

l’application de l’utilisateur final tel que les drivers pour les périphériques, de larges look
up table…
1. 2. Les différents types d’implémentation du CodeGuard Security

Selon le nombre de segments (ou utilisateurs) dont on a besoin, il y a trois implémentations
possibles [8] :
Basic security : ce type d’implémentation est utilisé surtout pour les composants qui ne
disposent que d’une mémoire flash de faible taille. Il n’y a qu’un seul segment ; toute la
mémoire programme est alloué pour le general segment (il n’est pas possible d’alloué de
l’espace mémoire pour le boot et secure segment puisqu’ils n’existent pas).
Intermediate security : utilisée aussi avec les composants (microcontrôleurs) qui
disposent d’une petite mémoire programme (inférieur à 48KOctet). Il y a deux segments :
le boot et le general segment.
Advanced security: les trois segments peuvent être presents (boot, secure and general
segment).
Le tableau 1 résume les différents types d’implémentation du CodeGuard Security c'est-à-dire
qu’il détermine le nombre de segments présents suivant le choix du type d’implémentation.
Type d’implémentation
Basic Intermediate Advanced
Boot segment Non Oui Oui
Secure segment Non Non Oui
General segment Oui Oui Oui
Tableau 1 : Type d’implémentation du CodeGuard.
Suivant la taille de la mémoire, on peut choisir un des trois types d’implémentations donc ce
choix dépends du composant sur lequel on travaille. Le tableau 2 montre les différents types
d’implémentations qu’on peut avoir sur trois familles de composants.
Type de Type d’implémentation du CodeGuard Security

microcontrôleur Basic Intermediate Advanced
PIC24F Oui Non Non
PIC24H Oui Oui Oui
dsPIC33F Oui Oui Oui
Tableau 2: Type d’implémentation du CodeGuard suivant le composant.
16
Tous les microcontrôleurs cités dans le tableau 2 possèdent une architecture de harvard ; c'est-à-
dire que la mémoire programme et la mémoire de données sont séparées. Ils possèdent des bus
programme et données séparés (leur tailles dépend du type de microcontrôleur) comme on peut
le noter dans la figure 7.
Figure 7: Organisation de la mémoire programme et de la mémoire de données.
1. 3. Les niveaux de sécurité du CodeGuard Security

Il y a deux niveaux de sécurité :
Niveau de sécurité élevé: l’accès au boot segment (respectivement au secure segment) à
partir d’un autre segment est limité aux 32 premières instructions qui définissent le boot
segment access area (respectivement le secure segment access area). C'est-à-dire qu’un
accès via une instruction de branchement (par exemple un « go to » ou un « call ») n’est
possible que dans le boot (secure) segment access area. La figure 8 montre la
segmentation de la mémoire programme dans le cas où le niveau de sécurité est élévé
pour les deux segments boot et secure.
Boot Segment Access Area
Boot Segment
Secure Segment Access Area
Secure Segment
General Segment
Figure 8: Organisation de la mémoire pour un niveau de sécurité élevée.

17
Prenons un exemple avec trois utilisateurs 1, 2 et 3 qui enregistrent respectivement leur

application dans le boot, secure et general segment. Dans le cas d’un niveau de sécurité élevée
pour le boot et le secure, si l’utilisateur 2 essaye d’accéder au boot segment (région après le
boot segment access area) alors il se produira un security reset. C'est-à-dire que l’instruction
ne va pas s’exécuter ainsi que les autres instructions qui viennent après l’instruction qui a
tenté un accès illégal à une partie sécurisé. La figure 9 résume les accès qui génèrent un
security reset.
Boot Segment Access Area
Boot Segment
Secure Segment Access Area
Secure Segment
General Segment
Figure 9 : les accès qui génèrent le security reset.
Niveau de sécurité standard: il n’y a pas de restrictions d’accès pour les autres
segments c'est-à-dire qu’on peut accéder au segment en entier. Dans ce cas il n’y a pas de
security reset et tout le segment est accessible comme le montre la figure 10.
Boot Segment Boot Segment
Secure Segment Secure Segment
General Segment General Segment
Figure 10 : Les accès autorisés dans le cas d’un niveau de sécurité standard.
18
Le tableau 3 résume les opérations possibles entre les différents segments en tenant compte du
niveau de sécurité choisi.
Opération vers
Exécution du code à Boot segment Secure segment General segment
partir du Niveau de Niveau de Niveau de sécurité
sécurité sécurité
Standard Elevé Standard Elevé Standard Elevé Aucun
Boot Standard L, E, B - L, E, B BR L, E, B B L, E, B
segment Elevé - L, E, B L, E, B BR L, E, B B L, E, B
Secure Standard B BR L, E, B - L, E, B B L, E, B
segment Elevé B BR - L, E, B L, E, B B L, E, B
General Standard B BR B BR L, E, B - -
segment Elevé B BR B BR - L, E, B -
Aucun B BR B BR - - L, E, B
Tableau 3 : Les opérations possibles entre les différents segments suivant le niveau de sécurité
choisi.
Légende :
L : lecture
E : écriture
B : branchement vers tout le segment
BR : branchement restreint aux 32 premières instructions
1. 4. Organisation de la mémoire programme

La figure 11 montre que la mémoire programme peut être divisée en trois segments dont la taille
est déterminée par des registres de configuration. L’emplacement de chaque segment reste le
même pour les deux niveaux de sécurité. Puisque le Boot Segment se trouve toujours après la
table de vecteur d’interruption, le secure segment s’il existe vient juste après le boot segment et le
general segment occupe l’espace juste après le secure segment s’il existe ou juste après le boot
segment (le general segment occupe l’espace restant dans la mémoire).
19
Figure 11: Organisation de la mémoire programme.
1. 5. Organisation de la mémoire de données

La mémoire RAM peut aussi être divisée en trois segments : boot, secure and general segment.
Ce partitionnement permet d’allouer une partie de la RAM pour chaque segment ; par exemple, le
boot segment data RAM (partie de la RAM allouée au boot segment) n‘est accessible que par le
boot segment et de même pour le secure segment. La figure 12 donne un aperçu sur la
segmentation de la RAM.
Figure 12: Organisation de la RAM.
20
La figure 13 montre les accès permis à partir de la mémoire programme vers la mémoire RAM si
cette dernière est segmentée.
Figure 13: Accès à la mémoire RAM à partir de la mémoire Flash.
Dans le cas de la figure 13, si par exemple l’utilisateur ayant enregistré son application dans le
general segment (mémoire programme) tente d’accéder au boot segment RAM. Sa demande
d’accès sera interdite via le contrôle effectué sur des registres de configurations qui seront étudiés
plus en détails dans la section suivante.
1. 6. Les registres de configurations

Pour pouvoir assurer et contrôler les fonctions de sécurité, il y a un certain nombre de registres
internes au microcontrôleur. Ces registres permettent la configuration du niveau de sécurité, du
type d’implémentation du CodeGuard Security, de la segmentation de la mémoire RAM…
Nous allons détailler dans la suite comment initialiser ces différents registres que voici cités ci-
dessous :
FBS : registre de configuration du boot segment.
FSS: registre de configuration du secure segment.
FGS: registre de configuration du general segment.
BSRAM : registre de configuration de la RAM pour le boot segment.
SSRAM : registre de configuration de la RAM pour le secure segment.
2. Allocation des segments

2. 1. Le boot segment
a. Présentation
C’est le segment le plus sécurisé, pour le créer et déterminer sa taille, on doit configurer les bits
BSS (2 :0) du registre FBS (3 :1) [8] qui est représenté par la figure 14.
21
Figure 14: Le registre FBS de configuration du boot segment.

Légende :
Case vide : bits non utilisés pour la configuration du boot segment
RBS: Boot Segment RAM Code Protection bits
BSS: Boot Segment Program Flash Code Protection bits
BWRP: Boot Segment Program Flash Write Protection bit
La taille de ce segment est déterminée par les trois bits du BSS ; en fait la taille du segment est
prédéfinie et on a le choix entre trois configurations. Ce choix dépend de l’application que
l’utilisateur veut enregistrer dans ce segment, le tableau 4 résume les différentes valeurs qui
peuvent être affectées au BSS suivant le niveau de sécurité choisi et la taille du segment.
BSS (2 :0) Niveau de Taille du boot Nombre de KO

sécurité segment du segment
x11 Pas de boot segment
110 Standard Faible 3
010 Elevé Faible 3
101 Standard Moyen 12
001 Elevé Moyen 12
100 Standard Large 24
000 élevé large 24
Tableau 4 : Les différentes combinaisons possibles pour les bits BSS (2 :0).
*KO : Kilos Octets
b. Choix du niveau de sécurité (voir paragraphe II. 1. 3)

Le niveau de sécurité du boot segment est déterminé par le troisième bit du FBS :
1 : niveau de sécurité standard
0 : niveau de sécurité élevé
c. Allocation de la RAM pour le boot segment

On peut allouer de la RAM pour le boot segment, c'est-à-dire que seulement ce dernier pourra y
accéder. Ceci permet de préserver l’intégrité des données résidant dans ce segment, par exemple,
si on stocke une clé de cryptage dans le boot segment, on peut effectuer le décryptage d’une
22
application dans le BSRAM (Boot Segment RAM). La configuration de cette dernière s’effectue
via le sixième et le septième bit du FBS nommés RBS.
La figure 15 montre que le boot segment RAM se situe à la fin de la mémoire RAM juste avant la
DMA.
Figure 15 : Emplacement du boot segment RAM dans la mémoire de donnée.
En ce qui concerne la taille de la RAM allouée pour le boot segment, il y a trois tailles prédéfinies
qui sont résumées dans le tableau 5 ainsi que la valeur des bits de configurations.
RBS Taille Taille (octets)

11 Pas de boot segment RAM
10 Petit 128
01 Moyen 256
00 Large 1024
Tableau 5 : Les différentes configurations du RBS pour le choix de la taille de la RAM.
d. Libération de la RAM réservé au boot segment

Quand toutes les instructions se trouvant dans le boot segment ont été exécutée et une
instruction se trouvant dans un segment de plus basse priorité (soit le secure ou le general
segment) va être exécutée. Alors il y aura libération de la partie de la RAM qui a été réservée pour
le boot segment pour un usage général. Et ceci s’effectue en configurant le registre BSRAM qui
se trouve dans le SFR (Special Function Register). Et l’organisation de ce registre est présentée
dans la figure 16.
23
Figure 16: Le registre BSRAM.
Le bit RL_BSRAM est mis à 1 lorsque l’exécution du code qui se trouve dans le boot segment est
terminé pour libérer la RAM réservée, et quand le code effectue un branchement au boot
segment, ce bit est remit à zéro pour réallouer la RAM pour ce segment.
Le deuxième bit du registre BSRAM ; IR_BSR est mis à 1 s’il y a eu un accès de lecture non
autorisé et sera remis à 0 lors d’un reset ou d’un accès autorisé.
Le bit IW_BSR est mis à 1 s’il y a eu une tentative d’écriture non autorisée et sera remis à 0 lors
d’un reset ou d’une tentative d’écriture autorisée.
2. 2. Le secure segment
a. Définition des caractéristiques de ce segment
C’est le segment qui se trouve juste après le boot segment et son accès est restreint au segment
dont le niveau de priorité est inferieur c'est-à-dire pour le general segment.
De même que le boot segment, ce segment est configuré via le registre FSS qui est représenté
dans la figure 17.
Figure 17: Registre de configuration FSS du secure segment.
Légende :
Case vide : bits non implémentés
RSS : Secure Segment RAM Code Protection bits
SSS: Secure Segment Program Flash Code Protection bits
SWRP: Secure Segment Program Flash Write Protection bit
Le tableau 6 montre que la taille de ce segment est, comme le boot segment, prédéfinie.
24
SSS (2 :0) Niveau de Taille du secure Nombre de KO

sécurité segment du segment
x11 Pas de boot segment
110 Standard Petite 24
010 Elevé Petite 24
101 Standard Moyen 48
001 Elevé Moyen 48
100 Standard Grande 96
000 élevé Grande 96
Tableau 6: Valeur du SSS suivant la taille et le niveau de sécurité du secure segment.
*KO : Kilos Octets
b. Choix du niveau de sécurité (voir paragraphe II. 1. 3)

Le niveau de sécurité du boot segment est déterminé par le troisième bit du FSS :
1 : niveau de sécurité standard
0 : niveau de sécurité élevé
c. Allocation de la RAM pour le secure segment

De même pour le secure segment, on peut allouer à ce segment une partie de la RAM, comme le
montre la figure 18; le secure segment data RAM qui n’est accessible que par le secure segment.
Figure 18: Emplacement du secure segment RAM dans la mémoire.
25
La configuration de la RAM s’effectue via le sixième et le septième bit du FSS nommés RSS. Et
pour le choix de la taille de ce segment, il y a trois tailles prédéfinies qui sont listées dans le
tableau 7.
RSS Size Taille (octets)

11 Pas de boot segment
10 Petit 128
01 Moyen 256
00 Large 1024
Tableau 7: Détermination de la taille de la RAM
d. Libération de la RAM réservée au secure segment

Comme pour le boot segment, la libération de la SSRAM est possible pour un usage général après
l’exécution de l’algorithme qui se trouve dans le secure segment. Et ceci s’effectue par la
configuration du registre SSRAM qui est représenté par la figure 19.
Figure 19: Le registre SSRAM.
Le tableau 8 décrit les valeurs possibles du SSRAM pour différentes configurations.
Prend la valeur
1 0
IW_SSR Pas de tentative d’écriture Tentative d’écriture illégale
illégale ou un reset a été effectué
IR_SSR Pas d’accès de lecture non Accès de lecture non autorisé
autorisé
Libération du secure segment Le secure segment RAM est
RL_SSR RAM pour un usage général réservé pour le secure
segment
Tableau 8: Description des combinaisons de valeurs que peut prendre le registre SSRAM
2. 3. Le general segment
C’est le dernier segment qui est accessible par les autres segments sans aucune restriction, et sa
taille est la partie de la mémoire flash qui reste c'est-à-dire la taille de la mémoire flash moins la
26
taille du boot et secure segment. Ce segment existe toujours sans tenir compte de l’existence des
deux autres segments et il se trouve juste après le secure segment, si ce dernier existe.
Et sa configuration s’effectue via le registre FGS représenté par la figure 20.
Figure 20: Le registre FGS.
Légende:
GSS: General Segment Program Flash Code Protection bits
GWRP: General Segment Program Flash Write Protection bit
Le general segment possède la protection en écriture c'est-à-dire qu’il ne peut pas être modifié et
pour activer cette option, on doit mettre le bit GWRP ou FBS(0) à 0. Dans le cas contraire,
quand le FBS(0) prend la valeur 1, le general segment peut être écrit.
En ce qui concerne la mémoire de données, le general segment data RAM est accessible par les
trois segments, comme on peut le voir sur la figure 13.
Après l’étude du concept du CodeGuard Security, le choix du microcontrôleur s’impose selon le
type d’implémentation qui va être choisi et selon les caractéristiques de ce dernier.
3. Choix du composant
Pour implémenter le CodeGuard Security, le choix entre quatre composants se présente et qui
sont le PIC24F [9], PIC24H [10], dsPIC30F [11] ou le dsPIC33F [12]. Pour pouvoir prendre une
décision sur le choix du composant, on va se baser sur un certains nombres de critères qui sont
résumés dans le tableau 9.
Vitesse du Type
Flash (KO) RAM (KO) CPU d’implémentation Prix
(MIPS) du CodeGuard
PIC24F 128 8 16 Basic $5.02
PIC24H 256 16 40 Advanced $7.16
dsPIC30F* 144 8 30 Advanced $8.31
dsPIC33F 256 30 40 Advanced $7.66
Tableau 9: Choix du microcontrôleur.
*Le dsPIC30F60
Tous les composants décrit dans le tableau suivant ont un package de 100 pins à part le dspic30 qui
possède 80 pins.
27
On va déjà éliminer le PIC24F puisqu’il ne peut supporter que l’implémentation basique c'est-à-
dire celle qui ne contient qu’un seul segment (le general segment) et cette configuration ne nous
intéresse pas pour notre application.
On ne va pas non plus choisir le dspic30F vu son prix élevé et sa faible taille de la mémoire Flash.
Il nous reste à choisir entre le pic24H et le dspic33F qui supportent l’implémentation advanced
du CodeGuard, notre choix va se tourner vers le dspic33F car il possède une taille de RAM
supérieure, en plus il possède une unité arithmétique et logique pour le traitement du signal ce qui
lui confère une rapidité de calcul supérieur à celle du PIC24H.
4. Caractéristiques des dsPIC

Les dsPIC sont des microcontrôleurs 16 bits rapides avec des fonctionalités de DSP (Digital
Signal Processor) convenant ainsi à de nombreuses applications de traitement du signal.
4. 1. Architecture Harvard
Les dsPIC ont une architecture harvard avec des bus programme et données séparés. Cette
architecture autorise des tailles de bus différentes : soit 16 bits pour les données et 24 bits pour
les instructions comme le montre la figure 21.
Figure 21: Architecture de harvard du dsPIC33F.
Cette organisation permet aussi de réduire considérablement les temps d'exécution car, pendant
que le processeur lit la prochaine instruction dans la mémoire programme, il exécute l'actuelle qui
manipule des données en RAM.
4. 2. Mémoire programme
Elle est organisée [12] [13] de la manière suivante :
Les vecteurs d'interruption se placent au début de la mémoire programme juste après
l’instruction de reset.
Le code du programme de l'application est programmé à partir de l'adresse 0x000200.
28
Les derniers emplacements mémorisent différents numéros d'identification (types et

versions du dsPIC), ainsi que certains bits de configuration nécessaire pour le reset du
microcontrôleur (par exemple le choix de l'horloge, validation ou inhibition de certaines
fonctions).
La figure 22 montres les différentes parties de la mémoire programme définies dans le paragraphe
précédent.
Figure 22: Organisation de la mémoire programme.
4. 3. Mémoire RAM
Elle est représentée par la figure 23. L'espace adressable est de 30K octets. Elle est divisée en
plusieurs blocs [12] :
SFR (Special Function Register): ce bloc de 2Ko regroupe les registres du CPU (Central
Process Unit) (travail, état et pointeur de pile) et les registres de configuration des
périphériques
X RAM et Y RAM: ces deux blocs sont contigus ; le CPU y lit et écrit de façon classique
mais le module DSP peut accéder simultanément aux deux blocs en un seul cycle pour
effectuer les opérations de type MAC (Multiply And Accumulate)
29
Le dernier bloc de 32Koctets n'est pas implanté et on peut y stocké des données ; cela
permet au CPU d'accéder à des tableaux de constantes comme il le fait avec des variables
en RAM.
Figure 23: Organisation de la mémoire RAM.
Pour plus de détails sur le dsPIC33F se référer à l’annexe A.
4. 4. Présentation de la carte
La figure 24 présente la carte explorer 16 [14] que nous allons utiliser pour la mise en œuvre du
CodeGuard. Pour plus de détails sur les différents composants, se référer à l’annexe B.
Figure 24: La carte explorer 16.
30
5. Résultats d’implémentation
Le travail de développement a été effectué sur l’outil MPLAB IDE v7.60 [15] qui supporte le
langage ANSI C avec des instructions en plus spécifiques au microcontrôleur (compilateur
MPLAB C30 [16]) et le langage assembleur (MPASM [17]).
MPLAB ICD2 (In Circuit Debugger 2) [18] permet la programmation et le debbugage sur le
dsPIC via l’interface de MPLAB IDE. Ce dernier est connecté (figure 25) au PC via une interface
USB ou RS-232 et est connecté à la carte via une interface RJ-11.
Figure 25: Connexion du MPLAB ICD2 à la carte et au PC.
5. 1. Description d’un scénario entre trois utilisateurs

Pour mettre en évidence le CodeGuard Security, nous allons imaginer un scenario avec trois
utilisateurs et chacun d’eux va enregistrer au fur et à mesure son application dans un des trois
segments. La figure 26 nous permet de mieux imaginer ce scénario.
Figure 26: Scenario avec trois utilisateurs.
Dans cet exemple, on va implémenter le CodeGuard Security avec un niveau de sécurité élevé
(high security) et les spécifications des trois segments sont listées dans le tableau 10.
31
Niveau de sécurité Taille flash Taille RAM

Boot segment Elevé Large Large
Secure segment Elevé Petite Petite
General segment Standard Le reste Le reste
Tableau 10: Type de configuration des trois segments.
Le reste= taille mémoire totale du composant-(taille mémoire (boot + secure))
Dans le boot segment, le premier utilisateur va enregistrer son code. Les utilisateurs 2 et 3 vont
respectivement enregistrer leurs applications dans le secure et le general segment. Et ces deux
derniers ne pourront accéder qu’au boot segment access area (c'est-à-dire aux 32 premières
instructions) et l’utilisateur 3 pourra accéder aussi au secure segment access area.
La figure 27 nous montre les accès permis en utilisant les spécifications décrites dans le tableau
10.
Figure 27: Les accès autorisés entre les différents segments.
La figure 28 montre comment se déroule le scénario avec trois utilisateurs.
32
Figure 28: Déroulement du scénario avec trois personnes.
Pour mieux comprendre, on va détailler les documents que doit fournir un utilisateur à un autre.
L’utilisateur 1 :
Il doit fournir à l’utilisateur 2 le fichier d’édition des liens et un fichier assembleur dans lequel il y
a les adresses des fonctions qui se trouvent dans le boot segment access area ainsi que bien sûr le
microcontrôleur programmé.
Dans le linker script l’utilisateur doit définir les champs suivant :
Les différentes régions de la mémoire programme et de donnée
L’emplacement de certains registres de configuration
L’adresse de début de la table des vecteurs d’interruption
L’adresse de début de l’aivt (Alternate Interrupt Vector Table) des sections qui se
trouvent dans la mémoire de donnée
Emplacement du programme qui se trouve dans le main
L’adresse de début de chaque segment
Réservation de l’espace mémoire dans la flash pour chaque segment (allocation de la
mémoire)
Réservation de l’espace mémoire pour les registres de configurations de l’oscillateur
33
Réservation de la RAM pour Mplab ICD2 (à partir de l’adresse 0x800)

Information utile pour le débogage
Définition de la table des vecteurs d’interruption
Definition de l’Alternate Interrupt Vector Table
Déterminer l’emplacement des SFR (Special Function Register) c'est-à-dire qu’on va
donner l’adresse mémoire de chaque registre comme décrit ci-dessous
Pour plus de détails sur ce fichier, voir l’annexe C.
L’utilisateur 2 :
Il doit fournir à l’utilisateur 3 le linker script ainsi que les adresses des fonctions qui se trouvent
dans le secure segment access area.
Si cet utilisateur tente d’accéder au boot segment, un security reset sera établi et qui consiste en la
non exécution du code et en un changement de la valeur du registre RCON (qui se trouve à
l’adresse 740 dans la mémoire RAM). Le tableau 11 résume les valeurs que peut prendre le
registre RCON.
Accès autorisé Accès non autorisé
Valeur de RCON 83h 4083h
Tableau 11: Valeur du registre RCON.
Plus généralement, la figure 29 montre les accès qui vont générés le security reset.
Figure 29: Les accès qui génèrent le security reset.
L’exemple qui suit va mettre en évidence le security reset, on prendra le cas où l’utilisateur 3
accède au boot segment de l’utilisateur 1. La figure 30 montre bien que l’utilisateur a bien
configuré son segment avec un niveau de sécurité élevé.
34
Figure 30: Configuration du niveau de sécurité du boot segment.
Puis dans la figure 31, on aperçoit que la valeur du registre RCON prend la valeur de 4083h et
bien sûr, on ne peut pas le distinguer sur cette figure, l’appel de la fonction qui se trouve dans ce
segment n’aura pas lieu.
Figure 31: Security reset.
Par contre si l’utilisateur 3 accède à la zone autorisé c'est-à-dire au boot access area (les 32
premières instructions) de l’utilisateur 1 donc il n’y aura pas de security reset et l’exécution de
l’appel de la fonction résidant dans cette partie sera effectuée. La figure 32 nous donne la valeur
du registre RCON qui est à 83h.
35
Figure 32: Valeur du registre RCON pour un accès autorisé.
Le tableau 12 présente différents tests, concernant l’implémentation du CodeGuard, effectués sur

la carte.
36
Description Niveau de sécurité Résultats
Test 1 Définition dans le boot de plusieurs procédures

dans le boot secure access area (ne dépassant pa s Boot segment : Elevé Exécution du code
les 32 instructions).
Tableau 12: Exemples de quelques tests effectués sur la carte.

Appel de ces procédures dans le secure segment.
Test 2 Définition dans le boot de plusieurs fonctions

(avec paramètres en entrées et en sortie) dans le
boot secure access area. Boot segment : Elevé Exécution du code
Appel de ces fonctions dans le secure segment.
37
Test 3 Définition dans le boot de plusieurs fonctions
(avec paramètres en entrées et en sortie) dans le Exécution seulement des fonctions
boot secure access area et définition d’une Boot segment : Elevé qui se trouvent le boot access area
fonction hors du boot access area.
Appel de ces fonctions dans le secure segment.
Test 4 Détermination du boot segment avec un niveau de La tentative échoue, on ne peut

sécurité high. Boot segment : Elevé pas changer le niveau de sécurité
Tentative de changement du niveau de sécurité du d’un segment qui a été programmé
boot segment par l’utilisateur 2.
5. 2. Inconvénients du CodeGuard Security

L’inconvénient du CodeGuard Security est que c’est une solution figée :
Le nombre de segments qui peut exister dans la mémoire programme est limité à trois.
La taille des segments est fixe puisqu’elle est prédéfinie ; on a seulement le choix entre
trois tailles (petit, moyen et large).
Dans une configuration avec trois utilisateurs (1, 2 et 3) ; l’utilisateur 1 enregistre son
application dans le boot segment avec un niveau de sécurité élevé. Il veut donner un
résultat à l’utilisateur 2 seulement sans que l’utilisateur 3 n’accède à l’information. Ceci
n’est pas possible dans le concept de CodeGuard de Microchip.
6. Conclusion
Dans ce chapitre, nous avons répondu à la problématique de l’entreprise SAFT en proposant une
solution de sécurisation hardware sur des microcontrôleurs. Dans la première partie de ce
chapitre, le principe de CodeGuard a été défini. Puis les méthodes de configuration de ce dernier
ont été décrites. Des exemples d’implémentation ont été présentés et à la fin de ce chapitre, les
inconvénients d’une telle architecture ont été cités.
Pour répondre aux inconvénients du CodeGuard et aux performances limitées des
microcontrôleurs ; nous allons dans le chapitre suivant, proposer d’autres solutions de protection
de l’IP sur FPGA.
38
Chapitre III
Système matériel reconfigurable sécurisé
Les progrès des technologies de conception et des architectures permettent d’implémenter de très grands
circuits sur FPGA. De nos jours, les FPGA peuvent implémenter des designs comportant des millions de
portes logiques et blocs mémoire de taille moyenne. De plus, des FPGA comprenant des microcontrôleurs,
implémentés directement dans le silicium ou dans leurs ressources disponibles. Les FPGA et les
Configurable System on Chip (CSoC) des entreprises comme Xilinx, Altera ou Actel sont devenus de
vraies plate-formes d’implémentation de systèmes entiers.
La tendance à implémenter des systèmes entiers sur FPGA a crée un besoin de protection des données
contenus dans ces derniers. Assurer la protection d’un FPGA revient à protéger le fichier de configuration.
Nous verrons dans ce chapitre diverses technologies utilisées pour assurer la protection de ce fichier.
Ce chapitre sera basé sur l’étude des solutions de sécurisation pour le matériel reconfigurable. En première
partie, les failles de sécurité dans les FPGA SRAM et Flash vont être étudiées. La deuxième partie de ce
chapitre, présente les solutions qui se trouvent sur le marché et plus précisément celles proposées par Actel,
Xilinx et Altera. Puis les résultats d’implémentations sur les trois cartes des constructeurs définis
précédemment seront presentés.
39
Chapitre III-Système matériel reconfigurable sécurisé
1. Problème de protection du bitstream pour FPGA

SRAM et Flash
Le bitstream [7] est le fichier qui permet de configurer un FPGA dont le flot de conception est
représenté par la figure 33.
Fichier VHDL
Synthèse
Netlist
Placement et
FPGA routage
Bitstream
Génération du Configuration du FPGA

bitstream
Figure 33: Flot de conception d’un FPGA: du VHDL au bitstream.
La figure 33, décrit les étapes de génération du fichier de configuration ; la synthèse est une étape
qui permet de convertir le fichier VHDL en un circuit d’éléments logiques représenté sous forme
de netlist (fichier EDIF). La deuxième étape est le placement et routage, cette opération permet
d’instancier dans le FPGA tous les composants décrits dans la netlist ainsi que leur
interconnexion. La dernière étape est la génération du bitstream; le résultat du placement et
routage est converti en binaire de façon à pouvoir configurer le FPGA.
Pour les FPGA SRAM, le fichier de configuration est programmé dans une mémoire externe non
volatile, ce dernier devra être chargé à chaque mise sous tension dans une mémoire volatile
interne au FPGA.
Par contre le problème de transfert du bitstream d’une mémoire externe non volatile vers la
mémoire de configuration ne se pose pas pour les FPGA Flash. Puisque ces derniers ont une
mémoire non volatile intégré. Cependant ce problème existe pour les mises à jour à distances.
Pour remédier à ce problème, le fichier de configuration doit être crypté. Sans oublier que la
mémoire Flash doit être protégée en lecture et écriture. Nous étudierons plus en détails ce type de
FPGA dans ce chapitre.
40
2. Les FPGA SRAM
2. 1. Problème de protection du bitstream

Les FPGA SRAM perdent leur configuration quand ils sont mis hors tension, c’est pour cela qu’il
faut une mémoire externe non volatile de type EEPROM ou Flash pour permettre le stockage de
la configuration du FPGA et de le charger à chaque mise sous tension avec un fichier de
configuration. Mais l’inconvénient d’un tel échange est qu’il augmente les failles de sécurité.
Effectivement, le fichier de configuration peut facilement être copié à chaque mise sous tension
du FPGA. Pour répondre à cette lacune, le bitstream peut être protégé en utilisant la
cryptographie comme le montre la figure 34. Cette dernière décrit les étapes de transfert sécurisé
du bitstream: une clé de sécurité est stockée de manière permanente dans le FPGA SRAM.
L’outil de CAO chiffre le bitstream en utilisant la même clé (enregistré dans le FPGA) et produit
le bitstream chiffré qui le stocke dans une mémoire non-volatile externe. Ce dernier est chargé
dans le FPGA et déchiffré en utilisant la clé de sécurité.
Figure 34: Transfert du fichier de configuration dans un FPGA SRAM.
Nous allons étudier deux exemples de protection du bitstream pour ce type de FPGA à savoir la
solution de la société Xilinx et Altera.
2. 2. La solution de Xilinx
Pour garantir la sécurité des FPGA, Xilinx propose d’utiliser sur les Virtex 4 [19] le cryptage
symétrique AES (chiffrement de blocs de 128 bits avec une clé de 256 bits) [20]. Les Virtex ont
un bloc de décryptage intégré qui permet le décryptage du bitstream. Le cryptage se fait par le
logiciel de Xilinx (ISE). La clé de décryptage est stockée dans une mémoire volatile soutenue par
une batterie. La figure 35 permet de mieux comprendre cette procédure.
41
Figure 35 : La solution de Xilinx pour un Virtex 4.
La clé est stockée dans le FPGA via l’interface JTAG, puis le fichier de configuration sera généré
et crypté avec la même clé enregistrée dans le FPGA. Le fichier de configuration sera programmé
dans une mémoire externe, le décryptage de ce dernier sera effectué dans le FPGA.
Cette structure ne présente pas que des avantages, au contraire, elle possède un certains nombres
d’inconvénients : la batterie prend de la place sur la carte, sa durée de vie est limitée et elle
augmente le coût du composant. Dans cette même optique, nous allons étudier les FPGA Stratix
III d’Altera qui ont une petite variante par rapport aux Virtex que nous venons de voir ; c’est
qu’ils permettent de stocker la clé d’une manière volatile ou non (la batterie est optionnel selon le
choix de stockage de la clé).
2. 3. La solution d’Altera
La solution proposée par Altera, pour les Stratix III [21], utilise l’algorithme de cryptage avancé
AES et une clé de 256 bits et convient parfaitement aux applications nécessitant un haut niveau
de protection. Avant de recevoir le fichier de configuration crypté, l’utilisateur défini et stocke
une clé dans le FPGA qui permettra le décryptage. Les FPGA Stratix permettent de stocker la clé
de deux manières possibles ; soit d’une manière non volatile c'est-à-dire que la clé dans ce cas doit
être supportée par une batterie. Soit d’une manière non volatile (ne nécessite pas de batterie
externe) la clé est enregistrée dans une petite mémoire Flash interne.
La figure 36 explique les étapes de transfert du bitstream de la mémoire externe non volatile vers
la mémoire interne (SRAM) du FPGA. Nous allons décrire les étapes de cryptage/décryptage du
bitstream. Une clé AES définie par l’utilisateur peut être programmée dans le Stratix III (nous
prendrons le cas où la clé sera stockée d’une manière non volatile). Cette même clé est utilisée par
le logiciel de conception Quartus II pour générer un fichier de configuration crypté qui sera
stocké dans une mémoire externe. Lors de la mise sous tension, la mémoire transfert le fichier de
configuration crypté vers le FPGA qui utilise la clé stockée pour décrypter le fichier et s’auto-
configurer.
42
Figure 36: Cryptage/décryptage du bitstream pour un FPGA Stratix III.
Après l’étude théorique des FPGA SRAM et du problème de transfert du bitstream qui doit être
crypté lors de la mise sous tension. Nous allons étudier les FPGA Flash pour les quelles le
problème de protection du fichier de configuration existe mais sous une autre forme.
3. Les FPGA Flash

3. 1. Problème de protection du bitstream
La Flash est une mémoire non volatile donc il n’y a pas d’échange de bitstream avec un FPGA et
un autre composant. Mais ceci n’empêche pas qu’une attaque soit possible, car nous pouvons lire
le contenu de la mémoire Flash, c’est pour cela qu’il faut protéger cette mémoire en lecture pour
protéger la conception du système contre la copie.
Le problème de transfert du bitstream pour ce type de FPGA apparait lors des mises à jour à
distance. Si le fichier de configuration n’est pas crypté, une tierce personne peut intercepter ce
fichier comme le montre la figure 37.
Figure 37: Interception du fichier de configuration lors des mises à jour.
43
La figure 37 met l’accent sur la nécessité de crypter le bitstream lors des mises à jour effectuées à
distance. Sans oublier que la mémoire Flash doit être protégée en lecture et écriture pour
empêcher la lecture ou l’altération du fichier de configuration. Pour répondre à ces deux
problèmes, une solution est disponible sur le marché et elle a été proposée par ACTEL en
commercialisant les FPGA fusion, que nous allons étudier plus en détails dans le paragraphe
suivant.
3. 2. ACTEL fusion
Les FPGA fusion [22], produit par ACTEL, permettent de traiter les signaux numériques et
analogiques, et sont constitués essentiellement de trois éléments qui sont la Flash, FBs (Flash
Memory Blocks) et le core du FPGA. Chacune de ses trois parties peut être programmée
indépendamment avec un fichier de configuration. Et ce dernier peut être crypté avec AES (128
bits) ou non.
La solution d’ACTEL [23] permet de crypter le fichier de configuration avec l’algorithme AES et
de protéger le FPGA en lecture (Flashlock) c'est-à-dire qu’on ne peut pas accéder au FPGA sans
la bonne clé. La figure 38 montre comment le bitstream est crypté et décrypté.
Figure 38: Cryptage/décryptage du bitstream.
Dans la figure 38, le circuit de décryptage est représenté ainsi que le block MAC (Message
Authentication Control) qui vérifie si dans le fichier de configuration, il y a la bonne clé de
cryptage. Le cryptage/décryptage présenté précédemment permet la protection du fichier de
configuration lors des mises à jour à distance, et pour protéger l’accès en lecture et écriture au
FPGA, une technologie de contrôle d’accès est utilisée : le Flashlock. Elle utilise une clé de 128
bits pour protéger la mémoire Flash en lecture et écriture et permet aussi de protéger la clé de
44
l’algorithme de cryptage. En d’autres termes, le Flashlock est comme un mot de passe qui permet
d’identifier l’utilisateur.
Les FPGA fusion permettent d’utiliser deux technologies pour protéger le fichier de
configuration et le choix dépend de l’action qui sera établie. Les différents niveaux de sécurité
possibles sont listés dans le tableau 13.
Niveau de sécurité
Mise à jour FPGA programmé
Pas de Flashlock et pas nul nul
d’AES
Flashlock nul élevé
Cryptage avec AES et élevé élevé
Flashlock
Tableau 13 : Les niveaux de sécurité possibles avec le FPGA fusion.
Pour chacun de ces niveaux de sécurité, on peut imaginer trois scenarios qui sont résumés par la
figure 39. Puisque le choix du niveau de sécurité dépend du lieu dans lequel il y aura le transfert
du bitstream.
Figure 39: Trois scenarios de cryptage/décryptage du bitstream.
45
1 : Le premier scenario se déroule dans un environnement de confiance comme par

exemple au sein d’une même entreprise donc il n’est pas nécessaire de crypter le fichier de
configuration.
2 : Le deuxième scénario nous montre que la programmation se déroule dans un lieu
différent du lieu de fabrication. C'est-à-dire que la programmation du FPGA se fait dans
un lieu externe par un sous-traitant, par exemple (figure 40).
3 : La programmation du FPGA se fait à distance (des mises à jours sont faites à
distance). Le fichier de configuration sera envoyé via un réseau donc ce dernier sera
crypté (AES) avec la même clé qui se trouve sur le FPGA pour éviter qu’il soit intercepté
par un tiers.
Figure 40 : Exemple de programmation du FPGA dans un environnement extérieur.
Dans cette partie, nous avons étudié les FPGA Flash en nous basant sur les FPGA fusion
d’ACTEL et nous avons décrit le problème de protection du bitstream pour ce type de FPGA.
Nous avons vu qu’il fallait crypter le fichier de configuration lors des mises à jour à distances et
qu’il fallait protéger la mémoire Flash en lecture et écriture.
Après l’étude théorique des deux familles de FPGA à savoir les FPGA SRAM et Flash, nous
allons effectuer des tests pour pouvoir déterminer la taille du fichier de configuration crypté ou
non.
46
4. Résultats
4. 1. FPGA d’ACTEL
Des tests sur le AFS 600 avec un programme simple ont été effectués pour des niveaux différents
de sécurités, et ceci dans le but de déterminer la taille du fichier de configuration :
Sans niveaux de sécurité : x kOctets
Avec un niveau de sécurité moyen (Flashlock) : y = x + 5 kOctets
Avec un niveau de sécurité élevé (Flashlock + AES) : y + 1 kOctets
4. 2. FPGA de Xilinx
Les tests ont été effectués sur un Virtex 4 dans le but de déterminer la variation de la taille du
fichier de configuration avec ou sans cryptographie.
Sans AES : x kOctets
Avec AES : x+2 kOctets
5. Conclusion
Dans ce chapitre, nous avons étudié les solutions de protection de données sur FPGA, même si
ca ne répond qu’en partie à la problématique de l’entreprise SAFT puisque, comme nous l’avons
présenté dans le cahier de charges (cf. premier chapitre), n’impose pas des contraintes de rapidité
de calculs. Le but de cette étude est de trouver une nouvelle solution de protection de données
qui répond aux contraintes actuelles et qui soit sûr. Nous avons abouti à la conclusion suivante :
implémenter le concept de CodeGuard Security sur FPGA, en répondant bien sûr aux
inconvénients de ce dernier. La solution qui sera développée durant le mois de juillet sera une
solution reconfigurable ; elle ne sera pas figée comme celle proposée par Microchip. Le nombre
d’utilisateurs ne sera pas limité à trois et le choix de la taille des segments sera choisi et non
imposé. L’établissement du cahier de charge de cette solution sera établi dans la conclusion dans
la partie perspectives.
47
Conclusions et perspectives
Conclusions
Dans le cadre de ce projet de fin d’étude, nous nous sommes intéressés aux solutions de
protection matérielle de la propriété intellectuelle dans le cadre d’un projet pour l’entreprise
SAFT. Nous avons dans ce document répondu à la problématique présentée dans le premier
chapitre. Dans un premier temps, nous avons étudié diverses solutions de protection de la
propriété intellectuelle, puis nous avons optés pour les solutions matérielles sur microcontrôleurs
et FPGA.
Nous avons étudié la solution sur des microcontrôleurs 16 bits de Microchip à savoir le
CodeGuard Security que nous avons mis en œuvre sur dsPIC33F. Puis après l’avoir mis en
application sur la cible via MPLAB IDE et effectué un ensemble de tests simulant plusieurs
scénarios, nous avons effectué une formation pour SAFT sur le concept du CodeGuard Security
et sur sa mise en œuvre. Un document de type tutorial doit être livrer à la société.
Dans le troisième et dernier chapitre, nous avons étudié les solutions sur des systèmes
reconfigurables car nous cherchions une solution flexible, qui réponde aux attentes actuelles et
future. Nous avons étudié les solutions de protection des FPGA SRAM et Flash en particulier
celles proposées par Actel (Flash), Xilinx et Altera(SRAM).
Néanmoins les deux solutions proposées dans ce document, même si elles répondent à la
problématique de l’entreprise SAFT, présentent chacune des inconvénients et des avantages
propres à chaque solution. Le concept de CodeGuard est une solution simple qui ne consomme
pas beaucoup de ressources mais figée, les solutions sur FPGA sont reconfigurables mais
consomment beaucoup de ressources (au moment du décryptage). Pour remédier à ces
inconvénients, nous allons proposer une solution mixte : implémenter le concept de CodeGuard
sur FPGA. Ainsi nous aurons répondu au problème de rapidité de calcul, de consommation de
ressources et la solution n’est plus figée.
48
Déroulement du travail
Perspectives
Nous implémentons actuellement un système de protection des IPs pour un système embarqué
avec des contrôles de privilèges d’accès. Nous nous sommes inspirés du concept de Microchip :
CodeGuard pour la segmentation de la mémoire et nous avons répondu aux inconvénients de ce
dernier à savoir le nombre limité d’utilisateurs et les niveaux de sécurité limité aussi (deux niveaux
de sécurité).
Notre système répondra aux attentes présentes et futur en termes de rapidité de calculs, il
permettra à n utilisateurs d’enregistrer leurs applications dans un même composant (n est limité
par la taille de la mémoire), ce système sera doté d’au moins quatre niveaux de sécurité (accès en
lecture, en lecture/écriture, en lecture aux 32 premières instructions, non accéssibles).
49
Nous implémenterions ce système sur MicroBlaze (voir annexe D), processeur softcore de Xilinx.
L’architecture que nous proposons pour le moment est la suivante:
Registre Segment 1
Registre Segment 2
Registre Segment n
Lecture de
l’instruction sur Opération de
le bus d’addresse Z-1 Unité de Contrôle
de la mémoire Opération vers
programme
Reset
Mémoire programme
Architecture proposée.
Nous allons définir le cahier des charges de cette application et commencer l’implémentation de
cette solution après avoir approfondi notre étude durant le mois de Juillet.
50
Annexe
51
Annexe A
Architecture du dsPIC33F
Figure : Architecture du dsPIC33F.
52
Annexe A : Architecture du dsPIC33F
On va énumérer très rapidement, les différents périphériques du dsPIC33F qui sont représentés
par la figure précédente :
ALU (Unité Arithmétique et Logique):16 bits
Les registres de travail (16 bits) : Ce sont des registres lié à l’ALU et qui reçoivent par le bus de
données les informations issues des blocs de registres ou des entrées/sorties.
AGU (Adress Generation Unit): génère des adresses sur 16 bits, il y a deux modules.
DSP : Il est composé de deux accumulateurs de 40 bits, un multiplieur de 17 bits et un
Barrel Shifter de 40 bits. Ce qui lui permet d’effectuer des opérations MAC en un seul
cycle.
La figure suivante nous montre la composition du DSP et nous éclair par suite sur son
fonctionnement.
Périphériques
ADC (Analog to Digital Converter): Il y a deux modules qui peuvent avoir une résolution
de 10 ou 12 bits.
Watchdog: Il peut être assimilé à un mécanisme qui va surveiller si le programme
s’exécute toujours dans de bonnes conditions, dans le cas contraire ce processus va
effectuer un reset du microcontrôleur.
53
Les timers : Leur nombre peut aller jusqu’à neuf, le timer 0 est toujours présent (il peut se
nommer RTCC pour horloge temps réel). Chaque timer peut générer une interruption et
fonctionne de façon très différente.
Output Compare: permet de générer des signaux type PWM.
Input Capture: permet de recevoir les signaux de type PWM et de sauvegarder la valeur
d’un timer lors d’une action sur une broche. Il joue le rôle d’une horloge interne
différente de l’horloge système
Périphériques de communication série
UART (Universal Asynchronous Receiver Transmitter): permet les communications
séries asynchrones. Il communique avec le microprocesseur par l’intermédiaire du bus de
données et en série avec l’extérieur par une liaison série asynchrone (sans horloge).
SPI (Sérial Peripheral Interface): Ce type de communication est généralement réservé à
l’échange de données entre deux circuits intégrés sur un même circuit imprimé. C’est le
maitre qui cadence l’échange avec son horloge.
I2C (Inter-Integrated Circuit): Les communications utilisent deux fils (SCL et SDA pour
horloge et données), l’horloge est unique (donc synchrone) et générée par un maitre. Les
données transitent sur un seul fil en émission et en réception.
Controller Area Network (CAN): interface série permettant de communiquer avec
d’autres CAN ou microcontrôleur.
Data Converter Interface module (DCI): permet par exemple l’interfaçage avec des
codeur/décodeur audio.
Périphériques (utilisation d’un moteur)
Motor Control PWM module: permet de commander un moteur.
Quadrature Encoder Interface module: nous renseigne sur le mouvement (vitesse) du
moteur.
Les entrées/sorties
Chaque E/S possède trois registres
Data Direction Register: permet de déterminer si les pins associées à un port jouent le
rôle d’une entrée ou sortie.
Port Register:
En mode écriture, il affecte la valeur à la bascule.
En mode lecture, il permet de lire la valeur de l’E/S.
Data Latch Register:
En mode écriture, il affecte la valeur à la bascule.
54
En mode lecture, il lit la valeur se trouvant dans la bascule.

Le Jeu d’Instruction
Il est composé de 84 instructions (24 bits). Elles sont en majorité exécutées en un seul cycle à
l’exception de:
Les instructions de division (18 cycles)
Les instructions de branchement (2 cycles)
Il est composé de :
MOVE instructions
MATH instructions
LOGIC instructions
SHIFT / ROTATE instructions
BIT instructions
COMPARE instructions
STACK instructions
PROGRAM FLOW instructions
CONTROL instructions
DSP instructions (accumulateur
Le tableau résume quelques spécifications du dsPIC33F.
dsPIC33F J256GP710
Taille Flash (KO) 256
Taille RAM (KO) 30
16-bits timers 9
Input capture 8
Output compare 8
Codec Interface 1
ADC 2
UART 2
SPI 2
I2C 2
Enhanced CAN 2
I/O pins 85
pins 100
55
Annexe B
La carte explorer 16
Légende :
1. Bouton reset
2. Port RJ-11
3. Sélecteur PIC/PIM (PIC : si on change de microcontrôleur, PIM : si on garde toujours le
PIC24F).
4. Port USB
5. PIC18F
56
Annexe B : La carte explorer 16
6. Port RS 232 qui permet de relier le MPLAB ICD2

7. LED témoin d’alimentation
8. Entrée de l’alimentation (9 V)
9. Œillets de connexion
10. Bouton poussoir
11. Huit LEDs (configurable par port)
12. Port JTAG
13. Bus d’extension permettant de raccorder un PICtail plus
14. Bus d’extension permettant de raccorder un PICtail plus
15. Oscillateur indépendant
16. Pins permet de raccorder un programmeur PICkit 2
17. Permet de raccorder un PICtail plus
18. Permet de raccorder un dsPIC33F ou PIC24F
19. Zone de prototypage
20. LCD à deux lignes de 16 caractères chacune
21. Potentiomètre qui permet de régler l’entrée analogique
22. Permet de raccorder un autre LCD.
57
Annexe C
Le Fichier d’édition des liens (fichier .gld)
OUTPUT_ARCH("33FJ256GP710")
EXTERN(__resetPRI)
EXTERN(__resetALT)
Définition des différentes régions de la mémoire et ceci permet d’informer le linker l’état
de la mémoire est disponible dans le composant
MEMORY
{
data (a!xr) : ORIGIN = 0x800, LENGTH = 0x7800
reset : ORIGIN = 0x0, LENGTH = 0x4
ivt : ORIGIN = 0x4, LENGTH = 0xFC
aivt : ORIGIN = 0x104, LENGTH = 0xFC
program (xr) : ORIGIN = 0x200, LENGTH = 0x2AA00
Emplacement de certains registres de configuration

CONFIG1 : ORIGIN = 0xF80000, LENGTH = 0x2
CONFIG2 : ORIGIN = 0xF80002, LENGTH = 0x2
FGS : ORIGIN = 0xF80004, LENGTH = 0x2
FOSCSEL : ORIGIN = 0xF80006, LENGTH = 0x2
FOSC : ORIGIN = 0xF80008, LENGTH = 0x2
FWDT : ORIGIN = 0xF8000A, LENGTH = 0x2
FPOR : ORIGIN = 0xF8000C, LENGTH = 0x2
CONFIG3 : ORIGIN = 0xF8000E, LENGTH = 0x2
FUID0 : ORIGIN = 0xF80010, LENGTH = 0x2
}
Détermination de l’adresse de début de la table des vecteurs d’interruption

__IVT_BASE = 0x4;
Détermination de l’adresse de début de l’aivt

__AIVT_BASE = 0x104;
Détermination des adresses des sections qui se trouvent dans la mémoire de donnée
__YDATA_BASE = 0x4800;
58
Annexe C : Le fichier d’édition des liens
__DMA_BASE = 0x7800;
__DMA_END = 0x7FFF;
__DATA_BASE = 0x2000;
Emplacement du programme qui se trouve dans le main

__CODE_BASE = 0x20000;
Détermination de l’adresse de début de chaque segment

__BSP_BASE = 0x0200;
__SSP_BASE = 0x4000;
__GSP_BASE = 0x10000;
Mémoire Programme
Instructions lors du reset
.reset :
{
SHORT(ABSOLUTE(__reset)); (La première fonction qui sera appelé après le reset du
composant)
SHORT(0x04);
SHORT((ABSOLUTE(__reset) >> 16) & 0x7F);
SHORT(0);
} >reset
On retrouve le code exécutable des inputs sections

.text __CODE_BASE :
{
*(.handle);
*(.libc) *(.libm) *(.libdsp); /* keep together in this order */
*(.lib*);
*(.text);
} >program
Réservation de l’espace mémoire dans la flash pour chaque segment (allocation de la

mémoire)
Pour ce faire voici l’écriture générale
Nom_de_la_section son_adresse
{
*( Nom_de_la_section ) ;
}>région de la mémoire
BS_Section __BSP_BASE :
{
*(BS_Section);
}>program
SS_Section __SSP_BASE :
{
59
*(SS_Section);
}>program
GS_Section __GSP_BASE :
{
*(GS_Section);
}>program
Mémoire Donnée
Réservation de l’espace mémoire pour les registres de configurations de l’oscillateur
__FGS :
{ *(__FGS.sec) } >__FGS
__FOSCSEL :
{ *(__FOSCSEL.sec) } >__FOSCSEL
__FOSC :
{ *(__FOSC.sec) } >__FOSC
__FWDT :
{ *(__FWDT.sec) } >__FWDT
Réservation de la RAM pour Mplab ICD2 (à partir de l’adresse 0x800)

.icd __DATA_BASE (NOLOAD):
{
. += (DEFINED (__ICD2RAM) ? 0x50 : 0 );
} > data
Information utile pour le debuggage

.comment 0 : { *(.comment) }
.debug_info 0 : { *(.debug_info) *(.gnu.linkonce.wi.*) }
.debug_abbrev 0 : { *(.debug_abbrev) }
.debug_line 0 : { *(.debug_line) }
.debug_frame 0 : { *(.debug_frame) }
.debug_str 0 : { *(.debug_str) }
.debug_loc 0 : { *(.debug_loc) }
.debug_macinfo 0 : { *(.debug_macinfo) }
.debug_pubnames 0 : { *(.debug_pubnames) }
.debug_ranges 0 : { *(.debug_ranges) }
.debug_aranges 0 : { *(.debug_aranges) }
}
SECTIONS
{
Définition de la table des vecteurs d’interruption
.ivt __IVT_BASE :
{
LONG(DEFINED(__ReservedTrap0) ? ABSOLUTE(__ReservedTrap0) :
ABSOLUTE(__DefaultInterrupt));
.
.
.
LONG(DEFINED(__Interrupt117) ? ABSOLUTE(__Interrupt117) :
ABSOLUTE(__DefaultInterrupt));
} >ivt
60
Définition de l’Alternate Interrupt Vector Table

.aivt __AIVT_BASE :
{
LONG(DEFINED(__AltReservedTrap0) ? ABSOLUTE(__AltReservedTrap0) :
(DEFINED(__ReservedTrap0) ? ABSOLUTE(__ReservedTrap0) :
ABSOLUTE(__DefaultInterrupt)));
.
.
.
LONG(DEFINED(__AltInterrupt117) ? ABSOLUTE(__AltInterrupt117) :
(DEFINED(__Interrupt117) ? ABSOLUTE(__Interrupt117) :
ABSOLUTE(__DefaultInterrupt)));
} >aivt
}
Dans cette dernière partie du fichier, on va indiquer l’emplacement des SFR (Special
Function Register) c'est-à-dire qu’on va donner l’adresse mémoire de chaque registre
comme décrit ci-dessous.
L’adresse de chaque registre est écrite en deux versions, une avec un underscore et
l’autre sans, et ceci permet au programme écrit en langage c et assembleur de ce référer à
ces registres.
_WREG0 = 0x0000 ;
WREG0 = 0x0000 ;
_WREG1 = 0x0002 ;
WREG1 = 0x0002 ;
Et ainsi de suite jusqu'à atteindre l’adresse 0x774.
61
Annexe D
Le MicroBlaze
Architecture du MicroBlaze
Le MicroBlaze est un microprocesseur RISC qui possède une architecture de harvard et qui est
sur 32 bits. Il possède comme le montre la figure ci dessous:
32 registres internes de 32 bits de large,
Un pipeline à 3 niveaux,
Un bus instructions interne (ILMB),
Un bus de données interne (DLMB),
Un bus d'instructions externe (IOPB),
Un bus de données externe (DOPB),
Jeu d’instruction sur 32 bits.
Architecture interne du MicroBlaze.
62
Annexe D : Le MicroBlaze
La figure précédente nous présente les différentes liaisons entre le MicroBlaze et les autres
composants qui se trouvent dans le FPGA.
Le MicroBlaze dans le FPGA.
Caractéristiques du MicroBlaze
Le MicroBlaze possède plusieurs caractéristiques dont on en cite les plus importantes ci-dessous :
C’est un processeur facilement reconfigurable puisqu’il est possible de sélectionner ses
composants internes et de les paramétrer,
Jeu d’instructions optimisé pour les applications embarquées,
Pas d’occupation de silicium en plus puisqu’il est à l’intérieur du FPGA,
On peut atteindre de bonnes performances sans ajouter de coût
63
Bibliographie
[1] Cours de Sécurité, Michel Riguidel, 2005 – 2006. http://perso.enst.fr/~legrand/UESecur/Sec-

MR-2pp.pdf
[2] Virtual Socket Interface Alliance, Intellectual Property Protection Development Working
Group. Intellectual property protection: Schemes, alternatives and discussion, Janvier 2001.
[3] IP watermarking techniques: survey and comparison Abdel-Hamid, A.T.; Tahar, S.; El
Mostapha Aboulhamid System-on-Chip for Real-Time Applications, 2003.
[4] Gang Qu et Miodrag Potkonjak, Intellectual property protection in VLSI design, 2003.
[5] Microchip. CodeGuard Security: Protecting Intellectual Property in Collaborative System Designs, Rishi
Vasuki, 2006.
[6] Actel.Understanding Antifuse Device Security, January 2004
[7] Lilian Bossuet, FPGA Evolutions et nouvelles applications, 2006.
http://www.lilianbossuet.com/fr/Doc/documents_pedagogiques/Bossuet_seminaire_JESSICA
_2006.pdf
[8] Microchip. Section 1. CodeGuard Security, DS70180A, 2006.
[9] Microchip. PIC24FJ128GA FamilyData Sheet, DS39747C, 2006
[10] Microchip. PIC24H Family Data Sheet, DS70175D, 2006.
[11] Microchip. dsPIC30 Family Data Sheet
[12] Microchip. dsPIC33F Family Data Sheet, DS70165D, 2006.
[13] Microchip. Getting Started with the DS Digital Signal Controller, Microchip.
[14] Microchip. Explorer 16 Development Board User’s Guide, DS51589A, 2005.
[15] Microchip. MPLAB IDE User’s Guide, DS51519B, 2006.
[16] Microchip. MPLAB C30 C COMPILER USER’S GUIDE, DS51284E, 2005.
[17] Microchip. MPASM Assembler, MPLINK, Object Linker, MPLIB Object Librarian User’s Guide,
DS33014J, 2005.
[18] Microchip. MPLAB ICD 2 In-Circuit Debbuger User’s Guide, DS51331B, 2005.
[19] Xilinx. Virtex-4 Configuration Guide, UG071 (v1.1) , Septembre 2004.
[20] http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf
[21] Altera. Stratix III Device Handbook, Volume 1, Mai 2007.
64
[22] Actel.Fusion Family of Mixed-Signal Flash FPGAs with Optional Soft ARM Support, Avril 2006.
[23] Actel.Application Note Fusion Security, Avril 2006.
Liens utiles :
www.microchip.com
www.actel.com
www.xilinx.com
www.actel.com
65

Conception Et Mise en Oeuvre Des Méthodes de

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Conception Et Mise en Oeuvre Des Méthodes de

Transféré par

Droits d'auteur :

Formats disponibles

Cycle de formation des ingénieurs en Télécommunications

Architecture des Systèmes des Télécommunications

Rapport de projet de fin d’étude

Conception et mise en œuvre des méthodes de

Travail proposé et réalisé en collaboration avec le laboratoire IMS, Bordeaux

Année universitaire : 2006/2007

Ce projet a été réalisé en collaboration avec le laboratoire de l'Intégration du Matériau au Système

Au terme de ce travail, je voudrais exprimer mes remerciements à mes encadrants:

Mr. Lilian Bossuet, maître de conférences à l’Ecole Nationale Supérieure d’Electronique,

Je remercie aussi Yosra pour sa gentillesse et son soutien.

3. Choix du composant .......................................................................................................27

Figure 1: Communication entre les différents IPs...................................................................................5

Figure 29: Les accès qui génèrent le security reset. ...............................................................................34

Tableau 1 : Type d’implémentation du CodeGuard..............................................................................12

étudiées; pour répondre au problème de protection du fichier de configuration. L’étude sera

1. Problématique de la société SAFT

Figure 1: Communication entre les différents IPs.

Figure 2: Sécurité en électronique.

3. Les solutions de protection des IP

3. 1. Solutions software (Watermarking et Fingerprinting)

3. 2. Protection hardware pour une cible software

Figure 3: Sécurisation des données avec trois circuits.

Figure 4: Segmentation de la mémoire.

3. 3. Solution avec protection hardware reconfigurable sur FPGA

Figure 5: Transfert sécurisé du bitstream dans un FPGA SRAM.

3. 4. Choix des solutions à étudier

Solution software avec protection

Figure 6: Principe du CodeGuard Security.

Le general segment : c’est le segment le moins sécurisé, nous pouvons y trouver

1. 2. Les différents types d’implémentation du CodeGuard Security

Type de Type d’implémentation du CodeGuard Security

Figure 7: Organisation de la mémoire programme et de la mémoire de données.

1. 3. Les niveaux de sécurité du CodeGuard Security

Boot Segment Access Area

Secure Segment Access Area

Figure 8: Organisation de la mémoire pour un niveau de sécurité élevée.

Prenons un exemple avec trois utilisateurs 1, 2 et 3 qui enregistrent respectivement leur

Secure Segment Access Area

Figure 9 : les accès qui génèrent le security reset.

Boot Segment Boot Segment

Secure Segment Secure Segment

General Segment General Segment

1. 4. Organisation de la mémoire programme

Figure 11: Organisation de la mémoire programme.

1. 5. Organisation de la mémoire de données

Figure 12: Organisation de la RAM.

Figure 13: Accès à la mémoire RAM à partir de la mémoire Flash.

1. 6. Les registres de configurations

2. Allocation des segments

Figure 14: Le registre FBS de configuration du boot segment.

BSS (2 :0) Niveau de Taille du boot Nombre de KO

*KO : Kilos Octets

b. Choix du niveau de sécurité (voir paragraphe II. 1. 3)

c. Allocation de la RAM pour le boot segment

Figure 15 : Emplacement du boot segment RAM dans la mémoire de donnée.

RBS Taille Taille (octets)

d. Libération de la RAM réservé au boot segment

Figure 16: Le registre BSRAM.

Figure 17: Registre de configuration FSS du secure segment.

SSS (2 :0) Niveau de Taille du secure Nombre de KO

*KO : Kilos Octets

b. Choix du niveau de sécurité (voir paragraphe II. 1. 3)

c. Allocation de la RAM pour le secure segment