Brevet FR3076920A1 — publié le 20190719

L'invention a pour domaine technique la sécurité des calculateurs multicceurs à mémoire non volatile et plus particulièrement, la sécurité des calculateurs multicceurs à mémoire non volatile munis de coeurs de sécurité. Les véhicules automobiles actuels comprennent des calculateurs permettant 5 de gérer un nombre croissant de fonctions, notamment le contrôle du moteur, le contrôle de trajectoire ou encore l'interface homme machine. Un calculateur comprend au moins une mémoire et au moins un processeur présentant au moins un coeur d'exécution dit coeur d'exécution HOST. Chaque mémoire peut comprendre des zones de mémoire dans lesquelles 10 des données peuvent être mémorisées ou lues par au moins un coeur d'exécution HOST. Les mémoires peuvent être de type non volatile NVMY (acronyme anglophone pour « Non Volatil Memory »), qui présentent la particularité de maintenir les données mémorisées en l'absence d'alimentation électrique. Les données mémorisées peuvent être des programmes ou des données de paramétrage de programmes ou résultant de 15 l'exécution de programmes. Les coeurs d'exécution du processeur exécutent les programmes ou parties de programmes telles que des fonctions, de façon indépendante ou liée par rapport aux autres coeurs. Les mémoires et les coeurs d'exécution sont susceptibles d'être altérés par 20 une intrusion extérieure au système ce qui n'est pas admissible pour certaines applications liées à la sécurité, notamment l'anti-démarrage du véhicule. Pour ces applications, un coeur de sécurité HSM (acronyme anglophone pour « Hardware Security Management ») est ajouté au système afin de sécuriser les parties les plus critiques de ces applications. Cette sécurisation passe par la définition de zones 25 de mémoire protégées dans lesquelles seul le coeur de sécurité HSM peut écrire et lire. Ces zones de mémoire protégées sont physiquement distinctes des zones de mémoire des coeurs d'exécution. Lors du développement d'un véhicule, il est parfois nécessaire de réinitialiser les zones de mémoire liées à une fonction à un état similaire à un état de sortie d'usine, 30 c'est-à-dire avec des zones de mémoire vierges ou avec des valeurs par défaut. Une telle remise à zéro implique un effacement ou un écrasement des zones de mémoire liées à la fonction et situées en mémoire non-volatile réalisé par au moins coeur d'exécution HOST à réception d'une requête de réinitialisation spécifique. 2 De façon générale, les données stockées dans une mémoire non-volatile NVMY sont groupées par zones ou canal (terme dérivé du terme anglophone usité « Channel »). Pour chaque canal, on définit des propriétés spécifiques en fonction des besoins des coeurs d'exécution y accédant. Une de ces propriétés concerne la résistance à l'effacement et peut prendre une valeur « RESISTANT » ou une valeur « NON-RESISTANT ». Un canal « RESISTANT » n'est pas effacé lors d'une réinitialisation. Les données qu'il contient sont conservées. Un canal « NON-RESISTANT » est effacé lors d'une réinitialisation. Toutes les données qu'il contient, sont perdues lors de la réinitialisation. Les données stockées dans les canaux « NON-RESISTANT » d'une mémoire non-volatile NVMY liée à un coeur d'exécution HOST peuvent être effacées lors d'une réinitialisation logicielle. Pour chaque canal, une fonction d'initialisation peut être définie. Elle permet 15 d'initialiser les données qu'il contient à des valeurs spécifiques et/ou d'effectuer des traitements prédéfinis. Une telle réinitialisation est rendue plus complexe de par la présence du coeur de sécurité HSM, et des données le concernant dans des zones de mémoire protégées de mémoire non-volatile. 20 En effet, les données de la mémoire protégée non-volatile gérées par le coeur de sécurité HSM ne peuvent être modifiées ou supprimées par une requête extérieure au coeur de sécurité HSM. Elles ne peuvent donc pas être effacées ou écrasées par le coeur d'exécution HOST exécutant la requête de réinitialisation. Toutefois, certaines fonctions de sécurité comprennent des données situées 25 aussi bien dans des zones de mémoires gérées par un coeur d'exécution HOST et dans des zones de mémoire gérées par un coeur de sécurité HSM. Il existe un besoin pour une réinitialisation des données d'une fonction comprise dans au moins une mémoire non-volatile, une partie des données étant gérée par un coeur d'exécution HOST et une autre partie étant gérée par un coeur de sécurité 30 HSM. L'invention a pour objet un procédé de reprogrammation des données d'une fonction logicielle exécutée par au moins un coeur d'exécution et au moins un coeur de sécurité, les données à reprogrammer étant présentes dans au moins une mémoire non volatile gérée par un coeur d'exécution et dans au moins une mémoire non volatile gérée 35 par un coeur de sécurité, la au moins une mémoire non volatile gérée par un coeur d'exécution étant physiquement distincte de la au moins une mémoire non volatile gérée 3 par un coeur de sécurité, chaque mémoire non volatile étant gérée par un ensemble de fonctions de gestion. Le procédé comprend les étapes suivantes : - lorsque l'on reçoit une requête de reprogrammation, - on mémorise une deuxième valeur dans un premier booléen, 5 - on détermine si le premier booléen est égal à la deuxième valeur et si un deuxième booléen est égal à une première valeur, - si tel est le cas, on fait émettre par un coeur d'exécution au moins une requête de réinitialisation par un canal de communication bidirectionnel à destination du au moins un coeur de sécurité gérant une mémoire non volatile comprenant des 10 données à reprogrammer et au moins une requête d'initialisation à destination de chaque ensemble de fonctions de gestion de la mémoire non volatile gérée par un coeur d'exécution comprenant des données à reprogrammer, - après qu'une durée prédéterminée à partir de l'instant d'émission de la au moins une requête de réinitialisation s'est écoulée, - on mémorise une deuxième valeur dans le deuxième booléen, - on détermine si un événement de reprogrammation prédéterminé a eu lieu, - si tel est le cas, on mémorise dans le premier booléen la première valeur, tout en maintenant la deuxième valeur dans le deuxième booléen et on fait émettre par le au moins un coeur de sécurité gérant une mémoire non volatile comprenant des données à reprogrammer une requête d'écriture de valeurs prédéterminées et mémorisées à destination de l'ensemble de fonctions de gestion de la mémoire associé à la mémoire non volatile gérée par ledit au moins un coeur de sécurité de sorte que des valeurs prédéterminées et mémorisées considérées comme vierges associées à la fonction logicielle soient écrites dans ladite mémoire non volatile gérée par ledit au moins un coeur de sécurité comprenant des données à reprogrammer. On peut déterminer si un événement initialisant prédéterminé a eu lieu avant la réception d'une requête de reprogrammation, et si tel est le cas on peut initialiser le premier booléen et le deuxième booléen avec la première valeur. L'événement initialisant peut être choisi parmi l'établissement de l'alimentation du au moins un coeur d'exécution, du au moins un coeur de sécurité, des mémoires non volatiles et des fonctions de gestion associées et une temporisation prédéterminée. La requête de reprogrammation peut comprendre un numéro de version logicielle après réinitialisation et, après émission de la au moins une requête de 35 réinitialisation à destination du au moins un coeur de sécurité par un canal de communication bidirectionnel, on peut mémoriser la version logicielle après réinitialisation, et on peut modifier le deuxième booléen de sorte qu'il prenne une deuxième valeur et de 4 sorte à pouvoir déterminer si une requête ultérieure de réinitialisation est une première requête pour le numéro de version courant. L'événement de reprogrammation peut être choisi parmi un arrêt suivi d'une reprise de l'alimentation du au moins un coeur d'exécution et du au moins un coeur de 5 sécurité, des mémoires non volatiles et des fonctions de gestion associées, une temporisation prédéterminée correspondant à la durée estimée du traitement de la au moins une requête de réinitialisation. D'autres buts, caractéristiques et avantages de l'invention apparaîtront à la lecture de la description suivante, donnée uniquement à titre d'exemple non limitatif et 10 faite en référence aux dessins annexés sur lesquels : - la figure 1 illustre les principaux éléments matériels impliqués dans le procédé de reprogrammation selon l'invention, et - la figure 2 illustre les principales étapes du procédé de reprogrammation selon l'invention. 15 Afin de résoudre le problème technique, il est proposé un procédé de reprogrammation en deux parties permettant de réaliser une réinitialisation dans des conditions de requête contrôlées des données d'une fonction se trouvant pour partie dans une zone de mémoire non volatile gérées par au moins un coeur d'exécution HOST, une autre partie se trouvant dans une zone de mémoire non volatile gérée par le coeur de 20 sécurité HSM. La description ci-dessous est réalisée pour des données gérées par un coeur d'exécution HOST et par un coeur de sécurité HSM. L'homme du métier peut appliquer cet enseignement à des données gérées par plusieurs coeurs d'exécution HOST et par au moins un coeur de sécurité HSM sans faire preuve d'inventivité en multipliant les 25 messages, les requêtes et les booléens de sorte que les échanges entre un coeur d'exécution HOST et un coeur de sécurité HSM se conforment à la description ci-dessous. Sur la figure 1, on peut voir qu'une première partie du procédé de reprogrammation est exécutée par un coeur d'exécution HOST référencé 1, tandis qu'une deuxième partie du procédé est exécutée par le coeur de sécurité HSM référencé 2. 30 Cela est rendu possible de par le fait que le coeur d'exécution HOST 1 et le coeur de sécurité HSM 2 peuvent communiquer en définissant un canal de communication bidirectionnel 3 permettant d'échanger des messages. Le contenu des messages est prédéfini et peut comprendre une demande d'exécution d'une fonction avec une liste de paramètres. Afin que les deux parties du procédé puissent communiquer de façon sécurisée pour que les données en mémoire non volatile gérées par le coeur de sécurité HSM 2 soient réinitialisées, un message supplémentaire est ajouté dans le canal de 5 communication entre le coeur d'exécution HOST 1 et le coeur de sécurité HSM 2. Ce message supplémentaire est spécifique au procédé de reprogrammation de sorte à éviter une réinitialisation intempestive ou un détournement à des fins d'intrusion. En complément de la présentation des données en mémoire NVMY réalisée 5 en introduction, on précise que les données gérées par un coeur d'exécution HOST 1 sont comprises soit dans un canal « NON-RESISTANT » 4a, soit dans un canal « RESISTANT » 4b d'une première mémoire NVMY 4. Par « RESISTANT » ou « NONRESISTANT », on entend réciproquement, résistant ou non résistant à une reprogrammation. Les données gérées par le coeur de sécurité HSM 2 sont comprises 10 dans un canal « RESISTANT » d'une deuxième mémoire NVMY 5 distincte de la première mémoire NVMY 4. Pour chacun de ces canaux, une fonction d'initialisation de mémoire NVMY est associée, lorsqu'il n'y a pas de données, tel que c'est le cas lors du premier démarrage. Il existe également des fonctions d'écriture de données. Ces fonctions 15 d'initialisation et d'écriture ne sont pas appelables par une fonction, mais par les fonctions de gestion de la mémoire NVMY. Il existe ainsi un premier ensemble de fonctions de gestion de la mémoire NVMY référencé 6 associé à la première mémoire non volatile NVMY 4, et un deuxième ensemble 7 de fonctions de gestion de la mémoire NVMY référencé associé à la deuxième mémoire non volatile NVMY 5. Une requête de 20 reprogrammation traitée par un coeur d'exécution HOST fait l'objet d'une requête d'initialisation req init à destination du premier ensemble 6 de fonctions de gestion de la mémoire NVMY qui procède à l'initialisation des données (référencée « mit» sur la figure 1) dans la première mémoire non volatile 4 gérées par le coeur d'exécution HOST en fonction du format de la requête d'initialisation req init et des caractères « RESISTANT » 25 ou « NON-RESISTANT » des canaux de mémoire. Par ailleurs, alors que la fonction d'initialisation des données dans la première mémoire non volatile NVMY 4 gérées par un coeur d'exécution HOST peut être appelée à tout moment, la fonction d'initialisation de la mémoire protégée gérée par le coeur de sécurité HSM 2 ne peut être appelée que lors de la première initialisation alors qu'aucune 30 donnée n'est présente dans la deuxième mémoire non volatile NVMY 5 gérée par le coeur de sécurité HSM 2. Aucune autre condition n'est prévue dans cette fonction d'initialisation et il n'est pas prévu que le coeur de sécurité HSM 2 puisse recevoir une requête d'initialisation autre que la requête de première initialisation. Il est ainsi nécessaire de simuler une initialisation en faisant émettre par le 35 coeur HSM 2 une requête d'écriture req write à destination de l'ensemble 7 de fonctions de gestion de la mémoire NVMY relatives à la deuxième mémoire non volatile NVMY 5 gérée par le coeur de sécurité HSM 2 de sorte que la deuxième mémoire non volatile 6 NVMY 5 se retrouve dans un état similaire à celui qui serait obtenu à l'issue d'une initialisation. Cette simulation passe par l'écriture (référencée « write » sur la figure 1) de valeurs vierges, prédéterminées et mémorisées, dans la deuxième mémoire non volatile NVMY 5. 5 Les étapes du procédé de reprogrammation, illustrées par la figure 2, vont maintenant être décrites. Le procédé débute par une première étape El au cours de laquelle on détermine l'occurrence d'un événement initialisant suite auquel on initialise des booléens avec une première valeur. Dans un mode de réalisation, l'événement initialisant est 10 l'établissement de l'alimentation du coeur HOST 1, du coeur HSM 2 des mémoires non volatiles et des fonctions de gestion associées. A réception d'une requête de reprogrammation req repro par le coeur d'exécution HOST 1 concernant la fonction logicielle présentant des données dans la première mémoire non volatile 4 et dans la deuxième mémoire non volatile 5, on modifie 15 le premier booléen de sorte qu'il prenne une deuxième valeur, au cours d'une deuxième étape E2. Lorsque le premier booléen est égal à une deuxième valeur, si le deuxième booléen est égal à une première valeur, et si le numéro de version logicielle de la requête de reprogrammation req repro est différent de la version mémorisée dans le canal 20 « RESISTANT » géré par le coeur HOST, on fait émettre par le coeur HOST 1 une requête de réinitialisation req reinit à destination du coeur de sécurité HSM 2 par le canal de communication bidirectionnel 3 et une requête d'initialisation req init à destination de l'ensemble 6 de fonctions de gestion de la mémoire NVMY associé à la première mémoire non volatile NVMY 4 lors d'une troisième étape E3. 25 Au cours d'une quatrième étape E4, après que la requête de réinitialisation ait été effectivement émise, on mémorise la version logicielle de la requête de reprogrammation et on modifie un deuxième booléen de sorte qu'il prenne une deuxième valeur. On considère que la requête de réinitialisation a été effectivement émise lorsqu'une durée égale à la durée entre deux cycles d'exécution s'est écoulée (par 30 exemple, 10ms). La mémorisation de la version logicielle de la requête de reprogrammation permet une comparaison ultérieure avec la version logicielle associée à une requête de reprogrammation ultérieure, de sorte à déterminer si la requête ultérieure de reprogrammation est une première requête pour le numéro de version courant. 35 Le passage du deuxième booléen à la deuxième valeur permet, en conjonction d'un premier booléen à la deuxième valeur, de mémoriser que la requête de réinitialisation a été émise. 7 La mémorisation de la version logicielle et le changement de valeur du deuxième booléen permettent d'éviter que des requêtes ultérieures de réinitialisation soient transmises au coeur de sécurité HSM alors que la première requête de réinitialisation est en cours de traitement. 5 Après un événement de reprogrammation tel qu'un arrêt de l'alimentation du coeur HOST 1 et du coeur HSM 2 suivi d'une reprise de cette alimentation, on mémorise dans le premier booléen la première valeur, tout en maintenant la deuxième valeur dans le deuxième booléen, au cours d'une cinquième étape E5. On mémorise ainsi qu'une requête de réinitialisation a eu lieu précédemment. 10 Apres une durée prédéterminée telle que la durée entre deux cycles d'exécution (par exemple, 10ms), on mémorise la première valeur dans le deuxième booléen, tout en maintenant le premier booléen à la première valeur, au cours d'une sixième étape E6. On retourne ainsi au cas nominal, en attente d'une nouvelle requête de reprogrammation. 15 Le procédé se poursuit par une septième étape E7, exécutée par le coeur de sécurité HSM, au cours de laquelle, à réception de la requête de réinitialisation req reinit par le canal de communication bidirectionnel 3, on simule la fonction d'initialisation associée à la deuxième mémoire non volatile NVMY 5 gérée par le coeur de sécurité HSM 2. En effet, comme expliqué plus haut, cette fonction d'initialisation n'est pas 20 appelable par la fonction dont les données sont à réinitialiser, ni par l'ensemble 6 de fonctions de gestion NVMY passée la première initialisation, on doit recourir à une simulation. Par simulation, on entend faire émettre par le coeur HSM 2 une requête d'écriture req write à destination de la fonction d'écriture du deuxième ensemble 7 de 25 fonctions de gestion de la mémoire NVMY associé à la deuxième mémoire non volatile NVMY 5 de sorte que des valeurs prédéterminées et mémorisées considérées comme vierges soient écrites dans la deuxième mémoire non volatile 5 gérée par le coeur de sécurité HSM 2. On obtient ainsi à l'issue de l'opération d'écriture, référencée write, la deuxième mémoire non volatile NVMY 5 dans un état similaire à l'état résultant de la 30 première initialisation. Par valeurs vierges, on entend des valeurs prédéterminées, mémorisées soit dans le coeur HSM 2, soit dans un canal « RESISTANT » de la deuxième mémoire non volatile NVMY 5. Par ailleurs, la réinitialisation des données d'une fonction dans la première mémoire non volatile NVMY 4 peut avoir lieu suite à une demande explicite d'effacement des données en mémoire non-volatile NVMY ou à une 35 réinitialisation d'une nouvelle version logicielle. Dans le premier cas, tous les canaux « NON-RESISTANT » dans la première mémoire non volatile NVMY 4 sont effacés. 8 Dans le deuxième cas, l'effacement des canaux « NON-RESISTANT » dans la première mémoire non volatile NVMY 4 sera effectué uniquement si le numéro de version logicielle mémorisé dans la requête de reprogrammation est différent du numéro de version mémorisé dans le canal « RESISTANT » de la première mémoire non volatile 5 NVMY 4. Cela est notamment le cas lorsque l'on souhaite disposer de valeurs par défaut sans modifier la version logicielle. En complément du mode de réalisation décrit ci-dessus, on note que plusieurs modes de réalisation alternatifs sont obtenus par altération de l'un et/ou l'autre de l'événement initialisant et de l'événement de reprogrammation. 10 Dans un premier mode de réalisation alternatif, on considère un premier événement initialisant différent de l'établissement de l'alimentation des coeurs, tel qu'une temporisation prédéterminée. Dans un deuxième mode de réalisation alternatif, on considère un deuxième événement de reprogrammation différent d'une succession d'interruption/reprise de 15 l'alimentation des coeurs, tel qu'une temporisation prédéterminée correspondant à la durée estimée du traitement de la requête de réinitialisation, ou un message de confirmation du traitement de la requête de réinitialisation émis par le coeur de sécurité HSM 2 et reçu par le coeur d'exécution HOST 1. Lorsque un premier et un deuxième événements de reprogrammation sont 20 des temporisations, l'homme du métier comprendra que le procédé est exécuté en boucle par les coeurs respectifs (la septième étape est alors exécutée en boucle par le coeur de sécurité HSM 2 tandis que les première à sixième étapes sont exécutées en boucle par le coeur d'exécution HOST 1. L'homme du métier comprendra par ailleurs que les premier et deuxième 25 modes de réalisation alternatifs peuvent être combinés. Lorsque la fonction logicielle est exécutée par plusieurs coeurs d'exécution et par plusieurs coeurs de sécurité, la requête de reprogrammation req repro est reçue par un coeur d'exécution. Le coeur d'exécution ayant reçu la requête applique les différentes étapes du procédé tel que décrit ci-dessus. Toutefois, il émet, en parallèle de la requête 30 d'initialisation à destination de l'ensemble de fonction de gestion de la mémoire non volatile géré par lui-même, des requêtes d'initialisation à destination des ensembles de fonctions de gestion de la mémoire non volatile gérée par les autres coeurs d'exécution. De même, le coeur d'exécution ayant reçu la requête de reprogrammation émet une requête de réinitialisation à destination de chaque coeur de sécurité par des canaux de 35 communication bidirectionnel distincts. Le mode de fonctionnement du procédé de reprogrammation lorsque plus d'un coeur d'exécution et plus d'un coeur de sécurité sont impliqués a été décrit ci-dessus 9 dans le cas d'un fonctionnement maître-esclaves. Toutefois, d'autres modes de communication et de supervision tels que des modes de communication décentralisés ou de proche en proche peuvent être employés tout en restant dans la portée de l'invention tant que chaque ensemble de fonction de gestion de mémoire non volatile dans laquelle 5 sont mémorisées des données de la fonction logicielle objet de la reprogrammation reçoit une requête d'initialisation req init ou une requête d'écriture REVENDICATIONS1. Procédé de reprogrammation des données d'une fonction logicielle exécutée par au moins un coeur d'exécution (1), et au moins un coeur de sécurité (2), les données à reprogrammer étant présentes dans au moins une mémoire non volatile (4) gérée par un coeur d'exécution (1) et dans au moins une mémoire non volatile (5) gérée par un coeur de sécurité (2), la au moins une mémoire non volatile (4) gérée par un coeur d'exécution (1) étant physiquement distincte de la au moins une mémoire non volatile (5) gérée par un coeur de sécurité (2), chaque mémoire non volatile étant gérée par un ensemble de fonctions de gestion, caractérisé par le fait qu'il comprend les étapes suivantes : - lorsque l'on reçoit une requête de reprogrammation, - on mémorise une deuxième valeur dans un premier booléen, - on détermine si le premier booléen est égal à la deuxième valeur et si un deuxième booléen est égal à une première valeur, - si tel est le cas, on fait émettre par un coeur d'exécution (1) au moins une requête de réinitialisation par un canal de communication bidirectionnel (3) à destination du au moins un coeur de sécurité (2) gérant une mémoire non volatile comprenant des données à reprogrammer et au moins une requête d'initialisation à destination de chaque ensemble (6) de fonctions de gestion de la mémoire non volatile gérée par un coeur d'exécution (1) comprenant des données à reprogrammer, - après qu'une durée prédéterminée à partir de l'instant d'émission de la au moins une requête de réinitialisation s'est écoulée, on mémorise une deuxième valeur dans le deuxième booléen, - on détermine si un événement de reprogrammation prédéterminé a eu lieu, - si tel est le cas, on mémorise dans le premier booléen la première valeur, tout en maintenant la deuxième valeur dans le deuxième booléen et on fait émettre par le au moins un coeur de sécurité (2) gérant une mémoire non volatile comprenant des données à reprogrammer une requête d'écriture de valeurs prédéterminées et mémorisées à destination de l'ensemble (7) de fonctions de gestion de la mémoire associé à la mémoire non volatile (5) gérée par ledit au moins un coeur de sécurité (2) de sorte que des valeurs prédéterminées et mémorisées considérées comme vierges associées à la fonction logicielle soient écrites dans ladite mémoire non volatile (5) gérée par ledit au moins un coeur de sécurité (2) comprenant des données à reprogrammer. 11 2. Procédé selon la revendication 1, dans lequel, on détermine si un événement initialisant prédéterminé a eu lieu avant la réception d'une requête de reprogrammation, et si tel est le cas, on initialise le premier booléen et le deuxième booléen avec la première valeur. 5 3. Procédé selon la revendication 2, dans lequel l'événement initialisant est choisi parmi l'établissement de l'alimentation du au moins un coeur d'exécution (1), du au moins un coeur de sécurité (2), des mémoires non volatiles et des fonctions de gestion associées et une temporisation prédéterminée. 4. Procédé selon l'une quelconque des revendications précédentes, dans lequel 10 la requête de reprogrammation comprend un numéro de version logicielle après réinitialisation et, après émission de la au moins une requête de réinitialisation à destination du au moins un coeur de sécurité (2) par un canal de communication bidirectionnel (3), on mémorise la version logicielle après réinitialisation, et on modifie le deuxième booléen de sorte qu'il prenne une deuxième valeur et de sorte à pouvoir 15 déterminer si une requête ultérieure de réinitialisation est une première requête pour le numéro de version courant. 5. Procédé selon l'une quelconque des revendications précédentes, dans lequel l'événement de reprogrammation est choisi parmi un arrêt suivi d'une reprise de l'alimentation du au moins un coeur d'exécution (1) et du au moins un coeur de 20 sécurité (2), des mémoires non volatiles et des fonctions de gestion associées, une temporisation prédéterminée correspondant à la durée estimée du traitement de la au moins une requête de réinitialisation.