securisation/pro composants materiel securisation/protection de

Transcription

Projet Systèmes Embarqués 2008/2009
SECURISATION/PROTECTION DE
COMPOSANTS MATERIELS SUR ASIC & FPGA
Dris AGROUR
Farid AIT ACHOUR
Wajdi BEN SALEM
Alain TRAN
Encadré par : Bertrand LEGAL
Lilian BOSSUET
SOMMAIRE
INTRODUCTION …………………………………………………………………………………...……………………..1
1. PRESENTATION DU SUJET …………………………………………………………………….…………………………2
1.1. EXPLICATION DU CONTEXTE
1.2. OBJECTIFS ET CAHIER DES CHARGES
1.3. ENVIRONNEMENT DU SYSTEME
2. SPECIFICATIONS MATERIELLES …………………………………………………………………………………………7
2.1. ARCHITECTURE DU SYSTEME MMSC
2.2. DEFINITION DES SCENARIOS
2.3. CHOIX DES IPS DE CRYPTAGE
3. L’INTERFACE GRAPHIQUE ………………………………………………………………………………………….…18
3.1 BESOIN
3.2 LES ETAPES DE CONFIGURATION
3.3 DIAGRAMMES DES CLASSES
4. PERFORMANCES APRES SYNTHESE ……………………………………………………….…………………………20
5. SIMULATION ET TEST ……………………………………………………………………….…………………………22
5.1. SIMULATION SOUS MODELSIM
5.2. IMPLEMENTATION SOUS XILINX SPARTAN 3E
6. CONCLUSION ………………………………………………………………………………….…………………………26
ANNEXES ….………………………………………………………………………….………………………………….27
Introduction
Les progrès de la technologie de fabrication des circuits intégrés permettent
d'atteindre une densité telle que des systèmes complets peuvent maintenant être regroupés
sur une seule puce. Les applications de téléphonie mobile, de télévision numérique ou de
visiophonie sont des exemples de tels systèmes intégrés.
Cela induit deux problèmes majeurs. Tous d’abord, toute la sécurité repose sur un
seul et même circuit. Si celle-ci n’est pas suffisante alors cela peut engendrer une faille de
sécurité importante dans le système.
Ensuite, les besoins croissants de flexibilité des produits imposent l'intégration de
nombreuses fonctions, ou mode de fonctionnement, complexe mais surtout couteuse
envers leurs clients. Malheureusement il peut arriver que les clients ne souhaite pas payer
pour l’ensemble des fonctions car ne veulent utiliser que certaines d’entres elles.
Le cadre de ce projet est donc de répondre au mieux à ces deux problématiques et
consiste au développement d’un contrôleur en charge des droits d'utilisation de composants
matériels.
Nous commencerons par présenter le cadre technique du sujet, avant de continuer sur le
détail des spécifications matérielles puis logicielles, pour finalement terminer par les
vérifications et les performances du système.
Page | 1
I1.1.
Présentation du sujet :
EXPLICATION DU CONTEXTE :
Pour faire face à la demande du marché, les fabricants de produits publics doit faire preuve
d’innovations et d’ingéniosité. Leurs produits doivent faire face aux besoins grandissant de
leurs clients et doivent donc fournir un maximum de fonctionnalités.
L’on pourra prendre l’exemple du téléphone portable. Aujourd’hui, à part sa fonctionnalité
principale qui est de téléphoner, celui-ci doit pouvoir fournir des services supplémentaires
comme des jeux, l’accès à internet, ou le multimédia (musique, TV, photos).
Ces systèmes à complexité grandissante peuvent être considérés comme des systèmes
incluant des sous systèmes représentatif de chaque fonctionnalité. La complexité des
systèmes oblige les concepteurs à relever le niveau d'abstraction de leur description et à
réutiliser des blocs fonctionnels préconçus nommée IP (Intellectual Property).
Il existe trois types d’IPs :
IP HARD : Ces IP sont directement prêt à l’emploi et complètement optimisé et fixe.
IP SOFT : Ce sont des algorithmes décrit avec un haut niveau d’abstraction. Ils sont
utilisables dans un design particulier et complètement flexible (générique) et
personnalisable.
IP FIRM : Ces IP sont un mélange entre les IP Hard et Soft. Ce sont des circuits postsynthèse (ou post-compilation) pré-optimisé.
L’intégration d’IP’s dans le monde industriel offrent un avantage considérable dans le temps
de développement de l’application mais introduit aussi des désavantages comme :
• La copie frauduleuse.
• Le reverse engineering.
• L’application d’attaque sous différentes formes (Hackers, Pirates….).
• L’augmentation de la complexité du circuit.
• L’introduction de circuits rarement utilisés.
Le marché des IP’s étant en pleine expansion, ceux-ci nécessitent donc:
• Des systèmes de détection et de protection contre la copie ou le reverse engineering.
• L’intégration dans une IP globale (IP multi mode) pour diminuer la complexité du
circuit.
• Des optimisations en consommation contre les circuits non utilisés.
Page | 2
1.2.
OBJECTIFS ET CAHIER DES CHARGES:
Le sujet faite suite à la description des différents problèmes détaillés dans le chapitre
précédent et consiste à étudier et reconcevoir un contrôleur matériel en charge des droits
d'utilisation de composants matériels. Le rôle de ce contrôleur est de s’assurer qu’un circuit
ne peut être utilisé que par des personnes (ou autres circuits) possédant les droits
nécessaires.
La mise en œuvre de ce type de circuit peu apparaître :
• Dans le cadre de la lutte contre le piratage des IP ou l’on désire éviter leurs
contrefaçons, voir être capable d’identifier la source de la fuite
• Lorsqu’un client souhaite acheter un composant pour lequel il ne souhaite pas
bénéficier de l’ensemble des fonctionnalités
• Dans un circuit qui peut être la cible d’attaques matérielles et ou chaque
communication et chaque changement doit être sécurisée.
Des travaux ont déjà été réalisé dans ce domaine au travers d’un stage l’an dernier ayant
amené une version “beta” d’un tel contrôleur. L’objectif est maintenant de reconcevoir ce
contrôleur en prenant en considération l’ensemble des primitives de sécurité nécessaires
(algorithmes de cryptage différents, taille des clefs, sélection des opérations à sécuriser,
etc.).
Le travail à réaliser consiste en 6 étapes :
• Comprendre les différentes protections mises en œuvre (DRM, tatouage, trames
cryptées, etc.).
• Comprendre et trouver des IP de cryptographie (DES, AES, TEA, etc…) sur internet.
• concevoir un nouveau contrôleur matériel facilement configurable sous contrainte de
surface et de consommation d’énergie.
• Concevoir une interface graphique QT/Java permettant de créer/configurer des
contrôleurs matériels.
• Mesurer les performances du contrôleur sur différents FPGA /ASICs.
• Réaliser un démonstrateur matériel sur FPGA autour d’un processeur (avec ou sans
OS)
Le système devra pouvoir faire face à différentes attaques :
•
ATTAQUES FORCE BRUTE :
Pour activer une fonction ou une norme il sera demandé à l’utilisateur sa clé. Si
l’utilisateur n’en possède aucune et qu’aucune protection n’est adoptée alors celui-ci
pourra réaliser autant de tentatives qu’il souhaite jusqu’à tomber sur la bonne clé.
Une solution est donc (comme pour les cartes bancaires) de limiter à trois essais la
saisie des clés. Une seconde solution serait d’appliquer une temporisation après
chaque tentative permettant ainsi d’allonger considérablement le temps de
recherche de la clé. On comprend que plus cette temporisation sera élevée et plus la
protection sera importante. Par exemple, dans le cas d’un chiffrement à 128 bits, il
existe 2 128 possibilités. Si l’on applique une temporisation de 1 seconde alors il
faudra plus d’un milliard d’année pour réaliser toutes les possibilités.
Page | 3
•
PROBLEME DE PLAGIA :
Pour contrer les problèmes de copies frauduleuses de notre contrôleur il est
important de lui spécifier une clé supplémentaire qui servira de numéro de série.
Pour vérifier que le produit n’est pas une copie frauduleuse, il est donc important de
pouvoir récupérer cette clé. Pour cela nous mettrons en place un mécanisme
ordonné permettant de spécifier que l’on souhaite récupérer et renvoyer la valeur de
cette clé.
•
ATTAQUE DU BUS DE TRANSMISSION :
Une personne malveillante peut se débrouiller pour capter une trame diffusée dans
le bus de transmission. Pour nuire au système, la personne peut donc émettre cette
trame et modifier le fonctionnement du système. Pour contrer ce problème, chaque
trame se verra attribuée un numéro. A chaque envoi le numéro sera incrémenté (par
ex). Ainsi si l’on est arrivé au numéro 18 et que la personne malveillante envoie la
trame dont le numéro est 4 alors le système pourra détecter l’erreur et agir en
conséquence.
•
ATTAQUE PAR MANIPULATION DE BITS:
Les états de chaque fonction ou mode seront contenus dans un RAM. Cependant, de
nos jours, certaines techniques au laser permettent la modification de bit d’un
circuit. Par exemple, dans notre cas une personne pourrait très bien manipuler les
bits contenus dans la RAM. La solution que l’on adoptera ici sera de ne jamais écrire
une donnée dans la RAM sur 1 bit mais au minimum sur 2 bits.
Exemple :
Si une variable doit avoir l’état 1 ou 0 ont codera la variable de telle sorte
qu’elle valle 10 (pour 1) et 01 (pour 0). On ne prendra surtout pas 10 et 11 car la
modification du deuxième bit ne permettra pas de détecter l’erreur.
Selon le nombre d’erreurs consécutives détectées et l’application on pourra réagir de
différentes manières :
• Blocage du système.
• Application d’une temporisation.
• Ne rien faire.
Au niveau matériel, le travail consistera donc à concevoir un nouveau contrôleur matériel.
Nous réaliserons une première version contenant une entrée pour le canal crypté et une
entrée pour le changement de mode.
Page | 4
La seconde version consistera à n’utiliser qu’une seule entrée pour le canal crypté qui
contiendra le changement de mode.
Les objectifs seront de :
Minimiser l’impact en consommation.
Minimiser l’utilisation en surface.
Augmenter la sécurité de transmission.
Améliorer l’intégration au sein d’un même système.
A l’état initial aucune fonctionnalité ne devra être activée car il faut attendre de
vérifier si la personne à bien les droits nécessaires. Pour cela s’il existe n modes de
fonctionnement, nous gérerons n+1 états. Cet état supplémentaire sera fixé à l’initialisation
et consistera à mettre à 0 l’horloge ainsi :
On diminuera la consommation du circuit.
On évitera les failles de sécurité.
Au niveau logiciel, l’idée est de concevoir une interface graphique Java permettant de créer
ou configurer des contrôleurs matériels.
L’interface conçue pour le développeur permettra de configurer le code VHDL générique à
partir des paramètres entrés sur celle-ci. On prêtera attention au fait que le système doit
être le plus configurable possible.
Pour cela plusieurs paramètres devront être pris en compte comme par exemple:
•
•
•
•
•
•
Le type de cryptage (AES, DES……).
La clé de cryptage et sa longueur.
Les clés d’accès aux fonctions.
Le nombre de fonctions disponibles.
Le numéro de série (watermark/fingerprint).
Gestion des attaques (Type de réaction et à partir de combien d’attaques).
1.3.
ENVIRONNEMENT DU SYSTEME:
Pour avoir une idée plus claire de l’utilité du projet, nous avons détaillée en figure 1, un
exemple ou un utilisateur souhaite avoir accès à certaine fonctionnalité d’une IP multi mode
créée par un concepteur. En fonction de ses contraintes, le concepteur va, par
l’intermédiaire de l’interface Java, modifier les fichiers VHDL préconçus pour fournir une IP
MMSC (MultiMode Secure Control) adaptée aux caractéristiques du client.
L’IP MMSC associée à l’IP multi mode est regroupés dans une IP globale permettant de
protéger les fonctions des différents attaquants. L’interface génère également les clés
d’accès aux différentes fonctions. Ainsi l’utilisateur n’a plus qu’à payer les différentes clés
permettant l’accès aux différentes fonctions pour les utiliser.
Page | 5
Figure 1 : Diagramme Sagittal du système
Une fois les clés en possession de l’utilisateur, celui-ci
celui ci peut les utiliser pour obtenir accès aux
différents modes de fonctionnement de l’IP conformément à la figure 2.
Figure 2 : Schéma environnemental du système
Page | 6
II- Spécifications matérielles
2.1. ARCHITECTURE DU SYSTEME MMSC
La solution proposée pour notre système est nommée MMSC (MultiMode Secure
Control). Par la suite l’on nommera IPS (IP Secure) Le bloc comportant l’IP à protéger et la
MMSC.
A chaque demande d’activation de mode, l’utilisateur devra envoyer les trames
correspondantes contenant les clés associées et le MMSC contrôlera les droits de cet
utilisateur à propos de la configuration souhaitée.
Le MMSC comporte deux types d’entrées :
Mode Activation Input : à travers cette entrée, l’utilisateur envoi une trame pour
activer/désactiver un mode ou plusieurs modes de l’IP.
• Mode Selection Input : comme son nom l’indique, à travers cette entrée, l’utilisateur
choisira le mode de l’IP qu’il souhaite faire fonctionner.
•
Pour protéger l’IP, les trames d’activation des différents modes seront cryptées. Ce sont
ces trames que devra connaître l’utilisateur pour activer ou désactiver un mode. La trame à
la forme suivante :
Figure 3 : Schéma de la trame d'activation de mode
Elle comporte plusieurs champs :
Activation Key : la clé d’activation du mode codée sur (128 bits – la taille de l’entête).
Dans un premier temps, nous avons considérés que la taille de nos trames était fixe
(128 bits) même si le but final est d’avoir une taille de trame variable.
Une entête codée se composant de :
o Frame Number qui correspond au numéro de la trame, l’utilisateur fera en
sorte d’envoyer les trames dans le bon ordre. Ce champ a été introduit pour
faire face aux attaques du bus de transmission ou de BruteForce. Lorsque le
pirate envoie une trame aléatoire qu’il a réussi à capter, le système réussira à
le détecter. La taille attribuée à ce champ dépend du nombre de fonctions
disponibles.
o Mode Number qui correspond au numéro du mode à activer ou désactiver. Sa
taille est attribuée selon le nombre de fonctions dont dispose le système.
o Enable/Disable qui correspond à l’action choisie, activer ou désactiver. L’on
utilisera au minimum 2 bits pour éviter les problèmes de manipulation de
bits.
Page | 7
Ci-dessous sont représentés les différents blocs du système MMSC :
Figure 4 : Schéma fonctionnel du bloc MMSC
FIFO :
Comme le bus de données est fixé à 32 bits et que les modules de décryptage
décrypte des données de taille différents (DES : 64 bits, AES : 128bits), il est nécessaire de
placer une FIFO en entrée du bloc de décryptage pour palier aux problèmes de
synchronisation. Il en sera de même entre sa sortie et la FSM.
CONTROLEUR :
Le contrôleur est le cœur du système, c’est lui qui va permettre de gérer le système.
Il est en charge de contrôler les trames en entrées et de gérer les erreurs en conséquence.
Figure 5 : Machine d'état du contrôleur.
Page | 8
ROM :
Pour permettre de contrôler l’accès à certaines fonctionnalités (ou normes) de l’IP,
on associe chaque fonction à une clé de validation qui permettra de vérifier les droits
d’accès. Ces clés seront donc contenues dans une ROM ou l’on considéra qu’aucun pirate ne
pourra avoir accès.
RAM :
La ram contient l’état des différentes fonctionnalités de l’IP. A l’état initial celles-ci
sont toutes initialisées à l’état inactif. Leurs états changeront en fonction des trames
transmises et des droits associées par l’intermédiaire du contrôleur.
DECIPHER :
Ce module a pour but de décrypter les informations contenues dans la trame.
Comme l’on souhaite que notre système soit le plus paramétrable possible, plusieurs
algorithmes de décryptage seront adoptés. On pourra prendre par exemple :
• DES (Data Encryption Standard),
• AES (Advanced Encryption Standard),
• XOR (Exclusive Or).
Figure 6 : Schéma fonctionnel du bloc Decipher
Le Main Bloc est le module contenant l’IP de décryptage. Comme les entrées des blocs de
décryptage ne sont pas toujours identique l’un à l’autre et envers les fifo’s, nous sommes
obligés d’ajouter des wrapper. Ces wrappers sont nommées PRE et POST et permettent une
connexion correcte avec les fifo’s d’entrée et de sortie.
2.2
DEFINITION DES SCENARIOS :
a. Scénario : procédure d'initialisation (cas "rien à signaler")
Hypothèses :
i. L'IP comporte 5 modes de fonctionnement : M1, M2, M3, M4, M5.
(Par défaut, le seul mode actif est le mode M0, propre au bloc MMSC.)
ii. L'utilisateur possède les clés des 3 modes suivants : M2, M3, M5, et les valide.
Initialisation :
Lors de l'initialisation, les trames que l'utilisateur envoie au bloc MMSC sont les suivantes :
Page | 9
Trame n°1 : activer M2
N° de trame
1
N° de mode
2
Validation/Dévalidation
Valider
Clé
Clé mode 2
N° de trame
2
N° de mode
3
Valider
Clé
Clé mode 3
N° de trame
3
N° de mode
5
Valider
Clé
Clé mode 5
En fonctionnement :
L'utilisateur souhaite utiliser le mode M3 :
Il envoie le n° du mode désiré sur l'entrée switch _mode, validée par le signal switch_enable.
Valeur de switch_mode : '011' = (3)10.
b. Scénario : Gestion du numéro de trame
Hypothèses :
ii. L'utilisateur possède les clés des 3 modes suivants : M2, M3, M5.
Après décryptage de la trame, on commence par vérifier le numéro de trame.
Si après vérification, le numéro de trame est correct, alors on passe à la vérification de la
clé. (cf. suite)
Si le numéro de trame est incorrect alors plusieurs réactions sont envisageables selon les
configurations.
Les trames suivantes sont reçues :
N° de trame
N° de mode
1
-
-
Clé
-
N° de trame
2
N° de mode
-
-
Clé
-
N° de trame
3
N° de mode
-
-
Clé
-
N° de trame
1
N° de mode
-
-
Clé
-
Le n° de la quatrième trame ne correspond pas au n° attendu, cela peut signifier deux
choses:
a) Un attaquant a réussi à capter la 1ère trame et tente de la retransmettre pour
corrompre le système.
b) Une erreur s’est produite sur le bus de transmission et la valeur du numéro de
trame est erronée.
Page | 10
Il n'y a aucun moyen de déceler s'il s'agit du premier ou du second cas, cette erreur sera
donc interprétée comme une tentative de rejeu et sera traitée d'une des manières
suivantes:
a) On bloque le système jusqu’au prochain redémarrage.
b) On bloque le système après un certain nombre d’erreurs détectées et fixé par le
concepteur.
c) L’erreur est ignorée. Le système considère que les rejeux ne sont pas des
problèmes.
A la détection d’une erreur sur le numéro de trame, le bloc MMSC la signale par
l'intermédiaire du signal error.
c. Scénario : validation des modes (cas "rien à signaler")
Hypothèses :
ii. L'utilisateur possède les clés des 2 modes suivants : M2, M3.
iii. Puis, l'utilisateur souhaite remplacer le mode M3 par le mode M5, dont il obtient
la clé.
Il va donc dévalider le mode M3 et valider le mode M5.
Après vérification du numéro de trame, le système vérifie si l’utilisateur a bien les droits
correspondant à la validation des modes qu’il souhaite activer. Cette vérification est faite par
le test de la clé.
Contenu de la ROM (statique) :
Adresse
Valeur
0
Clé mode 0*
1
Clé mode 1
2
Clé mode 2
…
…
M
Clé mode M
*La clé du mode 0 est le n° de série de l'IP.
Contenu de la RAM :
Dans la RAM, à chaque mode est associée une valeur binaire qui caractérise son état
présent.
Adresse
Valeur
0
Etat mode 0
1
Etat mode 1
2
Etat mode 2
…
…
M
Etat mode M
Un mode possède 2 états inactif (par défaut) et actif.
Au démarrage du système, les valeurs de la RAM sont inconnues donc on initialise tout à
l'état inactif.
Page | 11
Les états actif et inactif sont codés par les valeurs binaires '1010' et '0101' :
Etat
Valeur binaire
Verrouillé
0000
Actif
1010
Inactif
0101
Initialisation :
Etat de la RAM et du système :
Adresse
Valeur
0
1010
1
0101
2
0101
3
0101
4
0101
5
0101
Mode
0
1
2
3
4
5
Etat
Actif
Inactif
Inactif
Inactif
Inactif
Inactif
Lors de l'initialisation, les trames reçues de la part de l'utilisateur sont les suivantes :
N° de trame
N° de mode
Clé
1
2
Valider
Clé mode 2
Adresse
Valeur
0
1010
1
0101
2
1010
3
0101
4
0101
5
0101
N° de trame
2
N° de mode
3
Adresse
Valeur
0
1010
1
0101
2
1010
3
1010
4
0101
5
0101
Trame n°3 : désactiver M3
N° de trame
N° de mode
3
3
Mode
0
1
2
3
4
5
Valider
Mode
0
1
2
3
4
5
dévalider
Etat
Actif
Inactif
Actif
Inactif
Inactif
Inactif
Clé
Clé mode 3
Etat
Actif
Inactif
Actif
Actif
Inactif
Inactif
Clé
Clé mode 3
Page | 12
Adresse
Valeur
0
1010
1
0101
2
1010
3
0101
4
0101
5
0101
N° de trame
4
N° de mode
5
Adresse
Valeur
0
1010
1
0101
2
1010
3
0101
4
0101
5
1010
Mode
0
1
2
3
4
5
Valider
Mode
0
1
2
3
4
5
Etat
Actif
Inactif
Actif
Inactif
Inactif
Inactif
Clé
Clé mode 5
Etat
Actif
Inactif
Actif
Inactif
Inactif
Actif
En fonctionnement :
L'utilisateur souhaite utiliser le mode M5 :
Il envoie le n° du mode désiré sur l'entrée switch _mode, validée par le signal switch_enable.
Valeur de switch_mode : '101' = (5)10.
Le fonctionnement est correct. Aucune erreur n'est détectée.
Remarque :
Si un mode verrouillé est sollicité dans la configuration de switch _mode, alors le système se
bloque.
d. Scénario : problème de clé
Dans ce scénario, le système reçoit une clé erronée. Trois cas sont possibles :
a) C'est une tentative de piratage. L'utilisateur tente d'accéder à un mode dont il n'a
pas les droits.
b) C'est une erreur de la part de l'utilisateur.
c) Il s'agit d'une erreur de bus de transmission sur le champ 'clé'.
Hypothèses :
iii. L'utilisateur souhaite activer les modes suivants : M2, M5 et M4 dont il ne connaît
pas la clé.
Page | 13
Les trames suivantes sont reçues :
N° de trame
1
N° de mode
2
Valider
Clé
Clé mode 2
N° de trame
2
N° de mode
3
Valider
Clé
Clé mode 3
N° de trame
3
N° de mode
4
Valider
Clé
Clé incorrecte
N° de trame
4
N° de mode
5
Valider
Clé
Clé mode 5
A chaque trame reçue, le système compare avec les clés contenues dans la ROM.
A la 3ème trame, la clé ne correspond pas à la valeur dans la ROM. Plusieurs réactions seront
envisageables :
a) On bloque le système jusqu’au prochain redémarrage.
b) On ne bloque le système qu'après un certain nombre d’erreurs détectées et fixé
par le concepteur.
Dans le 2ème type de profil, la 3ème trame est ignorée et une valeur de compteur est
incrémentée.
e. Scénario : problème de n° de mode
Dans cet exemple, on considère l'apparition d’erreurs provoquées par le bus de transmission
sur le N° de mode.
Hypothèses :
iii. L'utilisateur souhaite activer les modes suivants : M2, M5 mais l'erreur transforme
le n° de mode.
Trame envoyée par l'utilisateur/μC :
N° de trame
N° de mode
1
2
Valider
Clé
Clé mode 2
N° de trame
2
N° de mode
3
Valider
Clé
Clé mode 3
N° de trame
3
N° de mode
5
Valider
Clé
Clé mode 5
Page | 14
Trame reçue :
N° de trame
1
N° de mode
2
Valider
Clé
Clé mode 2
N° de trame
2
N° de mode
3
Valider
Clé
Clé mode 3
N° de trame
3
N° de mode
1
Valider
Clé
Clé mode 5
Si l'on considère que les modes sont codés de la manière suivante :
mode 1 = 001, mode 2 = 010, mode 3 = 011, ...
Il est possible qu'un bit erroné fasse passer mode 5 en mode 1 (101 -> 001).
Cela a pour conséquence de demander une validation du mode 1 avec la clé du mode 5.
La clé étant incorrecte, le système traite ce cas de manière similaire à une tentative de
piratage, réagit selon la politique choisie et génère une erreur. Ce type d'erreur de bus de
transmission ne peut pas être détecté et est considérée comme une erreur de clé incorrecte.
f. Scénario : problème de validation/dévalidation
Dans cet exemple, on considère l'apparition d’erreurs provoquées par le bus de transmission
sur le champ de validation/dévalidation.
Hypothèses :
iii. L'utilisateur souhaite activer les modes suivants : M2, M5 mais l'erreur modifie le
champ de validation.
Le champ de Validation/Dévalidation étant le seul point faible de la trame, un codage sur 1
bit unique rendrait possible de traiter une demande erronée dans le cas d'une erreur de bus
de transmission ayant changé la valeur de ce bit. E.g. désactivation d'un mode tandis que
l'utilisateur en demande l'activation.
Ce champ est donc codé sur 2 bits et aux demandes validation et dévalidation sont associées
les valeurs : ‘10’ et ‘01’ successivement.
Pour passer d'une valeur à l'autre, il faut modifier 2 bits. La probabilité pour qu'une erreur
survienne sur ces deux bits consécutifs peut être considérée comme nulle.
Une erreur du bus de transmission sur ce champ génère donc les valeurs 11 ou 00.
Trames reçues :
N° de trame
1
N° de mode
2
Valider
Clé
Clé mode 2
N° de trame
2
N° de mode
3
Valider
Clé
Clé mode 3
N° de trame
N° de mode
3
5
11
L'erreur sur la trame 3 est détectée et signalée par le biais du signal error.
Clé
Clé mode 5
Page | 15
2.3. CHOIX DES IPS DE CRYPTAGE
Dans cette partie, on compare les performances de 3 IP pour le cryptage AES et 2 IP
pour le cryptage DES. Tout ces IPs sont open source et leurs sources ont été téléchargées sur
Internet.
Pour l’AES, il s’agit de : Simple AES, Fast AES, et Mini AES. Et pour le DES, il s’agit de
Simple DES et Triple DES.Pour avoir une première idée de l’encombrement que ces
différents blocs de décryptage peuvent occupées nous les avons synthétisés sous Xilinx ISE.
Nous avons choisis de faire toutes les synthèses sur le circuit suivant :
Famille : Spartan3E
Circuit : XC3S500E
Boitier : FG320
Vitesse : -4
Ci-dessous est un récapitulatif des résultats d’implémentation des cinq IPs de cryptage:
AES
AES1
DES
AES-FAST
MINI-AES
DES simple
Triple DES
Optimisation
Speed
Area
Speed
Area
Speed
Area
Speed
Area
Speed
Area
Slices
14%
(670)
3%
(291)
13%
(1284)
31
19%
(895)
3%
(325)
16%
(1569)
31
155%
(7218)
9%
(914)
150%
(13986)
262
160%
(7471)
7%
(657)
140%
(13105)
262
77%
(3622)
41%
(3873)
42%
(3934)
29
72%
(3382)
40%
(3785)
38%
(3600)
29
6%
(293)
2%
(192)
5%
(555)
199
5%
(276)
1%
(125)
5%
(512)
199
34%
(1670)
13%
(1227)
28%
(2680)
326
28%
(1309)
10%
(1012)
25%
(2347)
326
112%
(262)
-
112%
(262)
-
82%
(191)
-
82%
(191)
-
130%
(302)
-
130%
(302)
-
4%
(1)
56.251
MHz
4%
(1)
44.819
MHz
12%
12%
(29)
(29)
20%
20%
(4)
(4)
8%
8%
(2)
(2)
69.348 52.407
MHz
MHz
115
4%
(1)
143.761
MHz
4%
(1)
145.054
MHz
Slice Flip Flops
4 input LUTs
IOs
bonded IOBs
BRAMs
GCLKs
Maximum
Frequency
Durée de
traitement
(périodes
d’horloge)
Debits (Mbps)
13%
13%
(31)
(31)
15%
20%
(3)
(4)
4%
4%
(1)
(1)
122.171 82.596
MHz
MHz
278
56
38
17
424
337
77
58
18
511
515
4%
4%
(1)
(1)
101.031 77.743
MHz
MHz
57
113
Tableau 1 : Récapitulatif des résultats d'implémentation des IPs de cryptage
Page | 16
87
AES :
Nous constatons que le Fast AES est très rapide mais il prend énormément de la
surface, de même pour le Mini AES. Nous optons alors pour le choix du Simple AES qui
occupe un nombre de slice moins important mais qui est malheureusement plus lent.
DES :
Le Simple DES par rapport au Triple DES n’occupe pas énormément de surface et est
rapide. Seul inconvénient est qu’il ne sera pas aussi sécurisé que le Triple DES. Nous optons
dans notre choix pour le Simple DES.
Pour mieux comparer ces algorithmes de cryptages, nous en avons conçu un autre
avec un simple XOR (ou exclusif). Ses résultats d’implémentation figurent ci-dessous :
Optimisation
Slices
Slice Flip Flops
4 input LUTs
IOs
bonded IOBs
BRAMs
GCLKs
Durée de traitement (périodes d’horloge)
XOR
The same for Speed or Area
0% (19)
0% (33)
100
43% (100)
4% (1)
1
Tableau 2 : Résultat d'implémentation du XOR
On constate que le XOR n’occupe quasiment rien en surface puisque l’algorithme est
vraiment basique. Il ne nous a pas été possible de déterminer le débit de celui-ci du fait que
la synthèse n’a malheureusement pas réussi à déterminer de fréquence maximale.
Page | 17
III- Interface Graphique
3.1. BESOINS :
L’on a déjà vue que le rôle du MMSC est de protéger les IPs contre les différentes
attaques possibles. Mais pour s’adapter aux différents besoins des utilisateurs il est
nécessaire que notre bloc soit le plus configurable possible.
possible Le moyen le plus simple pour
cela a été l’écriture d’un code VHDL générique (utilisation de la notion de généricité
gén
dans les
déclarations). Par conséquence la configuration
configurat
est une « simple » modification des
paramètres génériques.
Comme outil de configuration, on a choisi de développer une interface graphique en JAVA
qui agit sur 3 fichiers : le fichier MMSC_aes.vhd, le fichier MMSC_des.vhd et le fichier
rom.vhd.
Le développement
eloppement de cette interface permet de mettre en œuvre les étapes de
configuration qui seront détaillées dans la partie suivante.
3.2. LES ETAPES DE CONFIGURATION
CONFIGU
:
Les différentes étapes de configuration de l’interface peuvent être résumé à la figure 7.
Figure 7 : Schéma des différentes étapes de configuration
L’on commence par demander le choix de l’algorithme de cryptage souhaité (AES ou DES)
puis l’on génère la clé de cryptage qui sera enregistrée dans le fichier « MMSC_aes.vhd
MMSC_aes.v »ou
« MMSC_des.vhd ».
La configuration
onfiguration de la FSM se réalise à travers les fichiers « MMSC_aes.vhd
MMSC_aes
» et
« MMSC_des.vhd » :
Choix du nombre de modes : paramètre générique nb_modes.
Choix de la taille de la clé : paramètre générique key_size.
Choix du nombre de cycles d’horloge à attendre après l’initialisation : paramètre
générique t_wait.
La configuration de la FIFO utilise le fichier « MMSC_aes.vhd » ou « MMSC_des.vhd » :
Choix du nombre de bits pour le bus de données : paramètre générique size_bus.
Choix du nombre de bits pour le bus d’adresse : paramètre générique size_add.
Page | 18
La génération
énération des clés des différents modes puis l’enregistrement de ces clés dans la
ROM utilise le fichier « rom.vhd ».
Enfin, la dernière étape est le cryptage
c
des clés des différents modes puis l’enregistrement
l’
de celles-ci dans un fichier texte.
3.3. DIAGRAMME DES CLASSES:
Le diagramme de classe qui permet de modéliser les relations entre les différentes classes
utilisées est le suivant :
Figure 8 : Diagramme de classes
Pour arriver à notre objectif, on a utilisé 7 classes :
Classes
Description
Interface
Classe
lasse principale qui contient le main.
main
Blocs
Classe qui va afficher les boutons qui correspondent à nos blocs.
FSM
classe à travers laquelle on modifie les paramètres de la machine
d’état.
Modes
classe qui affiche les différents modes et qui génère les clés
correspondant à ces modes.
Cryptage
classe qui décrit la procédure de cryptage.
Choix_Cryptage
classe qui permet de choisir l’algorithme de cryptage, génère la clé de
cryptage et crypte les clés de modes qui seront stockées dans un
fichier texte.
FIFO
classe à travers laquelle on modifie les paramètres de la FIFO.
Page | 19
Explication des différentes relations
•
•
•
•
•
•
•
•
L’objet Blocks fait partie de la classe Interface : relation d’agrégation.
Les 4 objets FIFO, Modes,
Modes Choix Cryptage, FSM font partie de la classe Blocks :
relation d’agrégation.
Pour faire le cryptage des clés des différents modes dans la classe Choix_Cryptage,
Choix_Cryptage on
a besoin
in d’instancier un objet de la classe Cryptage : relation de dépendance.
Selon l’algorithme de cryptage choisi dans la classe Choix_Cryptage,
Choix_Cryptage on modifie dans
la classe FIFO soit le fichier MMSC_aes.vhd soit le fichier MMSC_des.vhd : relation
d’association.
Dans la classe Choix_Cryptage on récupère les clés des modes générées dans la classe
Modes pour les crypter : relation d’association.
Les classes Blocks, Modes,
Modes FSM, Choix_Cryptage et FIFO héritent de la classe JFrame,
classe qui permet de créer une fenêtre
fenêt graphique.
Les classes Blocks, Modes,
Modes FSM, Choix_Cryptage implémentent l’interface
ActionListener,, classe qui permet une action à la suite d’un appui sur un bouton (pour
les classes Blocks, Modes,
Modes Choix_Cryptage)) ou le fait de cocher une case (pour la
classe Choix_Cryptage)) ou choisir une option dans un menu (pour
pour la classe FSM).
La classe FSM implémente aussi l’interface ItemListener pour permettre de connaître
l’option sélectionnée dans chaque menu à tout instant.
IV- Performances après synthèse :
Dans less figures suivantes, nous avons essayé de récapituler les différents résultats de
synthèse du projet. En figure 9, nous apercevons les différents taux d’occupation en nombre
de slices. Ces résultats proviennent d’une synthèse sur FPGA de famille Spartan3E dont les
caractéristiques sont décrites ci-dessous
ci
:
Circuit : XC3S500E
Boitier : FG320
Vitesse : -4
Taux d'occupation de chaque blocs
Nombre de slices
1000
800
920
729
600
Area Optimization
Speed Optimization
336 341
400
271 269
122 128
200
110 112
122 133
fifo_in
fifo_out
0
AES
DES
XOR
fsm
Figure 9 : Courbes des taux d'occupation de chaque bloc en nombre de slices
Page | 20
On remarque que plus l’algorithme est sécurisant (AES puis DES et finalement XOR) et plus la
surface d’occupation augmente, ce qui est dans un certain sens cohérent. Les différents
blocs de décryptage prennent en compte leurs composants PRE et POST permettant
permett
une
communication correcte avec les deux Fifo.
Débits (Mbps) en fonction des blocs de cryptage
467
461
XOR
DES
209
AES
75
0
50
100
250
Speed optimisation
Area Optimisation
110
150
200
250
300
350
400
450
500
Débits (Mbps)
Figure 10 : Courbes des débits en fonction des différents blocs de cryptage.
La figure 10, concerne
oncerne quand à elle les performances en termes de débits maximum. Ces
paramètres devront donc être pris en compte en fonction du cahier des charges de
l’utilisateur. Il faut aussi prendre en compte que ces résultats concernent une description
précise de la MMSC (par exemple une fifo d’entrée de 32bits). Comme les blocs sont
génériques ces valeurs sont susceptibles d’être modifiée.
Page | 21
V-
Simulation et test :
V.1. SIMULATION SOUS MODELSIM:
On a choisi de ne mettre que les résultats de simulation du MMSC avec le cryptage
AES. On obtient les mêmes résultats avec le DES et le XOR.
MMSC avec un algorithme AES
Avec un test bench, on envoi quatre trames : trois pour l’activation des modes 1, 2 et
4 et une trame pour désactiver le mode 2. Ensuite, on essaye de changer les modes.
Evidement, lorsqu’on essayera de choisir le mode 2, le système se bloquera. Ci-dessous
figurent les résultats de la simulation.
Figure 11 : Ecriture de la première trame sur la fifo d’entrée
Figure 12 : Envoi de la clé de décryptage par le bloc ‘pre_aes’ vers ‘aes_dec’
Page | 22
Figure 13 : Transmission des données depuis la fifo d’entrées vers ‘aes_dec’
Figure 14 : Ecriture de la trame décryptée sur la fifo de sortie par ‘post_aes’ et début de sa
lecture par le contrôleur.
Figure 15 : Traitement réussi de la première trame par le contrôleur
On constate que le contrôleur écrit à la première adresse de la RAM la valeur
‘00001010’, ce qui veut dire qu’il a activé le premier mode. Le traitement des autres trames
qui restent se fait de la même manière.
Page | 23
Ci-dessous sont représentées des figures pour les demandes de changement de
mode :
Figure 16 : Changement de mode vers le mode 4 qui est activé dans la RAM (x0A).
Figure 17 : blocage du système après la demande du mode 2 qui est non activée (x05):
Page | 24
V.2. IMPLEMENTATION SOUS XILINX SPARTAN3E :
Une fois le modèle testé et validé par les simulations VHDL il est important de pouvoir tester
celui-ci
ci sous implémentation. Pour ce faire, l’implémentation d’un microcontrôleur PicoBlaze
a été nécessaire conformément à la figure ci-dessous
Pour transférer
férer les trames nous avons repris un programme C++ que nous avons adapté
selon nos besoins. Le programme se contente de transférer les trames ou les divers signaux
d’activation sur un port USB. Le PC est ensuite connecté au kit de développement par
l’intermédiaire
rmédiaire d’un câble USB to RS232. Ainsi le microcontrôleur peut recevoir directement
les trames depuis un PC.
Lors de nos tests nous avons prouvé le bon fonctionnement du changement de mode. Pour
cela nous avons considérer que toutes les fonctions étaient
étaient initialement activées
(initialisation de la RAM,, ici on n’utilise pas les trames pour activer les fonctions).
fonctions Puis en
transférant les signaux adéquates nous changions de mode tous en affichant celui-ci
celui sur les
led’s. Comme il ne nous était pas possible d’avoir accès directement aux états des différents
registres, l’utilisation des led’s a été une des solutions.
Cependant, il ne nous a pas été possible de tester l’ensemble du design étant donné que
nous avions encore quelques problèmes tant à la réception des trames.
Page | 25
VI.
Conclusion
Pour ce qui concerne le projet en lui-même, une bonne partie fonctionne cependant il reste
encore certain point à corriger :
Interface JAVA :
Celle-ci fonctionne correctement excepter pour fournir des trames sous
cryptage DES.
Simulation VHDL
Les simulations des blocs AES, DES, XOR fonctionnent correctement.
La gestion des erreurs de la fsm.
Test d’implémentation
Sélection des modes à travers un test de la RAM.
Activation des modes à partir des clés d’activation.
Personnellement ce projet nous as permis d’abord d’acquérir de nouvelles connaissances
comme :
La cryptographie : AES, DES, XOR.
La définition de scénarios (Description de différents points de vue)
Le développement d’IP (recherche, évaluation, tests, réutilisation)
Des notions aux problèmes liés aux développements de FPGA.
De plus, le projet nous as permis de pouvoir travailler en équipe et de faire face aux différents
problèmes que l’on peut rencontrer (Différents point de vue par exemple). Celui-ci nous offre donc
une très bonne expérience qui nous sera utile dans le domaine professionnel.
Page | 26
Annexes
Fonctionnement du PRE et POST AES :
•
•
•
Le bloc AES se compose de :
« pré_aes » qui adapte les données de la fifo d’entrée pour les envoyer au « aes_dec »,
« aes_dec » décrypte des données,
« post_aes » stocke les données décryptés dans la fifo de sortie.
Pre_aes
Aes_dec
Post_aes
Schéma du bloc AES
Schéma bloc AES avec entrées / sorties
Page | 27
« pre_aes » :
Machine d’état « pre_aes » :
Machine d’états « pre_aes »
Premier processus (P1)
Etat
init
envoi_key
attente_AES_ready
attente_fifo_out_ready
attente_fifo_in_ready
attente_key_ready
lecture_envoi_data
Description
Permet l’initialisation des différents signaux utilisés
Pendant cet état, la clé utilisée pour le décryptage est envoyée au bloc
«aes_dec » octet par octet
Permet d’attendre que le bloc « aes_dec » soit près pour commencer un
autre décryptage (lorsque aes_ready_t = ‘1’)
Permet d’attendre que la fifo de la sortie soit vide
Permet d’attendre que la fifo d’entrée soit remplie
Permet d’attendre que le bloc « aes_dec » ait fini le traitement de la clé
(KEY_READY_O=’1’)
Permet de lire les données de la fifo d’entrée (trame de 128 bits) et de les
envoyer octet par octet au bloc « aes_dec » pour le décryptage (la lecture
et l’envoi sont simultannés)
Page | 28
Second processus (P2)
Etat
init
AES_ready_S
AES_busy
Description
Permet l’initialisation des différents signaux utilisés
Pendant cet état, le bloc « aes_dec » est près à recevoir des données et à
les décrypter (on met le signal aes_ready_t à ‘1’)
Pendant cet état, le bloc « aes_dec » est occupé ; il décrypte une trame
(attente que le signal aes_ready change d’état de ‘0’ à ‘1’)
Un scénario possible:
Les processus du « pre_aes » commencent à leurs états init ; ils initialisent les différents
signaux utilisés puis passent à l’état envoi_key pour P1 et AES_ready_S pour P2,
P1 envoi la clé au bloc « aes_dec » octet par octet et ensuite passe à l’état
attente_AES_ready, P2 compte 16 cycle d’horloge avant de signaler à P1 que « aes_dec » est
près à recevoir les données à travers le signal aes_ready_t, lorsque P1 arrive à l’état
lecture_envoi_data P2 passe à l’état AES_busy,
Lorsque aes_ready_t est à ‘1’, P1 passe à l’état attente_fifo_out_ready,
Lorsque la fifo de sortie est vide, P1 passe à l’état attente_fifo_in_ready,
Lorsque « aes_dec » finisse le traitement de la clé, il met KEY_READY_O à ’1’ et P1 passe à
l’état lecture_envoi_data,
P2 maintenant arrive à l’état AES_busy, et P1 commence la lecture et l’envoi simultanés des
données. Lorsque « aes_dec » ait fini de décrypter et commence l’envoi des données au
« post_aes », P2 passe à l’état AES_ready_S.
Lorsque P1 ait fini d’envoyer les données, il passe à l’état « attente_AES_ready ».
« post_aes » :
Le post AES est très simple puisque le pré AES contrôle tout les composants (les fifos,
aes_dec ). Lorsque le signal aes_data_valid est à ‘1’, le post transfert les données décryptées de l’AES
vers la fifo de sortie.
Page | 29
Fonctionnement du PRE et POST DES :
DIAGRAMME D’ETAT PRE-DES
Reset
Init
Empty_fifo_in = ‘0’
Attente_fifo
Empty_fifo_in = ‘1’
Acquisition
Cpt_acquisition !=
size_data_crypt
Cpt_acquisition !=
size_data_crypt
Cptacquisition =
size_data_crypt
Test_fin_
Acquisition
Cptacquisition =
size_data_crypt
DES_FREE
DES_FREE
Attente_DES
DES_BUSY
Page | 30
------- Conditions dans le cas ou le nombre de bits des données d’entrées est moins important ou
égale aux nombres de bits des données de sortie.
------- Conditions dans le cas ou le nombre de bits des données d’entrées est plus important que le
nombre de bits des données de sortie.
-------
Conditions dans les deux cas.
SECOND PROCESS (Gestion de l’etat du DES)
Reset
Prevent_DES = ‘0’
DES_free
Prevent_DES = ‘1’
Synchro_Post = ‘1’
Synchro_Post = ‘0’
DES_busy
ETAT
Init
DESCRIPTION
permet l’initialisation des sorties, des signaux….
Attente_fifo
Attend qu’une donnée soit présente dans la fifo in et que la fifo out ne soit
pas full.
Cet état permet de récupérer la donnée en sortie de la fifo et de transmettre et
d’adapter celle-ci selon le nombre de bits d’entrée du DES.
Test si l’on a correctement adapté la donnée de sortie avant de lancer le
décryptage.
Attend que le DES ait finit son calcul avant de lancer un nouveaux
décryptage.
Acquisition
Test_fin_
Acquisition
Attente_DES
Page | 31
1. Scénario possible :
a. Données entrée = 32bits (fifo in) et Données sortie = 64bits (DES).
Le Pre DES commence à son état INIT:
- Il initialise tous les signaux et les sorties puis passe à l’état Attente_fifo.
Etat Attente_fifo :
- Initialisation de signaux suite aux états suivants.
- La fifo n’a pas encore de donnée (Empty_fifo_in = ‘0’) :
Il reste donc bloquer à l’état Attente_fifo
- La fifo détient des données :
La première donnée est disponible à sa sortie et empty_fifo_in est passé à 0.
Comme la fifo in détient au moins une donnée et que la fifo out est non pleine
alors l’état passe donc à Acquisition (test sur la fifo out est une sécurité en plus
car on considère que le contrôleur vide plus rapidement la fifo que le Post DES
ne la remplie).
Etat Acquisition :
- On passe Read Enable de la fifo d’entrée à 1 pour préparer la donnée n°2.
- On transmet les 32 bits (donnée n°1) à la fifo.
- On passe à l’état test_fin_acquisition.
Etat test_fin_acquisition :
- Remise à Zéro de Read Enable.
- Il test la valeur de Cptacquisition. Celle-ci est initialisée à la longueur des données
de la fifo (32). Si Cptacquisition vaut la valeur de la longueur des données du DES
(64) alors il passe en Attente_DES sinon à l’état Attente_fifo.
Dans notre cas Cptacquisition = 32 < 64 donc l’on passe en Attente_fifo.
- On incrémente Cptacquisition de 32.
Etat Attente_fifo :
L’on passe à l’état Acquisition.
Etat Acquisition :
- On passe Read Enable de la fifo d’entrée à 1 pour préparer la donnée n°3.
- On transmet les 32 bits (donnée n°2) à la fifo.
- On passe à l’état test_fin_acquisition.
- Remise à Zéro de Read Enable.
- Il test la valeur de Cptacquisition. Cptacquisition = 64 = Taille des données de sorties
donc l’on passe en Attente_DES.
- Réinitialisation de Cptacquisition.
Etat Attente_DES:
Le DES n’est pas occupé.
- On lance le décryptage des données n°1 et n°2 concaténées.
- On prévient le second processus qu’il peut faire basculer le DES en occupé
- On passe en état Attente_fifo.
Page | 32
b. Données entrée = 128bits (fifo in) et Données sortie = 64bits (DES).
Le Pre DES commence à son état INIT:
Etat Attente_fifo :
- Initialisation de signaux suite aux états suivants.
- La fifo n’a pas encore de donnée (Empty_fifo_in = ‘0’) :
Il reste donc bloquer à l’état Attente_fifo
La première donnée est disponible à sa sortie et empty_fifo_in est passé à 1.
Comme la fifo in détient au moins une donnée et que la fifo out est non pleine
alors l’état passe donc à Acquisition.
Etat Acquisition :
- On transmet les 64 bits de poids fort à la fifo.
- On passe à l’état Attente_DES.
Etat Attente_DES:
Le DES n’est pas occupé.
- On lance le décryptage.
- On passe en état test_fin_acquisition.
- On test la valeur de Cptacquisition. Celle-ci est initialisée à la longueur des données
(64) alors il passe en Attente_fifo sinon à l’état Acquisition.
Dans notre cas Cptacquisition = 128 > 64 donc l’on passe en état Acquisition
- On décrémente Cptacquisition de 64 (longueur donnée traitée).
Etat Acquisition :
- On transmet les 64 bits de poids faible à la fifo.
- On passe à l’état Attente_DES.
Etat Attente_DES:
Le DES n’a pas finit de traiter la première donnée :
- On attend que le DES soit libre.
Plus tard le DES passe en non occupé.
- On lance le décryptage.
- On passe en état test_fin_acquisition.
- On test la valeur de Cptacquisition. Dans notre cas Cptacquisition = 64 = longueur
des données de sortie donc l’on passe en état Attente_fifo
- On réinitialise Cptacquisition à 128 (longueur donnée d’entrée).
- On passe Read Enable à 1 pour préparer la donnée suivante.
Etat Attente_fifo :
- Remise à zéro de Read Enable……….
Page | 33
DIAGRAMME D’ETAT POST-DES
Reset
Init
Data_in_ready = ‘0’
Attente_fin_DES
Data_in_ready = ‘1’
Cpt_acquisition =
size_data_crypt
Acquisition
Cptacquisition !=
size_data_crypt
------- Conditions dans le cas ou le nombre de bits des données d’entrées est moins important ou
égale aux nombres de bits des données de sortie.
------- Conditions dans le cas ou le nombre de bits des données d’entrées est plus important que le
nombre de bits des données de sortie.
-------
Conditions dans les deux cas.
ETAT
Init
DESCRIPTION
permet l’initialisation des sorties, des signaux….
Attente_fin_DES
Permet d’attendre qu’une donnée décryptée soit présente en sortie du
DES.
Cet état permet de récupérer la donnée en sortie du DES et d’adapter
celle-ci selon le nombre de bits d’entrée de la Fifo.
Acquisition
Page | 34
2. Scénario possible :
a. Données sortie = 32bits (fifo out) et Données entrée = 64bits (DES).
Le Post DES commence à son état INIT:
Etat Attente_fin_DES :
- Il passe Write Enable de la fifo de sortie à 0 (voir par la suite).
- On passe le signal prévenant PRE_DES qu’il peut lancer un nouveau calcul à ‘0’ (voir par la
suite)
- Le DES n’a pas encore finit de décrypter une donnée (data_in_ready = ‘0’) :
Il reste donc bloquer à l’état Attente_fin_DES.
- Le DES a finit de décrypter une donnée :
La donnée est disponible à sa sortie et data_in_ready passe à ‘1’. L’état passe donc à
Acquisition.
Etat Acquisition :
- Au premier front d’horloge :
- Il passe Write Enable de la fifo de sortie à 1.
- Il transmet les 32 bits de poids fort à la fifo.
- Il test la valeur de Cptacquisition. Celle-ci est initialisée à la longueur des données
(64) alors il passe en Attente_fin_DES sinon il continue à récupérer et à transmettre.
Dans notre cas Cptacquisition = 32 < 64 donc l’on reste dans l’état acquisition.
- Il incrémente Cptacquisition de 32 (longueur donnée d’entrée).
- Au second front d’horloge :
- Write Enable est toujours à 1.
- Il transmet les 32 bits de poids faible à la fifo.
- Il test la valeur de Cptacquisition. Celle-ci vaut 64 = longueur donnée d’entrée, donc
l’état passe à Attente_DES.
- On ré-initialise Cptacquisition à la longueur de la donnée d’entrée (32).
- On prévient PRE_DES que la donnée est lue il qu’il peut lancer un nouveau calcul.
- On attend qu’une donnée soit prête (data_in_ready = ‘1’) ;
Si les Données de sortie et d’entrée sont identique = 64bits alors l’on se retrouve avec le
même cas sauf que l’on ne restera dans l’état acquisition que pendant un coup d’horloge.
Page | 35
Données sortie = 128bits (fifo out) et Données entrée = 64bits (DES).
Le Post DES commence à son état INIT:
- On passe le signal prévenant PRE_DES qu’il peut lancer un nouveau calcul à ‘0’.
- Il attend qu’une donnée soit présente.
- Data_in_ready passe à ‘1’ et l’état passe en acquisition.
Etat Acquisition :
- Il transmet les 64 bits d’entrée et de poids fort à la fifo.
- Il test la valeur de Cptacquisition (cette fois-ci initialisée à la longueur des données de sortie
soit 128).
- Cptacquisition est différent de la longueur des données d’entrée (64) alors :
- On décrémente Cptacquisition de la longueur des données d’entrées (64).
- On passe en état Attente_fin_DES.
- On signale à PRE_DES qu’il peut lancer un nouveau décryptage.
- On passe le signal prévenant PRE_DES qu’il peut lancer un nouveau calcul à ‘0’.
- Il attend qu’une donnée soit présente.
- Data_in_ready passe à ‘1’ et l’état passe en acquisition.
Etat Acquisition :
- Il transmet les 64 bits d’entrée et de poids faible à la fifo.
- Il test la valeur de Cptacquisition. Celle-ci vaut 64 :
- On effectue Write Enable à ‘1’ pour enregistrer les deux données de 64 bits
concaténées dans la fifo de sortie.
- Ré-initialisation de Cptacquisition.
- On passe en état Attente_fin_DES.
- On signale à PRE_DES qu’il peut lancer un nouveau décryptage.
Page | 36

securisation/pro composants materiel securisation/protection de

Transcription

Documents pareils

Document d`information sur le stage obligatoire en Licence 3

FICHE DE POSTE PRAG en Mathématiques Titulaire d`un CAPES

SpiTex T75 M1 : une toile tramée

ats lurcat.indd - Lycée Jean

Approche de la victime ABCDE Bilans

N° N° - ATF Flexo

UPVD - Service de la Scolarité UFR SJE

aéroport rouen

aEs - IUT du Creusot - Université de Bourgogne

Spcifications techniques pour la gravure de CD et de DVD