Introduire la Sécurité Sans les Appareils Basés sur Androïd

Androïd et la sécurité : perspective historique

Lorsque le premier smartphone sous Androïd a été lancé en septembre 2008, son architecture de sécurité a été acclamée par Google comme l’une de ses innovations majeures par rapport aux systèmes d’exploitation des précédents téléphones à puces. Pour citer le site Web d’Androïd : « Un point central dans la conception de l’architecture de sécurité d’Androïd est qu’aucune application, par défaut, n’a la permission d’exécuter des opérations qui pourraient nuire à d’autres applications, au système d’exploitation ou à l’utilisateur ».

Quelques jours après le lancement de ce téléphone, on a découvert une vulnérabilité sévère, qui a été largement rendue publique, dans son logiciel de navigation Web. Le navigateur faisait partie des millions de lignes de code que les concepteurs de Google ont adopté en bloc dans le système sans avoir bien compris son mode de fonctionnement interne ni ses antécédents. En novembre 2008, des hackers ont découvert une faille bien plus sévère dans cet OS, permettant d’installer des programmes arbitraires sur le téléphone. Lamentations de Google : « Nous avions vraiment fait le maximum pour sécuriser Androïd. C’est incontestablement un énorme bug. La raison pour laquelle nous le considérons comme un problème majeur de sécurité est que l’accès au compte ‘root’ sur l’appareil vient à bout du bac à sable des applications. »

Dire que la technologie des smartphones venant de chez Google, Microsoft, Apple et RIM a beaucoup contribué à améliorer notre société serait très en dessous de la vérité. Androïd s’est avéré une excellente plate-forme multimédia, bourrée de petites options sympathiques, et un excellent environnement ouvert qui se prête à l’innovation et à la productivité. Néanmoins, l’incapacité d’Androïd (et d’autres OS généralistes multimédia comme iOS sur lequel des manipulations récentes ont montré qu’aucune plate-forme de smartphone n’est immune) empêche les consommateurs, les entreprises et les fournisseurs d’infrastructures stratégiques d’avoir assez confiance en eux pour déployer des fonctions à sécurité critique sur des smartphones. Le pire est encore que des fournisseurs de services puissent confier aux smartphones des rôles à sûreté critiques sans réaliser le risque qu’ils introduisent.

Pour en voir un exemple, consultez http://www.eetimes.com/electronics-blogs/davek-s-embeddedsecurity-blog/4204921/Smart-phone-security-in-cars.

Pourquoi devrions-nous confier nos identités numériques et notre argent à une technologie incapable de fournir une protection contre des hackers de plus en plus déterminés et sophistiqués ? Nous avons besoin de faire confiance à nos smartphones pour la confirmation d’identité (in-person proofing), l’argent mobile, la télécommande automobile et le traitement d’informations cruciales pour l’entreprise. Mais nous manquons tout simplement de la plate-forme de confiance nécessaire.

Présentation de TrustZone

Une solution technologique à ce dilemme réside dans une fonction souvent méconnue et tristement sous-évaluée dans les microprocesseurs mobiles actuels : ARM TrustZone. TrustZone autorise une forme personnalisée de virtualisation système qui est basée sur l’électronique du processeur. Il consiste en deux zones : une zone « normale » et une zone de « confiance » ou « sécurisée ». Avec TrustZone, le système d’exploitation multimédia (ce que l’utilisateur voit en vérité) tourne dans la zone normale, alors que le logiciel à sécurité critique tourne dans la zone sécurisée (figure 1).

Le logiciel de mode superviseur de la zone sécurisée peut accéder à la mémoire de la zone normale mais l’inverse n’est pas possible. La zone normale agit donc comme une machine virtuelle sous contrôle d’un hyperviseur tournant dans la zone de confiance. Toutefois, à la différence des autres technologies de virtualisation basées sur l’électronique du processeur comme Intel VT, le système d’exploitation invité de la zone normale n’encourt aucun sur débit d’exécution par rapport au fonctionnement sans TrustZone. TrustZone élimine donc l’obstacle de la performance (sans doute le plus important) qui est opposé à l’adoption de la virtualisation système dans les systèmes embarqués à faible puissance.


