10. Fraîcheur

10. Fraîcheur

Un vérificateur ou une partie utilisatrice peut avoir besoin de connaître le moment précis (c'est-à-dire l'« époque ») auquel une preuve ou un résultat d'attestation a été produit. Cela est essentiel pour décider si les revendications incluses peuvent être considérées comme fraîches, ce qui signifie qu'elles reflètent toujours l'état actuel de l'attestateur et que tout résultat d'attestation a été généré en utilisant la politique d'évaluation la plus récente pour les preuves, les endorsements et les valeurs de référence.

Cette section fournit un certain nombre de détails. Cependant, elle ne définit aucun format de protocole et les interactions présentées sont abstraites. Cette section est destinée à ceux qui créent des protocoles et des solutions pour comprendre les options disponibles pour garantir la fraîcheur. La manière dont la fraîcheur est fournie dans un protocole est une décision architecturale. La fourniture de fraîcheur a un impact sur le nombre d'allers-retours nécessaires dans un protocole ; par conséquent, elle doit être prise très tôt dans la conception. Différentes décisions auront des impacts significatifs sur l'interopérabilité résultante, c'est pourquoi cette section entre dans suffisamment de détails pour que les choix en matière de fraîcheur soient compatibles entre les protocoles en interaction, comme illustré dans la figure 9.

