SlideShare une entreprise Scribd logo
1  sur  16
Télécharger pour lire hors ligne
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
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
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...
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
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.
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.
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.
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.
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é.
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
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
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
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).
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).
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
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.

Contenu connexe

En vedette

Base de datos ACCESS 2010
Base de datos ACCESS 2010Base de datos ACCESS 2010
Base de datos ACCESS 2010Esteban Varon
 
VelotourCuba-Scenario-pedagogique-Doc-Diffusion
VelotourCuba-Scenario-pedagogique-Doc-DiffusionVelotourCuba-Scenario-pedagogique-Doc-Diffusion
VelotourCuba-Scenario-pedagogique-Doc-DiffusionRaquel Pollo Gonzalez
 
Laboratorio para el área tecnológica Fgrb m4 u2_gpo24
Laboratorio para el área tecnológica Fgrb m4 u2_gpo24Laboratorio para el área tecnológica Fgrb m4 u2_gpo24
Laboratorio para el área tecnológica Fgrb m4 u2_gpo24Germán Reyes
 
operaciones combinadas
operaciones combinadasoperaciones combinadas
operaciones combinadasangelaanabella
 
Caveclandestine copie
Caveclandestine   copieCaveclandestine   copie
Caveclandestine copiecracodan
 
Presentación Plastic Repair System
Presentación Plastic Repair SystemPresentación Plastic Repair System
Presentación Plastic Repair SystemANEPMA
 
Ejercicio 1 maquete utilizando css externo
Ejercicio 1 maquete utilizando css externoEjercicio 1 maquete utilizando css externo
Ejercicio 1 maquete utilizando css externoMerly QA
 
Maicol garcia y lessly tique
Maicol garcia y lessly tiqueMaicol garcia y lessly tique
Maicol garcia y lessly tiqueLessly Tique
 
Sondage Personal Branding au service de la marque par L'Atelier et l'Ifop
Sondage Personal Branding au service de la marque par L'Atelier et l'IfopSondage Personal Branding au service de la marque par L'Atelier et l'Ifop
Sondage Personal Branding au service de la marque par L'Atelier et l'IfopL'Atelier BNP Paribas
 
FERIA DE LA CIENCIA
FERIA DE LA CIENCIAFERIA DE LA CIENCIA
FERIA DE LA CIENCIAemilita12
 
PréSentation Lamortauxtrousses
PréSentation LamortauxtroussesPréSentation Lamortauxtrousses
PréSentation LamortauxtroussesMélanie Auriel
 
Repositorios taller-nora-medina-2014ppt
Repositorios taller-nora-medina-2014pptRepositorios taller-nora-medina-2014ppt
Repositorios taller-nora-medina-2014pptmariaauxiliadora79
 
Presentación Informe RSS ANEPMA 2014. Miguel Ángel Pérez Alonso, LIMASA
Presentación Informe RSS ANEPMA 2014. Miguel Ángel Pérez Alonso, LIMASAPresentación Informe RSS ANEPMA 2014. Miguel Ángel Pérez Alonso, LIMASA
Presentación Informe RSS ANEPMA 2014. Miguel Ángel Pérez Alonso, LIMASAANEPMA
 

En vedette (20)

