12.2. Protection des messages conceptuels
Toute solution qui transmet des informations dans un message conceptuel (voir section 8) doit prendre en charge la protection de l'intégrité de bout en bout et la prévention des attaques par rejeu. Elle doit souvent également prendre en charge des propriétés de sécurité supplémentaires, notamment :
- chiffrement de bout en bout,
- protection contre le déni de service,
- authentification,
- audit,
- contrôles d'accès à grain fin, et
- journalisation.
La section 10 discute des moyens par lesquels la fraîcheur peut être utilisée dans cette architecture pour se protéger contre les attaques par rejeu.
Pour évaluer la sécurité fournie par une politique d'évaluation particulière, il est important de comprendre la force de la racine de confiance, par exemple, s'il s'agit d'un logiciel mutable ou d'un micrologiciel en lecture seule après le démarrage ou d'un matériel/ROM immuable.
Il est également important que la politique d'évaluation ait été obtenue de manière sécurisée. Si un attaquant peut configurer ou modifier les politiques d'évaluation et les approbations ou valeurs de référence pour une partie utilisatrice ou un vérificateur, alors l'intégrité du processus est compromise.
Les protections de sécurité dans l'architecture RATS peuvent être appliquées à différentes couches, que ce soit par un protocole de transport ou un format d'encodage d'informations. Cette architecture s'attend à ce que les messages conceptuels soient protégés de bout en bout en fonction du contexte d'interaction des rôles. Par exemple, si un attesteur produit des preuves qui sont relayées par une autre entité qui n'implémente pas les rôles d'attesteur ou de vérificateur prévu, alors l'entité de relais ne devrait pas s'attendre à avoir accès aux preuves.
L'architecture RATS permet à une entité de fonctionner dans plusieurs rôles (section 6) et pour des appareils composites (section 3.3). Les implémenteurs doivent évaluer leurs conceptions pour s'assurer que les propriétés de sécurité supposées des composants et rôles individuels restent valables malgré l'absence de séparation et qu'aucun risque émergent n'est introduit. Les spécificités de cette évaluation dépendront de l'implémentation et du cas d'usage ; par conséquent, elles sont hors du champ d'application de ce document. Les mécanismes d'isolation dans le logiciel ou le matériel qui séparent les environnements d'attestation et les environnements cibles (section 3.1) peuvent soutenir l'évaluation d'un implémenteur et les décisions de conception qui en résultent.