Sécurité du cycle de vie d’un dispositif médical

Télécharger le fichier pdf d’un mémoire de fin d’études

Extension et segmentation du cycle de vie

La complexité et diversité croissantes des composants électroniques se répercutent sur le cycle de vie des objets cyber-physiques. Les flots de production s’étendent avec la multiplication des opérations d’intégration, vérification et assemblage; cela oblige les compagnies à de lourds investissements dans les équipements et compétences nécessaires pour ces étapes. Certaines entreprises se concentrent parfois entièrement pour une seule opération, phénomène accrut par la spécialisation économique. En outre la mondialisation favorise les échanges de matériels et de services à grandes échelle. Ainsi l’ensemble des phases de production et de développements des composants des SoCs se mondialisent, incluant des tierces parties délocalisées. Le cycle de vie est ainsi aujourd’hui segmenté entre différents fabricants et sous-traitants en charge de services techniques spécifiques (test, emballage, assemblage…). Cette distribution non standardisée des rôles varie selon la capacité (en termes de ressource et de compétence) des acteurs à réaliser les opérations.
Les informations contenues dans le présent document sont la propriété des contractants. Il ne peut être reproduit ou transmis à des tiers sans l’autorisation expresse des contractants. 8/123
Fonction Physique Non-clonable pour la Sécurité du Cycle de Vie des Objets Cyber-Physiques
§ Les acteurs de la chaine d’approvisionnement des SoC :
– Les concepteurs qui élaborent les masques des puces et incorporent souvent des IPs de tierces parties. Après la conception les dessins des masques sont transmis aux usines de production.
– Les fondeurs en charge de la fabrication des puces.
– Les OSATs (Outsources Semiconductor Assembly and Test Services), sous-traitants qui effectuent les étapes de tests et d’emballage des puces.
§ Original Component Manufacturer (OCM): entreprise qui produit un composant qui sera intégré dans le système, un semi-conducteur complet avec un micrologiciel spécifique. Plusieurs modèles sont proposés en vente, libre au fabricant du SOC de sélectionner celui à sa convenance. La fabrication du composant de l’OCM est souvent sous-traitée à des fondeurs et des OSATs.
§ Original Equipment Manufacturer (OEM): le fabricant de l’objet final, incorporant le système sur puce et tous les composants tierces. L’OEM définit les spécifications de son système et charge des tiers de la fabrication, distribution, déploiement et fin de vie des dispositifs. Selon ses besoin l’OEM choisit tel ou tel SoC disponible auprès des fournisseurs.
§ Electronic Manufacturing Service (EMS): sous-traitant qui réalise l’assemblage du SoC et des composants sur le PCB, ainsi que l’emballage et l’intégration logiciel final du dispositif produit. Nous constatons une multiplicité des acteurs et des interactions. Certaines étapes impliquent l’échange d’atouts sensibles : transfert de micrologiciels spécifiques au système sur puce, intégration d’application logiciel tierce, assemblage matériel par des sous-traitants…

Diversité des applications

La grande diversité des architectures, des modèles et des acteurs du cycle de vie IoT va de pair  avec l’immensité des applications émergentes dans ce domaine. Les usages en lien avec l’IoT se multiplient dans tous les domaines et dans de nombreux pays y compris la France [3]. Divers secteurs voient de nouveaux dispositifs émergés. La domotique connectée et automatisée émerge : thermostat, lampe, serrure…
Les informations contenues dans le présent document sont la propriété des contractants. Il ne peut être reproduit ou transmis à des tiers sans l’autorisation expresse des contractants. 9/123
Fonction Physique Non-clonable pour la Sécurité du Cycle de Vie des Objets Cyber-Physiques calcul perfectionné. Il en est de même pour une partie des dispositifs médicaux tels que les pompes à insuline, ou les stimulateurs cardiaques (pacemaker). Ce développement des objets connectés se constate aussi dans les milieux industriels, militaires et aéronautiques. La liste des applications et des métiers potentiellement concernés est longue. Cette multiplicité des usages s’appuie sur la création et l’amélioration des fonctionnalités des systèmes sur puce. Les capacités de calcul et de communication accrues offrent de nouveaux potentiels pour des applications inédites et performantes ; alliant connectivité et automatisation. Les atouts se multiplient et se diversifient. Cela génère des risques au cours du cycle de vie ainsi que de nouvelles exigences de sécurité, dépendantes du cas d’usage.
Selon l’usage destiné à l’objet connecté les phases de déploiement, d’utilisation, de maintenance mais aussi de fin de vie font intervenir des acteurs et des métiers différents. Les modes opératoires et les cadres légaux ne sont pas identiques ; ainsi que la nature des données et fonctions manipulées par le système. Ces spécificités, variables selon les usages et applications ciblées par l’objet cyber-physique, influencent nécessairement les objectifs et exigences de sécurité. Les exigences de sécurité dépendront entre autre du niveau de confidentialité requis pour les données générées et stockées par le circuit. De plus, selon l’application et l’interaction avec l’extérieur des objets connectés, le détournement ou l’interruption de leurs fonctionnements n’auront pas le même impact. De même les contraintes de coûts et performances varient selon les besoins des utilisateurs et des fabricants. Les objectifs peuvent porter sur le coût de fabrication et la surface silicium du circuit, sur sa durée de vie, sur la vitesse et précision des calculs ou sur l’autonomie énergétique. Ainsi chaque cas d’usage d’un dispositif IoT présente des exigences de coûts, de performances et de sécurité qui lui sont spécifiques. Etudier le cycle de vie IoT pour un cas prédéfini est moins complexe que d’établir un modèle générique.

Besoins pour la sécurité au cours du cycle de vie

Accroissement de la surface d’attaque

