Titre de l’invention : Procédé de vérification de l’authenticité d’une commande d’un actionneur

[0001] L’invention se rapporte à un procédé de vérification de l’authenticité d’une commande d’un actionneur, ainsi qu’à un système de commande d’un actionneur. L’invention est particulièrement adaptée au domaine de l’automobile, mais peut également être appliquée à d’autres domaines, notamment la domotique.

[0002] L’infodivertissement (« infotainment » selon la terminologie anglo-saxonne) est devenu un atout majeur de vente des véhicules automobiles. Les utilisateurs veulent pouvoir accéder, depuis un tableau de bord du véhicule, à différents contenus multimédia, ou à différents services de télécommunications ou encore de navigation. Des systèmes multimédias, encore connus sous l'acronyme « IVI » (In-Vehicle Infotainment), ont ainsi été développés pour équiper les véhicules.

[0003] Des solutions ont également été proposées pour donner à l’utilisateur un accès au contenu d’un dispositif de communication extérieure, par exemple un smartphone, ou une tablette, sur le tableau de bord. Le tableau de bord est alors un écran déporté à partir duquel l'utilisateur peut accéder à ses applications et à une interface habituelle, afin qu’il ne soit pas perturbé par le changement d’interface.

[0004] Sur l’écran tactile du tableau de bord, l’utilisateur peut ainsi accéder au contenu de son dispositif de communication externe (par exemple smartphone), et commander certaines parties du véhicule, par exemple l’aide à la conduite, le confort (sièges, chauffage), la configuration de la boite de vitesse automatique, le volume du son etc.

[0005] Le système multimédia comprend en outre un système d’exploitation intégré permettant de déporter l’affichage d’un dispositif de communication extérieur sur l’afficheur tactile du système multimédia. Android Auto ou encore CarPlay sont des exemples de tels systèmes d’exploitation.

[0006] Cependant, une telle connectivité entraîne une augmentation de la surface d’attaque. En effet, le fait de connecter le système multimédia à un réseau de communication externe, par exemple Internet, via des systèmes ouverts, comme le sont certains systèmes d’exploitation, peut rendre le système de communication vulnérable à des cyberattaques. [0007] Par ailleurs, l’utilisation de systèmes « ouverts » comme système d’exploitation OS de l’IVI peut poser des problèmes de sécurité. Par exemple certains constructeurs utilisent le système d’exploitation Android, qui permet l’installation d’applications tierces à travers le magasin (store) Android. Ces applications représentent une menace potentielle. Aussi ces systèmes ouverts nécessitent le plus souvent une connexion à internet, qui est fournie le plus souvent par le véhicule lui-même à travers une unité de commande dédiée.

[0008] Or, en cas de d’attaque du système multimédia, l’ensemble des fonctions disponibles peut être utilisé par l’attaquant, y compris les fonctions les plus critiques, comme les fonctions relatives au contrôle du véhicule.

[0009] Il existe des solutions pour garantir la confidentialité des données saisies dans un smartphone, utilisées par exemple pour les applications bancaires. Le système d’exploitation comprend une partie sécurisée. L’application est exécutée par le système d’exploitation.

[0010] Lorsque l’utilisateur doit saisir un mot de passe, la partie sécurisée prend la main, et chiffre le mot de passe. A la fin de la procédure d’authentification, la partie sécurisée transmet le mot de passe chiffré au système d’exploitation. Ainsi, en cas de cyberattaque du système d’exploitation, l’attaquant ne peut pas être en possession du mot de passe.

[0011] Les systèmes de sécurité intégrés actuellement dans les smartphones empêchent également un attaquant de deviner le code secret à l’aide d’une analyse des appuis écrans, corrélée à une analyse de l’affichage.

[0012] Les solutions connues de l’état de la technique, divulguées par exemple dans la demande de brevet US2005/0275661 A1 ou US 2016/0255073 A1, permettent ainsi de garantir la confidentialité des données échangées. Ces solutions ne visent toutefois pas à garantir l’authenticité (ou intégrité) des données échangées.

