Meetup Cybersécurité RGPD Conséquences dans l'Embarqué

11 Avenue Marigny 13014 Marseille www.ciose.fr christian.charreyre@ciose.fr
Cybersécurité, RGPD- Conséquences dans l'embarqué 11/04/2019
Cybersécurité, RGPD– ConséquencesCybersécurité, RGPD– Conséquences
dans l’embarquédans l’embarqué
C. CharreyreC. Charreyre
christian.charreyre@ciose.frchristian.charreyre@ciose.fr
http://www.ciose.frhttp://www.ciose.fr
https://twitter.com/CIO_SysEmbhttps://twitter.com/CIO_SysEmb
http://fr.slideshare.net/charreyrehttp://fr.slideshare.net/charreyre

Licence
Attribution-Noncommercial-Share Alike 4.0 International
● You are free:
to Share - copy and redistribute the material in any medium or format
to Adapt - remix, transform, and build upon the material
The licensor cannot revoke these freedoms as long as you follow the license terms.
● Under the following conditions:
Attribution — You must give appropriate credit, provide a link to the license, and indicate if changes were made. You
may do so in any reasonable manner, but not in any way that suggests the licensor endorses you or your use.
NonCommercial — You may not use the material for commercial purposes.
ShareAlike — If you remix, transform, or build upon the material, you must distribute your contributions under the
same license as the original.
● No additional restrictions — You may not apply legal terms or technological
measures that legally restrict others from doing anything the license permits.
● License text : http://creativecommons.org/licenses/by-nc-sa/4.0/legalcode

Cybersécurité, RGPD- Conséquences dans l'embarqué 3
 Associé et Directeur Technique au sein de CIO
 Responsable des technologies Linux embarqué
 Formateur Linux embarqué (avec Captronic et en direct)
 30 ans dans l'embarqué et le monde Unix / Linux
 Fervent promoteur du logiciel libre
 Membre de Medinsoft – Commission Logiciel Libre
1/04/2019
Présentation de l’orateur

Pourquoi ce meetup ?
● Nous ne sommes pas (encore?) des experts en cybersécurité
● Mais
– Celle-ci devient de plus en plus important dans les projets que nous
développons
● ⇒ prise en compte dans les projets récents de problématiques de
cybersécurité
● actions de sensibilisation auprès des clients
– L’avènement du RGPD renforce la problématique
● Est ce un marronnier ?
– Oui car le sujet est récurrent ces temps-ci
– Non car dans les faits beaucoup de travail de sensibilisation puis de prise
en compte

Contexte
● Multiplication des devices embarqués connectés
– Le plus souvent avec connexion sans fil
● 50 Milliards d’objets connectés estimés en 2020
– De plus en plus d’interconnexions entre objets, sans interaction humaine
● Touche tous les domaines
– Domotique
– Santé
– Industrie
– Smart City ...
● La data est le pétrole de demain...

Exemple: voiture connectée
● Logiciel = 35 % du coût en 2015 ⇒ 50 % en 2020
● Connexion pour
– Infotainment
– Gestion du trafic (smart city)
– Remote maintenance
● Ouverture canaux de communication + importance fonctions logicielles ⇒
risque de cyber attaque
● La cybersécurité devient un enjeu dans l’industrie automobile
● Exemple de risque : Hack Chrysler Cherokee dévoilé à Black Hat 2015
– Prise de contrôle à distance de la radio, du volant et de freins du véhicule en
circulation
– Conséquence : rappel de 1,4 M de véhicules pour corriger la faille

Risques liés à la cybersécurité
● « Cyberattacks are an even bigger threat than catastrophic natural disasters » Lloyd’s of
London
●
« We suspect in 2018 we'll start to see larger scale attacks in the IoT space »
Caleb Barlow, IBM Security's vice president of threat intelligence
● Accès non autorisé aux données : rupture de Confidentialité
– Trajets effectués dans un GPS de voiture
– Absence du logement dans un système domotique
– Données de santé dans un appareil médical …
● Corruption des données : rupture d’Intégrité
– Altération des mesures d’un capteur
– Injection de fausses informations …
● Altération du fonctionnement : rupture de Disponibilité
– Détournement de fonction (DDoS OVH par caméras connectées)
– Mise en cause de la sécurité (altération des fonctions d’un véhicule autonome)
– Ransomwares ...z

Sûreté de fonctionnement &
Cybersécurité
● De plus en plus de fonctions autonomes (ex : voiture autonome)
● Autonomie impose sûreté de fonctionnement
● Pas de sûreté de fonctionnement sans cybersécurité :
– Sûreté de fonctionnement ⇒ qualification du produit avant mise en
service
– Mises à jour logicielles à prévoir ⇒mécanismes d’update, parfois
Over The Air
– Nécessité de sécuriser les updates pour :
● n’installer que des mises à jours certifiées
● éviter toute tentative de hacking qui compromettrait la sûreté