Quel que soit le cas d’usage étudié, des problématiques génériques sont établies. L’évolution des technologies et de l’écosystème de l’IoT – complexification et segmentation du cycle de vie, multiplication des atouts et des acteurs – aboutit à de nouveaux enjeux de sécurité pour le cycle de vie.
Criticité des fonctionnalités : Les objets connectés disposent de fonctionnalités de plus en plus étendues : automatisation, inter-connectivité, calcul embarqué. Si cela améliore leurs capacités, cela implique aussi une augmentation du nombre de fonctions et de données à protéger. Les dispositifs accumulent et traitent des données privées des utilisateurs (géolocalisation, données de santé) de plus en plus sensible et en plus grande quantité. Le règlement général sur la protection des données [4] impose que la confidentialité et l’intégrité de celles-ci soient assurées. En outre, dans certains domaines (industriel, médical, aéronautique…) les conséquences d’une compromission de l’application IoT sont fortes : un détournement d’une fonction de calcul ou de commande menace directement l’intégrité physique du système ou de l’utilisateur : un dispositif médical peut commander une mauvaise infusion, un thermostat connecté dérégler la température de sa zone industriel…
Multiplication des interactions acteurs – système : De nouveaux acteurs sont impliqués, la liste établie en section 1.1.2 est longue et diversifiée : développeurs logiciels, fournisseurs de composants matériels, services prestataires pour la maintenance et l’assistance techniques… Les objets connectés subissent de plus en plus d’interaction avec des tierces parties qui peuvent élever leurs privilèges et réaliser des opérations non-autorisées, notamment via les interfaces de débogage JTAG ( [5], [6]). Un acteur qui intervient sur le dispositif au cours d’une opération d’assemblage des composant matériels, ou pendant une maintenance, peut exploiter les fuites d’informations ou introduire des éléments malveillants tant logiciels que matériels (aussi dits Chevaux de Troie [7]). Ces menaces exposent les atouts, telles que les IPs (propriétés intellectuelles) intégrées dans le dispositif. Cela génère un fort besoin en authentification et en sécurisation des accès. Les interactions à distance sont aussi une source de menace. Une mise à jour logicielle développée par un tiers peut contenir un virus ; par ailleurs les autres dispositifs communicants sur le réseau peuvent être compromis et être un vecteur d’attaque contre l’objet ( [8], [9]). Dans ces situations, non-exhaustives, la confidentialité et l’intégrité des atouts sont menacées.
Les informations contenues dans le présent document sont la propriété des contractants. Il ne peut être reproduit ou transmis à des tiers sans l’autorisation expresse des contractants. 10 / 123
Fonction Physique Non-clonable pour la Sécurité du Cycle de Vie des Objets Cyber-Physiques Confiance matérielle des SoC : Aujourd’hui, les SoCs nécessitent la fabrication, l’intégration et l’assemblage de divers composants matériels. L’ensemble de ces phases est aujourd’hui mondialisé, segmenté entre différents acteurs. La confiance n’est pas assurée aisément. Il y’a un risque que ces tiers éléments matériels soient compromis au cours de leur fabrication ou de leur distribution ( [10], [11]). Les micrologiciels des systèmes sur puces, ainsi même que leurs composants matériels, sont désormais susceptibles d’être compromis ; incorporant des fonctions malveillantes ou des fuites d’informations.
En conséquence, un accroissement de la surface d’attaque est constaté. Les dispositifs comportent de plus en plus de composants matériels et logiciels. Ceux-ci sont de nature diverse et présentent des vulnérabilités qui leur sont propres. Les points d’entrées dans le système et les éléments sensibles se multiplient. Par ailleurs leur intégration implique des interactions et des accès physiques, parfois intrusifs, avec différents acteurs. Ces interactions peuvent être détournées, ou les acteurs usurpés. L’objet est exposé tout le long du cycle de vie, vulnérable face à des attaques d’origines multiples.

Accroissement des menaces et modèles d’adversaires

Les motivations des attaquants se multiplient : l’IoT concerne de plus en plus de données, parfois sensibles et sources de gain financier, et ce sans que la sécurité soit sérieusement prise en compte. De plus, l’IoT induit aussi une mise en réseau et des communications entre les systèmes et les utilisateurs, potentiellement un dispositif compromis peut ainsi fournir des accès ou données supplémentaires. L’exploitation des faiblesses de la sécurité des paramètres sensibles (mots de passe, clef de sécurité) fait notamment l’objet de nombreuses démonstrations. L’attaque de caméras connectées contre Dyn en 2016 [9] a provoqué des dégâts considérables. Les caméras, rattachées à un botnet, furent utilisées pour un DDoS de grande ampleur. La gestion des clefs d’authentication des caméras n’était pas assurée au cours du cycle de vie, aucune personnalisation des clefs et aucune vérification des accès. La sécurité de tels atouts doit être assurée tout au long du cycle de vie. Outre ces menaces qui s’appuient sur des failles logicielles, voir sur un simple manque d’hygiène en sécurité, la protection du matériel inquiète : les rapports d’étude sur les circuits intégrés et l’approvisionnement des composants électroniques pointent le nombre croissant des contrefaçons ainsi que le vol de propriétés intellectuels. Cela concerne y compris des domaines critiques (aéronautiques, militaires, médicales…)
Aujourd’hui les menaces se multiplient et se diversifient. Les scénarios d’attaques varient selon la capacité des attaquants et selon l’exposition du dispositif. La définition d’un modèle d’adversaires pour une étude sécurité peut s’avérer délicate. Nous relevons un modèle pertinent, établi par Bhunia et Ray [12], où les adversaires se classent selon le niveau d’accès aux interfaces logicielles et matérielles. Le tri se fait de l’accès le plus restreint (à distance, avec droit utilisateur seulement) à l’accès le plus intrusif (opération physique directe réalisée sur l’objet) :
§ Adversaire à distance exploitant des failles logicielles et matérielles :
– Adversaire sans privilèges qui attaque le système via l’application embarquée sur le SoC, et possède des droits utilisateurs restreints. Des failles logicielles ou matérielles sont exploitées pour élever les privilèges.
– Adversaire avec privilèges qui a des accès au système d’exploitation ; et peut interagir avec les communications et opérations internes du système. Les protections doivent intervenir aux couches basses du système (firmware ou matérielles).
– Adversaire avec privilèges et accès aux canaux auxiliaires qui, outre les accès classiques, dispose d’informations supplémentaires telles que la consommation d’énergie ou l’horloge.
§ Adversaire avec un accès physique au dispositif :
– Adversaire limité (dit naïf) qui utilise des équipements basiques (et peu cher) pour interagir avec le SoC via des accès usuels, type interface de débogage ou port JTAG.
– Adversaire avec équipement de rétro-ingénierie qui dispose des équipements et des compétences suffisantes pour extraire les micrologiciels ou les designs matériels du SoC, y compris les paramètres de sécurité sensibles (clefs cryptographiques ou DRM).
Les informations contenues dans le présent document sont la propriété des contractants. Il ne peut être reproduit ou transmis à des tiers sans l’autorisation expresse des contractants. 11 / 123
Fonction Physique Non-clonable pour la Sécurité du Cycle de Vie des Objets Cyber-Physiques
– Adversaire hautement intrusif qui compromet le SoC par l’intégration de fonctionnalités ou de composants malveillants (Trojan). Cela suppose des accès à des composants matériels pendant les premières phases de production du SoC.
Ces modèles d’adversaires ne sont pas pris en compte avec la même importance selon le cas d’usage et les enjeux de sécurité. Une analyse spécifique doit être menée pour définir les besoins du cas étudié. Il apparaît toutefois aujourd’hui obligatoire de considérer les menaces matérielles et de déployer des contremesures adéquates.

