Le rapport détaille un stage chez l'entreprise L'Héritier où l'objectif était de développer un algorithme de cryptage intégré dans leurs caméras pour protéger des modules avancés. Le document présente l'entreprise, ses domaines d'expertise, le principe de fonctionnement du projet, les étapes de développement, et les technologies utilisées, notamment le microcontrôleur PIC pour le cryptage. L'Héritier se spécialise dans des caméras pour des applications militaires, médicales et industrielles, offrant des solutions innovantes en conditions de visibilité dégradées.

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.