La fraîcheur est évaluée en fonction de la politique d'évaluation pour les preuves ou les résultats d'attestation qui compare l'époque estimée à un seuil d'« expiration » défini localement pour cette politique. Il existe cependant toujours une condition de concurrence possible dans la mesure où l'état de l'attestateur et les politiques d'évaluation peuvent changer immédiatement après la génération de la preuve ou du résultat d'attestation. L'objectif est simplement de réduire leur récence à quelque chose que le vérificateur (pour les preuves) ou la partie utilisatrice (pour le résultat d'attestation) est prêt à accepter. Une certaine flexibilité sur l'exigence de fraîcheur est un élément clé pour permettre la mise en cache et la réutilisation des preuves et des résultats d'attestation, ce qui est particulièrement précieux dans les cas où leur calcul utilise une partie substantielle du budget de ressources (par exemple, l'énergie dans les appareils contraints).

Il existe trois approches courantes pour déterminer l'époque d'une preuve ou d'un résultat d'attestation.

10.1. Chronométrage explicite utilisant des horloges synchronisées

La première approche consiste à s'appuyer sur des horloges synchronisées et dignes de confiance et à inclure un horodatage signé (voir [RATS-TUDA]) avec les revendications dans la preuve ou le résultat d'attestation. Les horodatages peuvent également être ajoutés par revendication pour distinguer le moment de génération de la preuve ou du résultat d'attestation du moment où une revendication spécifique a été générée. La fiabilité de l'horloge peut généralement être établie via des endorsements et nécessite généralement des revendications supplémentaires sur le mécanisme de synchronisation temporelle du signataire.

Cependant, une horloge digne de confiance peut ne pas être disponible dans certains cas d'usage. Par exemple, dans de nombreux TEE aujourd'hui, une horloge n'est disponible qu'à l'extérieur du TEE ; elle ne peut donc pas être considérée comme fiable par le TEE.

10.2. Chronométrage implicite utilisant des nonces

Une deuxième approche place la responsabilité du chronométrage uniquement sur le vérificateur (pour les preuves) ou la partie utilisatrice (pour les résultats d'attestation). Par exemple, cette approche peut être appropriée si l'attestateur n'a pas d'horloge digne de confiance ou si la synchronisation temporelle est autrement compromise. Dans cette approche, un nonce imprévisible est envoyé par l'entité d'évaluation et le nonce est ensuite signé et inclus avec les revendications dans la preuve ou le résultat d'attestation. Après avoir vérifié que les nonces envoyés et reçus sont identiques, l'entité d'évaluation sait que les revendications ont été signées après la génération du nonce. Cela permet d'associer une époque « approximative » à la preuve ou au résultat d'attestation. Dans ce cas, l'époque est dite approximative car :

• L'époque s'applique à l'ensemble des revendications au lieu d'une association plus granulaire, et

• Le temps entre la création des revendications et la collecte des revendications est indiscernable.

10.3. Chronométrage implicite utilisant des identifiants d'époque

Une troisième approche repose sur l'envoi périodique d'identifiants d'époque (ID) à la fois à l'expéditeur et au destinataire des preuves ou des résultats d'attestation par un « distributeur d'ID d'époque ».

Les ID d'époque sont différents des nonces car ils peuvent être utilisés plus d'une fois et peuvent même être utilisés par plusieurs entités en même temps. Les ID d'époque sont différents des horodatages car ils n'ont pas à transmettre d'informations sur un moment précis, c'est-à-dire qu'ils ne sont pas nécessairement des entiers croissants de manière monotone.

Comme l'approche par nonce, cela permet d'associer une époque « approximative » sans nécessiter d'horloge digne de confiance ou de synchronisation temporelle pour générer ou évaluer la fraîcheur des preuves ou des résultats d'attestation. Seul le distributeur d'ID d'époque nécessite un accès à une horloge afin de pouvoir envoyer périodiquement de nouveaux ID d'époque.

L'ID d'époque le plus récent est inclus dans la preuve ou les résultats d'attestation produits, et l'entité d'évaluation peut comparer l'ID d'époque dans les preuves ou les résultats d'attestation reçus avec le dernier ID d'époque qu'elle a reçu du distributeur d'ID d'époque pour déterminer s'il se situe dans l'époque actuelle. Une solution réelle doit également tenir compte des conditions de concurrence lors de la transition vers une nouvelle époque, par exemple en utilisant un compteur signé par le distributeur d'ID d'époque comme ID d'époque, en incluant à la fois les ID d'époque actuels et précédents dans les messages et/ou les vérifications en exigeant des nouvelles tentatives en cas de non-correspondance des ID d'époque, ou en mettant en mémoire tampon les messages entrants qui pourraient être associés à un ID d'époque que le destinataire n'a pas encore obtenu.

Plus généralement, afin d'empêcher une entité d'évaluation de générer des faux négatifs (par exemple, rejeter des preuves jugées obsolètes même si elles ne le sont pas), l'entité d'évaluation doit conserver une « fenêtre d'époque » constituée des ID d'époque les plus récemment reçus. La profondeur d'une telle fenêtre d'époque est directement proportionnelle au délai de propagation réseau maximal entre le premier à recevoir l'ID d'époque et le dernier à recevoir l'ID d'époque et elle est inversement proportionnelle à la durée de l'époque. L'entité d'évaluation doit comparer l'ID d'époque porté dans la preuve ou le résultat d'attestation reçu avec les ID d'époque de sa fenêtre d'époque pour trouver une correspondance appropriée.

Alors que l'approche par nonce nécessite généralement que l'entité d'évaluation conserve un état pour chaque nonce généré, l'approche par ID d'époque minimise l'état conservé pour être indépendant du nombre d'attestateurs ou de vérificateurs dont elle s'attend à recevoir des preuves ou des résultats d'attestation tant que tous utilisent le même distributeur d'ID d'époque.

10.4. Discussion

Le chronométrage implicite et explicite peut être combiné en mécanismes hybrides. Par exemple, si des horloges existent dans l'environnement d'attestation et sont considérées comme dignes de confiance (inviolables) mais ne sont pas synchronisées, un échange basé sur un nonce peut être utilisé pour déterminer le décalage temporel (relatif) entre les pairs impliqués, suivi d'un nombre quelconque d'échanges basés sur des horodatages.

Il est important de noter que les valeurs réelles des revendications peuvent avoir été générées bien avant que les revendications ne soient signées. Si tel est le cas, il incombe au signataire de s'assurer que les valeurs sont toujours fraîches au moment de leur signature. Par exemple, les valeurs générées au moment du démarrage peuvent avoir été enregistrées dans un stockage sécurisé jusqu'à ce que la connectivité réseau soit établie avec le vérificateur distant et qu'un nonce soit obtenu.

Une discussion plus détaillée avec des exemples apparaît dans l'annexe A.

Pour une discussion sur la sécurité des ID d'époque, voir la section 12.3.