Sécurité matérielle et cycle de vie

Contremesures pour les menaces matérielles : état de l’art et limites de l’existant pour la sécurité du cycle de vie

Un ensemble de contremesures existent dans l’industrie et dans la littérature scientifique pour atténuer les menaces et les risques que font peser les différents adversaires sur le cycle de vie. Les travaux sur ces protections, parfois très différents, entremêlent plusieurs disciplines – cryptographie, électronique, physique. Dans l’état de l’art, des études pertinentes balayent les vulnérabilités des systèmes sur puces et les solutions existantes : [11] pour les contrefaçons, [7] pour les chevaux de Troie, ou encore [10] qui couvre un ensemble plus larges des menaces connues. Ces études intègrent le cycle de vie des puces électroniques dans les modèles d’adversaires, en particulier au niveau des phases de production. Plusieurs solutions atténuent les failles de sécurité sans toutefois répondre à tous les besoins et exigences du cycle.
Protection spécifique pour les IPs matérielles : Comme décrit en 1.1.1et 1.1.2 un système sur puce intègre des IPs d’origines diverses. La confidentialité peut être exigée tant pour certaines de ces IPs que pour le design du SoC dans son ensemble. Diverses approches sont listées dans l’état de l’art [10] pour la sécurité IPs :
– Marquage de filigrane : la signature du concepteur de l’IP est marquée dans le circuit et utilisée au cours du cycle de vie pour authentifier l’IP.
– Caractérisation d’empreinte physique : la signature du circuit est extraite à partir d’un ou plusieurs paramètres choisis. Cette signature assure l’authenticité du circuit au cours du cycle de vie. Une forme aboutit de cette contremesure est l’intégration de primitive PUF (Physical Unclonable Function) dans le design du circuit. Un PUF génère une réponse en fonction de l’état physique du circuit et d’un challenge fournit par un acteur (utilisateur, intégrateur, auditeur…). Stockés dans une base de donnée, ces couples challenge-réponses permettent d’établir un protocole d’authentification pour les acteurs du cycle de vie.
– Offuscation de design : Des éléments logiques additionnels – type portes logiques (XOR/XNOR) ou éléments mémoires – couplés avec les fonctions et les IPs du circuit complexifient le design. Dans certains cas, les fonctions / IPs ne s’activent que si les éléments d’offuscations sont soumis à un vecteur d’entrée spécifique. Cela rend plus difficile la rétro-ingénierie et l’extraction des IPs.
– Segmentation des masques de gravures : Le design du circuit est divisé et répartie entre différentes fonderies, généralement entre les couches silicium arrière (back-end) et avant (front-end). Cela dépend du nombre de ligne de métal, une référence prend la quatrième ligne de métal comme séparateur. L’assemblage et le test du circuit sont réalisés par la suite par un tiers acteur. Ces solutions apportent authenticité et confidentialité des IPs, toutefois elles ne répondent pas à tous les besoins du cycle de vie. Elles concernent la protection de l’IP d’un acteur, et non pas de l’ensemble des atouts du système. Les exigences de sécurité impliquent aussi les données privées de l’utilisateur, les fonctionnalités de l’objet et ses interactions avec l’extérieur. En outre, les solutions énumérées ne permettent pas l’usage ou la protection de clefs de sécurité, nécessaires pour les protocoles de chiffrement et d’authentification. Seule exception les PUFs, dont certaines implémentations remplissent les critères des primitives de sécurité pour la génération et stockage de clefs cryptographiques.
Les informations contenues dans le présent document sont la propriété descontractants. Il ne peut être reproduit ou transmis à des tiers sans l’autorisation expresse des contractants. 12 / 123
Fonction Physique Non-clonable pour la Sécurité du Cycle de Vie des Objets Cyber-Physiques Réduction de la fuite d’information : Les attaques par canaux auxiliaires sont une des menaces redoutées. L’analyse de variations des paramètres physiques (consommation énergétique, temps de calcul, émanation électromagnétique) permet d’extraire des informations sensibles tels que les clefs de chiffrement. L’accès non sécurisé des chaines de scan interne (utilisé pour du débogage) sont une faille par laquelle les clefs peuvent être extraites. Plusieurs solutions réduisent ces fuites d’informations:
– Injection de bruit aléatoire: Ajout d’opération pour introduire de l’aléa dans la consommation d’énergie du circuit, ou dans les temps de calcul, faisant ainsi échouer les analyses de corrélation.
– Mise à jour des clefs de sécurité et restriction de leur usage : Cette contremesure se concentre sur le protocole de sécurité. La clé est restreinte à un nombre limité d’utilisation ; l’attaquant doit alors réussir l’analyse avec peu de trace. Aussi la clef est modifiée régulièrement au cours du cycle de vie ; l’attaquant doit réitérer l’analyse pour chaque nouvelle clef.
– Sécurisation des chaines de scan : L’accès aux chaines internes pour le débogage peut être protégé par diverses méthodes. Un filtrage par des mécanismes d’authentification peut limiter l’accès aux informations sensibles [13], ou une désorganisation aléatoire de la chaine en sous-chaines.
Ces protections sont nécessaires car une compromission des clefs de sécurité à un impact grave sur le système. Les exigences de sécurité concernant ces modèles d’attaques sont parfois sévères, notamment dans le domaine des cartes à puce bancaire : des normes strictes imposent l’intégration et l’étude de contremesures robustes. Toutefois ces protections concernent uniquement la protection du stockage des clefs de sécurité, elles ne répondent pas aux autres besoins de sécurité : authenticité des IPs, génération des clefs de sécurité, répudiation des clefs corrompues ou obsolètes et confidentialité du design.
Lutte contre la contrefaçon : Dans les solutions décrites précédemment plusieurs d’entre elles assurent l’authenticité du matériel : le marquage de filigrane pour authentifier le concepteur, l’empreinte physique pour authentifier le circuit ou en particulier les PUFs qui potentiellement offrent un large espace de signature. En outre, les clefs de sécurité sont aussi un moyen de vérifier l’authenticité du circuit sous réserve que la génération, la programmation et le stockage de ces clefs soient sûre. Ici, une approche idéale est l’implémentation légère et sures d’un PUF vérifiant des critères de sécurité élevés, preuve de l’authenticité et de l’unicité des clefs de sécurité générés.
Une autre gamme de contremesures se base sur des techniques d’inspection [11] :
– Les tests électriques classiques : Tests paramétriques, tests fonctionnels ou tests
structurels ; initialement utilisés pour valider la bonne fabrication et la fonctionnalité des puces sont ici mis en œuvre pour vérifier l’authenticité et l’intégrité du circuit
– Les inspections physiques extérieures : Analyse de l’état du circuit sans décapsulation.
– Les inspections physiques internes : Intervention sur l’emballage du circuit pour exposer sa structure et réaliser une observation approfondie.
– Les analyses de matériaux : Observations du circuit et de ses couches internes par des équipements optiques ou physiques qui détaillent leur composition.
Si ces inspections offrent une authenticité forte du circuit, elles sont aussi couteuses, fastidieuses et ne couvrent que les premières phases du cycle. Elles ne sont réalisables que au cours de la production et ne répondent pas non plus aux autres besoins de sécurité du cycle de vie : génération et stockage des clefs de sécurité, sécurisation des accès physiques aux atouts sensibles ou mise à jour logicielle.

