SOMMAIRE INTRODUCTION PRESENTATION DU SUJET EXPLICATION DU CONTEXTE 1.2. OBJECTIFS ET CAHIER DES CHARGES 1.3. ENVIRONNEMENT DU SYSTEME

Transcription

1 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

2 SOMMAIRE INTRODUCTION PRESENTATION DU SUJET EXPLICATION DU CONTEXTE 1.2. OBJECTIFS ET CAHIER DES CHARGES 1.3. ENVIRONNEMENT DU SYSTEME 2. SPECIFICATIONS MATERIELLES ARCHITECTURE DU SYSTEME MMSC 2.2. DEFINITION DES SCENARIOS 2.3. CHOIX DES IPS DE CRYPTAGE 3. L INTERFACE GRAPHIQUE BESOIN 3.2 LES ETAPES DE CONFIGURATION 3.3 DIAGRAMMES DES CLASSES 4. PERFORMANCES APRES SYNTHESE SIMULATION ET TEST SIMULATION SOUS MODELSIM 5.2. IMPLEMENTATION SOUS XILINX SPARTAN 3E 6. CONCLUSION. 26 ANNEXES...27

3 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

4 I- Présentation du sujet : 1.1. 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

5 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 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

6 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

7 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) 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

8 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

9 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

10 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

11 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

12 Trame n 1 : activer M2 1 2 Valider Clé mode 2 Trame n 2 : activer M3 2 3 Valider Clé mode 3 Trame n 3 : activer M5 3 5 Valider 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 : i. L'IP comporte 5 modes de fonctionnement : M1, M2, M3, M4, M5. 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 : 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

13 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 : i. L'IP comporte 5 modes de fonctionnement : M1, M2, M3, M4, M5. 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

14 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 Mode Etat 0 Actif 1 Inactif 2 Inactif 3 Inactif 4 Inactif 5 Inactif Lors de l'initialisation, les trames reçues de la part de l'utilisateur sont les suivantes : Trame n 1 : activer M2 1 2 Valider Clé mode 2 Etat de la RAM et du système : Adresse Valeur Mode Etat 0 Actif 1 Inactif 2 Actif 3 Inactif 4 Inactif 5 Inactif Trame n 2 : activer M3 2 3 Valider Clé mode 3 Etat de la RAM et du système : Adresse Valeur Mode Etat 0 Actif 1 Inactif 2 Actif 3 Actif 4 Inactif 5 Inactif Trame n 3 : désactiver M3 3 3 dévalider Clé mode 3 Page 12

15 Etat de la RAM et du système : Adresse Valeur Mode Etat 0 Actif 1 Inactif 2 Actif 3 Inactif 4 Inactif 5 Inactif Trame n 4 : activer M5 4 5 Valider Clé mode 5 Etat de la RAM et du système : Adresse Valeur Mode Etat 0 Actif 1 Inactif 2 Actif 3 Inactif 4 Inactif 5 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 : i. L'IP comporte 5 modes de fonctionnement : M1, M2, M3, M4, M5. ii. L'utilisateur possède les clés des 3 modes suivants : M2, M3, M5. iii. L'utilisateur souhaite activer les modes suivants : M2, M5 et M4 dont il ne connaît pas la clé. Page 13

16 Les trames suivantes sont reçues : 1 2 Valider Clé mode Valider Clé mode Valider Clé incorrecte 4 5 Valider 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 : i. L'IP comporte 5 modes de fonctionnement : M1, M2, M3, M4, M5. ii. L'utilisateur possède les clés des 3 modes suivants : M2, M3, M5. 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 : 1 2 Valider Clé mode Valider Clé mode Valider Clé mode 5 Page 14

17 Trame reçue : 1 2 Valider Clé mode Valider Clé mode Valider 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 : i. L'IP comporte 5 modes de fonctionnement : M1, M2, M3, M4, M5. ii. L'utilisateur possède les clés des 3 modes suivants : M2, M3, M5. 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 : 1 2 Valider Clé mode Valider Clé mode Clé mode 5 L'erreur sur la trame 3 est détectée et signalée par le biais du signal error. Page 15

