EEI est-il un substitut à l'attestation plateforme ?

Non. L'attestation établit que l'appareil est dans un état de trust à un point de contrôle — typiquement quand l'app démarre, ou quand un flow sensible commence. EEI établit ce que l'appareil a fait entre les points de contrôle — chaque utilisation de credential, biométrie, assemblage de payload, soumission de requête. Les deux sont conçus pour composer : l'attestation est le marque-page, EEI est la trajectoire.

Que fait Play Integrity / App Attest qu'EEI ne fait pas ?

Les services d'attestation plateforme émettent un token signé par le fournisseur confirmant que l'appareil, l'application, et l'OS sont dans un état known-good au moment de l'appel. Ils sont aussi le chemin vers une identité d'appareil hardware-rooted dans la chaîne de trust de la plateforme. EEI ne réplique pas cette relation fournisseur-plateforme ; il consomme le trust basis que la plateforme déclare et signe la trajectoire runtime qui suit.

Que fait EEI que l'attestation ne fait pas ?

L'attestation vous dit que l'appareil a passé un check d'intégrité à un instant. Elle ne vous dit pas ce qui s'est passé pendant les 30 secondes suivantes — utilisation de credential, biométrie, assemblage de payload, swap réseau, retry. EEI signe chacun de ces événements à mesure qu'ils se produisent, hash-linké au précédent. Le résultat est un enregistrement continu, ordonné, et signé de l'exécution que les consommateurs downstream (émetteur, scheme, plateforme de litiges) peuvent vérifier.

Puis-je utiliser les deux ?

Oui — et la plupart des déploiements de production le font. L'attestation établit le trust basis au début de session (`hardware_backed`, `hardware_bound`, `software_layer`) ; EEI porte ce trust basis dans chaque événement signé, déclaré dans l'Evidence Token. Le moteur de policy de l'opérateur lit les deux : l'attestation donne le marque-page, EEI donne le chemin.

Pourquoi le chemin de vérification compte-t-il ?

Les tokens d'attestation sont typiquement vérifiés via le service du fournisseur plateforme ou contre la chaîne de certificats du fournisseur. Les tokens EEI sont vérifiés contre des clés publiques stockées par l'opérateur, dans la stack de l'opérateur, sans endpoint YinkoShield dans le chemin. Cela compte quand le consommateur est un régulateur, un scheme, ou un partenaire qui ne fait pas partie de la relation fournisseur-plateforme — ils peuvent vérifier EEI directement sans coordination avec Apple, Google, ou Samsung.

comparaison · EEI vs attestation plateforme

Marque-page, voici la trajectoire.
L'attestation est ponctuelle. EEI est continue.

Play Integrity, App Attest, SafetyNet, attestation Keystore hardware-backed — ces services établissent que l'appareil est dans un état de trust à un instant. EEI établit ce que l'appareil a fait entre ces instants. Les deux composent ; aucun ne remplace l'autre.

réponse courte

L'attestation plateforme est le marque-page — preuve signée fournisseur que l'appareil, l'app, et l'OS sont dans un état known-good à un moment. EEI est la trajectoire — preuve signée opérateur de ce que le runtime a fait entre les marque-pages, hash-linkée, ordonnée, vérifiable sans YinkoShield dans le chemin.

marque-page vs trajectoire

Deux pilliers. Cinq événements signés entre eux. Un seul trust basis déclaré tout du long.

L'attestation est ponctuelle. EEI est continue. Le trust basis attesté est porté dans chaque Evidence Token entre marque-pages — pas de ré-appel Play Integrity / App Attest par événement.

côte à côte

Ce que chacune prouve. Ce que chacune ne prouve pas.