Solutions de sécurité complètes pour les besoins de sécurité du cycle de vie

La plupart des contremesures se limitent à répondre à un ou deux besoins de sécurité spécifiques, sans considérer l’ensemble du cycle de vie. Certains articles proposent toutefois des solutions de sécurité pour le cycle de vie, des supports matériels pour une gestion sûre et flexible des atouts du cycle de vie. Elles répondent aux besoins spécifiques du cycle de vie, décris en 1.1.2 et 1.2.1: authentification des acteurs et gestion sécurisée des accès, et ce pour diverses opérations du cycle.
Les informations contenues dans le présent document sont la propriété des contractants. Il ne peut être reproduit ou transmis à des tiers sans l’autorisation expresse des contractants. 13 / 123
Fonction Physique Non-clonable pour la Sécurité du Cycle de Vie des Objets Cyber-Physiques Architecture et protocole pour des mécanismes de débogage sécurisé et flexible [13]: Les auteurs détaillent une architecture personnalisée de l’interface de débogage de SoC. Elle assure la confidentialité des atouts et la sécurité des accès au SoC. Un mécanisme de filtre est intégré en amont du bus de débogage, les données qui y transitent sont chiffrées (AES). Cela inclut les micrologiciels propriétaires des concepteurs. Les identifiants des acteurs du cycle de vie (nommés en 1.1.2, OEM, OSAT…) sont stockés dans un table. La solution impose pour tout accès au SoC une authentification des acteurs avec ces identifiants. Le filtre peut chiffrer les données pour lesquelles l’acteur n’a aucun droit d’interaction. Pour contrer une extraction malveillante des clefs d’authentification (stockées en ROM) les auteurs suggèrent de substituer les clefs par un PUF. En l’occurrence, l’article [14] inclut l’intégration et l’utilisation d’un TERO-PUF dans l’architecture sécurisée de débogage. Une évaluation indique un surplus de surface qui ne dépasse pas 7 % du total initial requis pour le circuit de l’étude.
Plateforme de gestion sécurisée du cycle de vie du SoC et de ses IPs [15] : les auteurs proposent d’intégrer dans le SoC une IP matériel, un contrôleur qui d’une part stocke des informations de sécurité (code d’autorisation, identifiant, empreinte d’authentification) et qui par ailleurs contient des primitives de sécurité (implémentation matérielle cryptographique pour chiffrement ou authentification). Selon un ensemble de spécifications protocolaires ce contrôleur permet de sécuriser la communication et les interactions avec le SoC ; assurant l’authenticité des actions et la confidentialité des IPs. Un élément clef de l’architecture est la SRAM-PUF, un modèle PUF basé sur le comportement aléatoire des cellules mémoires pour générer la clef maîtresse assurant la confiance dans le SoC (Root of Trust)
Ces références sont les premiers travaux pertinents offrant une réponse aux besoins de sécurité du cycle de vie IoT. Dans les deux cas cités, nous constatons que les primitives PUFs jouent un rôle primordial. Ces fonctions matérielles sont un socle pour l’architecture de sécurité ; mécanismes de génération et de stockage des paramètres (clefs, signatures) sur lesquelles reposent les propriétés de sécurité.

Objectifs

Premier bilan sur la sécurité du cycle de vie IoT

L’accroissement de la surface d’attaque et des menaces (section 1.2) génère des besoins de sécurité importants tout au long du cycle de vie ; la sécurisation ne peut se faire sans prise en compte des menaces en amont ou en aval. Une étude approfondie de la sécurité du dispositif sur l’ensemble des phases de production et d’utilisation est nécessaire. Il existe des approches pour instaurer la confiance au cours du cycle de vie mais les schémas sont difficiles à mettre en place et leurs apports parfois limités. De plus les besoins en vérifications et surveillance décris en 1.1.1 nécessitent des accès flexibles. Chaque acteur requiert en effet des accès aux fonctionnalités et aux atouts du système pour performer les tâches spécifiques qui lui sont attribuées.
Comment assurer qu’une partie prenante dispose d’un accès uniquement aux atouts qui lui sont autorisées et nécessaires, et cela à travers les multiples phases du cycle de vie dotées de politiques d’accès distinctes ?
La sécurisation et la gestion de ces accès mène naturellement à la mise en œuvre de chiffrement pour assurer la confidentialité des données et de protocole d’authentification pour authentifier les acteurs. De telles primitives reposent sur des paramètres de sécurité: clefs de chiffrement, signature d‘authentification… Ces éléments sont stockés et manipulés par le matériel (au niveau du SoC) et cela oblige de prendre en compte des besoins en sécurité matérielle. Une première conclusion souligne les considérations suivantes :
– Des mécanismes matériels doivent être intégrés pour sécuriser le cycle de vie, gérer et filtrer les accès et actions réalisés dès les premières phases de production des puces.
– Ces mécanismes doivent être flexibles, c.à.d. permettre les accès et interactions nécessaires aux opérations d’intégration, programmation ou vérification au cours du cycle.
Les informations contenues dans le présent document sont la propriété des contractants. Il ne peut être reproduit ou transmis à des tiers sans l’autorisation expresse des contractants. 14 / 123
– Ces mécanismes doivent assurer une certaine robustesse contre les menaces matérielles, c.à.d. être sujet à une fuite d’information par canal auxiliaire limitée, offrir une certaine résistance à la rétro-ingénierie ou à la contrefaçon…
– Pour terminer ces mécanismes doivent offrir des possibilités de compromis, respectant les contraintes de ressources et d’usage du dispositif IoT.