18 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 AES-FAST MINI-AES DES simple Triple DES Optimisation Speed Area Speed Area Speed Area Speed Area Speed Area Slices 14% (670) 19% (895) 155% (7218) 160% (7471) 77% (3622) 72% (3382) 6% (293) 5% (276) 34% (1670) 28% (1309) Slice Flip Flops 3% (291) 3% (325) 9% (914) 7% (657) 41% (3873) 40% (3785) 2% (192) 1% (125) 13% (1227) 10% (1012) 4 input LUTs 13% (1284) 16% (1569) 150% (13986) 140% (13105) 42% (3934) 38% (3600) 5% (555) 5% (512) 28% (2680) 25% (2347) IOs bonded IOBs 13% (31) 13% (31) 112% (262) 112% (262) 12% (29) 12% (29) 82% (191) 82% (191) 130% (302) 130% (302) BRAMs 15% 20% % 20% (3) (4) (4) (4) GCLKs 4% (1) 4% (1) 4% (1) 4% (1) 8% (2) 8% (2) 4% (1) 4% (1) 4% (1) 4% (1) Maximum Frequency MHz MHz MHz MHz MHz MHz MHz MHz MHz MHz Durée de traitement (périodes d horloge) Debits (Mbps) Tableau 1 : Récapitulatif des résultats d'implémentation des IPs de cryptage DES Page 16

19 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 : XOR Optimisation The same for Speed or Area Slices 0% (19) Slice Flip Flops - 4 input LUTs 0% (33) IOs 100 bonded IOBs 43% (100) BRAMs - GCLKs 4% (1) Durée de traitement (périodes d horloge) 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

20 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. 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é dans les déclarations). Par conséquence la configuration 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 de cette interface permet de mettre en œuvre les étapes de configuration qui seront détaillées dans la partie suivante LES ETAPES DE CONFIGURATION: 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»ou «MMSC_des.vhd». La configuration de la FSM se réalise à travers les fichiers «MMSC_aes.vhd» 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

21 La gé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 des clés des différents modes puis l enregistrement de celles-ci dans un fichier texte 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 principale qui contient le 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

22 Explication des différentes relations L objet Blocks fait partie de la classe Interface : relation d agrégation. Les 4 objets FIFO, 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, on a besoin d instancier un objet de la classe Cryptage : relation de dépendance. Selon l algorithme de cryptage choisi dans la classe 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, FSM, Choix_Cryptage et FIFO héritent de la classe JFrame, classe qui permet de créer une fenêtre graphique. Les classes Blocks, 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, Choix_Cryptage) ) ou le fait de cocher une case (pour la classe Choix_Cryptage) ) ou choisir une option dans un menu (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 les 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 : Circuit : XC3S500E Boitier : FG320 Vitesse : -4 Taux d'occupation de chaque blocs Nombre de slices Area Optimization Speed Optimization 0 AES DES XOR fsm fifo_in fifo_out Figure 9 : Courbes des taux d'occupation de chaque bloc en nombre de slices Page 20

23 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 une communication correcte avec les deux Fifo. Débits (Mbps) en fonction des blocs de cryptage XOR DES AES Speed optimisation Area Optimisation Débits (Mbps) Figure 10 : Courbes des débits en fonction des différents blocs de cryptage. La figure 10, concerne 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

24 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

25 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 , 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

26 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

27 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

28 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

29 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 Schéma du bloc AES Post_aes Schéma bloc AES avec entrées / sorties Page 27

30 «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

31 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

32 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

33 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 Attente_fifo Acquisition Test_fin_ Acquisition Attente_DES DESCRIPTION permet l initialisation des sorties, des signaux. 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. Page 31

34 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 : - La fifo détient des données : 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. Etat 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

35 b. Données entrée = 128bits (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é à 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 prévient le second processus qu il peut faire basculer le DES en occupé - On passe en état test_fin_acquisition. Etat test_fin_acquisition : - On test la valeur de Cptacquisition. Celle-ci est initialisée à la longueur des données de la fifo (128). Si Cptacquisition vaut la valeur de la longueur des données du DES (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 prévient le second processus qu il peut faire basculer le DES en occupé - On passe en état test_fin_acquisition. Etat 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

36 DIAGRAMME D ETAT POST-DES Reset Init Data_in_ready = 0 Attente_fin_DES Data_in_ready = 1 Cpt_acquisition = size_data_crypt Cptacquisition!= size_data_crypt Acquisition 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 Attente_fin_DES Acquisition DESCRIPTION permet l initialisation des sorties, des signaux. 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. Page 34

37 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: - Il initialise tous les signaux et les sorties puis passe à l état Attente_fifo. 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 de la fifo (32). Si Cptacquisition vaut la valeur de la longueur des données du DES (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. Etat Attente_fin_DES : - Il passe Write Enable de la fifo de sortie à 0. - 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

38 Données sortie = 128bits (fifo out) et Données entrée = 64bits (DES). Le Post DES commence à son état INIT: - Il initialise tous les signaux et les sorties puis passe à l état Attente_fifo. Etat Attente_fin_DES : - Il passe Write Enable de la fifo de sortie à 0. - 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. Etat Attente_fin_DES : - Il passe Write Enable de la fifo de sortie à 0. - 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