INPI-France/Brevets-Francais-2024-Chunked huggingface dataset:
La illustre également que les sous-procédés 100 et 200 peuvent solliciter le registre de confiance TR du système de preuve en ligne au moyen de requêtes PI_R en consultation d’identités digitales publiques, ledit registre TR communiquant, en réponse, de telles identités digitales publiques par des messages de transmission PI_M. Cette variante avantageuse d’un procédé 300 selon l’invention permet au portefeuille Wm et à l’émetteur Ij’ sollicité pour un renouvellement d’attribut vérifiable de s’assurer mutuellement de la légitimité des requêtes et messages échangés ainsi que de l’authenticité de l’attribut vérifiable à renouveler. En effet, préalablement à l’émission d’une requête en renouvellement VC_RR, le portefeuille Wm peut consulter le registre de confiance pour sélectionner un émetteur légitime et satisfaisant certaines contraintes, comme celle évoquée précédemment pour prévenir un suivi des renouvellements par un émetteur malveillant ou cible d’une attaque. De son côté, pour donner une suite favorable à une requête en renouvellement adressée par un portefeuille Wm, un émetteur destinataire de ladite requête peut solliciter ledit registre de confiance TR pour disposer des identités digitales publiques respectives dudit portefeuille et de l’émetteur dont l’identité digitale publique est consignée dans l’attribut vérifiable objet d’un renouvellement. Ledit émetteur destinataire de la requête en renouvellement peut ainsi vérifier, d’une part, la signature du portefeuille Wm si celui-ci a signé la requête en renouvellement à l’aide de sa propre identité digitale privée et, d’autre part, la signature de l’émetteur de l’attribut vérifiable concerné par le renouvellement, si ce dernier comporte une telle signature élaborée à partir de l’identité digitale privée de son émetteur.
Enfin, la illustre un procédé 300 de renouvellement automatique d’un attribut vérifiable pour lequel le sous-procédé 100 permet une élaboration d’une requête en révocation VC_RKR d’un attribut vérifiable renouvelé VCi, c’est-à-dire celui sur lequel portait une requête en renouvellement VC_RR, à l’issue de la production d’un nouvel attribut vérifiable VCi+1. Une telle requête en révocation est agencée pour être interprétée par le registre de confiance TR ou tout autre registre dédié à cet effet, pour enregistrer les attributs vérifiables ainsi révoqués après renouvellement ou, en lieu et place de tels attributs vérifiables révoqués, enregistrer des informations caractéristiques de ces derniers, à l’instar du résultat d’une fonction cryptographique de hachage d’un tel attribut vérifiable par exemple. Selon cette variante, un émetteur Ij’ destinataire d’une requête en renouvellement d’un attribut vérifiable peut en outre vérifier, en sollicitant ledit registre, que l’attribut vérifiable objet d’un renouvellement n’est pas un attribut vérifiable révoqué. Dans la négative, le sous-procédé 200 ne procède pas au renouvellement et peut retourner un message d’erreur au portefeuille requérant le renouvellement.
La illustre en détail des modes de réalisation avantageux d’un sous-procédé 100 d’un procédé de renouvellement automatique d’attributs vérifiables selon l’invention. Comme indiqué précédemment, un tel sous-procédé 100 est agencé pour être mis en œuvre, ou faire partie, d’un portefeuille Wm adapté en conséquence et appartenant à un système de preuve en ligne S dont au moins un émetteur Ij’ est adapté pour mettre en œuvre un sous-procédé 200 exploitant une requête en renouvellement d’un attribut vérifiable.
Un tel sous-procédé 100 consiste en trois grandes étapes distinctes référencées 110, 120, 130 sur la , lesdites étapes étant dédiées respectivement à : la détection 110 d’un événement déclencheur d’un renouvellement d’un attribut vérifiable VCi, c’est-à-dire un attribut vérifiable d’ores et déjà émis légitimement (simplement créé ou précédemment renouvelé) par l’émetteur Ij (non représenté sur la ) ; l’élaboration et le déclenchement 120 de l’émission d’une requête VC_RR en renouvellement d’un tel attribut vérifiable VCi à destination d’un émetteur Ij’ du système de preuve en ligne S ; la gestion 130 d’un nouvel attribut vérifiable VCi+1 fruit d’une telle requête en renouvellement VC_RR et transmis par ledit émetteur Ij’ par un message de transmission VC_M.
Selon la , chaque entité électronique du système de preuve en ligne dont fait partie le portefeuille Wm est associée à une identité digitale formée d’une identité digitale publique et d’une identité digitale privée, ladite identité digitale étant enregistrée dans une mémoire de données 12 de chaque entité électronique. Un message, une requête ou un contenu peut être signé par une première entité électronique à l’aide de son identité digitale privée, ladite signature pouvant être vérifiée par toute deuxième entité électronique en exploitant l’identité digitale publique de ladite première entité électronique. Éventuellement, ladite première entité peut chiffrer messages, requêtes ou contenus à l’aide de l’identité digitale publique d’une deuxième entité électronique déterminée, de sorte que cette dernière soit la seule entité électronique capable de déchiffrer lesdits messages, requêtes ou contenus à l’aide de sa propre identité digitale privée inconnue des autres entités électroniques.
Ainsi, l’identité digitale IWm du portefeuille Wm consiste en : une identité digitale publique PIWm, en l’espèce un identifiant unique IDWm (éventuellement décentralisé) et une clé publique PKWm ; une identité digitale privée, en l’espèce une clé privée SKWm conjointement élaborée avec ladite clé publique PKWm pour assurer un schéma cryptographique de signature et/ou de chiffrement asymétrique.
L’identité digitale IIj de l’émetteur Ij de l’attribut VCi, objet d’un renouvellement automatique consiste en : une identité digitale publique PIIj, en l’espèce un identifiant unique IDIj (éventuellement décentralisé) et une clé publique PKIj ; une identité digitale privée, en l’espèce une clé privée SKIj conjointement élaborée avec ladite clé publique PKIj pour assurer un schéma cryptographique de signature et/ou de chiffrement asymétrique.
Il en est de même pour l’émetteur Ij’ destinataire d’une requête en renouvellement de l’attribut vérifiable VCi, éventuellement ou avantageusement distinct de l’émetteur Ij. Ainsi, l’identité digitale IIj’ de l’émetteur Ij’ consiste en : une identité digitale publique PIIj’, en l’espèce un identifiant unique IDIj’ (éventuellement décentralisé) et une clé publique PKIj’ ; une identité digitale privée, en l’espèce une clé privée SKIj’ conjointement élaborée avec ladite clé publique PKIj’ pour assurer un schéma cryptographique de signature et/ou de chiffrement asymétrique.
Le système de preuve en ligne S, dont fait partir le portefeuille Wm et les émetteurs Ij et Ij’, comprend un registre de confiance TR agencé pour enregistrer, dans une mémoire de données TRM qui lui est propre les identités digitales publiques PIWm, PIIj, PIIj’, respectives des entités électroniques Wm, Ij, et Ij’ dudit système de preuve en ligne S. Ledit registre est apte à recevoir une requête PI_R en consultation d’identités digitales publiques émanant d’une entité électronique dudit système S et élaborer, en réponse à une telle requête PI_R, un message de transmission PI_M véhiculant une ou plusieurs identités digitales publiques à destination de l’entité électronique émettrice de ladite requête PI_R en consultation d’identités digitales publiques.
Le sous-procédé 100 comporte donc une première étape de détection 110 d’un événement déclencheur d’un renouvellement d’un attribut vérifiable, en l’espèce l’attribut vérifiable VCi émis au préalable par l’émetteur Ij.
Un tel événement peut être de différentes natures. L’invention prévoit en effet qu’un renouvellement d’un attribut vérifiable puisse être déclenché automatiquement à la suite d’un nombre prédéterminé de réponses à des requêtes en présentation VC_PR d’un tel attribut vérifiable émanant de vérifieurs du système de preuve en ligne tel que le vérifieur Vn décrit en lien avec la . Un tel renouvellement d’attribut vérifiable pourrait également intervenir automatiquement après une certaine durée s’écoulant à compter de la date de création CD d’un tel attribut vérifiable, que ladite création découle d’une requête en création VC_CR selon l’état de l’art ou d’une requête en renouvellement CV_RR propre à l’invention. Un tel renouvellement d’attribut vérifiable pourrait en outre être déclenché automatiquement et de manière aléatoire par la mise en œuvre d’un algorithme exploitant tout ou partie du contenu dudit attribut vérifiable en qualité d’une graine pour la production d’un aléa comparé in fine à un seuil, etc. L’invention prévoit que la détection d’un éventement déclencheur ne se réduise à ces seuls exemples pris seuls ou en combinaison.
A titre d’exemple, la décrit un mode de réalisation selon lequel le portefeuille Wm associe à chaque attribut vérifiable VCi dont il assure la gestion, un compteur nPV d’émission de messages en présentation PV_M véhiculant ledit attribut vérifiable VCi en réponse à des requêtes en présentation VC_PR émanant de vérifieurs. Selon cet exemple de réalisation, chaque attribut vérifiable VCi est donc associé à un tel compteur conjointement enregistré en mémoire de données 12 de l’objet électronique hébergeant ledit portefeuille Wm. L’étape 110 peut alors consister tout d’abord en une lecture 111, dans une telle mémoire de données 12 accessible en lecture et écriture par le portefeuille Wm, de la valeur courante d’un compteur nPV de messages de présentation PV_M véhiculant l’attribut vérifiable VCi adressés à un vérifieur du système de preuve en ligne S. Ladite étape 110 peut alors consister en la comparaison 112 de la valeur courante dudit compteur nPV à un seuil maximal de présentations prédéterminé, par exemple compris entre deux et dix, préférentiellement égal à cinq de manière à ne pas trop fréquemment engendrer des renouvellements tout en préservant l’effet technique de non traçabilité recherché. Enfin, ladite étape 110 conclut en la détection d’un événement déclencheur d’un renouvellement automatique si ladite valeur dudit compteur nPV atteint ledit seuil prédéterminé. Une telle situation est représentée par le lien 112-y sur la . Tant que ledit compteur nPV demeure en deçà dudit seuil, aucun renouvellement de l’attribut vérifiable n’est déclenché (situation représentée par le lien 112-n sur la ).
Pour que le portefeuille Wm puisse élaborer la requête en renouvellement VC_RR à l’étape 125, celle-ci étant agencée pour véhiculer l’attribut vérifiable VCi, objet du renouvellement, ainsi que la nouvelle identité publique du portefeuille Wm, il est nécessaire de sélectionner un émetteur à qui adresser ladite requête en renouvellement VC_RR.
Pour cela, l’invention prévoit différents modes de réalisation pour sélectionner l’émetteur futur destinataire de la requête en renouvellement VC_RR.
Selon un premier mode de réalisation, le traitement 120 comporte une étape 122 pour lire, au sein de l’attribut vérifiable VCi (objet d’un renouvellement et inscrit dans la mémoire de données 12), l’identité digitale publique PIIj de l’émetteur Ij dudit attribut vérifiable VCi, afin d’adresser ladite requête en renouvellement VC_RR, à l’étape 125, à destination dudit émetteur Ij précédemment en charge de la création (ou d’un précédent renouvellement) dudit attribut vérifiable VCi.
En variante, l’invention prévoit que le portefeuille Wm dispose, dans la mémoire de données 12, d’une table des identités digitales publiques des émetteurs connus dudit portefeuille Wm. A chaque itération dudit traitement 120, la sélection de l’identité digitale publique de l’émetteur destinataire de la requête en renouvellement VC_RR peut être réalisée selon une lecture aléatoire ou cyclique selon un pas déterminé de ladite table.
Selon une alternative préférée, pour effectuer une telle sélection parmi une liste d’identités digitales publiques d’émetteurs, le traitement 120 comporte une étape 123 d’élaboration d’une requête PI_R en consultation d’identités digitales publiques d’entités émettrices du système de preuve en ligne S et de déclenchement de l’émission de ladite requête PI_R à destination du registre de confiance TR. Ledit traitement 120 comporte alors une étape 124, subséquente à l’étape 123, de réception d’un message de transmission PI_M émanant dudit registre de confiance TR et de lecture au sein de celui-ci d’une ou plusieurs identités digitales publiques d’émetteurs véhiculées par ledit message PI_M. Une telle sollicitation systématique du registre de confiance TR pour constituer une liste d’émetteurs permet au portefeuille Wm de connaître, à date, les émetteurs disponibles et aptes à réaliser un tel renouvellement d’attributs vérifiables. La sélection finale dudit émetteur destinataire de la requête en renouvellement VC_RR peut également être réalisée de manière aléatoire au sein de ladite liste obtenue ou bien de manière dirigée pour s’interdire d’émettre ladite requête CV_RR à destination de l’émetteur Ij de l’attribut vérifiable VCi objet du renouvellement. Dans ce cas, la sélection du destinataire s’effectue en choisissant une identité digitale publique distincte de celle de l’émetteur Ij.
L’étape 125 du traitement 120 consiste alors en une élaboration de la requête VC_RR en renouvellement de l’attribut vérifiable VCi, puis à en provoquer l’émission, à destination de l’entité émettrice Ij’ dont l’identité digitale publique PIIj’ a été sélectionnée, ladite requête en renouvellement comportant l’attribut vérifiable VCi à renouveler et la nouvelle identité digitale publique PIWm du portefeuille Wm.
Enfin, ladite étape 125 peut avantageusement consister à signer ladite requête VC_RR, préalablement à l’émission de cette dernière, à l’aide de l’identité digitale privée SKWm du portefeuille Wm. De cette manière, l’émetteur Ij’ destinataire pourra en vérifier la légitimité, comme il sera expliqué en lien avec la . De la même manière, ladite étape 125 pourrait consister, en variante ou en complément de ladite signature, à chiffrer le contenu de ladite requête VC_RR, préalablement à son émission, à l’aide de l’identité digitale publique PIIj’ (plus précisément de la clé publique PKIj’ issue de celle-ci) de sorte que ledit émetteur Ij’ puisse être le seul à déchiffrer ladite requête en renouvellement.
Le sous-procédé 100, outre le traitement 110 pour détecter un événement déclencheur d’un renouvellement d’un attribut vérifiable VCi et le traitement 120 pour produire et émettre une requête en renouvellement VC_RR de ce dernier, comporte un traitement ou étape de gestion 130 d’un nouvel attribut vérifiable VCi+1 fruit d’une telle requête en renouvellement VC_RR et transmis par un message de transmission VC_M élaboré par l’émetteur Ij’ destinataire de ladite requête en renouvellement VC_RR.
Un tel traitement 130 comporte une étape 131 de réception et de lecture d’un message de transmission d’un nouvel attribut vérifiable VCi+1 émanant de l’émetteur Ij’ destinataire de la requête en renouvellement VC_RR élaborée au traitement 120. Une telle étape 131 peut en outre consister en la vérification de la signature du nouvel attribut vérifiable VCi+1 par l’entité émettrice Ij’ de ce dernier, à l’aide de l’identité digitale publique PIIj’ de ladite entité émettrice Ij’, si ledit nouvel attribut a été signé par cette dernière. Le nouvel attribut vérifiable VCi+1 est rejeté si la vérification de la signature échoue et une nouvelle itération du traitement 120 est mise en œuvre, avantageusement en sélectionnant un émetteur Ij’ distinct de la précédente itération pour lui adresser une requête en renouvellement VC_RR.
Lorsque ledit nouvel attribut vérifiable paraît légitime, le traitement 130 comporte une étape 132 d’enregistrement du nouvel attribut vérifiable VCi+1, dans la mémoire de données 12, M, accessible en lecture et en écriture par le portefeuille Wm. Cet enregistrement du nouvel attribut vérifiable VCi+1 est réalisé en écrasant l’attribut vérifiable VCi ainsi renouvelé ou bien suivi par l’effacement de ce dernier.
Lorsque le sous-procédé 100 prévoit l’exploitation d’un compteur de présentations nPV, ladite étape 132 peut en outre consister en l’initialisation de la valeur d’un tel compteur nPV de messages de présentation PV_M véhiculant ledit nouvel attribut vérifiable VCi+1 dans une mémoire de données 12 de l’objet électronique Om hébergeant le portefeuille Wm, ladite mémoire étant accessible en lecture et en écriture par ledit portefeuille Wm.
Comme évoqué précédemment en lien avec la , le sous-procédé 100 peut prévoir une élaboration d’une requête en révocation VC_RKR d’un attribut vérifiable renouvelé VCi, c’est-à-dire celui sur lequel portait une requête en renouvellement VC_RR, à l’issue de la production d’un nouvel attribut vérifiable VCi+1. Selon ce mode de réalisation avantageux, le traitement 130 comporte en amont de la destruction (par écrasement ou effacement) d’un attribut vérifiable renouvelé VCi, une étape pour élaborer une telle requête en révocation VC_RKR agencée pour être interprétée par le registre de confiance TR ou tout autre registre dédié à cet effet. Ladite requête VC_RKR comporte l’attribut vérifiable VCi renouvelé et ainsi révoqué ou une information caractéristique de celui-ci, par exemple le résultat de la mise en œuvre d’une fonction cryptographique de hachage dudit attribut vérifiable VCi. Une telle requête VC_RKR peut être signée par le portefeuille Wm à l’étape 133 à l’aide de l’identité digitale privée SKWm du portefeuille Wm, voire être chiffrée à l’aide de l’identité digitale publique du registre destinataire de la requête en révocation. De cette manière, ledit registre peut lire, accepter ou rejeter ladite révocation après confirmation de la vérification de la signature dudit portefeuille Wm à l’aide de l’identité digitale publique PIWm de ce dernier.
Un procédé 300 de renouvellement automatique d’un attribut vérifiable VCi conforme à l’invention consiste en outre en un deuxième sous-procédé 200 agencé pour être mis en œuvre par une unité de traitement 11 d’émetteur Ij’ d’un système de preuve en ligne S tel que celui Ij illustré par la . Pour adapter le fonctionnement d’un tel émetteur Ij’, ledit sous-procédé 200 comprend principalement deux étapes ou traitements référencés 210 et 200 sur la : la première étape 210 permet le traitement d’une requête en renouvellement VC_RR d’un attribut vérifiable d’ores et déjà légitiment émis VCi, ladite requête étant transmise par un portefeuille Wm adapté pour mettre en œuvre le sous-procédé 100 ; la deuxième étape 220 consiste en la mise en œuvre du renouvellement d’un tel attribut vérifiable VCi en tant que tel ainsi qu’en la communication, par un message de transmission VC_M, d’un nouvel attribut vérifiable VCi+1 au portefeuille Wm requérant ledit renouvellement d’attribut vérifiable.
Le traitement 210 d’une requête en renouvellement VC_RR d’un attribut vérifiable VCi comporte une première étape de réception 211 d’une telle requête en renouvellement et de lecture des informations véhiculées par cette dernière parmi lesquelles l’attribut vérifiable VCi à renouveler et l’identité digitale publique PIWm du portefeuille Wm, respectivement objet et émetteur de ladite requête en renouvellement VC_RR.
Ledit traitement 210 comporte en outre une étape 214 de vérification : de la signature de ladite requête en renouvellement VC_RR par le portefeuille Wm, à l’aide de l’identité digitale publique PIWm de ce dernier ; de la signature de l’attribut vérifiable à renouveler VCi par l’entité électronique émettrice Ij de ce dernier, à l’aide l’identité digitale publique PIIj de cette dernière.
La vérification 214 de la signature de ladite requête en renouvellement VC_RR par le portefeuille Wm peut être optionnelle. En effet, une telle signature constitue une variante préférée mais non essentielle du sous-procédé 100. En revanche, la vérification 214 de la signature de l’attribut vérifiable à renouveler VCi par l’entité électronique émettrice Ij de ce dernier est davantage intéressante pour la mise en œuvre de l’invention puisque que la légitimité d’un tel attribut vérifiable VCi permet de déroger à la sollicitation de l’autorité de confiance TA. Ainsi, la deuxième étape 220, consistant en la mise en œuvre du renouvellement en tant que tel d’un attribut vérifiable, n’est mise œuvre que si ladite étape 214 de l’attribut vérifiable VCi à renouveler confirme l’authenticité de ladite signature dudit attribut vérifiable VCi (situation illustrée par le lien 214-y sur la ).
Lorsque la vérification 214 de la signature de ladite requête VC_RR par le portefeuille Wm est prévue, alors la mise en œuvre de la deuxième étape 220 consistant en tant que telle en le renouvellement d’un attribut vérifiable est également conditionnée à la confirmation de l’authenticité de ladite signature de ladite requête VC_RR (situation illustrée par le lien 214-y sur la ).
Parmi les plus populaires, on peut citer le couple XY composé de 2 microphones cardioïdes présentant une différence d’angle d’orientation entre 90° et 135°. Le couple MS pour « Mid-Side » est un autre couple très répandu composé d’un microphone de directivité cardioïde, et d’un second microphone dit en « figure de 8 » orienté à 90°. Par combinaison de ces 2 micros (somme/différence), on peut créer les voies gauche et droite de contenu stéréo. Ces couples sont dits coïncidents, c’est-à-dire que les capsules microphoniques ne présentent pas de retard entre elles, la spatialisation étant perçue par la différence d’intensité sonore entre les voies gauche et droite.
Une autre catégorie de couples dits à stéréophonie de phase consiste à utiliser des microphones distants l’un de l’autre, créant ainsi une différence de phase entre les voies pour les sources situés plus proche de l’un des micros. Le plus connu est le couple AB qui exploite 2 microphones onmidirectionnels espacés de quelques centimètres à plusieurs mètres. Un autre couple très répandu est le couple ORTF qui exploite à la fois une différence de phase par un espacement de 17cm des microphones et une différence d’amplitude par des directivités cardioïdes (les microphones présentent un angle autour de 90°). Le couple binaural consiste à placer des microphones omnidirectionnels dans les oreilles d’une tête artificielle : ce type de dispositif permet de créer nativement des contenus que l’on peut écouter au casque.
La méthode la plus simple pour créer un signal réduit par downmix est celle dite downmix passif. Elle consiste à effectuer une moyenne des voies gauche et droite du signal stéréo tel que :
ou dans le domaine fréquentiel :
où est la transformée de Fourier à court-terme de (ou FFT en anglais pour « Fast Fourier Transform »), f étant l’indice de la fréquence et k l’indice de la trame :
où k est l’indice de la trame de taille L , et N la taille de la FFT, une fenêtre d’apodisation de taille, de type sinus ou Hann ou autre, adaptée à la taille de la trame. peut être le signal lui-même ou une version augmentée avec des 0 (0-padding) : par exemple, dans le cas où la taille de la trame L est inférieure à la taille de la FFT N , peut être :
Cette méthode, très simple, fonctionne très bien dans les situations où les voies droite et gauche sont en phase. Cependant, dans les situations où les microphones ne sont pas coïncidents et présentent des différences de phase, un tel mixage génère un filtrage en peigne, qui se manifeste par une coloration du signal d’origine. Cela est dû au fait qu’en fonction de l’espacement des microphones, de la position de la source par rapport au couple de microphones et de la fréquence, les voies gauche et droite d’une même source peuvent se trouver soit en phase comme représenté en figure 1a, soit en opposition de phase comme représenté en figure 1b. Aussi, lors du downmix, les signaux gauche et droite vont soit s’additionner (interférence constructive), soit s’annuler (interférence destructive), créant ainsi des variations de niveau et des effets de coloration du signal réduit . La coloration vient de l’effet du filtrage en peigne : les effets d’interférences constructives et destructives se manifestent dans des bandes de fréquences différentes, modifiant ainsi l’équilibre et donc le timbre du signal issu du downmix par rapport à l'original.