Organisation du mémoire

La section 2 présente l’étude théorique de la sécurité d’un cas d’usage et ce avec l’appui d’une méthodologie de référence. Les objectifs sont d’acquérir un formalisme pour les analyses de sécurité, dégager les vulnérabilités induites par le cycle vie sur un cas concret et identifier les exigences à respecter pour une solution de sécurité efficace. En ce qui concerne le cas d’usage il a été retenu l’exemple des dispositifs médicaux (DM) connectés. Si les DMs apportent des bénéfices importants pour le secteur médical, leurs brèches de sécurité provoquent aussi des inquiétudes couramment relayées par les chercheurs du domaine lors des conférences. Une approche rationnelle est privilégiée pour estimer correctement les risques, une analyse de sécurité avec une vision globale du cycle de vie IoT. Cette étude révèle des vulnérabilités pernicieuses, toutefois l’intégration de protection se répercute sur le coût de fabrication, les performances de l’appareil ainsi que sur les contraintes d’utilisation et de maintenance. Nous concluons sur l’impératif de concevoir des mécanismes de sécurité flexibles et efficients qui répondent aux contraintes de coût et d’usage. Nous décidons par la suite de restreindre le périmètre de la thèse à la conception d’un nouveau modèle de Fonction Physique Non-clonable.
La section 3 offre un état de l’art des recherches sur les PUFs, avec pour intérêt premier la catégorie digital PUF. Cette gamme d’implémentations s’appuie sur un aléa de nature structurelle et se caractérise par une robustesse forte. Cela assure la reproductibilité des réponses de tels PUFs ; réduisant les risques de faux rejets et le besoin en code correcteur d’erreur. Le chapitre introduit d’abord des généralités sur les PUFs : définition, critères de classification, métriques de sécurité et avancement de la recherche. Nous détaillons ensuite les digital PUFs existants, les processus de fabrication à l’origine de l’aléa structurelle mais également les modèles de circuits logiques pour la génération des réponses et les résultats des évaluations de sécurité de ces PUFs. Dans le contexte du cycle de vie le PUF doit répondre à des besoins d’authentification au cours de multiples interactions impliquant divers acteurs. En conséquence nous nous focalisons sur les propriétés et contraintes pour concevoir un modèle strong digital PUF. Le qualificatif strong d’un PUF se caractérisant par un mécanisme de challenge-réponse offrant un « large » espace de réponses. Cela permettra de déployer un protocole d’authentification basé sur les multiples réponses du strong PUF.
La section 4 introduit notre proposition de modèle de circuit logique pour construire un modèle strong digital PUF assurant une forte entropie. Le circuit doit extraire une réponse de l’aléa structurel et permettre un compromis sécurité-coût. Nous spécifions un mécanisme challenge-réponse basé sur un réseau d’opération mathématiques de type substitution-permutation. Ce type de réseau (nommé SPN) offre une forte entropie et respecte des propriétés de sécurité adéquates. Pour la conception de ce circuit nous faisons l’hypothèse de la faisabilité d’une grille d’interconnections aléatoires par un procédé de fabrication DPUF quel qu’il soit. Nous définissons un modèle d’étude comportant plusieurs paramètres (en lien avec les aspects physiques de la grille aléatoire du DPUF mais aussi avec le schéma mathématique SPN). L’architecture obtenue est nommée SPN-DPUF. Par la suite, nous proposons une approche pour optimiser le design SPN-DPUF, limitant les coûts de surface du circuit DPUF et les contraintes sur le procédé de fabrication.
La section 5 présente l’analyse de sécurité du modèle SPN-DPUF ainsi que d’autres variantes incluant une des propositions de circuit existante dans la littérature. Nous présentons la méthodologie et les outils développés pour la modélisation et l’évaluation. La plateforme réalisée permet de générer une base de challenge-réponse pour les modèles DPUF étudiés et les jeux de paramètres choisis. Parmi les paramètres de configuration nous étudions l’impact de la probabilité de fermeture des connections, la taille de la grille (nombre de colonnes et de rangées) et le niveau de séquencement des opérations dans le réseau SPN. Une étude statistique approfondie l’influence de la configuration sur les métriques de sécurité des PUFs. Cette évaluation a permis d’identifier des jeux de paramètre pour optimiser le compromis entre la sécurité du DPUF et les contraintes de taille et d’entropie.
La section 6 complète l’étude précédente par des travaux de simulation et synthèse numériques des circuits; cela afin d’estimer des coûts d’implémentation des modèles proposés. Des codes descriptifs VHDL des modèles SPN-DPUFs sont développés et synthétisés pour les jeux de paramètres identifiés pour des compromis sécurit-cout. Une 1ère phase porte sur l’implémentation des circuits et la vérification des respects des contraintes de délais. Par la suite une 2ème phase analyse les indicateurs de performance fournis par les outils de synthèse. Les métriques ciblées sont la surface, l’énergie consommée et la vitesse de traitement ; elles sont relevées en fonction des paramètres des circuits SPN-DPUFs. Un bilan des résultats est réalisé sur l’ensemble des métriques: surface, fréquence, puissance mises en jeu par le circuit mais également énergie consommée par bit, latence et débit.
La section 7 conclut les travaux sur deux perspectives qui doivent être approfondies. La première concerne l’évaluation du coût globale et des contraintes pour la fabrication d’un circuit SPN-DPUF complet et performant. La deuxième porte sur les problématiques d’intégration du SPN-DPUF dans le cycle de vie et sur le déploiement des protocoles d’authentification exploitation la primitive.

Sécurité du cycle de vie d’un dispositif médical