[0013] Or, dans les systèmes multimédias appliqués à des domaines sensibles tels que l’automobile ou la domotique, il est important d’assurer que la commande est bien liée à une interaction utilisateur, et non pas à du code qui s’exécute sans interaction utilisateur.

[0014] Il existe ainsi un besoin pour un procédé et un dispositif capables de garantir que les commandes du système multimédia sont bien initiées « physiquement » par l’utilisateur, et qu’en cas de compromission du système d’exploitation, il ne soit pas possible pour le système d’exploitation d’initier de telles actions.

[0015] Un objet de l’invention est donc un procédé de vérification de l’authenticité d’une commande d’un actionneur susceptible d’être contrôlé par une unité de contrôle électronique, l’unité de contrôle électronique étant reliée à un système multimédia comprenant :

- un afficheur tactile configuré pour recevoir une commande utilisateur, et pour afficher des informations relatives à la commande de l’actionneur,

- un système d’exploitation configuré pour déporter l’affichage d’un dispositif de communication extérieur sur l’afficheur tactile du système multimédia, et

- un environnement sécurisé authentifié configuré pour fournir un niveau de sécurité supérieur au niveau de sécurité du système d’exploitation, l’environnement sécurisé authentifié comprenant un contrôleur d’appui configuré pour détecter une commande utilisateur sur l’afficheur tactile, le procédé comprenant : a) une signature d’une commande utilisateur par l’environnement sécurisé authentifié, ladite commande utilisateur correspondant à une activation physique d’au moins une zone de l’afficheur ; b) une transmission par le système d’exploitation de la commande signée à l’unité de contrôle électronique ; c) une vérification de la signature par l’unité de contrôle électronique ; d) une exécution de la commande utilisateur par l’actionneur.

[0016] Avantageusement, le procédé comprend au préalable : a’) une détection, par l’environnement sécurisé authentifié, de la commande utilisateur ; a”) une retransmission de la commande depuis l’environnement sécurisé authentifié vers le système d’exploitation ; a’”) une mise à jour de l’affichage sur l’afficheur tactile en fonction de la commande utilisateur. [0017] Avantageusement, l’environnement sécurisé authentifié comprend un composant d’authentification configuré pour commander des fonctions sécurisées relatives à la commande de l’actionneur, et pour dater la commande utilisateur effectuée sur l’afficheur tactile, l’étape a) de signature d’une commande comprenant : i) une réception, par le composant d’authentification d’une requête de fonction de véhicule émise par le système d’exploitation, et ii) une signature de la commande si le délai entre l’instant de réception de la requête de fonction de véhicule et l’instant de la commande utilisateur sur l’afficheur tactile est inférieur à une valeur prédéterminée.

[0018] Avantageusement, l’environnement sécurisé authentifié comprend un composant d’authentification configuré pour commander des fonctions sécurisées relatives à la commande de l’actionneur ; l’étape a) de signature de commande comprenant au préalable une détection, par le composant d’authentification, d’une trame de commencement d’action sécurisée relative à la commande utilisateur, en réponse à l’activation de la zone de l’afficheur, de façon à afficher un menu d’interaction véhicule ; le composant d’authentification générant, en réponse à l’étape b) de transmission par le système d’exploitation de la commande signée, une trame de fin d’action sécurisée relative à la commande utilisateur.

[0019] Avantageusement, le système d’exploitation envoie régulièrement une capture d’écran, à l’environnement sécurisé authentifié, du contenu spécifique au système d’exploitation, et l’environnement sécurisé authentifié superpose le menu d’interaction véhicule sur la capture d’écran reçue de la part du système d’exploitation.

[0020] Avantageusement, l’actionneur est configuré pour exécuter une commande de contrôle du confort d’un véhicule automobile, de contrôle de la configuration de la boite de vitesse automatique d’un véhicule automobile ou d’une fonction d’aide à la conduite d’un véhicule automobile. [0021] Avantageusement, dans lequel l’actionneur est configuré pour exécuter une commande d’un système domotique.

