FR 3100905 A1 20210319 FR 1910201 A 20190916 L’invention concerne un système sur puce (10) comprenant un élément sécurisé (102) comprenant une unité de traitement (1022) configurée pour envoyer des instructions à une mémoire non volatile réinscriptible (12) extérieure au système sur puce et relié à celui-ci, l’élément sécurisé (102) comprenant en outre une mémoire non volatile sécurisée (1024) ainsi qu’une mémoire volatile sécurisée (1026), le système sur puce (10) étant caractérisé en ce que l’unité de traitement (1022) est configurée pour commander : - le stockage, dans la mémoire non volatile réinscriptible (12) d’au moins un objet ayant une version courante, et d’un répertoire dédié associant un identifiant de chaque objet à un identifiant de la version courante de cet objet, le répertoire dédié comprenant en outre un identifiant de sa propre version courante ; et - le stockage, dans la mémoire non volatile (1024) de l’élément sécurisé, de l’identifiant de la version courante du répertoire dédié. Figure à publier avec l’abrégé : Fig. 1 Système sur puce et procédé garantissant la fraicheur des données stockées dans une mémoire extérieure L’invention est dans le domaine de la sécurité, notamment des systèmes sur puce à élément sécurisé dont une partie des données est stockée dans une mémoire extérieure au système sur puce. L’invention concerne, en particulier, un système sur puce et des procédés garantissant la fraicheur des données stockées dans cette mémoire extérieure. Etat de la technique Dans les systèmes sur puce ou SOC (pour System On Chip en terminologie anglo-saxonne) comprenant un élément intégré sécurisé, les données manipulées par le système d’exploitation sécurisé sont généralement stockées dans une mémoire extérieure au système sur puce, et ce pour des raisons de coûts. Ainsi, par exemple, l’élément sécurisé comprend une unité de traitement, une mémoire volatile ainsi qu’une mémoire non volatile de petite taille, présentant typiquement une faible endurance, telle qu’une mémoire OTP (pour One Time Programmable en terminologie anglo-saxonne) ou MTP (pour Multi Time Programmable en terminologie anglo-saxonne), tandis que la mémoire extérieure est typiquement une mémoire non volatile réinscriptible présentant une bien meilleure endurance. Il s’agit par exemple d’une mémoire Flash. Une difficulté est que la mémoire extérieure à l’élément sécurisé et au SOC peut être partagée avec d’autres applications que celles de l’élément sécurisé ou du SOC. De plus, elle peut être manipulée indépendamment de l’élément sécurisé ou du SOC qui ne peut donc pas contrôler l’utilisation des données qu’elle contient. Par exemple, les données de la mémoire extérieure peuvent être récupérées afin d’être réutilisées ultérieurement à des fins frauduleuses. Une telle attaque consistant à modifier la valeur courante d’une donnée en réutilisant une ancienne valeur est connue sous le nom d’attaque par rollback . Elle est d’autant plus difficile à détecter en l’absence d’une connexion permettant de vérifier à partir d’un serveur distant, la ‘fraicheur’ de la valeur utilisée, comme par exemple décrit dans le document US 2017/0124353 A1. A titre d’illustration, une telle attaque peut permettre à un utilisateur d’avoir accès à un service payant après la fin de son abonnement. Une autre illustration de ce type d’attaque peut permettre à un utilisateur de remettre son porte-monnaie électronique à son maximum après l’avoir vidé. Il existe donc un besoin pour un moyen local, c’est-à-dire ne nécessitant pas la connexion à un serveur distant, de vérifier la fraicheur des données d’une telle mémoire extérieure au SOC, afin d’éviter notamment les attaques par rollback . La présente invention a ainsi pour objet de pallier au moins un de ces inconvénients. Dans ce contexte, un premier aspect de l’invention concerne un système sur puce comprenant un élément sécurisé comprenant une unité de traitement configurée pour exécuter un système d’exploitation sécurisé et pour envoyer des instructions à une mémoire non volatile réinscriptible extérieure au système sur puce et relié à celui-ci, l’élément sécurisé comprenant en outre une mémoire non volatile sécurisée ainsi qu’une mémoire volatile sécurisée, le système sur puce étant caractérisé en ce que l’unité de traitement est configurée pour commander : - le stockage, dans la mémoire non volatile réinscriptible extérieure d’au moins un objet ayant une version courante, et d’un répertoire dédié associant un identifiant de chaque objet à un identifiant de la version courante de cet objet, le répertoire dédié comprenant en outre un identifiant de sa propre version courante ; et - le stockage, dans la mémoire non volatile de l’élément sécurisé, de l’identifiant de la version courante du répertoire dédié. Corrélativement, un deuxième aspect de l’invention concerne un procédé d’écriture sécurisée d’un objet dans une mémoire non volatile réinscriptible extérieure à un système sur puce et reliée à celui-ci, le système sur puce comprenant un élément sécurisé comprenant une unité de traitement configurée pour exécuter un système d’exploitation sécurisé et pour envoyer des instructions à la mémoire non volatile réinscriptible extérieure, l’élément sécurisé comprenant en outre une mémoire non volatile sécurisée ainsi qu’une mémoire volatile sécurisée, le procédé étant caractérisé en ce qu’il comprend les étapes suivantes : - commande de l’écriture d’un identifiant de la version courante de l’objet dans un répertoire dédié stocké dans la mémoire non volatile réinscriptible extérieure, en association avec un identifiant de l’objet, - commande de la mise à jour d’un identifiant de la version courante du répertoire dédié dans le répertoire dédié stocké dans la mémoire non volatile réinscriptible extérieure, - commande de l’écriture de l’identifiant de la version courante du répertoire dédié dans la mémoire non volatile sécurisée de l’élément sécurisé. L’invention ainsi revendiquée permet de s’assurer de la « fraicheur » des données stockées dans la mémoire extérieure au SOC et reliée à lui, c’est-à-dire de s’assurer que ces données correspondent bien à la version attendue à l’instant considéré. En effet, en attachant une version courante à chaque objet, et en consignant un identifiant de cette version dans un répertoire dédié ayant lui aussi une version dont un identifiant est consigné dans la mémoire non volatile sécurisée de l’élément sécurisé, une attaque consistant à remplacer les données de l’objet dans la mémoire externe par une ancienne version serait immédiatement détectée. La sécurité générale du système sur puce est donc améliorée, sans que cela nécessite de modification matérielle du système sur puce. Le bénéfice de l’utilisation d’une mémoire extérieure ayant une meilleure endurance que la mémoire non volatile de l’élément sécurisé est donc conservé. De plus, le système de réplication de version utilisé dans l’invention revendiquée permet de différencier un objet non à jour en raison d’une simple coupure d’alimentation (appelée « tearing » en terminologie anglo-saxonne) pendant l’écriture (la mise à jour) de ses données par rapport à une attaque visant à écrire d’anciennes données. Dans des modes de réalisation, l’unité de traitement est configurée pour commander l’écriture, dans une zone de type « rollforward » dans la mémoire non volatile réinscriptible extérieure, de données à utiliser pour mettre à jour un objet. Dans des modes de réalisation, l’unité de traitement est configurée pour commander la création d’une copie d’au moins une partie du contenu de la mémoire non volatile réinscriptible extérieure dans la mémoire volatile sécurisée de l’élément sécurisé. Dans des modes de réalisation, l’unité de traitement est configurée pour commander la modification de ladite copie dans la mémoire volatile sécurisée de l’élément sécurisé avant la modification de la mémoire non volatile réinscriptible extérieure. Dans des modes de réalisation, l’unité de traitement est configurée pour commander: - la reproduction des modifications effectuées sur la copie du répertoire dédié et de la zone de type « rollforward » en mémoire volatile sécurisée sur le répertoire dédié et la zone de type « rollforward » stockés dans la mémoire non volatile réinscriptible extérieure, puis - la modification du ou des objets concernés stockés dans la mémoire non volatile réinscriptible extérieure conformément au contenu de la zone de type « rollforward » et du répertoire dédié. Dans des modes de réalisation, l’unité de traitement est configurée pour commander la mise à jour de l’identifiant de la version courante du répertoire dédié dans la mémoire non volatile sécurisée de l’élément sécurisé avant la modification du ou des objets concernés stockés dans la mémoire non volatile réinscriptible extérieure conformément au contenu de la zone de type « rollforward » et du répertoire dédié. Dans des modes de réalisation, l’unité de traitement est configurée pour commander la reproduction des modifications en mémoire non volatile réinscriptible extérieure, après que plusieurs copies d’objets aient été modifiées dans la mémoire volatile sécurisée de l’élément sécurisé. Dans des modes de réalisation, la mémoire non volatile sécurisée de l’élément sécurisé est une mémoire à durée de vie limitée de type OTP ou MTP. Dans des modes de réalisation, l’identifiant de la version courante d’un objet et/ou l’identifiant de la version courante du répertoire dédié est un numéro de version. Dans des modes de réalisation, l’identifiant de la version courante d’un objet et/ou l’identifiant de la version courante du répertoire dédié est une somme de contrôle ( checksum en terminologie anglo-saxonne) calculée à partir de l’objet et/ou du répertoire dédié, identifiant de manière unique sa version. Dans des modes de réalisation, l’identifiant de la version courante d’un objet et/ou l’identifiant de la version courante du répertoire dédié est une signature de l’objet et/ou du répertoire dédié identifiant de manière unique sa version. Dans des modes de réalisation, l’unité de traitement met en œuvre une première fonction de comparaison et une deuxième fonction de comparaison afin de déterminer si un identifiant de version correspond à une version courante ou à une ancienne version, la première fonction consistant à déterminer si les valeurs sont identiques, la seconde fonction consistant à déterminer si ladite version est strictement supérieure ou strictement inférieure à la version courante. Par exemple, la première fonction consiste à déterminer si les valeurs de la version de la copie du répertoire en mémoire volatile sécurisée et celle de la version courante du répertoire consignée dans la mémoire non volatile sécurisée OTP/MTP de l’élément sécurisé sont identiques. La seconde fonction consiste à déterminer si la version de la copie du répertoire en mémoire volatile sécurisée est strictement supérieure ou strictement inférieure à la version courante du répertoire consignée dans la mémoire non volatile sécurisée OTP/MTP de l’élément sécurisé. Dans des modes de réalisation, l’unité de traitement est configurée pour fonctionner tantôt selon un mode d’exécution non sécurisé tantôt selon un mode d’exécution sécurisé. Dans des modes de réalisation, l’unité de traitement est configurée pour commander un contrôleur de mémoire contrôlant la mémoire non volatile réinscriptible extérieure. Ce contrôleur peut être sur le SOC ou à l’extérieur de celui-ci. Dans des modes de réalisation, le procédé comprend une étape de vérification de la fraicheur d’un objet stocké dans la mémoire non volatile réinscriptible extérieure, comprenant : - la création d’une copie du répertoire dédié et de l’objet dans la mémoire volatile sécurisée de l’élément sécurisé, - la comparaison de l’identifiant de la version courante du répertoire dédié stocké dans la copie (en mémoire volatile sécurisée) du répertoire dédiée, avec l’identifiant de la version courante du répertoire dédié stocké dans la mémoire non volatile sécurisée de l’élément sécurisé ; - en cas d’égalité, la comparaison de l’identifiant de la version courante de la copie (en mémoire volatile sécurisée) de l’objet avec l’identifiant de la version de cet objet stocké dans la copie (en mémoire volatile sécurisée) du répertoire dédié, afin de vérifier la fraicheur de l’objet. Dans des modes de réalisation, en cas d’égalité de version entre l’identifiant de la version courante du répertoire dédié stocké dans la copie (en mémoire volatile sécurisée) du répertoire dédiée et l’identifiant de la version courante du répertoire dédié stocké dans la mémoire non volatile sécurisée de l’élément sécurisé, mais de différence entre les versions de l’objet indiquées dans l’objet lui-même et dans le répertoire dédié, le procédé comprend une étape de mise à jour de la version et/ou du contenu dudit objet. Dans des modes de réalisation, ce procédé est mis en œuvre au démarrage de l’unité de traitement de l’élément sécurisé. Dans des modes de réalisation, le procédé comprend en outre une étape d’écriture, dans une zone de type « rollforward » dans la mémoire non volatile réinscriptible extérieure, de données à utiliser pour mettre à jour un objet. Dans des modes de réalisation, l’unité de traitement met en œuvre une première fonction de comparaison et une deuxième fonction de comparaison afin de déterminer si un identifiant de version correspond à une version courante ou à une ancienne version, la première fonction consistant à déterminer si les valeurs sont identiques, la seconde fonction consistant à déterminer si ladite version est strictement supérieure ou strictement inférieure à la version courante. Par exemple, la première fonction consiste à déterminer si les valeurs de la version de la copie du répertoire en mémoire volatile sécurisée et celle de la version courante du répertoire consignée dans la mémoire non volatile sécurisée OTP/MTP de l’élément sécurisé sont identiques. La seconde fonction consiste à déterminer si la version de la copie du répertoire en mémoire volatile sécurisée est strictement supérieure ou strictement inférieure à la version courante du répertoire consignée dans la mémoire non volatile sécurisée OTP/MTP de l’élément sécurisé. Les avantages, buts et caractéristiques particulières des procédés sont similaires à ceux du système sur puce qui les met en œuvre. Dans un mode particulier de réalisation, les différentes étapes des procédés précités sont déterminées par des instructions de programmes d'ordinateur. En conséquence, l'invention vise aussi des programmes d'ordinateur sur un support d’information, ces programmes étant susceptibles d'être mis en œuvre par un microprocesseur, ces programmes comprenant des instructions adaptées à la mise en œuvre des étapes des procédés tels que mentionnés ci-dessus. Ces programmes peuvent utiliser n'importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable. L'invention vise aussi un support d’information lisible par un microprocesseur, et comprenant des instructions de programmes d'ordinateur tels que mentionnés ci-dessus. Le support d’information peut être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comprendre un moyen de stockage, tel qu'une ROM, par exemple une ROM de microcircuit, ou encore un moyen d'enregistrement magnétique, par exemple un disque dur, ou encore une mémoire flash. D'autre part, le support d’information peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Le programme selon l'invention peut être en particulier téléchargé sur une plateforme de stockage d’un réseau de type Internet. Alternativement, le support d’information peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé en question. Le support d’information et les programmes d'ordinateur précités présentent des caractéristiques et avantages analogues aux procédés qu'ils mettent en œuvre. D'autres particularités et avantages de l'invention apparaîtront encore dans la description ci-après, illustrée par les figures ci-jointes qui en illustrent des exemples de réalisation dépourvus de tout caractère limitatif. La figure 1 représente un exemple d’architecture pour un système sur puce conforme à des modes de réalisation de l’invention. La figure 2 représente, sous forme d’organigramme, des étapes mises en œuvre par le système sur puce pour vérifier la fraicheur d’un objet conformément à des modes de réalisation de l’invention. [Fig. 3] La figure 3 qui comprend les figures 3A, 3B, 3C, 3D et 3E, illustre schématiquement l’état successif des différentes mémoires considérées lors d’une mise en œuvre des étapes de la figure 2. La figure 4 représente, sous forme d’organigramme, des étapes mises en œuvre par le système sur puce lors d’une écriture sécurisée conforme à des modes de réalisation de l’invention. [Fig. 5] La figure 5 qui comprend les figures 5A à 5M, illustre schématiquement l’état successif des différentes mémoires considérées lors de la mise en œuvre des étapes de la figure 4. Par la suite, les mêmes références sont utilisées pour désigner les mêmes éléments lorsqu’ils apparaissent dans différentes figures. Système sur puce (10) comprenant un élément sécurisé (102) comprenant une unité de traitement (1022) configurée pour exécuter un système d’exploitation sécurisé et pour envoyer des instructions à une mémoire non volatile réinscriptible (12) extérieure au système sur puce et relié à celui-ci, l’élément sécurisé (102) comprenant en outre une mémoire non volatile sécurisée (1024) ainsi qu’une mémoire volatile sécurisée (1026), le système sur puce (10) étant caractérisé en ce que l’unité de traitement (1022) est configurée pour commander : - le stockage, dans la mémoire non volatile réinscriptible extérieure (12) d’au moins un objet ayant une version courante, et d’un répertoire dédié associant un identifiant de chaque objet à un identifiant de la version courante de cet objet, le répertoire dédié comprenant en outre un identifiant de sa propre version courante ; et - le stockage, dans la mémoire non volatile (1024) de l’élément sécurisé, de l’identifiant de la version courante du répertoire dédié. Système sur puce (10) selon la revendication 1, dans lequel l’unité de traitement (1022) est configurée pour commander l’écriture, dans une zone de type « rollforward » dans la mémoire non volatile réinscriptible extérieure (12), de données à utiliser pour mettre à jour un objet. Système sur puce (10) selon la revendication 2, dans lequel l’unité de traitement (1022) est configurée pour commander la création d’une copie d’au moins une partie du contenu de la mémoire non volatile réinscriptible extérieure (12) dans la mémoire volatile sécurisée (1026) de l’élément sécurisé. Système sur puce (10) selon la revendication 3, dans lequel l’unité de traitement (1022) est configurée pour commander la modification de ladite copie dans la mémoire volatile sécurisée (1026) de l’élément sécurisé avant la modification de la mémoire non volatile réinscriptible extérieure (12). Système sur puce (10) selon la revendication 4, dans lequel l’unité de traitement (1022) est configurée pour commander: - la reproduction des modifications effectuées sur une copie du répertoire dédié et de la zone de type « rollforward » en mémoire volatile sécurisée (1026) sur le répertoire dédié et la zone de type « rollforward » stockés dans la mémoire non volatile réinscriptible extérieure (12), puis - la modification du ou des objets concernés stockés dans la mémoire non volatile réinscriptible extérieure (12) conformément au contenu de la zone de type « rollforward » et du répertoire dédié. Système sur puce (10) selon la revendication 5, dans lequel l’unité de traitement (1022) est configurée pour commander la mise à jour de l’identifiant de la version courante du répertoire dédié dans la mémoire non volatile sécurisée (1024) de l’élément sécurisé avant la modification du ou des objets concernés stockés dans la mémoire non volatile réinscriptible extérieure (12) conformément au contenu de la zone de type « rollforward » et du répertoire dédié. Système sur puce (10) selon la revendication 5, dans lequel l’unité de traitement (1022) est configurée pour commander la reproduction des modifications en mémoire non volatile réinscriptible extérieure (12), après que plusieurs copies d’objets aient été modifiées dans la mémoire volatile sécurisée (1026) de l’élément sécurisé. Système sur puce (10) selon l’une quelconque des revendications précédentes, dans lequel la mémoire non volatile sécurisée de l’élément sécurisé est une mémoire à durée de vie limitée de type OTP ou MTP. Système sur puce (10) selon l’une quelconque des revendications précédentes, dans lequel l’identifiant de la version courante d’un objet et/ou l’identifiant de la version courante du répertoire dédié est un numéro de version. Système sur puce (10) selon l’une quelconque des revendications précédentes, dans lequel l’identifiant de la version courante d’un objet et/ou l’identifiant de la version courante du répertoire dédié est une signature ou une somme de contrôle calculée à partir de l’objet et/ou du répertoire dédié, identifiant de manière unique sa version. Système sur puce (10) selon l’une quelconque des revendications précédentes, dans lequel l’unité de traitement (1022) met en œuvre une première fonction de comparaison et une deuxième fonction de comparaison afin de déterminer si un identifiant de version correspond à une version courante ou à une ancienne version, la première fonction consistant à déterminer si les valeurs sont identiques, la seconde fonction consistant à déterminer si ladite version est strictement supérieure ou strictement inférieure à la version courante. Système sur puce (10) selon l’une quelconque des revendications précédentes, dans lequel l’unité de traitement (1022) est configurée pour fonctionner tantôt selon un mode d’exécution non sécurisé tantôt selon un mode d’exécution sécurisé. Système sur puce (10) selon l’une quelconque des revendications précédentes, dans lequel l’unité de traitement (1022) est configurée pour commander un contrôleur (101) de mémoire contrôlant la mémoire non volatile réinscriptible extérieure (12). Procédé d’écriture sécurisée d’un objet dans une mémoire non volatile réinscriptible (12) extérieure à un système sur puce (10) et reliée à celui-ci, le système sur puce (10) comprenant un élément sécurisé (102) comprenant une unité de traitement (1022) configurée pour exécuter un système d’exploitation sécurisé et pour envoyer des instructions à la mémoire non volatile réinscriptible extérieure (12), l’élément sécurisé (102) comprenant en outre une mémoire non volatile sécurisée (1024) ainsi qu’une mémoire volatile sécurisée (1026), le procédé étant caractérisé en ce qu’il comprend les étapes suivantes : - commande de l’écriture (E420) d’un identifiant de la version courante de l’objet dans un répertoire dédié stocké dans la mémoire non volatile réinscriptible extérieure (12), en association avec un identifiant de l’objet, - commande de la mise à jour (E420) d’un identifiant de la version courante du répertoire dédié dans le répertoire dédié stocké dans la mémoire non volatile réinscriptible extérieure (12), - commande de l’écriture (E430) de l’identifiant de la version courante du répertoire dédié dans la mémoire non volatile sécurisée (1024) de l’élément sécurisé. Procédé selon la revendication 14, comprenant une étape de vérification de la fraicheur d’un objet stocké dans la mémoire non volatile réinscriptible extérieure (12), comprenant : - la création (E22) d’une copie du répertoire dédié et de l’objet dans la mémoire volatile sécurisée (1026) de l’élément sécurisé, - la comparaison (E24) de l’identifiant de la version courante du répertoire dédié stocké dans la copie du répertoire dédiée, avec l’identifiant de la version courante du répertoire dédié stocké dans la mémoire non volatile sécurisée (1024) de l’élément sécurisé ; - en cas d’égalité, la comparaison (E28) de l’identifiant de la version courante de la copie de l’objet avec l’identifiant de la version de cet objet stocké dans la copie du répertoire dédié, afin de vérifier la fraicheur de l’objet. Procédé selon la revendication 14 ou 15, mis en œuvre au démarrage (E20) de l’unité de traitement (1022) de l’élément sécurisé (102). Procédé selon l’une quelconque des revendications 14 à 16, dans lequel l’identifiant de la version courante d’un objet et/ou l’identifiant de la version courante du répertoire dédié est un numéro de version. Procédé selon l’une quelconque des revendications 14 à 17, dans lequel l’identifiant de la version courante d’un objet et/ou l’identifiant de la version courante du répertoire dédié est une signature ou une somme de contrôle calculée à partir de l’objet et/ou du répertoire dédié, identifiant de manière unique sa version. Procédé selon l’une quelconque des revendications 14 à 18, comprenant en outre une étape d’écriture, dans une zone de type « rollforward » dans la mémoire non volatile réinscriptible extérieure (12), de données à utiliser pour mettre à jour un objet. Procédé selon l’une quelconque des revendications 14 à 19, dans lequel une première fonction de comparaison et une deuxième fonction de comparaison sont mises en œuvre afin de déterminer si un identifiant de version correspond à une version courante ou à une ancienne version, la première fonction consistant à déterminer si les valeurs sont identiques, la seconde fonction consistant à déterminer si ladite version est strictement supérieure ou strictement inférieure à la version courante. Procédé selon la revendications 15, comprenant une étape de mise à jour (E26) de la version et/ou du contenu dudit objet en cas de différence détectée lors de ladite comparaison (E29) de l’identifiant de la version courante de la copie de l’objet avec l’identifiant de la version de cet objet stocké dans la copie du répertoire dédié.