Nous étudions un cas concret dans le but d’illustrer les enjeux de sécurité liés au cycle de vie. Notre objectif est aussi de formaliser les exigences de sécurité qui découlent des multiples interactions et vulnérabilités induites par le cycle. Le cas d’étude (pompe à perfusion connectée) est un système cyber-physique doté de fonctions spécifiques pour un usage médical et classifié en tant que dispositif médical (DM). Ce type de dispositif subit des contraintes réglementaires fortes, cadré par des règles de classification qui sont détaillées dans cette première section. L’analyse de sécurité sur ce dispositif nous permet d’établir les conséquences graves qui découlent des vulnérabilités de son cycle de vie et la nécessité de déployer des contremesures du fait des risques et exigences identifiés.
La première section introduit les dispositifs médicaux et le règlement 2017/745 de l’Union Européenne [16] qui définit les termes employés dans l’électronique médicale. Il distingue les dispositifs réglementés des applications de bien-être. Nous abordons quelles sont les exigences spécifiques pour les fabricants de DM au cours du cycle de vie. Nous précisons les contraintes et procédures qui doivent être respectées selon la classe du DM. Ces exigences portent sur la performance des dispositifs ainsi que sur leur sécurité. Nous détaillons nos motivations pour ce sujet, les craintes pour la sécurité et finalement le besoin d’établir un compromis avec les contraintes exigées pour les DMs.
La deuxième partie introduit le cas d’étude de sécurité des systèmes de perfusion ; avec comme modèle d’exemple le pancréas artificiel : un système avec pompe à insuline connectée et automatisée. Nous présentons la méthodologie EBIOS (Expression des Besoins et Identification des Objectifs de Sécurité) qui cadre, formalise et dirige l’étude de sécurité. La section détaille ensuite l’architecture de ce type de DM, les éléments qui le composent et les interactions auxquelles ils participent. Cela est déterminant pour la compréhension des risques et des besoins de sécurité. Nous réalisons un inventaire détaillé des composants du DM et des acteurs qui interviennent au cours du cycle de vie. Nous décrivons les accès et interactions qui exposent les éléments sensibles du DM (données, logiciels…). Cela éclaire un premier bilan sur les risques menaçant la sécurité du DM. Ce cas d’étude est représentatif des enjeux de sécurité l’IoT médical : concevoir des dispositifs portables performants et sures ; respectant à la fois les contraintes du médical et de flexibilité des accès au cours du cycle de vie.
La troisième et dernière section synthétise l’analyse de risque réalisée pour le dispositif médical. Le niveau de risque s’établit en fonction de de la vraisemblance des scénarios des menaces et de leur impact sur le dispositif. Le bilan de l’analyse aboutit à l’identification des risques les plus significatifs ; notamment la faible sécurisation des interfaces physiques et le manque d’assurance pour l’authenticité des composants. Des contremesures sont nécessaires pour atténuer ces risques. Au terme de cette étude, les besoins de sécurité du dispositif sont établis, ainsi que les exigences auxquelles doivent répondre les contremesures. Nous concluons sur notre intérêt pour la conception de primitive d’authentification de type PUF (Physical Unclonable Function) afin de répondre à ces besoins.

Dispositifs médicaux

Terminologie et classification des dispositifs médicaux

Les dispositifs électroniques à usages médicaux sont l’objet d’un cadre réglementaire rigoureux en particulier vis-à-vis des risques de défaillances et des exigences de traçabilité au cours du cycle de vie. Les récentes évolutions apportent une plus grande considération pour les aspects sécuritaires, et ce d’autant que dans certains cas d’usage la compromission de l’objet peut avoir un impact grave sur le patient ou les atouts sensibles du cycle de vie (données privées, logiciel médical…). Le règlement 2017/745 de l’Union Européenne [16] définit les termes employés dans l’électronique médicale ainsi que les critères qui déterminent le statut d’un objet en tant que dispositif médical (DM). Nous détaillons en annexe 10.1 cette partie du règlement, ainsi que des exemples de classifications de DM.
En résumé, il convient de distinguer les dispositifs médicaux certifiés et les produits de « bien-être ou de confort », aussi appelés produits ou applications de santé mobile. Un dispositif a donc le qualificatif « médical » s’il répond à un état de santé défaillant, et non pas un besoin de bien-être, confort ou de diagnostic physiologique à finalités sportive. Le règlement [16] considère qu’un produit relève du statut dispositif médical (DM) pour « tout instrument, appareil, équipement, logiciel, implant, réactif, matière ou autre article, destiné par le fabricant à être utilisé, seul ou en association, chez l’homme pour des fins médicales précises, (notamment traitement ou diagnostic) et dont l’action principale n’est pas obtenue par des moyens pharmacologiques. ». Les usages en médecine sont aujourd’hui multiples, diversifiés et ont des incidences variables en termes de risques. Il faut noter que le niveau de risque associé à un produit ne justifie pas le statut de celui-ci en tant que DM ; il intervient par contre dans les règles de classification des DMs
Le règlement de l’U.E. – article 51 – stipule que « Les dispositifs sont répartis dans quatre classes (I, IIa, IIb, III) en fonction de la destination (usage) des dispositifs et des risques qui leur sont inhérents. La classification est effectuée conformément à l’annexe VIII. » La dangerosité du dispositif pour le patient est prise en compte dans les règles de classification. Tous les critères interviennent, tels que la nature de l’usage, la durée d’utilisation du DM, le caractère ou encore la localisation du DM.
Chaque classe se voit attribuer des contraintes réglementaires spécifiques, des exigences de plus grande sévérité à mesure que la criticité du dispositif augmente. Nous décrivons des exemples de DM pour chaque classe avec une brève interprétation des règles de classifications dans l’annexe 10.1. Le cas d’usage que nous étudions, la pompe à perfusion, se positionne en classe IIb. Le dispositif administre des médicaments potentiellement dangereux, telle que l’insuline, et peut être reconfigurer à distance. Une compromission de cet objet impacte la santé du patient, face à un tel risque les aspects sécuritaires doivent être traités et ce tout au long du cycle de vie. Cela impose des contraintes au cours du cycle de vie, notamment des opérations de vérification et de suivi avant et après la mise sur le marché.

Contraintes réglementaires au cours du cycle de vie