[0022] Avantageusement, le dispositif de communication extérieur est un téléphone intelligent ou une tablette.

[0023] Avantageusement, l’activation physique d’au moins une zone de l’afficheur tactile comprend l’appui par l’utilisateur d’une zone de l’afficheur tactile.

[0024] L’invention se rapporte aussi à un système de commande d’un actionneur susceptible d’être contrôlé par une unité de contrôle électronique, l’unité de contrôle électronique étant reliée à un système multimédia comprenant :

- un afficheur tactile configuré pour recevoir une commande utilisateur, et pour afficher des informations en lien avec la commande de l’actionneur,

- un système d’exploitation configuré pour déporter l’affichage d’un dispositif de communication extérieur sur l’afficheur tactile du système multimédia, et

- un environnement sécurisé authentifié configuré pour fournir un niveau de sécurité plus élevé que le système d’exploitation, l’environnement sécurisé authentifié comprenant un contrôleur d’appui configuré pour détecter une commande utilisateur sur l’afficheur tactile, le système étant en outre configuré pour mettre en œuvre le procédé précité.

[0025] D’autres caractéristiques, détails et avantages de l’invention ressortiront à la lecture de la description faite en référence aux dessins annexés donnés à titre d’exemple et qui représentent, respectivement :

[0026] la figure 1 représente un système selon l’invention ;

[0027] la figure 2 représente les différentes étapes du procédé selon l’invention ;

[0028] les figures 3 et 4 représentent deux modes de réalisation du procédé selon l’invention ;

[0029] la figure 5 représente l’application du procédé selon le premier mode de réalisation, en réponse à une cyberattaque.

[0030] La figure 1 illustre l’architecture d’ensemble du système pour mettre en œuvre le procédé selon l’invention. [0031] Le système multimédia IVI comprend un écran tactile SC afin d’afficher les informations de navigation, ainsi que tout type de contenu multimédia tel que des images, des vidéos. L’écran tactile SC est également configuré pour restituer l’affichage d’un smartphone de l’utilisateur.

[0032] Le système multimédia IVI est composé de deux systèmes s’exécutant concurremment, à savoir un système d’exploitation OS configuré pour déporter l’affichage d’un dispositif de communication extérieur sur un afficheur tactile du système multimédia, ainsi qu’un environnement sécurisé authentifié TEE.

[0033] L’environnement sécurisé authentifié TEE, également appelé « Trusted Execution Environment » dans la littérature anglo-saxonne. L’environnement sécurisé authentifié TEE est configuré pour fournir un niveau de sécurité supérieur au niveau de sécurité du système d’exploitation, en s’appuyant sur sa capacité à isoler partiellement ou totalement certains périphériques (mémoires, écrans etc.).

[0034] Dans le système selon l’invention, le contrôleur d’appui TC (ou « driver » d’écran tactile) détecte un appui utilisateur sur l’afficheur tactile SC, et convertit l’appui en commande interprétable par l’environnement sécurisé authentifié TEE.

[0035] Les parties de l’interface utilisateur identifiées comme sensibles, à savoir permettant une interaction avec le véhicule, sont exécutées par un composant d’authentification CA intégré à l’environnement sécurisé authentifié TEE.

[0036] Si l’utilisateur interagit avec l’interface de sorte qu’il demande à contrôler certaines commandes du véhicule, le composant d’authentification CA génère alors des commandes signées à l’aide d’une clé de sécurité. L’environnement sécurisé authentifié TEE garantit la confidentialité de cette clé en s’appuyant sur les capacités d’isolation de l’environnement sécurisé authentifié TEE.

[0037] L’environnement sécurisé authentifié TEE transmet les commandes au système d’exploitation OS qui enverra la commande à l’unité de contrôle électronique UC, par exemple l’ordinateur de bord (BCM pour Body Control Module), ou le système qui gère l’aide à la conduite (ADAS pour Advanced Driver Assistance Systems). La transmission est effectuée sur une liaison de données, par exemple un bus de données CAN ou un bus l ² C.

