L’invention a pour domaine technique la sécurité des calculateurs multicoeurs à mémoire non volatile et plus particulièrement, la sécurité des calculateurs multicoeurs à mémoire non volatile munis de coeurs de sécurité.

Les véhicules automobiles actuels comprennent des calculateurs permettant 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 cœur d’exécution dit cœur d’exécution HOST.

Chaque mémoire peut comprendre des zones de mémoire dans lesquelles des données peuvent être mémorisées ou lues par au moins un cœur 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 l’exécution de programmes.

Les cœurs 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 cœurs.

Les mémoires et les cœurs d’exécution sont susceptibles d’être altérés par 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 cœur 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 de mémoire protégées dans lesquelles seul le cœur 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 cœurs 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, 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 cœur d’exécution HOST à réception d’une requête de réinitialisation spécifique. 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 cœur 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 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 cœur de sécurité HSM, et des données le concernant dans des zones de mémoire protégées de mémoire non-volatile.

En effet, les données de la mémoire protégée non-volatile gérées par le cœur de sécurité HSM ne peuvent être modifiées ou supprimées par une requête extérieure au cœur de sécurité HSM. Elles ne peuvent donc pas être effacées ou écrasées par le cœur d’exécution HOST exécutant la requête de réinitialisation.

Toutefois, certaines fonctions de sécurité comprennent des données situées aussi bien dans des zones de mémoires gérées par un cœur d’exécution HOST et dans des zones de mémoire gérées par un cœur 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 cœur d’exécution HOST et une autre partie étant gérée par un cœur de sécurité 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 cœur d’exécution et au moins un cœur de sécurité, les données à reprogrammer étant présentes dans au moins une mémoire non volatile gérée par un cœur d’exécution et dans au moins une mémoire non volatile gérée par un cœur de sécurité, la au moins une mémoire non volatile gérée par un cœur d’exécution étant physiquement distincte de la au moins une mémoire non volatile gérée par un cœur 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,

• 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 cœur d’exécution au moins une requête de réinitialisation par un canal de communication bidirectionnel à destination du au moins un cœur de sécurité gérant une mémoire non volatile comprenant des 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 cœur 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 cœur 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 cœur 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 cœur 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 cœur d’exécution, du au moins un cœur 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 réinitialisation à destination du au moins un cœur 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 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 cœur d’exécution et du au moins un cœur de 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 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.

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 cœur d’exécution HOST, une autre partie se trouvant dans une zone de mémoire non volatile gérée par le cœur de sécurité HSM.

La description ci-dessous est réalisée pour des données gérées par un cœur d’exécution HOST et par un cœur de sécurité HSM. L’homme du métier peut appliquer cet enseignement à des données gérées par plusieurs cœurs d’exécution HOST et par au moins un cœur de sécurité HSM sans faire preuve d’inventivité en multipliant les messages, les requêtes et les booléens de sorte que les échanges entre un cœur d’exécution HOST et un cœur 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 cœur d’exécution HOST référencé 1 , tandis qu’une deuxième partie du procédé est exécutée par le cœur de sécurité HSM référencé 2.

Cela est rendu possible de par le fait que le cœur d’exécution HOST 1 et le cœur 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 cœur de sécurité HSM 2 soient réinitialisées, un message supplémentaire est ajouté dans le canal de communication entre le cœur d’exécution HOST 1 et le cœur 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 en introduction, on précise que les données gérées par un cœur 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 « NON- RESISTANT », on entend réciproquement, résistant ou non résistant à une reprogrammation. Les données gérées par le cœur de sécurité HSM 2 sont comprises 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 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 reprogrammation traitée par un cœur d’exécution HOST fait l’objet d’une requête d’initialisation reqjnit à 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 « init » sur la figure 1 ) dans la première mémoire non volatile 4 gérées par le cœur d’exécution HOST en fonction du format de la requête d’initialisation reqjnit et des caractères « RESISTANT » 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 cœur 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 cœur de sécurité HSM 2 ne peut être appelée que lors de la première initialisation alors qu’aucune donnée n’est présente dans la deuxième mémoire non volatile NVMY 5 gérée par le cœur 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 cœur 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 cœur 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 cœur de sécurité HSM 2 de sorte que la deuxième mémoire non volatile 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.

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 E1 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 l’établissement de l’alimentation du cœur HOST 1 , du cœur 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 cœur 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 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 « RESISTANT » géré par le cœur HOST, on fait émettre par le cœur HOST 1 une requête de réinitialisation req_reinit à destination du cœur de sécurité HSM 2 par le canal de communication bidirectionnel 3 et une requête d’initialisation reqjnit à 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.

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 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.

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. 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 cœur de sécurité HSM alors que la première requête de réinitialisation est en cours de traitement.

Après un événement de reprogrammation tel qu’un arrêt de l’alimentation du cœur HOST 1 et du cœur 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.

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.

Le procédé se poursuit par une septième étape E7, exécutée par le cœur 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 cœur de sécurité HSM 2. En effet, comme expliqué plus haut, cette fonction d’initialisation n’est pas 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 cœur HSM 2 une requête d’écriture req_write à destination de la fonction d’écriture du deuxième ensemble 7 de 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 cœur 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 première initialisation. Par valeurs vierges, on entend des valeurs prédéterminées, mémorisées soit dans le cœur 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 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. 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 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.

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 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 cœur de sécurité HSM 2 et reçu par le cœur d’exécution HOST 1.

Lorsque un premier et un deuxième événements de reprogrammation sont des temporisations, l’homme du métier comprendra que le procédé est exécuté en boucle par les cœurs respectifs (la septième étape est alors exécutée en boucle par le cœur de sécurité HSM 2 tandis que les première à sixième étapes sont exécutées en boucle par le cœur d’exécution HOST 1.

L’homme du métier comprendra par ailleurs que les premier et deuxième modes de réalisation alternatifs peuvent être combinés.

Lorsque la fonction logicielle est exécutée par plusieurs cœurs d’exécution et par plusieurs cœurs de sécurité, la requête de reprogrammation req_repro est reçue par un cœur d’exécution. Le cœur 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 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 cœurs d’exécution. De même, le cœur d’exécution ayant reçu la requête de reprogrammation émet une requête de réinitialisation à destination de chaque cœur de sécurité par des canaux de communication bidirectionnel distincts.

Le mode de fonctionnement du procédé de reprogrammation lorsque plus d’un cœur d’exécution et plus d’un cœur de sécurité sont impliqués a été décrit ci-dessus 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 sont mémorisées des données de la fonction logicielle objet de la reprogrammation reçoit une requête d’initialisation reqjnit ou une requête d’écriture req_write.