Des organismes notifiés (« ON »), laboratoires ou groupes d’expertises certifiés, interviennent pendant le cycle de vie pour évaluer les DMs et valider le marquage CE (« Conformité Européenne »). Le fabricant justifie avec ce marquage la conformité technique de son DM auprès de ses utilisateurs ou partenaires ; obligatoire pour une mise sur le marché ( [17]). Cela nécessite des accès et des opérations de tests ou de vérification par les ONs à divers moments du cycle.
Deux exigences sont communes à toutes les classes : la réalisation d’un dossier technique (spécifications, analyse de risque, rapport d’évaluation …) et le déploiement de procédure de suivi au cours du cycle de vie (service d’assistance, surveillance des incidents). Dans la Figure 5, décrivant les exigences pour la classe IIb qui correspond à notre cas d’étude (pompe médicale connectée), le fabricant a le choix entre différentes procédures. Il peut déployer une assurance qualité, notamment avec l’application de la norme ISO 13485 (Dispositifs médicaux — Systèmes de management de la qualité
— Exigences à des fins réglementaires). Ces procédures d’assurance seront évaluées par un ON. L’autre option est la délégation à l’ON de certaines étapes du cycle de vie. Au final plusieurs démarches réglementaires sont offertes : le fabricant peut ainsi sélectionner ce qui convient le plus à sa situation.
Après obtention du marquage CE le fabricant légal peut commercialiser le DM. Des procédures de surveillance et de maintenance, exigées par le règlement, « sécurisent » le cycle de vie du DM :
§ Les protocoles de matériovigilance : Déploiement d’un service qui collecte les déclarations d’incidents par les utilisateurs et analyse ces données. Le service doit opérer toute maintenance préventive ou corrective pour assurer la qualité des DMs.
§ Surveillance post-marché (PMS) : Le fabricant doit veiller à l’évolution des DMs sur le terrain ; réévaluer périodiquement les risques et le niveau de qualité. Cela inclut des revues de la littérature et un suivi clinique. Des mises à jour logicielles sont prévues pour améliorer les performances ou rectifier les fonctionnalités.
§ Mise à jour d’un dossier post-marché : Le fabricant doit entretenir et mettre à disposition au cours d’un éventuel audit un dossier sur son DM. Le dossier contient les données de surveillance sur la qualité et les risques des DMs au cours de leur utilisation.
§ Maintenance matérielle : Le fabricant légal doit assurer la « maintenance matériel » du DM au cours de la phase d’utilisation. Ce service d’assistance réalise les remplacements et les reconfigurations, tel que cela est spécifié d’après les protocoles de matériovigilances. Il faut noter que le fabricant doit maintenir sa capacité à produire et distribuer tout composant matériel nécessaire au fonctionnement ou à la réparation des dispositifs encore présent sur le marché.
§ Audit de surveillance annuelle : L’organisme notifié réalise des contrôles annuels, vérifiant la bonne mise en œuvre des assurances de qualité. Cela se programme à des périodes prédéfinies mais intervient aussi de manière « inopinés ».
§ La phase de fin de vie : Le fabricant est responsable de la spécification, évaluation et mise en place des procédures d’élimination des DMs. Le recyclage des objets est autorisé ; l’opérateur qui recycle a par contre le statut de fabricant et doit respecter toutes les exigences décrites précédemment.

Motivation et enjeu pour la sécurité de l’IoT médical

Des dispositifs électroniques légers et portables embarquent aujourd’hui des logiciels médicaux performants avec les fonctions nécessaires pour des diagnostics ou des analyses. Cela a un intérêt sociétal fort : amélioration des traitements médicaux, hospitalisations à domicile et meilleure qualité de vie pour les patients. Les apports des DMs sont toutefois contrebalancés par les risques qu’ils induisent pour la sécurité des patient, en particulier au regards des cyber menaces. Des failles peuvent être exploités pour compromettre le dispositif, les chercheurs en font la démonstration régulièrement. Un état de l’art conséquent existe sur la sécurité des objets médicaux, [18] répertorie les vulnérabilités des dispositifs médicaux et les contremesures potentielles, [19] présente une étude plus holistique avec la considération pour l’environnement, « l’écosystème », qui interagit avec ces appareils. Les dispositifs IoT sont interconnectés, et ce avec des protocoles de communication comportant potentiellement des failles de sécurité : il y’a une exposition aux menaces par le réseau, en provenance de tierces parties criminelles ou d’autres dispositifs qui seraient compromis. Outre les démonstrations et les études de vulnérabilité nous constatons aussi que le secteur médical est régulièrement ciblé par des cyber-attaques ; vol de données médicales privées, exécution de rançongiciel sur les services informatiques. Cela ouvre par contre la question d’une « convergence » entre les risques induits par les failles des DMs et les menaces contre le médical. Cette question se répercute sur les exigences de sécurité définies par le cadre réglementaire, celui-ci est contraignant mais peut encore se durcir à l’avenir.
La chronologie [20] synthétise les événements marquants dans la recherche des vulnérabilités des dispositifs médicaux connectés, ainsi que les actions entreprises par les institutions, telle que la FDA (Food Drug and Administration), pour atténuer les risques. Les exigences de conformité techniques imposent des contraintes de sécurité du patient. L’accroissement des enjeux « cybersécurité » a provoqué l’édition de recommandations fortes et de règlement sur la sécurisation des DMs. La FDA (Food and Drug Administration) fournit des guides pour la cybersécurité, en amont [21] et aval [22] de la commercialisation d’un dispositif. Le nouveau règlement acté par l’Union Européenne a de plus fortes exigences sur la cybersécurité [16]. Le fabricant se confronte ainsi aux contraintes de sécurité de DMs ; il doit théoriquement concevoir un dispositif qui présente un niveau de sécurité élevé. La problématique s’aggrave avec le développement des dispositifs. Les interactions avec et autour d’un DM se complexifient, s’accroissent et impactent son utilisation, et ce tout au long du cycle de vie. Les avertissements listés en section 1.2.1 concernent aussi les DMs : le nombre et la criticité des fonctions à protéger augmentent, le cycle de vie intègre des composants de tierces parties et induit de nouvelles interactions. Le fabricant légal doit inclure ces vulnérabilités liées à la cybersécurité dans son analyse de risque ; et par la suite démontrer l’efficacité des contremesures intégrées dans le DM. Les protections sont proportionnelles à la classe de criticité du DM, et doivent considérer les menaces de tiers parties, et ce dans le contexte d’un cycle de vie à interactions multiples. Cette situation nécessite une étude approfondie de la sécurité du dispositif, et ce en considérant l’ensemble du cycle de vie. Au vue de ces enjeux, l’étude de sécurité du cycle de vie des DMs apparait donc aujourd’hui primordiale.

Besoin d’un compromis entré sécurité et contraintes des DMs