Figure 1 : Virtualisation basée sur TrustZone
TrustZone est une fonction inhérente aux cœurs de processeurs d’application ARM, qui comprennent ARM1176, Cortex-A5, Cortex-A8, et Cortex-A9. Toutefois, il est à noter que tous les SoC utilisant ces cœurs sont entièrement compatibles avec TrustZone. À charge pour le fabricant de la puce de permettre un partitionnement sécurisé des zones mémoire et des interruptions des périphérique d’E/S dans la composition complexe du SoC. Par ailleurs, le fournisseur de la puce doit impérativement ouvrir la zone sécurisée à des systèmes d’exploitation et applications tiers de confiance. Des exemples de SoC mobiles compatibles avec TrustZone sont l’i.MX53 (Cortex-A8) de Freescale et l’OMAP 4430 (Cortex-A9) de Texas Instruments.

Green Hills Software travaille avec ces fabricants de puces et avec les principaux fournisseurs de processeurs compatibles TrustZone pour offrir un système d’exploitation riche en fonctions mais certifié conforme à la sécurité, ainsi qu’un kit de développement (SDK) pour la création et le déploiement d’applications de confiance basées sur les normes ouvertes pour les appareils mobiles.

Un logiciel pour être digne de confiance devrait comprendre : algorithmes cryptographiques, protocoles de sécurité réseau (comme SSL/TLS) et électronique de mise à la clé, logiciel de gestion des droits numériques (DRM), clavier virtuel pour la saisie des authentifiants d’accès virtuels (virtual path credentials), sous-systèmes de paiement mobile, données d’identité électronique, et tous autres éléments qu’un fournisseur de services, un fabricant d’appareils mobiles, et/ou un fournisseur de SoC juge(nt) nécessaire de protéger de l’environnement utilisateur.

En plus d’améliorer la sécurité, TrustZone peut réduire le coût et le temps de mise sur le marché des appareils mobiles nécessitant une certification pour pouvoir être utilisés dans le secteur bancaire et dans d’autres secteurs sensibles. Avec TrustZone, la banque (ou l’autorité de certification) peut limiter le besoin de certification à la zone sécurisée et éviter ainsi la complexité (sinon inenvisageable) liée à la certification de l’environnement multimédia d’un système d’exploitation.

Il existe deux raisons majeures pour lesquelles un OS certifié à zone sécurisée peut réduire le coût et la durée de la certification. D’abord, l’OS certifié est déjà digne de confiance car les preuves établies durant la conception et le test sont déjà en possession de l’autorité de certification, ce qui évite le coût et le temps que prendrait la certification de la zone sécurisée.

Ensuite, du fait que la zone sécurisée est un cœur ARM logique complet, l’OS sécurisé est en mesure d’utiliser les capacités de partitionnement de son unité de gestion mémoire (MMU) pour subdiviser la zone sécurisée en métazones (figure 2). Par exemple, une banque peut exiger la certification de la métazone cryptographique utilisée pour authentifier et crypter les messages de transaction bancaire, mais elle ne se souciera pas de certifier une métazone de gestion des droits numériques multimédia. Cette dernière, bien qu’essentielle pour l’appareil dans son ensemble, n’est pas utilisée dans les transactions bancaires, et l’OS sécurisé garantit qu’elle ne peut causer aucun ennui.


Figure 2 : Temps et coût réduits de certification grâce à l’utilisation de métazones dans TrustZone
Le noyau de séparation de TrustZone

Le système d’exploitation sécurisé TrustZone met en œuvre un élément nommé noyau de séparation. Celui-ci utilise une architecture de sécurité basée sur les concepts de composants à haute assurance, de stricte isolation, et de flux d’informations contrôlé entre ces composants. Le noyau de séparation est un système d’exploitation temps réel (RTOS) spécialisé conçu pour satisfaire les plus hauts niveaux d’assurance tout en créant un environnement robuste pour héberger tout à la fois des applications généralistes, à sécurité critique, et en temps réel garanti (hard real time).