[0038] Le procédé est décrit plus en détail en référence aux figures 2 à 5. [0039] Le procédé comprend quatre étapes.

[0040] Dans une première étape a), l’environnement sécurisé authentifié TEE signe la commande utilisateur.

[0041] La signature est effectuée à l’aide d’une méthode cryptographique connue de l’homme du métier. La méthode cryptographique peut être du type symétrique, à clé partagée (par exemple mettant en oeuvre l’algorithme AES, DES ou Triple DES), ou encore asymétrique avec l’utilisation de clés publiques et privées (par exemple mettant en oeuvre l’algorithme RSA).

[0042] Dans une deuxième étape b), le système d’exploitation OS transmet la commande signée à l’unité de contrôle électronique UC.

[0043] Dans une troisième étape c), l’unité de contrôle électronique UC vérifie la signature.

[0044] Dans une quatrième étape d) la commande utilisateur est exécutée.

[0045] La figure 3 illustre un premier mode de réalisation du procédé selon l’invention.

[0046] L’utilisateur USR effectue une activation physique (appui écran) d’au moins une zone de l’afficheur SC, par exemple en appuyant sur l’écran afin de commander une fonction du véhicule, ou encore pour naviguer dans un menu propre à une fonction du véhicule.

[0047] L’environnement sécurisé authentifié TEE détecte la commande utilisateur (étape a’)).

[0048] L’information d’appui est transmise par l’écran au contrôleur d’appui TC, qui interprète l’activation de la zone de l’écran SC, afin que la commande soit interprétable par le système d’exploitation OS (étape a”)).

[0049] Par ailleurs, le contrôleur d’appui TC transmet au composant d’authentification CA une « copie » de l’événement d’appui, typiquement la zone où l’appui a été effectué, et avec quelle pression. Le composant d’authentification CA sauvegarde ensuite cet événement avec une datation (« timestamp »).

[0050] L’environnement sécurisé authentifié TEE est particulièrement difficile à attaquer de par son isolation et sa taille limitée, réduisant de fait la surface d’attaque exposé au système d’exploitation OS. La transmission d’une copie de l’événement d’appui par l’attaquant, sans qu’il n’y ait eu d’appui réel sur l’afficheur SC, est donc difficilement réalisable.

[0051] La partie IHM (Interface Homme Machine) du système d’exploitation OS met à jour l’affichage en fonction de la zone activée par l’utilisateur. Par exemple, la partie IHM met à jour l’affichage du menu au fur et à mesure que l’utilisateur navigue dans un menu, ou bien sélectionne une commande (étape a’”)).

[0052] Le système d’exploitation OS reçoit lui-même les événements du contrôleur d’appui TC, et il met à jour son affichage. L’environnement sécurisé authentifié TEE se comporte donc comme un contrôleur d’appui virtuel, et relaye les événements reçus du contrôleur d’appui physique.

[0053] La partie IHM du système d’exploitation OS transmet la demande d’accès à une fonction du véhicule REQ1 , qui correspond à la commande utilisateur, à un module HAL (couche d'abstraction matérielle) du système d’exploitation OS.

[0054] Le module HAL est une interface qui définit les propriétés du véhicule que le fabricant ou l’équipementier peut implémenter. Le module HAL contient des métadonnées de propriété. Pour le chauffage, ventilation et climatisation (HVAC), les propriétés peuvent être par exemple le réglage de la température par zone, ou le contrôle de la recirculation par zone.

[0055] Le module HAL définit si les propriétés sont en lecture seule, en écriture seule ou en lecture et en écriture.

[0056] En réponse à la demande d’accès effectuée par la partie IHM, le module HAL transmet au composant d’authentification CA la requête d’accès à une fonction du véhicule REQ1 (sous-étape i)).

[0057] Dans la sous-étape ii), le composant d’authentification CA valide la commande si le délai entre l’instant de réception de la requête de fonction de véhicule REQ1 et l’instant de la commande utilisateur sur l’afficheur tactile SC (i.e. l’instant d’appui) est inférieur à une valeur prédéterminée (par exemple quelques millisecondes).