Les dispositifs médicaux sont des systèmes isolés, embarquant une application logicielle exploitée sur le long terme. Cela correspond notamment au cas des pompes médical portables pour patients diabétiques. De tels dispositifs doivent respecter un certain niveau de performances :
– Faible consommation. Il s’agit d’un objet portable, sans canal d’alimentation, et avec le besoin de fonctionner sur de longue période.
– Disponibilité et fiabilité. Le dispositif doit réaliser avec succès ses fonctions pour le traitement médical. Cela implique une efficacité des opérations (vitesse, précision …).
– Coût de fabrication réduit. Le produit concerne des utilisateurs (patients ou institut médical) ayant des contraintes financières fortes. Il doit rester accessible.
Le fabricant se confronte donc à la fois aux questions de sécurité et de performances : cela mène au besoin d’un compromis optimal entre ces contraintes. Il s’agit d’une problématique courante dans la sécurité des systèmes embarqués, et qui est prise en compte dans la suite des recherches.
De plus, au cours du cycle de vie le fabricant doit accéder, ou autoriser l’accès à des tiers, aux dispositifs. Cela se fait à divers moments et pour diverses raisons : contrôle de la qualité, maintenance, ou audit. Par exemple, au cours du contrôle final, l’inspection d’un DMs consiste à vérifier si leurs performances, leurs niveaux de sécurité et de sûreté, et leurs fonctions médicales correspondent aux spécifications. Cela implique l’autorisation d’effectuer des tests sur le DM, d’exécuter ses fonctions et d’accéder à des données techniques. Certaines contraintes portent aussi sur l’usage des données :
– Usage médical pour l’observation du patient, avec collecte des données par l’objet et transmission à un serveur agrégé.
– Usage technique également, communication de données concernant le statut du dispositif. Le fabricant réalise un suivi de ses DMs évaluant performances et fonctionnalités.
Cela nécessite des droits d’accès à certaines données des DMs et la mise en œuvre d’une communication sécurisée. En outre, des opérations telles que les maintenances ou les mises à jour logicielles impliquent un accès à des composants critiques de l’objet. Cela ajoute un besoin d’accès flexible à des éléments internes du DM. Pour finir les utilisateurs requièrent dans certains cas, tels que des situations d’urgence, d’accéder à des fonctions de l’objet pour rectifier le traitement ou vérifier le fonctionnement du DM. Cela peut exiger une flexibilité des droits d’accès.
Cela justifie le besoin de sécuriser la gestion des interactions et des accès de manière flexible :; il faut intégrer des protections pour protéger les éléments critiques du DM, démontrer leur efficacité au cours du cycle de vie mais sans compromettre les autres contraintes (règlementation, couts, usages…).

Contexte de l’étude de sécurité de la pompe à insuline

Méthodologie EBIOS pour l’analyse de sécurité

Nous appliquons la méthodologie EBIOS (Expression des Besoins et Identification des Objectifs de Sécurité) sur le cas d’étude de pompe médicale connectée. Elle a été élaboré en 1995 par l’ANSSI (Agence Nationale de la Sécurité des Systèmes d’Information) qui fournit plusieurs documents de références, le guide détaillé [23] ainsi que [24], une base de connaissance pour l’énumération des types de menaces. EBIOS est une méthode générique qui s’adapte au contexte, le « bien » à protéger peut-être une infrastructure, un service interne d’une entreprise ou une application logicielle. Les objectifs de sécurité varient : cartographie des risques, mise en œuvre d’une politique de sécurité ou évaluation plus technique et précise des protections. La figure 11 présente les cinq modules de la méthode EBIOS. : l’étude de contexte, l’estimation des événements redoutés et de leur impact, la description des scénarios de menaces, la synthèse des risques et l’évaluation des contremesures.
Comme décrit par la figure 11 la synthèse des risques consiste à coupler les événements redoutés avec les scénarios de menaces. Ces deux modules s’appuient respectivement sur les cotations suivantes : un niveau d’impact (quels dégâts occasionnent l’événement) et un niveau de vraisemblance (crédibilité de la mise en œuvre du scénario de menaces par un adversaire). Le cinquième et dernier module n’est pas nécessaire dans le cas où l’étude se limites à l’établissement d’une cartographie des risques.

Table des matières

 1 Introduction
1.1 Complexité du cycle de vie IoT
1.2 Besoins pour la sécurité au cours du cycle de vie
1.3 Sécurité matérielle et cycle de vie
1.4 Objectifs
2 Sécurité du cycle de vie d’un dispositif médical
2.1 Dispositifs médicaux
2.2 Contexte de l’étude de sécurité de la pompe à insuline
2.3 Bilan de l’analyse de risques
3 Etat de l’art sur les Fonctions Physiques Nonclonables .
3.1 Fonctions Physiques Nonclonables Traditionnelles
3.2 Critères d’évaluation des PUFs
3.3 Apports et limites des PUFs traditionnels pour le cycle de vie
3.4 Motivation et problématique pour la conception des digital PUFs
3.5 Etat de l’art des implémentations DPUFs : analyse et classification
3.6 Bilan et perspective des recherches sur les DPUFs
4 Circuit d’extraction pour un strong PUF : proposition et description du modèle SPN (Substitution-Permutation-Network)
4.1 Motivations et Objectifs
4.2 Schémas mathématiques pour un circuit d’extraction sécurisé
4.3 SPN-DPUF : réseau de substitutions et permutations pour un strong DPUF
4.4 Enjeu et difficultés de la configuration du circuit d’extraction du SPN-DPUF
5 Evaluation Sécuritaire des Circuits d’Extraction
5.1 Méthodologie de l’évaluation de sécurité
5.2 Evaluation de l’uniformité
5.3 Evaluation de l’unicité
5.4 Évaluation de la diffusion
5.5 Evaluation de la diffusion : optimisation des configurations SPN et PN
5.6 Bilan de l’évaluation
6 Coûts d’implémentation des Circuits SPN pour un Strong DPUF
6.1 Flot de la conception et de l’évaluation des circuits
6.2 Implémentation des circuits d’extractions
6.3 Analyses et Réduction des Coûts d’Implémentation
6.4 Bilan et configuration finale pour le circuit SPN-DPUF
7 Conclusion et perspectives générales
7.1 Contributions pour la sécurité du cycle de vie
7.2 Bénéfices du SPN-DPUF pour le compromis sécurité-coût
7.3 Perspectives générales
8 Listes des publications..
9 Bibliographie 

Télécharger le rapport complet