RGPD
● Le RGPD est un règlement européen qui est entré en vigueur le 25 Mai
2018
● Il concerne tous les citoyens européens, n’importe où dans le monde
(extraterritorialité)
● Il impose aux entreprises de nouveaux principes :
– Principe d’accountability : mise en place de mesures par l’entreprise au lieu des
contrôles (CNIL)
– Registre des opérations et analyses d’impact
– Nomination d’un Data Protection Officer (DPO)
– Droit accès, rectification, opposition, portabilité et oubli
– Confidentialité des données par défaut et par design
– Responsabilité conjointe du donneur d’ordres et du sous traitant

RGPD
● En cas de non conformité :
– Risque de sanctions administratives : amendes pouvant aller
jusqu’à 20 M € ou 4 % du Chiffre d’Affaires mondial
– Risque juridique : possibilités d’action de groupe en matière
de protection des données personnelles
– Risque en matière de réputation

Les décideurs face au RGPD
● Résultats d’une étude NetApp sur les craintes face au
RGPD
Source : https://www.solutions-numeriques.com/1-decideur-sur-3-a-peur-de-mettre-la-cle-sous-la-porte-a-cause-du-rgpd/

Privacy By Design
● Nécessité d’intégrer la protection des données personnelles dès la
phase de conception d’un device connecté, autour des
principes suivants :
– des mesures proactives et préventives
– une protection implicite et automatique
– une intégration de la vie privée dans la conception des systèmes et au
cœur des pratiques
– une protection intégrale
– une sécurité durant toute la durée de conservation des données
– de la visibilité et de la transparence
– respecter la vie privée des utilisateurs

Privacy By Default
● Par défaut, protection de la vie privée la plus stricte ⇒
Obtenir le consentement explicite des utilisateurs pour toute
collecte de donnée personnelle
● Ne collecter que les données personnelles strictement
nécessaires pour l’objectif poursuivi. Ne les conserver que
le temps nécessaire à l’objectif

Cybersécurité, RGPD, quelles
conséquences dans l’embarqué ?
● Cybersécurité :
– Protéger son device pour éviter qu’il ne soit attaqué
● Garantir la fonction ⇒Disponibilité
● Garantir ses données ⇒Intégrité
● Protéger ses données ⇒Confidentialité
– Protéger son device pour garantir sa Sûreté de Fonctionnement
● Garantir que seules des versions licites et validées peuvent être installées
– Protéger les échanges de données avec l’extérieur du device (réseaux, supports amovibles)
● RGPD :
– Protéger les données personnelles stockées dans le device
● Exemple critique : appareil médical
– Protéger les échanges de données avec l’extérieur du device (réseaux, supports amovibles)
● Dans les 2 cas, un outil indispensable, la cryptographie

Cryptographie
● La cryptographie va servir à :
– Signer des éléments pour en garantir l’authenticité
● Exemple : message électronique, fichier de paramètres, binaire
d’un logiciel
– Chiffrer des éléments pour empêcher leur utilisation par des
tiers non autorisés
● Exemple : message électronique, fichier de données
personnelles, IP d’un FPGA

Chiffrement symétrique
● Une même clé pour chiffrer et déchiffrer
– Mais il faut se transmettre la clé
– Tous ceux qui ont la clé peuvent déchiffrer l’élément
– Gestion trop complexe fonction du nombre d’interlocuteurs

Chiffrement asymétrique

Chiffrement asymétrique
● Basé sur une paire de clé publique / clé privée
● Authentification :
– Anne authentifie le message en le chiffrant (ou plutôt en
chiffrant un hash du message) avec sa clé privée
– Si le récepteur (Bob ou Dylan) peut déchiffrer avec la clé
publique d’Anne, c’est que le message est authentique
● Chiffrement :
– Bob chiffre le message avec la clé publique de Anne
– Seule Anne peut déchiffrer le message

Authentification & chiffrement des
éléments installables
● Assurer l’authenticité des éléments installés sur le device (primo installation /
upgrade)
– Le chiffrement asymétrique permet d’authentifier un soft, des paramètres avant
de les injecter dans le device
● Le processus d’installation / update a besoin de la clé publique ⇒ pas de problème de
protection au niveau du device
● La clé privée doit être protégée ⇒ contrainte de sécurité sur la production des
éléments déployables
● Protéger la Propriété Intellectuelle des éléments installés
– Le chiffrement symétrique permet de chiffrer un soft
● Le processus d’installation / update a besoin de la clé pour déchiffrer ⇒ problème de
protection au niveau du device
● Possibilité de transmettre sans risque l’update par réseau, ou média volatile non
sécurisé
– Décryptage à l’installation ou maintien du soft crypté dans le device ?