My Sql [6
My Sql [6My Sql [6
My Sql [6
 
Base de datos ACCESS 2010
Base de datos ACCESS 2010Base de datos ACCESS 2010
Base de datos ACCESS 2010
 
VelotourCuba-Scenario-pedagogique-Doc-Diffusion
VelotourCuba-Scenario-pedagogique-Doc-DiffusionVelotourCuba-Scenario-pedagogique-Doc-Diffusion
VelotourCuba-Scenario-pedagogique-Doc-Diffusion
 
SICAS
SICASSICAS
SICAS
 
Laboratorio para el área tecnológica Fgrb m4 u2_gpo24
Laboratorio para el área tecnológica Fgrb m4 u2_gpo24Laboratorio para el área tecnológica Fgrb m4 u2_gpo24
Laboratorio para el área tecnológica Fgrb m4 u2_gpo24
 
operaciones combinadas
operaciones combinadasoperaciones combinadas
operaciones combinadas
 
Caveclandestine copie
Caveclandestine   copieCaveclandestine   copie
Caveclandestine copie
 
Presentación Plastic Repair System
Presentación Plastic Repair SystemPresentación Plastic Repair System
Presentación Plastic Repair System
 
Plagio.
Plagio.Plagio.
Plagio.
 
Plan Marketing Nike+
Plan Marketing Nike+Plan Marketing Nike+
Plan Marketing Nike+
 
Socle anglais-tice
Socle anglais-ticeSocle anglais-tice
Socle anglais-tice
 
Idées cadeaux pour Noël à Saint Rémy de Provence
Idées cadeaux pour Noël à Saint Rémy de ProvenceIdées cadeaux pour Noël à Saint Rémy de Provence
Idées cadeaux pour Noël à Saint Rémy de Provence
 
Ejercicio 1 maquete utilizando css externo
Ejercicio 1 maquete utilizando css externoEjercicio 1 maquete utilizando css externo
Ejercicio 1 maquete utilizando css externo
 
Gastro-peques
Gastro-pequesGastro-peques
Gastro-peques
 
Maicol garcia y lessly tique
Maicol garcia y lessly tiqueMaicol garcia y lessly tique
Maicol garcia y lessly tique
 
Sondage Personal Branding au service de la marque par L'Atelier et l'Ifop
Sondage Personal Branding au service de la marque par L'Atelier et l'IfopSondage Personal Branding au service de la marque par L'Atelier et l'Ifop
Sondage Personal Branding au service de la marque par L'Atelier et l'Ifop
 
FERIA DE LA CIENCIA
FERIA DE LA CIENCIAFERIA DE LA CIENCIA
FERIA DE LA CIENCIA
 
PréSentation Lamortauxtrousses
PréSentation LamortauxtroussesPréSentation Lamortauxtrousses
PréSentation Lamortauxtrousses
 
Repositorios taller-nora-medina-2014ppt
Repositorios taller-nora-medina-2014pptRepositorios taller-nora-medina-2014ppt
Repositorios taller-nora-medina-2014ppt
 
Presentación Informe RSS ANEPMA 2014. Miguel Ángel Pérez Alonso, LIMASA
Presentación Informe RSS ANEPMA 2014. Miguel Ángel Pérez Alonso, LIMASAPresentación Informe RSS ANEPMA 2014. Miguel Ángel Pérez Alonso, LIMASA
Presentación Informe RSS ANEPMA 2014. Miguel Ángel Pérez Alonso, LIMASA
 

Similaire à CERVELLO_Rapport de stage

Video surveillance fr_web
Video surveillance fr_webVideo surveillance fr_web
Video surveillance fr_webghkamel
 
PSM sécurité intégrée - sécurité du périmètre
PSM sécurité intégrée - sécurité du périmètrePSM sécurité intégrée - sécurité du périmètre
PSM sécurité intégrée - sécurité du périmètreGET Time & Security
 
Etat de l'art videosurveillance sur IP
Etat de l'art videosurveillance sur IPEtat de l'art videosurveillance sur IP
Etat de l'art videosurveillance sur IPPersonal Interactor
 
Presentation eocortex 3.5
Presentation eocortex 3.5 Presentation eocortex 3.5
Presentation eocortex 3.5 polyline
 
Poster_BAHNA_2015
Poster_BAHNA_2015Poster_BAHNA_2015
Poster_BAHNA_2015Amir BAHNA
 
Catalogue Routeurs 2019
Catalogue Routeurs 2019Catalogue Routeurs 2019
Catalogue Routeurs 2019DISTRIMEDIA
 
Agt solutions solution_video_surveillance-341
Agt solutions solution_video_surveillance-341Agt solutions solution_video_surveillance-341
Agt solutions solution_video_surveillance-341loufton2loufton
 
BIV CITEA - Borne Information Voyageurs aux arrêts
BIV CITEA - Borne Information Voyageurs aux arrêtsBIV CITEA - Borne Information Voyageurs aux arrêts
BIV CITEA - Borne Information Voyageurs aux arrêtsELAN CITE
 
Présentation1
Présentation1Présentation1
Présentation1majed.echi
 
Présentation1
Présentation1Présentation1
Présentation1majed.echi
 
Introduction AYUDO Technology
Introduction AYUDO TechnologyIntroduction AYUDO Technology
Introduction AYUDO Technologyayudo_france
 
Mobile World Congress 2017 - Debrief by Niji
Mobile World Congress 2017 - Debrief by NijiMobile World Congress 2017 - Debrief by Niji
Mobile World Congress 2017 - Debrief by NijiNiji
 

Similaire à CERVELLO_Rapport de stage (20)

Video surveillance fr_web
Video surveillance fr_webVideo surveillance fr_web
Video surveillance fr_web
 
PSM sécurité intégrée - sécurité du périmètre
PSM sécurité intégrée - sécurité du périmètrePSM sécurité intégrée - sécurité du périmètre
PSM sécurité intégrée - sécurité du périmètre
 
Catalogue Flir 2015
Catalogue Flir 2015Catalogue Flir 2015
Catalogue Flir 2015
 
Etat de l'art videosurveillance sur IP
Etat de l'art videosurveillance sur IPEtat de l'art videosurveillance sur IP
Etat de l'art videosurveillance sur IP
 
1070 t6 (1) (1)
1070 t6 (1) (1)1070 t6 (1) (1)
1070 t6 (1) (1)
 
Presentation eocortex 3.5
Presentation eocortex 3.5 Presentation eocortex 3.5
Presentation eocortex 3.5
 
Poster_BAHNA_2015
Poster_BAHNA_2015Poster_BAHNA_2015
Poster_BAHNA_2015
 
4èmes Rencontres ASIT VD - Drones : de la technologies aux applications
4èmes Rencontres ASIT VD - Drones : de la technologies aux applications4èmes Rencontres ASIT VD - Drones : de la technologies aux applications
4èmes Rencontres ASIT VD - Drones : de la technologies aux applications
 
Mega Sd Presen 1 V1 1
Mega Sd Presen 1 V1 1Mega Sd Presen 1 V1 1
Mega Sd Presen 1 V1 1
 
Révélation de traces de sang sur des textiles sombres ou colorés avec un Niko...
Révélation de traces de sang sur des textiles sombres ou colorés avec un Niko...Révélation de traces de sang sur des textiles sombres ou colorés avec un Niko...
Révélation de traces de sang sur des textiles sombres ou colorés avec un Niko...
 
Catalogue Routeurs 2019
Catalogue Routeurs 2019Catalogue Routeurs 2019
Catalogue Routeurs 2019
 
Présentation Alarm view
Présentation Alarm view Présentation Alarm view
Présentation Alarm view
 
Technoaware fr-v maghreb - leg
Technoaware fr-v maghreb - legTechnoaware fr-v maghreb - leg
Technoaware fr-v maghreb - leg
 
Agt solutions solution_video_surveillance-341
Agt solutions solution_video_surveillance-341Agt solutions solution_video_surveillance-341
Agt solutions solution_video_surveillance-341
 
BIV CITEA - Borne Information Voyageurs aux arrêts
BIV CITEA - Borne Information Voyageurs aux arrêtsBIV CITEA - Borne Information Voyageurs aux arrêts
BIV CITEA - Borne Information Voyageurs aux arrêts
 
www.radar-concept.com
www.radar-concept.comwww.radar-concept.com
www.radar-concept.com
 
Présentation1
Présentation1Présentation1
Présentation1
 
Présentation1
Présentation1Présentation1
Présentation1
 
Introduction AYUDO Technology
Introduction AYUDO TechnologyIntroduction AYUDO Technology
Introduction AYUDO Technology
 
Mobile World Congress 2017 - Debrief by Niji
Mobile World Congress 2017 - Debrief by NijiMobile World Congress 2017 - Debrief by Niji
Mobile World Congress 2017 - Debrief by Niji
 

CERVELLO_Rapport de stage

  • 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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.