[0058] Dans l’affirmative, le composant d’authentification CA signe la commande utilisateur, ce qui garantit l’authenticité de la commande. En effet, l’environnement sécurisé authentifié TEE a peu d’interactions avec le système d’exploitation OS du système multimédia IVI, ce qui le protège d’une attaque malveillante visant à prendre le contrôle du système d’exploitation OS voire même de l’ordinateur de bord du véhicule.

[0059] La commande signée est transmise au module HAL, qui le retransmet à l’unité de contrôle électronique UC, par exemple l’ordinateur de bord BCM ou le système qui gère l’aide à la conduite ADAS. Il est essentiel que l’unité électronique UC ne reçoive pas une commande initiée par un utilisateur non authentifié. L’unité électronique UC vérifie ainsi la signature.

[0060] La signature numérique de la commande par le composant d’authentification CA, et la vérification de la signature par l’unité électronique UC, utilisent un mécanisme de cryptographie asymétrique ou symétrique. Ce mécanisme permet de s'assurer de l'authenticité de l'expéditeur.

[0061] Une fois que l’unité électronique UC a vérifié l’authenticité de la commande, l’actionneur ACT exécute la commande utilisateur.

[0062] Selon ce premier mode de réalisation, le système d’exploitation OS garde le contrôle total de l’affichage sur l’afficheur SC : la partie IHM du système d’exploitation OS effectue les mises à jour de l’afficheur SC. Dans ce cas il existe un risque qu’un attaquant « surcharge » l’interface réelle dans le but de pousser l’utilisateur à interagir avec l’écran, et donc de déclencher des commandes véhicule à son insu.

[0063] La figure 4 illustre un deuxième mode de réalisation du procédé selon l’invention, dans lequel l’environnement sécurisé authentifié TEE a la main non seulement sur la couche tactile de l’afficheur SC (couche supérieure), mais également sur la couche d’affichage de l’afficheur SC (couche inférieure).

[0064] Dans le deuxième mode de réalisation, l’activation d’une zone de l’écran est transmise directement au système d’exploitation OS.

[0065] Dans ce mode de réalisation, quand l’utilisateur, en naviguant dans les menus, sélectionne une commande sécurisée du véhicule (par exemple HVAC ou ADAS), le système d’exploitation OS envoie la commande correspondante, par exemple « start HVAC » ou « start ADAS », demandant à l’environnement sécurisé authentifié TEE de prendre la main sur l’afficheur SC pour afficher le menu concerné. [0066] Si l’utilisateur appuie sur des commandes véhicule, l’environnement sécurisé authentifié TEE envoie les commandes chiffrées au système d’exploitation OS pour transfert à l’unité électronique UC.

[0067] Le composant d’authentification reçoit une trame START de commencement d’action sécurisée relative à la commande utilisateur, en réponse à l’activation de la zone de l’afficheur.

[0068] Quand l’environnement sécurisé authentifié TEE reçoit la trame « START » l’environnement sécurisé authentifié TEE devient le seul élément contrôlant totalement l’afficheur SC. C’est l’environnement sécurisé authentifié TEE qui fournit le contenu sur l’écran. Pour autant, l’environnement sécurisé authentifié TEE ne dispose pas des informations du système d’exploitation OS, telles que l’heure, les notifications etc.

[0069] Pour maintenir une unité dans l’expérience utilisateur, le système d’exploitation OS peut envoyer une capture d’écran de ce qu’il souhaite afficher de manière régulière à l’environnement sécurisé authentifié TEE.

[0070] L’environnement sécurisé authentifié TEE va superposer la partie qu’il doit fournir en contenu (i.e. le menu d’interaction véhicule, par exemple HVAC) sur la capture d’écran reçue de la part du système d’exploitation OS.

[0071] Dans la figure 4, la partie encadrée est entièrement gérée par l’environnement sécurisé authentifié TEE, ce qui accroît le niveau de sécurité par rapport au premier mode de réalisation.

