Le provisionnement de clés à distance de Google sera obligatoire dans Android 13, mais c'est un sujet compliqué. Voici ce que cela signifie pour vous.
L'attestation de clé d'Android constitue l'épine dorsale de nombreux services de confiance sur nos smartphones, notamment SafetyNet, Digital Car Key et l'API d'identification d'identité. Il est requis dans le cadre d'Android depuis Android 8 Oreo et dépend d'une clé racine installée sur un appareil en usine. La fourniture de ces clés exigeait le plus grand secret de la part du fabricant, et si une clé était divulguée, cela signifierait qu'elle devrait être révoquée. Cela aurait pour conséquence qu'un consommateur ne pourrait utiliser aucun de ces services de confiance, ce qui serait regrettable si jamais une vulnérabilité pouvait l'exposer. Le provisionnement de clés à distance, qui sera obligatoire dans Android 13, vise à résoudre ce problème.
Les composants composant la chaîne de confiance actuelle sur Android
Avant d'expliquer le fonctionnement du nouveau système, il est important de fournir un contexte sur la façon dont le
vieux (et toujours en place pour de nombreux appareils) le système fonctionne. De nos jours, de nombreux téléphones utilisent une attestation de clé matérielle, que vous connaissez peut-être comme le clou dans le cercueil de tout type de contournement SafetyNet. Il existe plusieurs concepts qu'il est important de comprendre pour l'état actuel de l'attestation de clé.C'est une combinaison de ces concepts qui garantit qu'un développeur peut être sûr qu'un appareil n'a pas été falsifié et qu'il peut gérer des informations sensibles dans le TEE.
Environnement d'exécution fiable
Un environnement d'exécution sécurisé (TEE) est une région sécurisée sur le SoC utilisée pour gérer les données critiques. TEE est obligatoire sur les appareils lancés avec Android 8 Oreo et supérieur, ce qui signifie que tout smartphone récent en est équipé. Tout ce qui ne se trouve pas dans le TEE est considéré comme « non fiable » et ne peut voir que le contenu crypté. Par exemple, le contenu protégé par DRM est chiffré avec des clés accessibles uniquement par les logiciels exécutés sur le TEE. Le processeur principal ne peut voir qu'un flux de contenu crypté, tandis que le contenu peut être déchiffré par le TEE puis affiché à l'utilisateur.
Zone de confiance ARM
Trusty est un système d'exploitation sécurisé qui fournit un TEE sur Android et sur les systèmes ARM, il utilise la Trustzone d'ARM. Trusty est exécuté sur le même processeur que le système d'exploitation principal et a accès à toute la puissance de l'appareil mais est complètement isolé du reste du téléphone. Trusty se compose des éléments suivants :
- Un petit noyau de système d'exploitation dérivé de Petit noyau
- Un pilote du noyau Linux pour transférer des données entre l'environnement sécurisé et Android
- Une bibliothèque d'espace utilisateur Android pour communiquer avec des applications de confiance (c'est-à-dire des tâches/services sécurisés) via le pilote du noyau
L'avantage qu'il présente par rapport aux systèmes TEE propriétaires est que ces systèmes TEE peuvent être coûteux et également créer une instabilité dans l'écosystème Android. Trusty est fourni gratuitement par Google aux OEM partenaires et il est open source. Android prend en charge d'autres systèmes TEE, mais Trusty est celui que Google propose le plus.
Coffre Fort
Les appareils StrongBox sont des processeurs sécurisés complètement séparés, spécialement conçus et certifiés. Ceux-ci peuvent inclure des éléments sécurisés (eSE) intégrés ou une unité de traitement sécurisée (SPU) sur SoC. Google affirme qu'il est actuellement « fortement recommandé » que StrongBox soit fourni avec les appareils lancés avec Android 12 (conformément au document de définition de compatibilité) car cela deviendra probablement une exigence dans une future version d'Android. Il s'agit essentiellement d'une implémentation plus stricte d'un magasin de clés basé sur le matériel et peut être implémenté avec TrustZone. Un exemple d'implémentation de StrongBox est la puce Titan M dans les smartphones Pixel. Peu de téléphones utilisent StrongBox et la plupart utilisent la Trustzone d'ARM.
Maître des clés TA
Keymaster Trusted Application (TA) est le keymaster sécurisé qui gère et exécute toutes les opérations du magasin de clés. Il peut fonctionner, par exemple, sur TrustZone d'ARM.
Comment l’attestation de clé évolue avec Android 12 et Android 13
Si une clé est exposée sur un smartphone Android, Google doit la révoquer. Cela pose un problème pour tout appareil doté d'une clé injectée en usine: tout type de fuite exposant la clé signifierait que les utilisateurs ne pourraient pas accéder à certains contenus protégés. Cela peut même inclure la révocation de l'accès à des services tels que Google Pay, sur lesquels comptent de nombreuses personnes. C’est regrettable pour les consommateurs car sans faire réparer votre téléphone par un fabricant, vous n’aurez aucun moyen de le réparer vous-même.
Entrez dans le provisionnement de clés à distance. À partir d'Android 12, Google remplace la fourniture de clés privées en usine par une combinaison de Extraction de clé publique en usine et fourniture de certificats en direct avec une durée de vie courte certificats. Ce schéma sera requis dans Android 13 et présente quelques avantages. Avant tout, cela évite aux OEM et ODM de devoir gérer le secret des clés dans une usine. Deuxièmement, cela permet de récupérer les appareils si leurs clés sont compromises, ce qui signifie que les consommateurs ne perdront pas définitivement l'accès aux services protégés. Désormais, plutôt que d'utiliser un certificat calculé à l'aide d'une clé présente sur l'appareil et susceptible d'être divulguée via un vulnérabilité, un certificat temporaire est demandé à Google chaque fois qu'un service nécessitant une attestation est utilisé.
Quant à son fonctionnement, c'est assez simple. Une paire de clés statique unique est générée par chaque appareil, et la partie publique de cette paire de clés est extraite par l'OEM dans son usine et soumise aux serveurs de Google. Là, ils serviront de base de confiance pour un approvisionnement ultérieur. La clé privée ne quitte jamais l'environnement sécurisé dans lequel elle est générée.
Lorsqu'un appareil est utilisé pour la première fois pour se connecter à Internet, il génère une demande de signature de certificat pour clés qu'il a générées, en le signant avec la clé privée qui correspond à la clé publique collectée dans le usine. Les serveurs backend de Google vérifieront l'authenticité de la demande, puis signeront les clés publiques, renvoyant les chaînes de certificat. Le magasin de clés sur l'appareil stockera ensuite ces chaînes de certificats, les attribuant aux applications chaque fois qu'une attestation est demandée. Cela peut aller de Google Pay à Pokemon Go.
Cette chaîne exacte de demande de certificat se produira régulièrement à l'expiration des certificats ou à l'épuisement de la fourniture de clés actuelle. Chaque application reçoit une clé d'attestation différente et les clés elles-mêmes changent régulièrement, ce qui garantit la confidentialité. De plus, les serveurs backend de Google sont segmentés de telle sorte que le serveur qui vérifie la clé publique de l'appareil ne voit pas les clés d'attestation jointes. Cela signifie qu'il n'est pas possible pour Google de corréler les clés d'attestation avec l'appareil particulier qui les a demandées.
Les utilisateurs finaux ne remarqueront aucun changement, même si les développeurs doivent faire attention aux points suivants, selon Google.
- Structure de la chaîne de certificats
- En raison de la nature de notre nouvelle infrastructure d'approvisionnement en ligne, la longueur de la chaîne est plus longue qu'auparavant et est susceptible de changer.
- Racine de confiance
- La racine de confiance sera éventuellement mise à jour de la clé RSA actuelle vers une clé ECDSA.
- Abandon de l’attestation RSA
- Toutes les clés générées et attestées par KeyMint seront signées avec une clé ECDSA et la chaîne de certificat correspondante. Auparavant, les clés asymétriques étaient signées par leur algorithme correspondant.
- Certificats de courte durée et clés d'attestation
- Les certificats fournis aux appareils seront généralement valables jusqu'à deux mois avant leur expiration et seront alternés.
Nous avons contacté Google et demandé si cela était pertinent pour Widevine DRM et comment certains utilisateurs de Pixel avaient signalé que leur niveau de DRM avait été dégradé avec un chargeur de démarrage verrouillé. Nous avons également demandé si cela pouvait désormais être distribué sous forme de mise à niveau OTA aux utilisateurs via les services Google Play. Nous ne manquerons pas de mettre à jour cet article si nous recevons une réponse. On ne sait pas clairement quels éléments de la chaîne de confiance actuelle seront affectés ni de quelle manière.
Source: Google