L’évaluation du niveau d’assurance de sécurité du logiciel est exécutée en utilisant la norme internationale d’évaluation des produits de sécurité de la technologie d’information : Common Criteria (ISO/IEC 15408) ou « critères communs ». Les niveaux d’assurance évalués (EAL) selon ces critères communs vont de 1 à 7. La plupart des produits généralistes, comme Windows, Androïd, VMware, les serveurs Web, pare-feu, etc. répondent tout au plus au niveau 4, qui ne protège que contre « des tentatives involontaires ou occasionnelles de rompre la sécurité d’un système ». Les niveaux 6+/7 correspondent aux hauts niveaux d’assurance. En novembre 2008, la technologie de noyau de séparation INTEGRITY de Green Hills Software est devenue le premier produit logiciel à avoir obtenu un certificat de haut niveau d’assurance Common Criteria. Les conditions requises pour obtenir ce niveau d’assurance sont : contrôles nombreux et rigoureux du processus de développement, preuve mathématique formelle de politique de sécurité, et tests de pénétration de la NSA (National Security Agency) avec plein accès au code source. Cette même technologie de RTOS est largement utilisée dans des systèmes à fiabilité critique telles les applications du contrôle industriel, de l’automobile, du médical, de l’avionique et des télécommunications.

EAL6+ ajoute à Commun Criteria l’appellation « high robustness » (grande robustesse) qui lui a été affectée par le gouvernement américain. High robustness est le niveau de sécurité recommandé pour un système de communications embarqué gérant des informations stratégiques dans un environnement fortement menacé. Si la valeur de ces informations ou le niveau de menace diminue, une solution à robustesse moyenne (EAL4) peut être suffisante.

Noyau de séparation et virtualisation

La virtualisation est la capacité de permettre à des applications à sécurité critique de coexister avec des applications généralistes. Dans certains cas, ces sous-systèmes généralistes sont des systèmes d’exploitation complets « invités » qui s’exécutent dans une machine virtuelle sous contrôle du noyau de séparation. À la différence des hyperviseurs traditionnels, le noyau de séparation peut héberger des applications natives au même titre que des applications invitées. Le strict ordonnancement des ressources et les mécanismes de protection font que la machine virtuelle et les applications qui la constituent ne peuvent impacter l’exécution des applications sensibles.

Le noyau de séparation est le seul logiciel à s’exécuter dans le mode le plus privilégié du processeur (c’est-à-dire le mode superviseur, qui représente l’état sécurisé dans un SoC compatible TrustZone). Le fonctionnement de la virtualisation système dépend des fonctions de virtualisation spécifiques du processeur. De plus en plus, les processeurs embarqués modernes incorporent un mécanisme de virtualisation ou « hardware virtualization » (comme TrustZone) qui permet à la gestion de la machine virtuelle d’être aussi simple et efficace que possible. Par ailleurs, le noyau de séparation peut effectuer une paravirtualisation des systèmes d’exploitation invités qui autorise l’hébergement de multiples invités sur un même SoC compatible TrustZone.

Le noyau de séparation peut assurer une communication interprocessus (IPC) strictement contrôlée entre Androïd et les services sensibles hébergés dans la zone sécurisée. Par exemple, les données Internet Protocol issus du sous-système réseau d’Androïd peuvent être transmises via le « conduit » (pipe) IPC à un sous-système de cryptographie (crypto subsystem) afin d’y être encryptées avant d’être transmises.

En exploitant TrustZone et la virtualisation opérée par le noyau de séparation, il est désormais possible d’incorporer en toute sécurité des fonctions à sécurité critique dans le plus généralistes des environnements logiciels mobiles multimédia ouverts, Androïd.