INPI-France/Brevets-Francais-2024-Chunked huggingface dataset:
Lorsqu’un calculateur secondaire 20 détecte, dans une étape E5, un évènement EVENT correspondant à une balise de déclenchement d’un scripte mémorisé en zone mémoire ou à un message reçu du calculateur principal 10, ledit calculateur secondaire 20 obtient, dans sa zone mémoire 21, le script SCR comprenant des instructions en mode passif et/ou actif associé dans une étape E6 puis exécute ledit script SCR obtenu dans une étape E7.
Ainsi le calculateur secondaire 20 ne dépend plus du calculateur principal 10 pour réagir à un évènement, il va puiser dans sa zone mémoire le script qui correspond à l’évènement détecté, le script pouvant faire basculer la communication entre le calculateur secondaire 20 et le dispositif 41 en mode de communication ultra large bande passif, passif renforcé (augmentation de la fréquence d’émission) ou actif.
Exemples d’application
Dans les exemples ci-après, une pluralité de configurations et une pluralité de scriptes ont été préalablement stockés dans la zone mémoire 21 de chaque calculateur secondaire 20.
Dans un premier exemple, le calculateur principal 10 envoie une requête de configuration à l’un des calculateurs secondaires 20 afin que ledit calculateur secondaire 20 opère dans un premier mode passif pur dans lequel il émet à basses fréquences.
Le calculateur secondaire 20, ainsi paramétré, détecte le dispositif 41 par polling à l’aide de signaux UWB qu’il émet, de manière connue en soi. Cette détection est un évènement qui correspond à une balise de déclenchement qui déclenche un scripte d’authentification associé en deux temps.
Dans un premier temps, le scripte fait basculer le calculateur secondaire 20 dans un deuxième mode passif pur, à hautes fréquences, qui permet d’éliminer les objets fixes, autres que l’utilisateur 40 du dispositif 41, afin de s’assurer que le dispositif 41 est bien un dispositif d’authentification adapté pour communiquer avec le véhicule 1, qui s’approche ou s’éloigne du véhicule 1.
Dans un deuxième temps, le scripte fait basculer le calculateur secondaire 20 dans un mode actif pur où ledit calculateur secondaire 20 communique avec le dispositif 41 afin de l’authentifier.
Une fois authentifié, des fonctions d’accueil du véhicule 1 peuvent par exemple être mises en œuvre comme, par exemple, le déverrouillage des ouvrants du véhicule1, un éclairage, le réglage des sièges selon le profil de l’utilisateur, etc.
Deuxième exemple
Dans un deuxième exemple, le calculateur principal 10 envoie une requête de configuration à l’un des calculateurs secondaires 20 afin que ledit calculateur secondaire 20 opère dans un mode passif pur avec un dispositif 41 déjà authentifié porté par un utilisateur 40 du véhicule 1.
La sous-étape de requête d’obtention correspond à une demande d’une donnée particulière, ladite donnée ayant été préalablement stockée au sein de l’espace sécurisé. Une telle requête peut faire suite à un besoin d’obtention des données protégées dans un but divers.
Si la requête est autorisée, alors la bibliothèque spécifique procède à une vérification d’empreintes de l’objet connecté. Une fois que les empreintes sont vérifiées, la bibliothèque spécifique extrait les données de l’espace sécurisé puis déchiffre la ou les données concernées et celles-ci peuvent être envoyées.
Selon une caractéristique de l’invention, l’étape de réception comprend une sous-étape d’indexation d’une pluralité de données partielles à partir d’un ensemble de données. Autrement dit, la sous-étape d’indexation permet de partitionner l’ensemble de données, et ce afin de pouvoir les isoler les unes des autres par la suite. A titre d’exemple, l’ensemble de données peut être un dossier médical d’un individu, et ce dossier peut être indexé de sorte à ce que chaque donnée partielle corresponde à un élément dudit dossier médical. Ce dernier est ensuite stocké au sein de l’espace sécurisé, un dossier médical contenant des informations confidentielles devant être protégé selon un haut niveau de sécurité. La sous-étape d’indexation est utile par la suite lors de l’étape d’extraction.
Selon une caractéristique de l’invention, l’étape d’extraction comprend : une sous-étape de requête d’obtention d’au moins l’une des données partielles, une sous-étape de sélection d’un index correspondant à au moins la donnée partielle, une sous-étape de transmission d’au moins la donnée partielle indexée.
On comprend que l’étape d’indexation assure par la suite une transmission partielle de l’ensemble de données ce qui limite l’exposition de celui-ci.
La sous-étape de requête d’obtention correspond à une demande d’une donnée partielle particulière, tel que cela a été décrit précédemment pour les données n’ayant pas été indexées. Pour reprendre l’exemple défini précédemment, à savoir l’exemple du dossier médical, une ou plusieurs données particulières de celui-ci peuvent être demandées par une personne ou une machine qui est autorisée à accéder à ces dernières.
A la suite de cette requête, la sous-étape de sélection de l’index est effectuée afin de récupérer les données partielles demandées, et uniquement celles-ci, sans exposer l’ensemble de données dans son entièreté, par exemple le dossier médical dans son intégralité tel qu’évoqué précédemment.
La ou les données partielles indexées sont ensuite transmises vers la personne ou la machine à l’origine de la requête après que la bibliothèque spécifique a vérifié les empreintes de l’objet connecté et déchiffré la ou les données partielles. Durant l’étape d’extraction, les données partielles non soumises à la requête d’obtention restent donc au sein de l’espace sécurisé et ne sont ainsi jamais exposées hors de celui-ci.
Selon une caractéristique de l’invention, l’ensemble de données est une structure de données organisée selon un principe de paire de données composée d’un libellé associé à au moins une valeur. Une telle structure est utilisable par la bibliothèque spécifique afin de stocker de manière sécurisée les données de cette structure de données.
Un exemple de ce type de structure de données est le format de données JSON. Il s’agit d’un format de données lisibles par plusieurs bibliothèques, mais pouvant être chiffrées par l’outil dédié afin de ne pouvoir être lues que par la bibliothèque spécifique. Une entité telle qu’un jeton peut se présenter sous la forme d’une structure de données au format JSON. Le jeton peut par exemple permettre d’authentifier l’objet connecté recevant ledit jeton auprès d’un réseau internet. On comprend ainsi qu’un tel jeton d’authentification doit être protégé efficacement afin d’éviter qu’une attaque illicite puisse voler le jeton d’authentification de l’objet connecté et se faire passer pour ce dernier afin de se connecter au réseau et pirater celui-ci.
Selon une caractéristique de l’invention, l’étape d’extraction est autorisée en réponse à une requête vérifiée. Comme cela a été évoqué précédemment, la requête pour récupérer des données stockées dans l’espace sécurisé doit être effectuée par une source autorisée, par exemple un individu ou une machine, considéré comme apte à obtenir un ensemble de données bien précis. L’autorisation peut être partielle afin que seules des données partielles de l’ensemble de données puisse être accessibles sur requête. A titre d’exemple, si l’ensemble de données est un dossier médical, celui-ci peut être rendu entièrement accessible par des médecins mais seulement partiellement accessibles par des membres du personnel d’un secrétariat médical.
L’invention couvre également un programme informatique appliqué à un objet connecté et comprenant des instructions de code de programme pour l’exécution des étapes d’un procédé de protection de données tel que décrit précédemment, ledit programme étant exécuté au moins partiellement par l’objet connecté. Le programme informatique peut être associé à un objet connecté afin d’opérer les mesures de sécurité évoquées précédemment de manière à protéger les données sensibles relatives au dit objet connecté. Chaque exécution du programme informatique est unique, c’est-à-dire que chaque exécution génère une bibliothèque propre à chaque objet connecté au sein duquel le programme informatique est exécuté. La sécurité des données est alors optimale.
L’invention couvre enfin un objet connecté comprenant des lignes de codes mettant en œuvre le programme informatique décrit ci-dessus ou un procédé tel qu’exposé dans le présent document.
représente un logigramme général d’un procédé de protection de données selon l’invention, ledit procédé étant appliqué à un objet connecté,
représente un logigramme détaillé d’une étape de génération d’une bibliothèque spécifique et d’un outil dédié, ladite étape étant opérée au cours du procédé selon l’invention,
Comme on l’a vu précédemment, une même image est encodée selon plusieurs formats. Lors d’une deuxième étape ET2, le terminal de lecture décodeur STB récupère des informations pour chaque format d’image la taille en kilo-octets des différentes images encodées et les types de formats, à savoir dans notre exemple JPEG et WebP. D’autres informations peuvent être récupérées comme une résolution d’image, ou d’autres informations pouvant avoir un impact sur la durée d’attente avant restitution.
Lors d’une troisième tape ET3, le terminal de lecture calcule des durées d’attente respectives avant restitution du contenu pour chaque format d’image ; Lors de ce calcul, un premier calcul estime en fonction de la bande passante courante le temps de téléchargement en fonction de la taille de l’image choisie et de la bande passante courante. La bande passante peut être déterminée grâce à un algorithme connu de l’homme du métier. Un tel algorithme est par exemple un algorithme dit de téléchargement progressif adaptatif, d’abréviation HAS.
On rappelle brièvement que, le plus souvent, le principe général de tels algorithmes HAS repose sur le téléchargement d’un segment encodé au débit d’encodage le plus faible proposé dans un fichier « Manifest » (aussi appelé fichier de description par l’homme du métier), et sur l’évaluation du temps de récupération de ce premier segment. Ce temps de récupération peut être assimilé au temps de téléchargement du segment.
Supposons que l’image encodée en JPEG a une taille de 1.5Mo (Mo = Méga Octets). Supposons aussi que la bande passante de l’utilisateur (calculée par un algorithme de type HAS) est de 10Mo. Le temps de téléchargement de l’image JPEG sera donc de 0.15 secondes. La même image encodée en WebP a une taille de 1Mo et requiert un temps de téléchargement de 0.1 secondes.
Ensuite, le deuxième calcul consiste à déterminer en fonction des capacités du terminal, à savoir en fonction de la présence ou pas du décodeur matériel spécifique à l’image JPEG ou WebP, et des caractéristiques de l’image (résolution / poids en Ko) le temps de décodage prévisible de l’image. Ce deuxième calcul pourrait aussi comprendre le délai de transmission de l’image décodée jusqu’à la restitution de l’image ; cependant, on considère dans cet exemple que ce délai est sans intérêt du fait qu’il est sensiblement le même pour toutes les images décodées et négligeable par rapport au délai de décodage.
D’une manière générale, une récupération d’une image sur un serveur comprend deux durées à savoir la durée de téléchargement et la durée de décodage ; les autres durées à savoir la durée de transmission d’une requête de téléchargement d’une image, ou le délai de transmission de l’image décodée vers l’écran, ou toutes autres durées ne sont pas prises en compte dans notre exemple car étant de durées sensiblement égales quel que soit le format d’image sélectionné.
La somme des deux résultats précédents, résultats issus du premier et du deuxième calcul, correspond à une durée avant restitution d’une image. Dans notre exemple, concrètement, grâce au deuxième calcul on détermine que l’image JPG peut être décodée par le décodeur matériel JPEG en 0.05 sec et que l’image WebP peut être quant à elle décodée par le processeur CPU en 0.25 sec.
Le calcul global regroupant le temps de téléchargement et le temps de décodage donne les résultats suivants :
Pour l’image IMG1, la durée prévisible de téléchargement ajoutée à la durée prévisible de décodage de l’image JPG (0.15 + 0.05) donne 0.155 sec de durée avant restitution.
Pour l’image IMG2, la durée prévisible de téléchargement ajoutée à la durée prévisible de décodage de l’image JPG temps de téléchargement ajouté au décodage de l’image WebP (0.1 + 0.25) donne 0.35 sec de durée d’attente avant restitution.
Si le besoin est d’obtenir une image le plus rapidement possible, l’image JPG est sélectionnée car le temps d’attente prévisible avant restitution est beaucoup plus court qu’avec l’image WebP. Dans notre exemple, lors d’une quatrième étame ET4, l’entité de gestion ENT sélectionne donc l’image JPEG à télécharger, de moins bonne qualité mais dont la durée avant restitution est la plus faible.
Lors d’une cinquième étape ET5, le terminal de lecture STB requiert auprès du serveur un téléchargement de l’image JPEG.
Lors d’une sixième étape ET6, le terminal de lecture STB reçoit l’image sélectionnée JPEG et décode cette image lors d’une septième étape.
Lors d’une huitième étape ET8, l’image JPEG est restituée.
On comprend ici que dans le mode de réalisation choisi que le terminal de lecture assure une durée d’attente avant restitution optimale.
Le procédé décrit ci-dessus peut faire l’objet de variantes.
L’outil dédié à la bibliothèque spécifique est généré en même temps que cette dernière, ce qui rend celui-ci apte à interagir avec la bibliothèque spécifique et avec elle seule. L’avantage d’un tel outil est que cela limite les interactions extérieures avec la bibliothèque spécifique, l’outil dédié pouvant servir de contrôle des données passantes.
La bibliothèque spécifique peut être directement intégrée au sein de l’objet connecté de par sa création, ou bien par exemple être transmise à l’objet connecté par un intermédiaire de confiance tel qu’un gestionnaire d’objets connectés.
La bibliothèque spécifique peut par la suite créer un ou plusieurs espaces sécurisés sur l’objet connecté. Cet espace sécurisé est spécifique à l’objet connecté car créé par la bibliothèque spécifique à l’aide d’éléments propres à l’objet connecté. Autrement dit, l’espace sécurisé est un fichier ou un dossier propre à l’objet connecté au sein duquel ledit espace sécurisé est créé. L’espace sécurisé fait office de coffre-fort (ou en anglais « vault file ») pour des données sensibles contenues ou destinées à être contenues au sein de l’objet connecté. Les données sont ainsi protégées dans l’espace sécurisé et ne peuvent être librement piratées.
L’espace sécurisé peut ainsi stocker et/ou transmettre les données qu’il contient, et ce en toute sécurité. Ledit espace sécurisé ayant été créé par la bibliothèque spécifique, elle-même étant créée de manière unique, et spécifique à l’objet connecté, la sécurité est ainsi extrêmement renforcée.
Selon une caractéristique de l’invention, l’étape de génération de la bibliothèque spécifique et de l’outil dédié à la bibliothèque spécifique est opérée à partir d’une bibliothèque générique et d’un code secret. La bibliothèque générique peut servir de base pour créer la bibliothèque spécifique, mais en étant modifiée via le code secret et/ou lors d’une compilation de la bibliothèque spécifique. Une telle compilation peut contenir des étapes de protection telles que des techniques de cryptographie et/ou d’obfuscation, et ce afin de garantir la spécificité de la bibliothèque générée. Dans le but d’également améliorer la spécificité, le code secret peut être aléatoirement généré à chaque itération du procédé.
Selon une caractéristique de l’invention, l’étape de création de l’espace sécurisé se fait par prise d’empreintes de l’objet connecté par la bibliothèque spécifique. La prise d’empreintes permet de lier dans l’ordre la bibliothèque spécifique, l’objet connecté puis l’espace sécurisé. Dans un premier temps, une première liaison entre la bibliothèque spécifique et l’objet connecté est effectué, créant l’espace sécurisé après la prise d’empreintes de l’objet connecté par la bibliothèque spécifique. Puis, l’espace sécurisé est lié à la bibliothèque spécifique et à l’objet connecté. D’une manière avantageuse, tant que cette prise d’empreintes n’est pas effectuée, l’espace sécurisé n’est pas généré ou n’est pas utilisable. De même, si l’empreinte n’est pas conforme, alors l’espace sécurisé n’est pas généré ou n’est pas utilisable.
Selon une caractéristique de l’invention, l’espace sécurisé créé lors de l’étape de création est protégé par des mesures antivols. Il s’agit d’une procédure supplémentaire de sécurité permettant d’éviter une potentielle usurpation de l’espace sécurisé. Ce dernier est alors prêt à recevoir et stocker des données sensibles.
Selon une caractéristique de l’invention, l’étape de réception est appliquée à des données internes à l’objet connecté. Une fois que l’espace sécurisé est créé, des données internes peuvent y être stockées. Les données sont internes à l’objet connecté et sont ainsi considérées comme des données de confiance. Le stockage des données internes se fait via la bibliothèque spécifique qui permet d’autoriser l’accès à l’espace sécurisé après avoir chiffré les données internes. A titre d’exemple, les données internes peuvent correspondre au numéro de série de l’objet connecté ou à son adresse IP.
Selon une caractéristique de l’invention, l’étape de réception est appliquée à des données initialement externes à l’objet connecté. Contrairement aux données internes, les données initialement externes proviennent d’un environnement extérieur à l’objet connecté mais sont toutefois destinées à être reçues par celui-ci. On comprend ainsi que le terme « initialement externe » est relatif à des données qui sont finalement stockées dans l’espace sécurisé mais qui de base ne proviennent pas de l’objet connecté.
Les données initialement externes sont ainsi moins fiables que les données internes et doivent donc être traitées avec plus d’attention. Un exemple de données initialement externes peut être un fichier de mise à jour de l’objet connecté provenant du réseau internet susmentionné.
Selon une caractéristique de l’invention, l’étape de réception comprend : une sous-étape de chiffrement des données initialement externes par l’outil dédié afin de générer des données chiffrées, les données chiffrées étant exclusivement lisibles par la bibliothèque spécifique, une sous-étape de vérification du chiffrement des données chiffrées, une sous-étape de stockage des données chiffrées au sein de l’espace sécurisé.
Des données initialement externes brutes ne peuvent être lues par la bibliothèque spécifique car elles ne proviennent pas directement de l’objet connecté. Ces dites données initialement externes ne peuvent donc en l’état être stockées au sein de l’espace sécurisé.
L’outil dédié à la bibliothèque spécifique et généré en même temps que cette dernière est donc utilisé pour interagir avec les données initialement externes lors de la sous-étape de chiffrement. L’outil dédié permet de chiffrer les données initialement externes afin de rendre celles-ci lisibles par la bibliothèque spécifique et uniquement par celle-ci. Les données initialement externes sont ainsi partiellement protégées d’un piratage visant à récupérer ces données, celles-ci ne pouvant être théoriquement lues que par la bibliothèque spécifique.
Une fois la sous-étape de chiffrement effectuée, les données chiffrées sont soumises à la sous-étape de vérification. Cette dernière permet de s’assurer que la sous-étape de chiffrement s’est déroulée correctement, et peut par exemple consister en une tentative de lecture des données chiffrées par la bibliothèque spécifique.
Si les données chiffrées sont correctement lues par la bibliothèque spécifique, alors elles peuvent être stockées au sein de l’espace sécurisé garantissant leur protection.
Selon une caractéristique de l’invention, l’étape d’extraction comprend : une sous-étape de requête d’obtention d’au moins l’une des données, une sous-étape de transmission d’au moins la donnée.
On présente désormais, en relation avec la , un système informatique SYS comprenant un serveur SRV depuis lequel des contenus peuvent être téléchargés, et un terminal de lecture STB depuis lequel des contenus peuvent être lus.
Différents types de contenus numériques IMG1/IMG2 ayant été codés ou compressés de différentes manières sont accessibles depuis le serveur SRV.
La illustre schématiquement un terminal de lecture STB. Ce dernier a une architecture classique d’un ordinateur ; le décodeur comprend, classiquement, des mémoires M associées à un processeur CPU. Les mémoires peuvent être de type ROM (de l’anglais « Read Only Memory ») ou RAM (de l’anglais « Random Access Memory ») ou encore Flash. Le décodeur communique avec le serveur soit directement au travers d’un réseau étendu WAN soit indirectement au travers d’une passerelle domestique GTW et du réseau Internet étendu WAN. La communication via un réseau LAN s’effectue via un module COM11 relié au processeur CPU assurant une communication locale sans fils de type WiFi avec la passerelle résidentielle GTW.
Le terminal de lecture STB comprend en outre un module de téléchargement pour requérir un téléchargement d’un contenu stocké sur le serveur SRV.
Dans notre exemple, le terminal de lecture STB est connecté à un téléviseur TV, par l’intermédiaire d’un module de communication COMM2 du type liaison HDMI.
Les contenus codés IMG1/IMG2 stockés sur le serveur SRV sont aptes à être décodés par des décodeurs spécifiques DEC1 et DEC2, respectivement. Lorsqu’un contenu est téléchargé et reçu par le terminal de lecture, un décodeur décode le contenu et requiert une restitution du contenu.
Le décodage peut être réalisé soit par un décodeur matériel soit par un décodeur logiciel ; le décodeur logiciel est géré par le processeur alors qu’un décodeur matériel est équipé d’un processeur distinct du processeur CPU.
En d’autres mots, le décodage logiciel utilise le processeur CPU pour décoder et lire u contenu tandis que le décodage matériel DEC1/DEC2 de type GPU est principalement basé sur unité de traitement graphique, ou GPU , plus performant qu’un processeur CPU pour traiter des contenus multimédias.
Selon l’invention, une entité de gestion ENT réalise, pour plusieurs formats de contenu, un calcul de durées d’attente respectives avant restitution du contenu. Ce calcul permet d’obtenir une estimation de durées précédant la restitution du contenu considéré. Ensuite un contenu est sélectionné en fonction du résultat du calcul. Le contenu sélectionné est ensuite téléchargé et restitué.
On suppose que le serveur SRV stocke des images IMG1 et IMG2 encodées selon deux techniques d’encodage respectives. Dans notre exemple, les images sont une image JPEG et une image WebP.
Le format WebP est un format d’image qui a un taux de compression supérieur au taux de compression JPEG. Il y a un rapport de deux entre le poids en Ko d’une image WebP par rapport à une image JPEG pour une qualité équivalente. Il y a de ce fait un gain certain à privilégier, lorsqu’une qualité d’image optimale est recherchée, un téléchargement d’un contenu codé au format WebP plutôt que JPEG
La plupart des terminaux sont équipés de décodeurs matériels de type JPEG. Ce n’est pas le cas pour les images WebP ; seuls quelques terminaux de lecture ou hauts de gamme ont des décodeurs matériels WebP intégrés. S’il n’y a pas de décodeur matériel spécifique WebP, le décodage s’effectue par défaut via le décodeur logiciel du processeur CPU, ce qui nécessite beaucoup plus de temps de traitement, bien plus qu’avec un décodeur WebP. On comprend que, selon que le terminal de lecture est équipé ou pas du décodeur matériel , il peut parfois être plus intéressant de récupérer une image JPEG plus lourde en taille qu’une image WebP mais plus rapide à décoder du fait de l’absence de décodeur WebP.
Dans notre exemple, on suppose que le terminal dispose, outre du décodeur logiciel, d’un décodeur matériel JPEG et qu’il n’est pas équipé de décodeur WebP.
La illustre des étapes d’un mode de réalisation illustrant l’invention. Le procédé comprend plusieurs étapes référencées ETn (n= 1,…,8).
Lors d’une première étape ET1, le terminal de lecture décodeur STB reçoit une demande d’accès à une image.