● Décryptage à l’installation :
– Pros
● Conserve une distribution Linux embarquée standard
– Cons
● Repose sur l’impossibilité d’accéder au device
● Nécessite de fermer tous les accès au device
– Du travail de tuning de l’image
– Pénalise les phases de développement (debug)
– Éventuellement avoir des bypass développeur
● Compromis facilité du bypass vs risque de sécurité induit
à trouver

● Maintien du soft crypté dans le device :
– Pros
● Protection du soft maintenue en cas d’accès au device (sous réserve de la protection des
clés)
– Cons
● Nécessite un moteur de décryptage performant (hard crypto sur ARM)
● Nécessite un décryptage à la volée avant lancement
●
Nécessite l’impossibilité de lire la clé de décryptage même en cas d’accès au device
(stockage des clés lisible seulement par le hard de décryptage)
● Cryptage total du File System :
– Pros
● Protection de tous les éléments
– Cons
● Saisie d’une information de déverrouillage au démarrage, la passphrase du volume. Très
peu pratique

Chaîne de confiance
● Assurer l’authenticité dans toutes les étapes du démarrage
– Primary Loader / BIOS
– Bootloader
– Distribution
– Soft applicatif
● Exemples :
– SecureBoot UEFI dans le monde PC : kernel et driver doivent être signés
– Zynq 7000 : Secure Boot pris en charge par le First Stage Boot Loader
● Authentification RSA et chiffrage AES des éléments de la chaîne de boot
● Moteur de crypto AES/HMAC disponible en hardware
● Si usage d’une image Ramdisk, tous les éléments peuvent être authentifiés et chiffrés

Chaîne de confiance
● Authentification et chiffrement Zynq7000
Signature
clé privée
Chiffrement avec
clé privée
Signature
élément chiffré
Authentification
clé privée
Déchiffrement
avec clé privée
Authentification
élément déchiffré
Développement Device

Protection des données sur le device
● Nécessité de protéger les données stockées sur le device
● Solution minimale :
– Stockage en clair mais tous accès fermés
● Comment récupérer les données ?
● Prévoir un mécanisme de récupération ⇒ Risque de récupération par un tiers
● Crypter les données :
– Crypter une partition data
● Nécessité de fournir une clé de décryptage au démarrage
– Utiliser une crypto asymétrique au niveau fichier de données
● Fichier chiffré avec la clé publique ou le certificat du destinataire
● Déchiffrement pour exploitation avec la clé privée (hors device donc plus facile à sécuriser)
– Attention aux fichiers temporaires avant cryptage
● Effacement sécurisé
● Tampon dans un ramfs

Protection des échanges
● Protéger les données échangées sur un réseau IP
● Utiliser des protocoles sécurisés
– ssh, scp
– sftp
– rsync over ssh
– Serveur https
● Le cas échéant stocker sa clé publique sur le device (ssh,
scp, rsync over ssh) pour éviter une saisie de mot de passe
(script de récupération des données par ex)

Protection logique / Protection
physique
● Protection logique : fermer les accès du device pour éviter toute intrusion
(connexion) et récupération/altération de clés, de données, analyse du File
System
● Protection physique : éviter toute attaque physique sur le device
– Dump d’une Flash
– Branchement sur sonde JTAG
– Récupération de clés par méthodes physiques
– Analyse d’un protocole par observation du rayonnement, de la consommation
électrique
●
Protection logique donne un 1er
degré de sécurité
● Si nécessaire, passer au stade protection physique
– Ex : terminal de carte bancaire

Quelques pistes de protection logique
sur le device
● Utiliser des mots de passe robustes
● Interdire les accès root ⇒ Créer des comptes non privilégiés pour accéder aux
données, aux logs ...
● Limiter strictement les possibilités de connexion, voire les supprimer
– getty
– serveur ssh
●
Supprimer les traces console
● Cantonner les accès aux seules zones autorisées
● Utiliser un firewall sur le device
– Tout interdire par défaut
– N’autoriser que le strict nécessaire
● Protéger strictement les clés de déchiffrement si utilisées

Protection de l’environnement
● Pour le développement, protéger strictement les clés
privées de production (authentification)
– Si corruption, nécessité de changer de jeu de clés ⇒Mise à
jour du parc installé
● Pour l’exploitation des données, protéger strictement les
clés privées permettant le déchiffrement (confidentialité)
– Si corruption, nécessité de changer de jeu de clés ⇒Mise à
jour du parc installé

Meetup Cybersécurité RGPD Conséquences dans l'Embarqué

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Meetup Cybersécurité RGPD Conséquences dans l'Embarqué

Similar to Meetup Cybersécurité RGPD Conséquences dans l'Embarqué (20)

More from Christian Charreyre

More from Christian Charreyre (20)

Meetup Cybersécurité RGPD Conséquences dans l'Embarqué