comparaison · EEI vs RASP
Points de décision différents.
Composables, pas concurrents.
RASP applique localement — bloque cet appel, termine cette session, déclare cette build hors-policy. EEI témoigne — produit un enregistrement signé qui voyage avec la transaction, vérifiable par toute partie disposant de la clé publique. Même surface de menace, point de décision différent. Les deux composent.
réponse courte
RASP et EEI ne sont pas des alternatives. RASP est la couche d'enforcement inline ; EEI est la couche d'evidence signée. Les opérateurs qui livrent les deux obtiennent le blocage sur-appareil plus une evidence portable et vérifiable downstream que l'émetteur, le scheme, et la plateforme de litiges peuvent consommer indépendamment.
où chacun décide
Même flow. Deux points de décision. Un seul moteur de policy.
côte à côte
Neuf dimensions. Trois colonnes.
| Dimension | RASP | EEI |
|---|---|---|
| Ce que cela fait | Détecte les menaces runtime sur l'appareil et agit dessus localement — bloque, termine, force la ré-auth. | Signe la trajectoire runtime à l'instant de l'exécution et produit un enregistrement portable que toute partie disposant de la clé publique peut vérifier. |
| Point de décision | Sur l'appareil, dans l'instant. | Côté opérateur, downstream — le risk engine de l'opérateur combine les signaux signés avec le contexte métier. |
| Forme de l'output | Verdict bloquer, autoriser, ou observer (souvent un interrupteur binaire par contrôle). | Evidence Token signé (~200 octets JWS-compact ES256) portant les classes de signaux et la déclaration de trust basis. |
| Qui peut vérifier | Typiquement la console du fournisseur ou l'intégration RASP de l'opérateur. | Toute partie à laquelle l'opérateur accorde la clé publique — gateway, émetteur, scheme, plateforme de litiges, régulateur. |
| Fournisseur dans le chemin | Souvent oui — backend fournisseur ou service de licence consulté au runtime. | Non — la vérification tourne dans la stack de l'opérateur contre les clés publiques stockées par l'opérateur. |
| Découplage de la policy | Interrupteur par contrôle (activer / désactiver / observer) ; rendre un contrôle context-aware exige généralement de reconstruire le moteur du fournisseur. | Signaux signés livrés au moteur de policy de l'opérateur ; la policy conditionnelle et contextuelle est définie par l'opérateur. |
| Profondeur forensique | Événements internes ; la portabilité à travers une frontière émetteur / scheme exige généralement un re-signing côté opérateur. | Local Evidence Ledger append-only et hash-linked sur l'appareil ; les requêtes forensiques plus profondes passent par le canal Commander. |
| Couverture du threat model | Compromission au niveau application, debugger attach, hooking, repackaging — gérés inline. | Même surface, plus la runtime coherence sur l'intervalle credential-use → network-receipt ; la même surface produit une evidence signée que l'opérateur peut auditer plus tard. |
| Pattern d'adoption | Catégorie mature ; beaucoup de déploiements tier-1 font déjà tourner un produit RASP. | Nouvelle catégorie ; se place sous ou à côté de RASP et absorbe la couche d'evidence que RASP ne livre pas. |
où ils composent
Enforcement inline plus evidence downstream.
Un déploiement tier-1 typique fait tourner les deux. RASP se place inline dans l'application mobile et le firmware POS de l'opérateur pour refuser les chargements, tuer les processus, et court-circuiter les flows manifestement adversariaux avant qu'ils n'atteignent un credential. EEI se place dessous, observant la trajectoire runtime sur chaque événement significatif et signant le résultat.
Ce qui change quand vous ajoutez EEI à une stack qui fait déjà tourner RASP :
- Les litiges se résolvent contre une evidence signée, pas un jugement de crédibilité entre logs backend et réclamation porteur.
- Émetteurs, schemes, et régulateurs vérifient indépendamment — même evidence, consommateurs différents, pas de re-signing à travers la frontière.
- La policy reste chez l'opérateur. Les signaux signés alimentent le risk engine de l'opérateur ; la policy conditionnelle et contextuelle remplace l'interrupteur par-contrôle de RASP.
- Une panne fournisseur ne casse pas la vérification. La vérification EEI tourne dans la stack de l'opérateur contre des clés publiques stockées par l'opérateur ; aucun endpoint YinkoShield n'est consulté.
questions fréquentes
Six questions, six réponses.
- ·01
EEI est-il un substitut au RASP ?
- Non. EEI et RASP couvrent des points de décision différents. RASP applique localement sur l'appareil — bloquer cet appel, terminer cette session, déclarer cette build hors-policy. EEI témoigne — produit un enregistrement signé qui voyage avec la transaction, vérifiable downstream par des parties qui ne tournent pas sur l'appareil. Les opérateurs qui livrent les deux obtiennent l'enforcement inline plus une evidence portable de qualité audit.
- ·02
Que fait RASP qu'EEI ne fait pas ?
- RASP peut agir sur l'appareil dans l'instant — refuser le chargement, tuer le processus, bloquer l'appel, forcer une ré-authentification. EEI n'applique pas ; il signe. Si votre threat model exige un runtime qui bloque localement plutôt que de rapporter, vous avez besoin de RASP (ou de contrôles type RASP dans l'application de l'opérateur).
- ·03
Que fait EEI que RASP ne fait pas ?
- EEI produit une evidence signée que toute partie disposant de la clé publique peut vérifier — la gateway, l'émetteur, la plateforme de litiges, le régulateur, un partenaire. L'evidence voyage avec la transaction et est rejouable depuis le ledger appareil. RASP, par défaut, produit des événements internes que la console du fournisseur consomme ; la même evidence est rarement portable à travers une frontière émetteur / scheme / régulateur sans re-signing côté opérateur.
- ·04
Puis-je faire tourner les deux ?
- Oui — et la plupart des déploiements tier-1 le font. RASP gère la décision inline bloquer-ou-autoriser ; EEI produit l'enregistrement qui valide ou réfute la décision downstream. Les deux composent. Ils ne sont pas en compétition ; ils se trouvent à des points différents dans le pipeline de trust.
- ·05
Pourquoi le modèle de vérification est-il différent ?
- Les verdicts RASP sont typiquement consommés par le moteur de policy du fournisseur ou l'intégration RASP de l'opérateur. Les verdicts EEI sont produits par le vérificateur propre de l'opérateur (implémentation de référence Python / JavaScript / Go / Java), contre des clés publiques stockées par l'opérateur, sans endpoint YinkoShield dans le chemin. Cette propriété — sovereign verification — est ce qui permet à la même evidence d'être consommée par les émetteurs, schemes, plateformes de litiges, et régulateurs sans ré-émission de trust via un fournisseur.
- ·06
Le runtime EEI et un SDK RASP peuvent-ils coexister dans le même process applicatif ?
- Oui. Les produits RASP s'interposent typiquement à la frontière JNI / bibliothèque native ou via du bytecode instrumenté. Le TRP d'EEI enveloppe les syscalls, libc, et appels framework — une couche différente du runtime. Les deux tournent côte à côte sans conflit de chaîne de hooks. Nous avons validé la coexistence avec les familles RASP majeures sur Android dans des estates de production ; spécificités couvertes en briefing de mapping sur demande.
Composer EEI avec votre déploiement RASP existant est l'un des briefings que nous menons le plus souvent.
Soixante minutes avec l'ingénierie. Nous mappons vos règles RASP actuelles aux classes de signaux EEI qu'elles alimenteraient ; vous gardez les règles, la policy, et le vérificateur.
Demander un briefing