CERVELLO Olivier
Entreprise : LHERITIER ALCEN
Maître de stage : Xavier Crouzy
Rapport de stage
Développement d’un algorith...
SOMMAIRE
Introduction
I. LHERITIER
1.1. Présentation
1.2. Domaines d’expertise
II. Présentation du projet
2.1. Principe de...
Introduction
L’objectif de mon stage chez LHERITIER était
d’implémenter un algorithme de cryptage dans
une caméra permetta...
Caméra Bas Niveau de Lumière / sCMOS
– ARTEMIS
La nouvelle gamme des caméras BNL ARTEMIS
développées par LHERITIER intègre...
compact permettent aux caméras EREBOS de
s’adapter à de nombreux usages.
LHERITIER a élargi sa gamme à des caméras à
temps...
Caméras de recopie HUD
LHERITIER fournit aux constructeurs d’avions
militaires (avions de combat, jets d’entraînement)
des...
II. Présentation du projet
2.1. Principe de fonctionnement
Au design existant (3 cartes FPGA Cyclone IV, une
carte d’alime...
Le nom PIC n'est pas officiellement un acronyme, bien
que la traduction en « Peripheral Interface Controller »
(« contrôle...
Note : Les microcontrôleurs PIC sont envoyés avec
LVP activé par défaut (si on utilise une puce
neuve on peut l’utiliser e...
Figure : Programmateur in situ
Pour la programmation, on utilise la sortie série
de l’ordinateur et le logiciel IcProg.
Fi...
III. Implémentation
3.1. Ressources utilisées
HARDWARE
PIC12F1822
Microcontrôleur 8-bits de type PIC (c’est-à-dire crées
p...
3.2. Réalisation de l’UART du PIC
Création d’une carte de développement
Le choix d’une programmation HVP nous a
contraints...
fonctionne de manière inverse (start à ‘0’ et stop
à ‘1’).
Photo : Caractère 0x55 envoyé par Realterm
Photo : Caractère re...
Photo : Communication du mot envoyé par le FPGA (en
haut) et de la clé renvoyée par le PIC (en bas)
Il faut bien comprendr...
Ces deux modes alternent comme on l’a vu dans
la figure précédente.
Ce code permet aussi la vérification et la
retransmiss...
Conclusion
La réalisation et l’implémentation de ce module
de cryptage m’ont permis de mettre à profit de
nombreuses facet...
Prochain SlideShare
Chargement dans…5
×

CERVELLO_Rapport de stage

390 vues

Publié le

0 commentaire
0 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

Aucun téléchargement
Vues
Nombre de vues
390
Sur SlideShare
0
Issues des intégrations
0
Intégrations
19
Actions
Partages
0
Téléchargements
4
Commentaires
0
J’aime
0
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

CERVELLO_Rapport de stage

  1. 1. CERVELLO Olivier Entreprise : LHERITIER ALCEN Maître de stage : Xavier Crouzy Rapport de stage Développement d’un algorithme de protection par cryptage embarqué dans une caméra Entreprise : LHERITIER Lieu : Parc d’entreprise – Cergy Saint-Christophe Dates : 15/06/2014 - 15/08/2014
  2. 2. SOMMAIRE Introduction I. LHERITIER 1.1. Présentation 1.2. Domaines d’expertise II. Présentation du projet 2.1. Principe de fonctionnement 2.2. Etapes du projet 2.3. Programmer un PIC 2.3.1. ICSP – In Serial Circuit Programming 2.3.2. Techniques de programmation 2.3.3. Programmateurs III. Implémentation 3.1. Ressources utilisées 3.2. Réalisation de l’UART du PIC 3.3. Communication PIC / PC 3.4. Communication PIC / FPGA 3.5. Cryptage Conclusion
  3. 3. Introduction L’objectif de mon stage chez LHERITIER était d’implémenter un algorithme de cryptage dans une caméra permettant de protéger certains modules avancés des caméras LHERITIER. Des exemples de modules avancés sont les modules de traitement d’image, de zoom numérique, d’amélioration de la qualité, de rectification des défauts. Ceci permettra d’assurer l’exclusivité des systèmes optiques LHERITIER et d’éviter que des concurrents puissent faire du reverse engineering sur ces modules internes qui sont un gage de qualité pour ces caméras hautes précision destinées principalement à des applications militaires. Ceci permettra aussi de contrôler la production, car le composant programmable responsable du cryptage sera probablement vendu séparément (déjà programmé) et la caméra ne pourra fonctionner sans celui-ci. Dans ce rapport nous présenterons l’entreprise et ses domaines d’expertise ainsi que ses produits phares, puis nous présenterons le principe et l’aspect théorique du projet pour enfin nous intéresser à l’implémentation elle-même. I. LHERITIER 1.1. Présentation LHERITIER est une petite structure d’une quarantaine d’employés, filiale du groupe ALCEN, entreprise travaillant dans 4 domaines : la défense & sécurité, l'énergie, le médical et l'aéronautique. Depuis 30 ans, LHERITIER est un acteur du domaine de l'optronique, spécialisé dans les conditions de visibilité dégradées. La société poursuit une politique dynamique de Recherche et Développement et propose des produits innovants et adaptés aux marchés de la défense, de la sécurité, de l'énergie et du transport. Les caméras LHERITIER résistent aux environnements les plus extrêmes (températures, fortes vibrations, chocs, radiations…). Elles intègrent des capacités de traitement d’image optimisant la restitution. 1.2. Domaines d’expertise Depuis plus de 25 ans, LHERITIER conçoit des caméras et développe des systèmes d’acquisition et de traitement d’images, plus particulièrement en bas niveau de lumière et en haute définition. Sa réputation s’est notamment affirmée dans les secteurs :  militaire : surveillance côtière et territoriale jour et nuit, trajectographie de missiles sous- marins, métrologie de champs de tirs ;  médical : angiographie rétinienne numérisée ;  industriel : dispositifs de visualisation embarqués (SNCF), guidage pour tramways et bus ;  scientifique : microscopie électronique et optique...
  4. 4. Caméra Bas Niveau de Lumière / sCMOS – ARTEMIS La nouvelle gamme des caméras BNL ARTEMIS développées par LHERITIER intègre, au cœur d’un design de caméra non refroidie, un capteur ‘Scientific CMOS’ (FAIRCHILD CIS1910F). Cette rupture technologique permet l’emploi d’une caméra BNL ultra-performante, tant en vision Jour qu’en vision de Nuit (dans la limite de Nuit Niveau 3 « Quart de Lune ») ainsi que ses systèmes de vision dérivés pour de multiples domaines : Défense :  Domaine Aérien: Voie visible (TV) pour Pods ou Charges utiles embarquées ;  Domaine Terrestre / Véhicules : Vision Panoramique (360°, Vision Jour/BNL), Surveillance Electro/Optique de Moyenne- Longue Portée ;  Domaine Maritime: Surveillance Longue- Portée (Tout Temps) pour bâtiments de Surface, Mâts périscopiques statiques. Aéronautique :  Caméra pour Vision Améliorée (système aide à l’atterrissage) pour Hélicoptères et Jets d’Affaires ;  Détection en mauvaises conditions climatiques. Securité :  Surveillance Côtière - Portuaire ;  Contrôle des Frontières ;  Sécurité Urbaine et Système de Surveillance pour Forces de maintien de l’ordre ;  Scientifique : Surveillance Jour/Nuit, sur Canal Vidéo unique : Observation des mouvements solaires, Astronomie. Médical :  Fluorescence. Les principales caractéristiques techniques d’ARTEMIS sont :  Ultra haute sensibilité du capteur (Efficacité quantique > à 25% en proche Infra-Rouge) ;  Très forte dynamique d’illumination : de 100 000 lux à 10-3 lux (Nuit Niveau 3) ;  Design compact ;  Dimensions: 70 x 70 x 34 mm;  Faible Masse : inf. à 350g ;  Caméra non refroidie, donc à faible consommation ;  Résolution Image : Format Full HD (2 Million de pixels) ;  Format Vidéo: Couleur ou Monochrome (Noir & Blanc). Les caméras ARTEMIS sont déjà opérationnelles sur certains sites sensibles. Elles répondent à toute demande de solution de surveillance (Défense, Aéronautique, Sécurité), dans des environnements standards ou dégradés, (Qualification Environnementale: MIL-STD 810F), grâce aux améliorations images embarquées :  Etirement d’Histogramme(DRC) en dynamique ;  Binning – Correction de Blemish en dynamique ;  Amélioration de la non-uniformité des Couleurs ;  Traitement moyennage récursif. Caméra Intensifiée ICCD – EREBOS LHERITIER développe depuis plus de 30 ans une gamme de caméras intensifiées dénommées EREBOS. La caméra intensifiée est strictement utilisée pour la vision nocturne (Conditions de Nuit 1 à 4) ou dans des conditions de luminosité très faible. L’image rendue, en format Haute Définition (HD), est le produit d’une haute technicité. Cette qualité d’image associée au processus de commande de haute performance et à un design
  5. 5. compact permettent aux caméras EREBOS de s’adapter à de nombreux usages. LHERITIER a élargi sa gamme à des caméras à temps de pause très réduit, permettant l’observation/détection de cibles à très grande vitesse. Les caméras intensifiées EREBOS ont de multiples applications :  Microscopie et Scientifique  Vision Nocturne pour véhicule  Surveillance Périmétrique/Côtière (opérée dans le système Jour/Nuit ATHENA)  Périscopie Sous-Marine  Astronomie La conception des caméras intensifiées EREBOS associe un tube intensificateur avec une caméra Haute-Définition (HD) HEMERA. Le tube intensificateur capture (phénomène dit Gating), en quelques nanosecondes, les photons externes et les transfère en électrons (via la photocathode), préalablement à l’intensification réalisée au sein des galettes de micro-canaux, au travers d’un réseau fibre optique. Après intensification, les électrons sont rendus en lumière visible (photons lumineux) au travers de la surface phosphorescente. Caméra portable Vision Jour/Nuit – CAT EYE Innovation mondiale, lancée commercialement mi-2014, CAT EYE est la 1re caméra portable de Vision Jour/Nuit, embarquant de l’Imagerie Active Gatée. CAT EYE dispose de capacités performantes et novatrices, offrant aux utilisateurs de la Défense comme de la Sécurité, une alternative nouvelle aux caméras classiques à base d’infrarouge. Destinée à équiper prioritairement les forces de maintien de l’ordre, les forces spéciales ainsi que les personnels militaires en intervention, CAT EYE permet d’opérer des missions d’observation à distance de sécurité, de surveiller des sites sensibles (frontières, côtes, ports, aéroports, stades), d’assurer des missions de renseignement lors d’évènements majeurs (sommets, pèlerinages, rassemblements de foules…) CAT EYE délivre, de jour comme de nuit, une image restituant la vision naturelle de l'œil : nette, fine et réaliste jusque dans les contrastes naturels identifiés par le cerveau humain. En mode passif, CAT EYE offre une excellente visibilité pour l’observation de jour jusque dans les bas niveaux de lumière (quart de lune) et également par temps de pluie, de brouillard ou de forte pollution. CAT EYE bénéficie également d’un double mode d’imagerie active. Via une source laser de faible puissance, l’opérateur choisit un éclairage en mode passif (mode illuminé) ou en mode actif gaté (crénelage spatial). Ce mode actif gaté permet la sélection d’une tranche ciblée de l’espace à plus ou moins 15 mètres. Il assure à l’utilisateur l’identification faciale d’un individu situé à 150 mètres, même en nuit profonde. D’architecture simple et robuste, la caméra CAT EYE opère sur une seule voie, en format vidéo Full HD, quel que soit le mode jour/nuit. Sa technologie unique d’imagerie active n’utilise pas de tube intensificateur. Elle consomme peu d’énergie et offre ainsi sur batterie une autonomie de mission jusqu’à 5 heures. La technologie OLED retenue délivre, via le monoculaire, une vision haute définition aussi bien en condition de jour que de nuit. CAT EYE fournit par ailleurs des informations essentielles (boussole, télémétrie, datation…), complétant l’enregistrement vidéo ou photo. Cette fonction d’enregistrement permet en particulier l’établissement de preuves juridiques et apporte le cas échéant une aide à la décision de l’opérateur. Avec CAT EYE, LHERITIER concrétise dans l’imagerie active son potentiel d’innovation. Cette avancée majeure complète son offre en bas- niveau de lumière notamment pour le domaine de la Sécurité et de la Défense.
  6. 6. Caméras de recopie HUD LHERITIER fournit aux constructeurs d’avions militaires (avions de combat, jets d’entraînement) des caméras de recopie HUD (Head-Up display ou Ecran Tête Haute), enregistrant en simultané la symbologie HUD et le paysage observé par le pilote. Conçues pour fonctionner en conditions nominales de vol ou en missions extrêmes, les caméras de recopie HUD sont une aide précieuse au rejeu de mission opérationnelle et à la formation des pilotes. Alignées dans l’axe du cockpit afin d’enregistrer la vue extérieure au pilote, elles enregistrent simultanément les données affichées des instruments de navigation en mission opérationnelle. Les caméras de recopie HUD présentent dès lors une image issue de la fusion de la vidéo (avec une dynamique optimisée par les algorithmes temps réel embarqués) et des informations de vol enregistrées en toute condition. Répondant à des conditions de qualifications extrêmes (gamme de température, degré d’humidité élevé, chocs violents notamment en conditions d’appontage, environnement pressurisé, haute altitude), les caméras de recopie HUD apportent un confort d’image inégalé. Bénéficiant d’un concept optique simple, d’un coût de revient optimisé, d’une présentation de qualité vidéo supérieure aux systèmes concurrents notamment concernant l’amélioration d’image par correction des effets du cockpit, les caméras HUD s’adaptent à chaque aéronef. LHERITIER, leader Mondial pour la fourniture de caméra de recopie HUD, équipe depuis près de 10 ans les avions de combat Mirage 2000, Mirage F1 et Rafale, ainsi que l’Avion d’entraînement Alphajet de Dassault Aviation. Plus récemment, LHERITIER a été sélectionnée pour équiper systématiquement les Avions de Combat F-15 et F-18 de Boeing. L’expertise de la société lui permet de répondre à toutes les demandes des constructeurs d’avions dans le monde. Caméras haute définition et Méga-pixels Ces caméras, compactes, bénéficient de structures simplifiées robustes pour des qualités d’image bien supérieures aux standards CCIR. Dotées en effet d’une architecture composée d’une carte (HEMERA HD, supportant des tailles de capteur allant du 1/6’’ au 2/3’’) à trois cartes (HEMERA MEGA avec capteur 11 MPx), de faible volume, elles intègrent des procédés embarqués d’amélioration de la qualité image comme l’amélioration de contraste, la réduction du bruit . Elles trouvent leurs applications dans tous les secteurs scientifiques, industriels, sécurité et militaires ou l’observation de détails en temps réel est importante. HEMERA MEGA De la taille d'un appareil photo 24X36, cette caméra génère un signal vidéo à partir de son capteur de 11 millions de pixels. Dotée d'un système de calibration dynamique, elle permet d'obtenir un flux vidéo supérieur à 5 images par seconde, idéal pour les applications de surveillance embarquée, de sécurité routière… HEMERA HD Son architecture monocarte la rendant très compacte, cette caméra durcie est adaptée aux systèmes de surveillance embarqués sur avions ou drones. Elle possède une capacité de calcul (FPGA, Mémoire) utilisée pour améliorer la qualité image de façon autonome et transparente pour l'utilisateur.
  7. 7. II. Présentation du projet 2.1. Principe de fonctionnement Au design existant (3 cartes FPGA Cyclone IV, une carte d’alimentation et une carte connecteur), nous allons rajouter un petit microprocesseur appelé PIC. Celui-ci sera responsable du cryptage en communiquant directement avec le FPGA. Lorsque le PIC est enlevé de la carte ou mis hors service, les fonctionnalités avancées de la caméra sont désactivées. Le PIC sera l’interface de communication avec le FPGA : il communiquera avec le FPGA en recevant des mots à crypter, les cryptant à l’aide d’une fonction de cryptage (ou fonction de hachage) et renvoyant le mot crypté au FPGA. Le FPGA intègrera en son sein une fonction de hachage similaire (codée « dans le dur » pour qu’on ne puisse pas la retrouver par reverse engineering), et un module qui se chargera de vérifier que le hash est correct, et de débloquer les fonctions de la caméra le cas échéant. 2.2. Etapes du projet 1. La première étape consistera à créer une carte de développement où l’on pourra tester le PIC (microprocesseur programmable) et y implémenter un bootloader et un programme de cryptage. 2. Ecrire un programme d’initialisation du PIC (en C), aussi appelé bootloader, qui se lancera à chaque Power-On-Reset (POR). Celui-ci est nécessaire pour faire un reset propre du PIC et pour initialiser correctement les registres gérant les protocoles de communication (UART par exemple) et le mode dans lequel est le PIC (programmation ou communication). 3. Burner le bootloader dans le PIC à l’aide du PICKIT 3 et observer les signaux qui transitent à l’aide du PICKIT 3 et de MPLab. 4. Faire un programme simple de transmission de données pour savoir si on a bien configuré le PIC. Par exemple, on envoie un octet à partir du PC et on regarde ce qu’il revient (réponse du PIC): si la donnée est la même, la transmission s’effectue correctements. 5. Une fois le PIC configuré correctement et prêt à recevoir et transmettre des données, faire quelques essais avec la communication FPGA / PIC. Ceci nécessite d’écrire un module VHDL implémenté sur le FPGA pour envoyer des données puis contrôler la réception. 6. Ecrire un programme de cryptage entre le PIC et le FPGA. Celui-ci sera divisé en 2 parties : une partie rédigée en C qu’on burnera avec le bootloader sur le PIC via le PICKIT 3 (et MPLab) ; la deuxième partie rédigée en VHDL qu’on implémentera sur le FPGA avec Quartus. 7. Faire en sorte si c’est possible d’effectuer le transfert du programme total devant aller sur le PIC (bootloader + programme) et le burner avec le FPGA directement. Il faut pour cela : - Récupérer le fichier .hex généré par MPLab et le transmettre à une mémoire du FPGA. - Rédiger un code VHDL pour le FPGA, permettant de transformer ce fichier .hex en bitstream compréhensible par la liaison ICSP du PIC. - Envoyer le bitstream directement via la connection ICSP établie entre le FPGA et le PIC. 2.3. Programmer un PIC Qu’est-ce qu’un PIC ? Les PIC (ou PICmicro dans la terminologie du fabricant) forment une famille de microcontrôleurs de la société Microchip.
  8. 8. Le nom PIC n'est pas officiellement un acronyme, bien que la traduction en « Peripheral Interface Controller » (« contrôleur d'interface périphérique ») soit généralement admise. Le PIC utilisé (Microchip PIC12F) étant déjà soudé sur la carte, nous ne pouvons (ni ne voulons) pas pour la phase de développement le dessouder, le programmer, puis le ressouder à chaque fois que l’on effectue une modification. On va donc chercher à programmer le PIC directement via la carte FPGA ou via un programmateur extérieur qui est transparent vis-à-vis du reste du système. 2.3.1. ICSP – In Circuit Serial Programming ICSP est l’interface série utilisée par le PIC pour télécharger un programme dans sa mémoire RAM (ou son EEPROM). ICSP est un moyen convenable de programmer un PIC sans le retirer de la carte de production / développement, ce qui nous intéresse pour la production finale même si dans un premier temps nous l’avons programmé séparément sur une carte de développement. VPP (or MCLRn) – Programming voltage (usually 13V). Vcc – Power (usually 5V). GND – Ground (0V). PGD – Usual port and connection RB7 PGC Clock – Usual port and connection RB6 PGM – Usual port and connection RB3/RB4 Figure: Schéma d’un connecteur ICSP. Signal VPP VPP est reliée à l’entrée de reset du PIC notée MCLR. Lors de la programmation ou la vérification ce signal est élevé au potentiel de programmation (13.5V en général ou VCC + 3.5V). Il indique ainsi au microcontrôleur que la programmation/vérification est sur le point de commencer. Il permet aussi pour des vieux PIC de fournir du courant. Note : Sur des PIC anciens cette ligne est utilisée directement pour alimenter le circuit mettant à jour la mémoire Flash du PIC. Cette connexion doit donc alors ramener du courant. Les nouveaux composants autorisent le LVP (Low Volt Programming) où la tension de programmation est générée en interne et VPP n’est plus qu’un indicateur (il ne fournit pas de courant) Signal VDD / VCC (puissance) Cette connexion fournit de la puissance au PIC, souvent à l’aide d’un régulateur 7805. Pour certains usages ceci peut être bénéfique puisqu’on peut développer une carte prototype sans avoir besoin d’autre source de puissance (juste une source qui se connecte sur le circuit de programmation du PIC). Signaux PGC et PGD (Horloge et Données) Ce sont ces signaux qui font le travail. Data (PGD) et Clock (PGC) transfèrent les données au PIC. Premièrement, les données sont envoyés à haute ou basse tension (0/1). Après un temps approprié l’horloge passe de l’état bas à l’état haut, ce qui fixe les données dans le PIC. PGD est aussi la ligne utilisée par le PIC pendant la vérification (bidirectionnelle). Signal PGM (Signal de programmation basse tension) Le but ici est de garder ce pin à l’état bas pour ne pas entrer dans le LVP mode (Low Volt Programming Mode). On met simplement une résistance pull down de 10k.
  9. 9. Note : Les microcontrôleurs PIC sont envoyés avec LVP activé par défaut (si on utilise une puce neuve on peut l’utiliser en LVP). Le seul moyen de changer le mode est d’utiliser un programmateur haute tension. 2.3.2. Techniques de programmation Programmation HVP La programmation de type HVP (High Voltage Programming) est effectuée en élevant la tension de la broche MCLR / VPP (P pour Programming) à VDD + 2.5V. La programmation s’effectue ensuite via les broches ICSPDAT et ICSPCLK (broches RA0 et RA1 respectivement). Programmer en HVP directement via le FPGA s’avère difficile car on ne possède aucun moyen de contrôle de la tension VPP. Il faudrait certainement rajouter au moins une pompe de tension hardware contrôlable via un I/O du FPGA mais cela n’est pas possible car le design est déjà réalisé. Programmation LVP L’idée d’une programmation LVP (Low Voltage Programming) est utile lorsque l’on souhaite programmer un PIC in situ, c’est-à-dire directement sur le design où elle se trouve (pas besoin de l’enlever de son support) Le protocole est le suivant : il suffit d’envoyer une séquence particulière de caractères au PIC via la broche ICSPDAT pour passer le PIC en mode programmation LVP. Il n’y a plus besoin d’élever la tension de la broche VPP. La séquence à envoyer est détaillée dans la datasheet du PIC12F1822 et cette étape est automatisée lorsqu’on travaille avec le PICKIT 3. Pour modifier a posteriori (si nécessaire) le firmware du PIC, sachant que celui-ci sera déjà soudé à la carte, il faudra utiliser ce type de programmation. 2.3.3. Programmateurs Bootloader Le Bootloader est un programme qu’on va placer dans le PIC et qui va servir à écrire dans la mémoire flash du PIC (EEPROM). Ce programme va se charger à chaque démarrage (alimentation) et initialiser le PIC comme on le veut. Il utilise n’importe quelle interface valable pour se charger dans l’EEPROM. Dans notre cas, il est écrit en C et ce qui nous intéresse est de pouvoir le charger dans le PIC directement avec la carte FPGA. Pour cela, il existe plusieurs types de programmateur : Programmateur in situ Un programmateur in situ permet de programmer directement le PIC sur son montage définitif : il n’y a pas à l’enlever, le mettre sur le programmateur, le remettre sur son montage et recommencer en cas de retouche du programme. 1ère possibilité : La carte supportant le pic a été prévue pour la programmation in situ : les broches MCLR, RB6 et RB7 vont vers un connecteur, partent vers le programmateur et en reviennent : En mode essais, le programmateur est transparent, ces trois broches reviennent sur le montage. En mode programmation, ces trois broches sont reliées au programmateur. Toutes les commutations se font automatiquement. 2ème possibilité : La carte n’est pas prévue pour le in situ : le programmateur vient alors se brancher à la place du PIC, et le PIC est enficher juste au- dessus. Les broches MCLR, RB6 et RB7 vont vers le programmateur et reviennent vers le montage. Le +5V peut aussi être acheminé.
  10. 10. Figure : Programmateur in situ Pour la programmation, on utilise la sortie série de l’ordinateur et le logiciel IcProg. Figure : Exemple de programmateur externe - TxD fait passer en mode programmation, la led s'allume et 4053 commute en position haute; après un délai introduit par le réseau 15k 0,68 uF, la tension sur MCLR passe à 13 Volts, le PIC est prêt à être programmé. - RTS envoie les tops d'horloge sur RB6 - DTR envoie les données à programmer sur RB7 En lecture du PIC, la procédure est la même et les données fournies par RB7 sont reçues sur CTS. Hors programmation le 4053 en position basse renvoie sur le montage les signaux MCLR, RB6 et RB7, le programmateur est transparent. Le programmateur nécessite une alimentation triple: 5V 13V et moins 12V; il transmet le 5V à la carte en essais. Le 13V peut être obtenu avec un régulateur 8V au- dessus du régulateur 5V, ou par deux diodes en série dans la patte de masse d'un régulateur 12V. Source : http://f5ad.free.fr/16F84/Programmateur_in_situ.ht m PICKIT 3 – Programmer-To-Go Le PICKIT est un programmateur de PIC facile d’utilisation. Il se présente comme un petit boîtier relié au PIC par un connecteur ICSP (cf. plus haut) et alimenté via l’USB relié au PC. Figure : Schéma d’utilisation du PICKIT Nous avons choisi d’utiliser le PICKIT pour 2 raisons : - Il dispose d’une fonctionnalité bien pratique, permettant de l’utiliser à la fois comme un programmateur externe (sur une carte de développement séparée) OU comme un programmateur in situ via la fonctionnalité Programmer-To-Go (cf. ci dessous). - Il permet de transférer un programme aisément via le programme MPLab. La fonctionnalité « PICkit 2 Programmer-To-Go » permet de télécharger une image mémoire MCU d’un PIC dans le PICkit 2 afin de pouvoir le télécharger dans un PIC MCU spécifique. Ceci veut dire qu’une fois le programme développé, nous le chargeons dans le PICKIT, et ensuite : Pas de logiciel ni de PC n’est nécessaire pour programmer le PIC une fois que le PICkit2 est dans le mode Programmer-To-Go. Une source d’énergie par USB pour le PICkit2 est tout ce qui est demandé. Remarque : La partie hardware du PICkit2 empêche le retour d’alimentation à travers le port VDD du connecteur ICSP du PIC. Source : http://ww1.microchip.com/downloads/en/DeviceDoc/PICkit %202%20Programmer-To-Go%20User%20Guide%20b.pdf
  11. 11. III. Implémentation 3.1. Ressources utilisées HARDWARE PIC12F1822 Microcontrôleur 8-bits de type PIC (c’est-à-dire crées par la société Microchip, leadeur dans le domaine). Il nous permet de discuter avec le FPGA de manière cryptée dans le but de créer une sécurité protégeant la caméra. Il est programmé via le programmateur hardware PICKIT3 sous le logiciel MPLAB. PICKIT3 Programmateur externe permettant la programmation in-situ (sans enlever le PIC de son environnement). Il permet d’automatiser la programmation qui manuellement est assez contraignante (il faut augmenter la tension sur le pin VPP pendant le temps de la programmation (HVP) ou envoyer une séquence de caractères bien précise pour passer le PIC en mode de programmation (LVP)). On gagne donc énormément de temps. USB-to-RS232 Il s’agit d’un boitier permettant d’établir une communication entre le PIC et le PC. Il convertit les signaux envoyés depuis le port USB du PC en signaux compatibles avec la logique TTL respectant la norme UART (RX / TX). Il suffit de connecter les ports RX, TX et GND à ceux du PIC12F1822 et de relier la tension d’alimentation du PIC à une source de tension (entre 2V et 3.7V) ALTERA CYCLONE IV Carte FPGA (Field-Programmable Gate Array ou Circuit logique programmable). Il permet d’accueillir le programme tournant sur la caméra (modules de traitements d’image ainsi que de correction gamma, de couleurs, routage etc. …). SOFTWARE MPLAB Software permettant de compiler le code C via le compileur HI-TECH C Compiler. Il permet la prise en charge complète du PICKIT 3 pour programmer ou débugger le PIC. Une des fonctionnalités intéressante est l’observation en temps réel des registres à l’intérieur du PIC via le menu View/Watch ainsi que celle du code situé dans la flash du PIC via le menu View/Program Memory. Une autre fonctionnalité bien pratique se trouve dans le menu Configure/Configuration Bits qui autorise l’utilisateur à modifier les bits de configuration sans les insérer dans le code : ils seront intégrés automatiquement lors de la compilation. Realterm Hyperterminal permettant d’interfacer avec le boitier USB-to-RS232 et de communiquer avec le PIC. Dans le menu display, cocher quel type nous voulons voir affiché à l’écran (ascii, hex(space) ou uint8 en général). Il faut cocher half duplex pour voir afficher les caractères envoyés à partir du PC. Ceux envoyés par le PIC apparaîtront automatiquement dans la console. Dans le menu port, il faut configurer le port utilisé en déroulant (le bon port est le x (serial port)). Il faut aussi régler le baudrate qui est définit dans le PIC à 9600. ALTERA QUARTUS Logiciel de design de dispositifs programmables (FPGA et CPLD). C’est grâce à Quartus que l’on va pouvoir faire une synthèse du code VHDL, corriger les warnings et les erreurs
  12. 12. 3.2. Réalisation de l’UART du PIC Création d’une carte de développement Le choix d’une programmation HVP nous a contraints dans un premier temps à utiliser une carte de développement spécifique comportant le PIC et la connectique RS232 nécessaire pour interfacer le PIC12F1822 avec le PICKIT 3. Cette carte de développement est très simple. Photo : Carte de développement du PIC12F1822 Choix d’un standard de communication Le choix s’est porté sur une communication UART ne nécessitant que 2 pins pour communiquer : TX – broche de transmission RX – broche de réception Ce type de communication est adaptée car elle utilise une séquence de transmission simple : START – DATA (8 bits) – STOP. De plus, le FPGA possède déjà un module d’UART près à être utilisé, donc nous n’avons pas eu à réecrire le module de communication du côté FPGA. Ecriture d’un programme d’initialisation d’UART sur le PIC Il a fallu initialiser différents registres (cf figure ci- contre) afin d’initialiser les pins de communication du PIC, de les configurer en entrée/sortie, de configurer le baudrate (ou bitrate) et d’initialiser l’UART. Photo : Mesure de la durée d’un bit pour configurer le registre BAUDCON gérant le baudrate. Figure : Code related to PIC registers to set up UART Le protocole de communication est au point, et les données sont correctement envoyées par le PIC, au baudrate voulu (9600 bauds). 3.3. Communication PIC / PC La communication PIC/PC nous permet d’établir le bon fonctionnement de l’UART du PIC. Le protocole est le suivant :  Envoi d’une séquence par le PC vers la pin RX du PIC.  Renvoi de la séquence reçue vers la pin TX du PIC puis vers le PC.  Comparaison de la valeur revenant sur le PC avec celle originellement envoyée. L’UART est fonctionnel lorsque les deux concordent. Nous avons eu des problèmes de réception dus au fait que le logiciel utilisé (Realterm) transmet des données avec une logique inverse de ce qu’attend le PIC : le bit de start est censé être un ‘0’ logique et le bit de stop un ‘1’, mais le logiciel
  13. 13. fonctionne de manière inverse (start à ‘0’ et stop à ‘1’). Photo : Caractère 0x55 envoyé par Realterm Photo : Caractère retransmis par le PIC Cependant, la transmission du PIC vers le PC a fini par fonctionner car nous avons inversé la broche TX du PIN en modifiant un registre du PIC (mais on ne peut pas inverser RX de cette façon). Ce problème est mineur car l’UART côté FPGA utilise la même norme de réception/transmission que le PIC donc la transmission entre les deux s’effectuera correctement. Photo : Transmission du mot « Bonjour » du PIC vers le PC 3.4. Communication PIC / FPGA Une fois le PIC initialisé dans le mode choisi (protocoles de communication USART), nous pouvons commencer les transferts de données PIC/FPGA. N’ayant pas d’interface graphique cette fois comme avec le PC, nous avons dû systématiquement utiliser l’oscilloscope pour vraiment voir les signaux entrants et sortant du PIC et vérifier qu’ils concordaient. Photo : Envoie de données via l’UART du PIC et écho par l’UART du FPGA. 3.5. Cryptage Protocole Le protocole choisi notre protection par cryptage est le suivant :  Envoi d’une séquence par le FPGA vers le PIC.  Cryptage de cette séquence dans le FPGA et dans le PIC.  Renvoi d’une clé de décodage par le PIC, appelé hash, vers le FPGA.  Comparaison des hash dans le FPGA, si OK autoriser le fonctionnement du reste du système. Sinon, éteindre.  Répéter ces opérations toutes les x frames (images, typiquement 30fps).
  14. 14. Photo : Communication du mot envoyé par le FPGA (en haut) et de la clé renvoyée par le PIC (en bas) Il faut bien comprendre que la fonction de hachage est implémentée à la fois dans le PIC et dans le FPGA, mais qu’elle ne peut être lue par personne, ni dans le premier ni dans le second, car : - Dans le FPGA, la fonction de hachage est « codée dans le dur », c’est un module hardware, ce qui signifie qu’une fois la synthèse terminée, il n’y a aucun moyen pour un utilisateur de disposant pas du code initial de remonter à cette fonction de hachage. - Le PIC sera fourni déjà programmé et de même que pour le FPGA, le code est déjà implémenté sous forme de bitstream. Il est presque impossible de retrouver le code C original en analysant un bitstream. Ces deux points garantissent une certaine sécurité dans ce protocole. Pour être précis et avoir une indication de temps sur l’envoi du mot à hasher par le FPGA, le renvoi du hash par le PIC ou l’échec de la transmission, nous utilisons des mots précis (que nous évitons dans les hash et les mots à échanger eux-mêmes). Le FPGA contrôle l’intégralité du protocole de transmission et le PIC agit en esclave : - Un envoi de 0x01 par le FPGA indique au PIC que la transmission et le cryptage du côté du FPGA s’est produite correctement et que le PIC peut crypter le mot envoyé. - Un envoi de 0x55 par le FPGA indique au PIC qu’il doit envoyer un byte du hash. - Un envoi de 0x02 signifie un échec dans la transmission et il est donc nécessaire de retransmettre le mot à hasher. - Pour tout autre envoi, le PIC interprète le byte reçu comme un byte du mot envoyé par le FPGA. Figure : Code du protocole de transmission dans le PIC Typiquement, le protocole implémenté est le suivant : FPGA PIC Frame Received Sent Received Sent 0 word_FPGA[0] 1 word_FPGA[1] word_PIC[0] 2 word_FPGA[2] word_PIC[1] 3 word_FPGA[3] word_PIC[2] 4 word_PIC[3] 5 0x01 6 0x01 7 0x55 8 0x55 hash_PIC[0] 9 hash_PIC[0] 0x55 10 0x55 hash_PIC[1] 11 hash_PIC[1] 0x55 12 0x55 hash_PIC[2] 13 hash_PIC[2] 0x55 14 0x55 hash_PIC[3] 15 hash_PIC[3] Figure : Protocole de communication FPGA / PIC Le protocole précédent est géré entièrement par un module FPGA dont une partie du code est présenté ci-dessous. Il se décompose principalement en deux conditions permettant de reconnaître un mode write (écrire sur la pin de transmision) ou un mode read (lire le buffer de la pin de réception).
  15. 15. Ces deux modes alternent comme on l’a vu dans la figure précédente. Ce code permet aussi la vérification et la retransmission de mots dont la communication a été défectueuse. Il réessaye jusqu’à 3 fois de retransmettre (hash_retry < 3). Si le mot n’est toujours pas bien retransmis, cela signifie que le PIC n’est pas connecté ou que son code a été modifié : dans ce cas on arrête la caméra en utilisant le bit hash_failure dans une autre function. Figure : Code du module FPGA implémenté Algorithme de cryptage La nécessité d’un code de taille très réduite dans le PIC nous a forcé d’utiliser un algorithme de cryptage limité en taille. Nous n’avions pas la place nécessaire pour implémenter un des algorithmes connus RSA, SHA3, MD5, de ce fait nous avons choisi de faire notre propre fonction de hachage basé sur un principe très répandu dans les algorithmes de cryptage sus-nommés appelé shuffle. Il s’agit tout simplement de décaler du mot original d’un octet et de réaliser ce décalage dans une boucle de 8 octets. Figure: Fonction de cryptage dans le FPGA La fonction de hachage ainsi réalisé à toutes les propriétés attendues d’une fonction de hachage classique (notamment non-collision et injectivité). Moi et mon maître de stage avons considéré que cette fonction de hachage, bien que très simple, est suffisante pour assurer la sécurité du système et décourager les personnes souhaitant effectuer du reverse engineering sur la carte. Rappelons aussi qu’une première protection est assurée par le fait que les fonctions de hachage soient codées dans le dur, ce qui rend le reverse engineering très difficile (voir impossible pour un design de la taille de celui-ci, c’est-à-dire plusieurs millions de lignes de codes !), comme en témoigne de nombreuses sources : “With the encryption technology supported by Xilinx where the keys are stored in a battery backed volatile storage on the FPGA, getting your hands on unencrypted bitstream is extremely difficult let alone reverse engineering to get a gate level representation which can be implemented again to get a functionality identical bitstream. I don't even want to think about getting a high level HDL representation of any non-trivial gate level design.” Source: Xilinx discussion forums OU https://www.emsec.rub.de/media/crypto/veroeffentlichu ngen/2013/01/11/StratixIIDPA_2.pdf
  16. 16. Conclusion La réalisation et l’implémentation de ce module de cryptage m’ont permis de mettre à profit de nombreuses facettes de ma formation d’ingénieur électronicien : électronique analogique, transmission du signal, conversion d’énergie, programmation en C et VHDL font partie des compétences exigées pour ce projet. Parmi les connaissances nouvelles acquises : programmation d’un PIC via différents moyens, apprentissage et mise en place de protocoles de communication courants et découverte des algorithmes de cryptage principalement utilisés. J’ai aussi pu observer comment un projet de taille considérable est géré et ordonné, tant au niveau des conventions d’écriture de code que de l’organisation générale des fichiers de projets et du réseau. J’ai aussi dû faire preuve de créativité ainsi que de beaucoup d’autonomie car aucun des ingénieurs de l’entreprise n’avait déjà travaillé avec un PIC. Leurs compétences techniques et leur expérience m’ont cependant été très utiles dans la mise en place des protocoles de communication, la réalisation des circuits électroniques (carte de développement) et l’utilisation des outils nécessaires à la maîtrise du projet, comme le logiciel de versions décentralisé Git, permettant de conserver les modifications effectuées et de revenir au précédent firmware quand un bug n’arrive pas à être corrigé, ou qu’une erreur ne peut être localisée facilement. Mon ressenti sur ce stage est bon, la communication avec les ingénieurs et techniciens s’avérait aisée. Travailler en open-space contribue à une meilleure aisance et à plus d’entraide directe de la part des autres employés.

×