Dimension	Attestation plateforme	EEI
Ce qu'elle prouve	L'appareil était dans un état de trust au moment de l'appel d'attestation (intégrité matérielle, intégrité OS, intégrité app).	La trajectoire runtime de l'appareil — chaque utilisation de credential, biométrie, assemblage de payload, soumission de requête — entre credential et réception réseau.
Portée temporelle	Ponctuelle. Une attestation = un marque-page.	Continue et ordonnée. Enregistrement hash-linké sur tout le flow transactionnel.
Qui émet le trust	Le fournisseur plateforme (Google, Apple, Samsung, le fournisseur TEE de l'OEM).	La clé appareil enregistrée par l'opérateur, générée dans le TEE de l'appareil à la première init. La relation fournisseur est au bootstrap ; YinkoShield n'est pas dans le chemin.
Qui vérifie	Service fournisseur ou chaîne de certificats fournisseur — Google Play Integrity API, service Apple App Attest, endpoints OEM-spécifiques.	La stack de l'opérateur, contre des clés publiques stockées par l'opérateur. Aucun endpoint YinkoShield dans le chemin de vérification.
Forme de l'output	Verdict d'intégrité signé fournisseur (PASS / FAIL avec détails). Lié à la chaîne de vérification du fournisseur.	Evidence Token signé (~200 octets JWS-compact ES256) portant les classes de signaux et la déclaration de trust basis.
Déclaration de trust basis	Catégories de verdict définies par le fournisseur (ex. `MEETS_DEVICE_INTEGRITY` / `MEETS_BASIC_INTEGRITY` / `MEETS_STRONG_INTEGRITY` pour Play Integrity).	`hardware_backed`, `hardware_bound`, `execution_proof`, `compromised_device`, `software_layer` — déclaré inline dans chaque Evidence Token, jamais inféré.
Couverture entre points de contrôle	Aucune — ce qui se passe après l'appel d'attestation jusqu'au prochain appel est inobservable.	Continue — chaque événement significatif signe et référence le hash de son prédécesseur.
Cohérence cross-plateforme	Chaque fournisseur plateforme a sa propre API d'attestation, sa propre forme de verdict, et son propre SLA.	Même forme d'Evidence Token sur Android, iOS, POS, SoftPOS, SST. Un seul vérificateur gère l'estate entier.
Couverture fournisseur	Google (Play Integrity), Apple (App Attest), Samsung Knox, OEM-spécifique (Huawei, Xiaomi, MediaTek). Chacun émet sa propre forme de verdict ; la couverture sur OEMs entry-tier (Tecno, Infinix, itel) est inconsistante.	Vendor-agnostic. Même Evidence Token sur chaque OEM Android, iOS, firmware POS, SST. Un seul vérificateur gère chaque appareil sur lequel l'app de l'opérateur tourne.
Pattern d'adoption	Mature ; exigée par beaucoup de programmes scheme et de policies de distribution OS.	Nouvelle catégorie ; consomme le trust basis d'attestation et signe la trajectoire qui suit.

où elles composent

L'attestation donne le marque-page. EEI le porte ensuite.

Un déploiement tier-1 typique fait tourner les deux. L'attestation plateforme tourne au début de session — l'application de l'opérateur appelle Play Integrity (Android) ou App Attest (iOS), reçoit un verdict signé fournisseur, et l'utilise pour décider si la session peut procéder. EEI tourne en continu ensuite, signant chaque événement significatif avec une clé liée au TEE de l'appareil.

La déclaration de trust basis lie les deux :

Play Integrity retourne MEETS_STRONG_INTEGRITY → les Evidence Tokens EEI pour cette session déclarent trust_basis = hardware_backed.
App Attest passe → EEI déclare trust_basis = hardware_bound.
L'attestation soft-fail (rooted device, ROM custom, émulateur) → EEI déclare trust_basis = compromised_device ou software_layer, et signe quand même. Le risk engine de l'opérateur lit les deux signaux et décide.

Le vérificateur de l'opérateur voit une seule séquence signée continue, partant du marque-page attesté, avec le trust basis porté dans chaque événement. La plateforme de litiges, l'émetteur, et le régulateur peuvent rejouer cette séquence indépendamment — aucun d'eux n'a besoin de rappeler Play Integrity ou App Attest.

Verdict plateforme	EEI `trust_basis` déclaré
Play Integrity `MEETS_STRONG_INTEGRITY`	`hardware_backed`
Play Integrity `MEETS_DEVICE_INTEGRITY`	`hardware_bound`
App Attest assertion vérifiée	`hardware_bound`
Attestation soft-fail (rooted, ROM custom, émulateur)	`compromised_device` ou `software_layer`
Attestation indisponible (OEM entry-tier, sans Play Services)	`software_layer` ou `execution_proof` (déclaré honnêtement)

Sur les marchés où Tecno, Infinix, itel, et autres OEMs entry-tier dominent, les verdicts d'attestation plateforme sont inconsistants ou indisponibles. La clé liée au matériel d'EEI produit toujours une evidence forte sur ces appareils quand le TEE est présent, et déclare software_layer honnêtement quand il ne l'est pas. Le risk engine de l'opérateur lit la déclaration ; le substrat n'infère pas.

questions fréquentes

Cinq questions, cinq réponses.

·01 EEI est-il un substitut à l'attestation plateforme ?: Non. L'attestation établit que l'appareil est dans un état de trust à un point de contrôle — typiquement quand l'app démarre, ou quand un flow sensible commence. EEI établit ce que l'appareil a fait entre les points de contrôle — chaque utilisation de credential, biométrie, assemblage de payload, soumission de requête. Les deux sont conçus pour composer : l'attestation est le marque-page, EEI est la trajectoire.
·02 Que fait Play Integrity / App Attest qu'EEI ne fait pas ?: Les services d'attestation plateforme émettent un token signé par le fournisseur confirmant que l'appareil, l'application, et l'OS sont dans un état known-good au moment de l'appel. Ils sont aussi le chemin vers une identité d'appareil hardware-rooted dans la chaîne de trust de la plateforme. EEI ne réplique pas cette relation fournisseur-plateforme ; il consomme le trust basis que la plateforme déclare et signe la trajectoire runtime qui suit.
·03 Que fait EEI que l'attestation ne fait pas ?: L'attestation vous dit que l'appareil a passé un check d'intégrité à un instant. Elle ne vous dit pas ce qui s'est passé pendant les 30 secondes suivantes — utilisation de credential, biométrie, assemblage de payload, swap réseau, retry. EEI signe chacun de ces événements à mesure qu'ils se produisent, hash-linké au précédent. Le résultat est un enregistrement continu, ordonné, et signé de l'exécution que les consommateurs downstream (émetteur, scheme, plateforme de litiges) peuvent vérifier.
·04 Puis-je utiliser les deux ?: Oui — et la plupart des déploiements de production le font. L'attestation établit le trust basis au début de session (`hardware_backed`, `hardware_bound`, `software_layer`) ; EEI porte ce trust basis dans chaque événement signé, déclaré dans l'Evidence Token. Le moteur de policy de l'opérateur lit les deux : l'attestation donne le marque-page, EEI donne le chemin.
·05 Pourquoi le chemin de vérification compte-t-il ?: Les tokens d'attestation sont typiquement vérifiés via le service du fournisseur plateforme ou contre la chaîne de certificats du fournisseur. Les tokens EEI sont vérifiés contre des clés publiques stockées par l'opérateur, dans la stack de l'opérateur, sans endpoint YinkoShield dans le chemin. Cela compte quand le consommateur est un régulateur, un scheme, ou un partenaire qui ne fait pas partie de la relation fournisseur-plateforme — ils peuvent vérifier EEI directement sans coordination avec Apple, Google, ou Samsung.

Les opérateurs qui font déjà tourner Play Integrity ou App Attest tirent le plus d'un briefing de mapping de 60 minutes.

Nous mappons vos verdicts d'attestation existants aux déclarations de trust-basis EEI et montrons comment la trajectoire runtime continue après l'appel d'attestation. Vous gardez l'attestation, vous ajoutez la trajectoire.

Demander un briefing

Marque-page, voici la trajectoire. L'attestation est ponctuelle. EEI est continue.