[0072] Le module HAL transmet au composant d’authentification l’information de début de fonction sécurisée START, donc l’appui utilisateur est considéré par le contrôleur d’appui TC comme étant un appui sécurisé. [0073] Après avoir détecté l’événement d’appui sécurisé correspondant cette fois-ci à une commande spécifique de la commande sécurisée (par exemple ADAS ou HVAC), le composant d’authentification signe la commande, et la transmet au module HAL, qui la retransmet à l’unité électronique UC.

[0074] Après avoir transmis la commande signée au module HAL, le composant d’authentification CA génère une trame END de fin d’action sécurisée relative à la commande utilisateur. La trame END est donc envoyée quand l’utilisateur décide de « sortir » de l’écran affiché par l’environnement sécurisé authentifié TEE.

[0075] L’unité électronique UC vérifie ensuite la signature de la commande signée, et, si la commande est authentifiée, à savoir que la commande est bien générée par l’environnement sécurisé authentifié TEE et donc correspond bien à une interaction utilisateur, l’unité électronique UC exécute la commande par le biais de l’actionneur ACT.

[0076] Ce mode de réalisation a donc deux avantages. Premièrement, la sécurité est améliorée, car seul l’environnement sécurisé authentifié TEE affiche du contenu à l’écran. Deuxièmement, l’environnement sécurisé authentifié TEE ne contrôle le contrôleur d’appui TC que quand cela est nécessaire (alors que dans le premier mode de réalisation, il y a une latence supplémentaire).

[0077] La figure 5 illustre un exemple d’attaque malveillante visant à prendre le contrôle d’une fonction du véhicule, en lien avec le premier mode de réalisation. [0078] L’attaquant émule, via le système d’exploitation OS, une fonction de commande d’un actionneur. Le module HAL, en réponse à une demande de fonction transmise par la partie IHM, envoie l’information correspondante au composant d’authentification CA.

[0079] Le composant d’authentification CA vérifie si la commande correspond à une activation physique par un utilisateur, par exemple un appui sur l’écran. Pour cela, le composant d’authentification CA vérifie si l’utilisateur a interagi avec l’écran sur une période prédéterminée précédant la vérification d’appui (par exemple sur les X dernières milli secondes).

[0080] Dans le cadre d’une attaque malveillante, la commande utilisateur n’est pas datée, donc le composant d’authentification CA envoie un message d’erreur au module HAL. Dans le même temps, l’attaquant peut générer une fausse signature. Dans les deux cas, l’unité électronique UC vérifie la signature, et renvoi un message d’erreur, car la commande n’est pas authentifiée.

[0081] Avec cette solution, il est donc impossible pour un attaquant ayant pris le contrôle du système d’exploitation OS d’utiliser les commandes véhicule sans prendre le contrôle de l’environnement sécurisé authentifié TEE. Or, la prise de contrôle de l’environnement sécurisé authentifié TEE est complexe, de par son isolation par rapport à la surface d’attaque habituelle des systèmes d’exploitation, et de par sa taille limitée.

[0082] L’invention permet ainsi d’augmenter le niveau de sécurité de certaines interfaces utilisateur en créant une chaîne de confiance entre l’action sur l’écran et l’action initiée par le système multimédia, tout en limitant l’impact sur l’expérience utilisateur (pas de nécessité d’avoir un autre écran).

[0083] L’invention n’est pas limitée au domaine automobile. Elle peut être utilisée dans tout système proposant une interaction utilisateur nécessitant un certain niveau de sécurité, où un accès à distance aux fonctions exposées peut présenter un intérêt pour un attaquant.

[0084] Par exemple, le procédé peut être appliqué à un système domotique avec une interface utilisateur disponible à l’intérieur de la maison, et connectée à un dispositif communicant extérieur peu sécurisé, par exemple un smartphone. Ainsi, les fonctions exposées, par exemple le contrôle des ouvrants, peuvent être protégées, de sorte qu’en cas de compromission de l’écran de contrôle, aucune action ne puisse être initiée sans accès physique à l’écran du système domotique.