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 — événements de sécurité configurés : 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.

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. Le service d'attestation Approov émet des verdicts signés fournisseur sur la même surface de point de contrôle que Play Integrity / App Attest ; EEI se place à côté, signant la trajectoire.

comparaison · EEI vs attestation plateforme

Marque-page, voici la trajectoire.
L'attestation est discrète. EEI est événement-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 — événements de sécurité configurés : utilisation de credential, biométrie, assemblage de payload, soumission de requête — entre credential et réception réseau.
Portée temporelle	Assertions de trust discrètes — chaque appel prouve l'état de l'appareil à ce moment. La re-attestation sur des flows sensibles ajoute des points de contrôle ; la séquence d'exécution entre les appels n'est pas capturée.	Ordonnée et hash-linkée. Enregistrement signé sur tout le flow transactionnel, du marque-page attesté à chaque événement jusqu'à la soumission.
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 platform key store 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	Chaque appel couvre le moment de l'appel. La re-attestation sur des flows sensibles ajoute des points de contrôle ; le trail d'exécution entre les appels reste hors du périmètre de l'attestation.	Événements de sécurité configurés — utilisation de credential, biométrie, assemblage de payload, changement réseau, soumission — chacun 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 d'attestation varie opérationnellement dans les flottes Android hétérogènes et les marchés avec des conditions Play Services inconsistantes.	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.	Catégorie émergente ; consomme le trust basis d'attestation et signe la trajectoire qui suit.

où elles composent

L'attestation donne le point de contrôle de trust. YinkoShield porte ce trust basis en avant comme evidence d'exécution signée sur tout le flow transactionnel.

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 — utilisation de credential, biométrie, assemblage de payload, changement réseau, soumission — avec une clé liée au platform key store de l'appareil.

La déclaration de trust basis lie les deux — le moteur de policy de l'opérateur définit la traduction du verdict plateforme vers le label trust-basis ; les mappings de référence ci-dessous sont les valeurs par défaut :

Play Integrity retourne MEETS_STRONG_INTEGRITY → les Evidence Tokens EEI pour cette session déclarent trust_basis = hardware_backed (par policy par défaut).
App Attest passe → EEI déclare trust_basis = hardware_bound (par policy par défaut).
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)

Valeurs par défaut de référence. Le moteur de policy de l'opérateur définit le mapping du verdict plateforme vers la déclaration de trust-basis ; les opérateurs — ou les schemes — peuvent surcharger ces valeurs par défaut.

Dans les flottes Android hétérogènes — particulièrement sur les marchés avec de nombreux OEMs entry-tier et des conditions Play Services inconsistantes — la couverture d'attestation peut varier opérationnellement. La clé hardware-bound d'EEI produit toujours une evidence forte sur ces appareils quand le platform key store 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 — événements de sécurité configurés : 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 ?: Même quand une re-attestation est appelée durant des flows sensibles, chaque appel est une assertion de trust discrète — elle prouve l'état de l'appareil à ce moment mais ne capture pas la séquence d'exécution entre les appels : utilisation de credential, biométrie, assemblage de payload, changement réseau, retry. EEI signe chacun de ces événements à mesure qu'ils se produisent, hash-linké au précédent, produisant un trail d'exécution ordonné et signé 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. Le service d'attestation Approov émet des verdicts signés fournisseur sur la même surface de point de contrôle que Play Integrity / App Attest ; EEI se place à côté, signant la trajectoire.

pour aller plus loin

Deux questions que cette page soulève sans répondre entièrement :

Quel est le schéma d'événements minimal pour un flow de paiement ?: Type d'événement, source timestamp, key ID, trust basis, numéro de séquence monotone, hash précédent, binding nonce/contexte, version app, version policy, résultat vérificateur — les définitions normatives de champs et contraintes de valeurs se trouvent dans la spécification YEI-001. L'article sur le format Evidence Token couvre le jeu de claims requis public.
Qui provisionne les clés — et que se passe-t-il lors d'une réinstallation, migration d'appareil, ou reset TEE ?: La génération de clé, les garanties de hardware-backing, la destruction au factory reset, et la chaîne d'attestation bootstrap sont couverts dans Custody locale des clés — frontières appareil, opérateur et fournisseur.

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.

Mapper votre déploiement d'attestation existant vers les signaux EEI

Marque-page, voici la trajectoire. L'attestation est discrète. EEI est événement-continue.