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 1recamé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.htm

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.