Politique de sécurité pour Android sensible au contexte 

Télécharger le fichier pdf d’un mémoire de fin d’études

Moyens de communication

Étant donnée cette isolation forte mise-en-place par le noyau, il est indispensable de posséder des mécanismes de communication pour que les applications soient en mesure d’accéder aux fonctionnalités offertes par les services système et les autres applications installées. De plus, ces moyens de communication devront être mis-en-œuvre au moins en partie par le noyau, car la seule surface de communication existante du point de vue d’un processus ainsi isolé est celle des appels systèmes. Ces derniers sont dans un premier temps utilisés par les applications, via la bibliothèque Bionic, pour accéder aux fonctionnalités du noyau, et aux IPC natifs proposés par celui-ci (fichiers partagés, sockets, …). De plus, ceux-ci sont utilisés dans un second temps pour faire transiter les messages des IPC de plus haut niveau, comme ceux du Binder.
Le Binder est le mécanisme de communication privilégié des composants d’An-droid et spécifique à cette plateforme. Il est d’ailleurs référencé sous le nom d’Inter Component Communication (ICC), en lieu et place d’IPC, car il a pour but de faire communiquer les composants des applications entre eux, ainsi qu’avec les services système. En effet, ce moyen d’échange puise sa source dans la volonté de réutilisa-tion inscrite dans la conception d’Android en offrant la possibilité aux applications de partager leurs fonctionnalités. Pour ce faire, le Binder implémente un modèle client-serveur où chaque composant, aussi appelé Binder Node (BN), est capable d’effectuer des Remote Procedure Calls (RPC) ciblant les autres composants du système exposant des services. De plus, les BN clients ne connaissent qu’un seul BN serveur par défaut : celui appartenant au ServiceManager. Ce dernier est ainsi utilisé comme un annuaire répertoriant l’ensemble des services système : lorsqu’il est interrogé par un BN client, il renvoie une référence vers le BN serveur du service recherché.
Plus précisément, le fonctionnement du Binder repose sur un module du noyau Linux assurant la communication inter-processus. Il est accessible depuis l’espace utilisateur à partir de la bibliothèque libbinder qui communique avec le character device associé au module (/dev/binder) via des appels systèmes ioctl. En outre,

Permissions des applications

L’autre point de contrôle des capacités d’une application réside dans le système de permissions. En effet, l’accès aux ressources exposées par les services système et les applications est protégé par des droits d’accès. Il existe ainsi un certain nombre de permissions natives, définies dans l’API Android, et restreignant de manière assez fine l’accès aux ressources matérielles et logicielles fournies par l’API. Il est cependant possible pour les développeurs d’applications d’enrichir celles-ci en créant des permissions personnalisées. Ainsi, ces permissions sont définies selon plusieurs niveaux :
• Les permissions normales pouvant être accordées aux applications sans avoir besoin d’une confirmation de la part de l’utilisateur.
• Les permissions dangereuses, donnant accès à des données sensibles de l’uti-lisateur, ou permettant d’effectuer des actions critiques sur l’appareil.
• Les permissions protégées par signature, dont l’utilisation est réservée aux applications signées par la même clé cryptographique que celle associée à la permission. Ce type de permissions est le plus souvent utilisé par les applica-tions système qui sont signées par une même platform key.
• Les permissions spéciales, relatives à des actions particulièrement sensibles, et requérant une approbation approfondie 8 de l’utilisateur.
Les permissions requises par une application doivent être déclarées dans le ma-nifeste de celle-ci. L’utilisateur est ensuite amené à accorder ces permissions à l’ins-tallation de l’application, ou bien à leur exécution depuis Android 6.0, lorsque l’ap-plication en question nécessite celle-ci pour une de ses fonctionnalités.

Points d’application du modèle de sécurité

Ce système de permissions est ensuite contrôlé dans différentes parties de l’éco-système Android. Premièrement, certaines permissions sont associées à des groupes Linux prédéfinis. Celles-ci sont le plus souvent amenées à restreindre la capacité de créer ou d’accéder à certains objets du noyau, tels que les sockets ou les fichiers. Par exemple, les applications possédant la permission INTERNET sont assignées au groupe inet. Le respect de ces permissions est donc assuré directement par les droits d’accès Linux, qui peuvent être assistés par d’autres composants du noyau comme le paranoid networking. Concernant les permissions relatives à des ressources acces-sibles via le binder, celles-ci sont directement contrôlées par le logiciel responsable de la ressource, que ce soit un service système, un daemon ou une application. En effet, comme il est impossible pour une application source de falsifier son identité à travers ce mécanisme de communication, il est aisé de vérifier les permissions détenues par celles-ci en interrogeant le service système PackageManager. De plus, des vérifications supplémentaires sont effectuées dans AMS afin de vérifier si les permissions nécessaires à l’exécution d’un intent sont respectées.
La sécurité des applications est aussi assurée lors de leur distribution et leur ins-tallation. Chaque application est en effet associée à un identifiant unique, nommé Application ID, renseigné dans le manifeste de celle-ci, et doit être signée par une ou plusieurs signatures cryptographique. Celles-ci sont ensuite vérifiées lors de leur installation et mise à jour. Cela permet ainsi au système de s’assurer que le contenu des applications n’a pas été altéré pendant la phase de distribution, ainsi que de vérifier que les mises à jour sont issues du ou des même(s) développeur(s). Les ap-plications système sont aussi concernées par le système de signature. Ces dernières sont en effet signées par un ensemble de clés générées par la personne en charge de la création de l’image système, c’est-à-dire le constructeur dans la plupart des cas. Le rôle de la signature ne s’arrête pas seulement à ces tâches. En effet, deux applications signées par une même clé cryptographique peuvent bénéficier de trai-tements particuliers. Notamment, elles ont la capacité de faire exception à la règle d’isolation en s’associant à un même UID et en partageant un même processus. De nombreuses applications système utilisent ce mécanisme pour pouvoir partager des ressources facilement. Concernant les applications des utilisateurs, la pratique est plus rare, d’autant plus qu’il est nécessaire de définir un paramètre spécifique dans le manifeste de chaque application concernée dès leur première installation.
Pour plus de détails sur le modèle de sécurité mis en œuvre par le système d’exploitation Android, le lecteur est invité à consulter [Mayrhofer 2019].

Motivations des attaquants et problématique

Après avoir passé en revue l’écosystème Android et son modèle de permissions, nous pouvons légitimement nous poser la question de son adéquation avec les me-naces auxquelles il fait face. La position particulière du smartphone, issue d’une part de sa grande capacité de connectivité, et d’autre part des nombreuses données qu’il héberge ou génère, en fait une cible de choix pour de nombreux attaquants.
Dans nos travaux, l’attaquant considéré peut avoir différents buts. Il peut vou-loir chercher à compromettre la sécurité du smartphone en question ; c’est-à-dire de compromettre l’intégrité, la confidentialité, ou la disponibilité du smartphone ou des objets avec lesquels il est connecté. Le but d’un attaquant peut se manifester de différentes façons. Il peut, par exemple, s’attaquer à l’intégrité ou la disponibilité du smartphone pour générer de l’argent en installant un adware, un malware crypto-mineur ou un ransomware. Il peut aussi en prendre le contrôle pour espionner son utilisateur, ou intégrer l’appareil au sein d’un botnet. De plus, il peut chercher à compromettre l’intégrité physique du smartphone pour nuire à son utilisateur. Du point de vue de la confidentialité, il peut aussi vouloir chercher à voler les données personnelles ou professionnelles présentes sur le smartphone, qu’elles soient stockées sur le système de fichiers de l’appareil ou générées à partir des différents périphé-riques de celui-ci. Les attaquants simplement curieux sont plus concentrés sur des violations de la confidentialité. On peut citer comme exemple les bibliothèques de publicité qui vont mettre en œuvre des techniques de fingerprinting ou de tracking, en se servant des données personnelles des utilisateurs ou des identifiants du smart-phone pour mieux effectuer leurs ciblages publicitaires.
Dans cette thèse, nous avons relevé un manque dans les capacités d’expression du modèle de permission d’Android vis-à-vis de ces menaces. Plus particulièrement, il est impossible de définir un contrôle d’accès dynamique des ressources et actions protégées par les permissions existantes. En effet, une fois qu’une permission est ac-cordée à l’application, les droits d’accès associés peuvent être utilisés quel que soit le contexte d’exécution du smartphone. Or, il existe certaines attaques reposant sur l’utilisation concurrente de ressources système mises à disposition des applications. Par exemple, [Sivakumaran 2018] et [Naveed 2014] ont démontré la possibilité de détourner des communications Bluetooth Low Energy (BLE) et Bluetooth, établies entre une application et un appareil externe, à partir d’une application malveillante hébergée sur le même smartphone. Il est important d’envisager que ce type d’at-taque soit étendu à d’autres types de périphériques. Par ailleurs, les applications exécutées sur un smartphone peuvent être de différents niveaux de criticité. Un uti-lisateur n’a cependant pas la capacité de classifier les applications installées selon le niveau de confiance qu’il leur accorde. Ce problème est d’autant plus important du fait de certaines permissions qui, comme mentionné dans la section 1.2.2, sont par-ticulièrement sensibles et accordent à leur détenteur des capacités supplémentaires de contrôle sur l’appareil. Là encore, il est impossible avec l’implémentation actuelle de restreindre l’usage de ces permissions lorsque les applications les plus critiques, comme les applications bancaires, sont démarrées. Par exemple, l’attaque Cloak and Dagger [Fratantonio 2017] repose sur le détournement de deux de ces permissions étant utilisées pour intercepter et modifier de manière furtive les interactions de l’utilisateur avec une application cible.

Terminologie de la sécurité informatique

Le but de cette section est de faire un état des lieux de la terminologie de la sécurité informatique qui est une composante de la sûreté de fonctionnement. Ensuite une attention plus particulière sera dévolue aux politiques de sécurité et aux termes leur étant associés.

Sûreté de fonctionnement

La sûreté de fonctionnement d’un système informatique est la propriété qui permet à ses utilisateurs de placer une confiance justifiée dans le service qu’il leur délivre [Laprie 1996]. Le service délivré correspond au comportement du système perçu par ses utilisateurs. La sûreté de fonctionnement peut être décomposée selon trois axes principaux : des attributs qui définissent les propriétés assurées, des en-traves précisant les obstacles à surmonter, et des moyens permettant d’assurer la délivrance du service. Ces trois axes sont présentés dans les paragraphes suivants.
Selon les applications auxquelles le système est destiné, l’accent peut être mis sur différentes facettes de la sûreté de fonctionnement. Ainsi la sûreté de fonctionnement peut être vue selon des propriétés différentes mais complémentaires, qui permettent de définir ses attributs :
• Le fait d’être prêt à l’utilisation conduit à la disponibilité.
• La continuité du service conduit à la fiabilité.
• La non-occurrence de conséquences catastrophiques pour l’environnement conduit à la sécurité-innocuité.
• La non-occurrence de divulgations non-autorisées de l’information conduit à la confidentialité.
• La non-occurrence d’altérations inappropriées de l’information conduit à l’intégrité.
• L’aptitude aux réparations et aux évolutions conduit à la maintenabilité.
Ainsi ces attributs permettent, d’une part d’exprimer les propriétés devant être respectées par le système, et d’autre part d’évaluer la qualité du service délivré vis-à-vis de ces propriétés. Les causes du non respect de ces attributs se nomment entraves à la sûreté de fonctionnement. Ces dernières peuvent être de trois types :
• Une défaillance survient lorsque le service délivré dévie de l’accomplissement de la fonction du système.
• Une erreur est la partie de l’état du système qui est susceptible d’entraîner une défaillance.
• Une faute est la cause adjugée ou supposée d’une erreur.
Pour minimiser l’impact de ces entraves sur les attributs retenus d’un système, la sûreté de fonctionnement dispose de méthodes et techniques qui permettent de conforter les utilisateurs quant au bon accomplissement des fonctions du système.
Le développement d’un système sûr de fonctionnement passe donc par l’utilisation combinée de ces méthodes, appelés moyens, pouvant être classée en quatre types :
• La prévention des fautes empêche l’occurrence ou l’introduction de fautes.
• La tolérance aux fautes permet de fournir un service à même de remplir la fonction du système en dépit des fautes.
• L’élimination des fautes réduit la présence (nombre, sévérité) des fautes.
• La prévision des fautes estime la présence, la création et les conséquences des fautes.
Dans la suite de ce mémoire, nous nous intéressons uniquement à la sécurité-immunité qui se définit comme la combinaison des attributs de disponibilité, de confidentialité et d’intégrité.

Sécurité-immunité

La sécurité-immunité (en anglais security) a pour but de protéger un système contre les fautes intentionnelles dues à l’homme, aussi appelées malveillances. Elle s’oppose à la sécurité-innocuité (en anglais safety) dont le domaine d’application concerne la prévention de catastrophes ayant des répercutions sur l’environnement du système. Dans la suite de ce manuscrit, nous emploierons uniquement les termes de sécurité ou de sécurité informatique pour faire référence à la sécurité-immunité.
La sécurité d’un système informatique est intrinsèquement liée à la sécurité des informations qu’il possède. Ainsi, sécuriser un système informatique consiste, d’une part à prévenir les accès et les manipulations illégitimes des informations du système, et d’autre part à garantir les accès et les manipulations légitimes de ces mêmes informations. Toutes opérations vouées à mettre à mal la sécurité d’un système devront ainsi transgresser un certain nombre de règles et de propriétés de sécurité, définies dans le cadre d’une politique de sécurité, qui encadrent l’ensemble des accès et manipulations réalisables par les acteurs du système. Par ailleurs ces propriétés de sécurité sont inhérentes aux trois attributs de la sûreté de fonction-nement qui, lorsqu’ils sont combinés, définissent plus précisément la portée de la sécurité-immunité. Les prochains paragraphes présentent les définitions de ces trois attributs affinées au contexte de la sécurité informatique.

La confidentialité

La confidentialité désigne la propriété d’une information à ne pas être divulguée aux utilisateurs non autorisés à la connaître. Cela implique que le système doit rendre inaccessibles (ou incompréhensibles) les informations aux utilisateurs non autorisés à y accéder. Cette exigence nécessite que le système :
• empêche un utilisateur de consulter directement une information qu’il n’est pas autorisé à connaître.
• empêche un utilisateur qui accède légitimement à une information de la di-vulguer à un utilisateur non autorisé à y accéder.
Dans cette définition, le terme d’information désigne à la fois les données en elles-même, mais aussi les méta-données lui étant associées, c’est-à-dire toutes les données indirectes résultantes de la création, de la transmission et de la manipulation de cette information. On peut illustrer ceci en prenant l’exemple de la protection de la vie-privée (en anglais privacy), attribut de la sécurité-immunité dérivé de la confidentialité. En effet, cet attribut se rapporte directement à la confidentialité des informations à caractère privé (données personnelles) et de leurs méta-données (identité de l’auteur des informations, données temporelles et localisation …).

L’intégrité

L’intégrité désigne la propriété d’une information à ne pas être corrompue ou altérée par un utilisateur non autorisé. Cela implique que le système doit :
• rendre impossible l’altération (création, modification ou destruction) d’une information par un utilisateur non autorisé à effectuer ce type d’opération sur l’information en question.
• faire en sorte qu’aucun utilisateur ne puisse empêcher les utilisateurs autorisés à légitimement modifier une information.

La disponibilité

La disponibilité désigne la propriété d’une information à rester accessible lors-qu’un utilisateur autorisé en a besoin. Cela implique que le système doit :
• fournir un moyen d’accès à l’information pour les utilisateurs autorisés.
• faire en sorte qu’aucun utilisateur ne puisse effectuer de rétentions d’infor-mations auprès des utilisateurs autorisés.

Fautes malveillantes et mesures de sécurité

Toutefois, les violations d’un ou plusieurs de ces attributs peuvent être à la fois dues à des malveillances ou à des fautes non intentionnelles dues à l’homme. Cependant dans ces travaux nous nous concentrons exclusivement sur les fautes malveillantes.
Les fautes intentionnelles, ou malveillances, se déclinent en deux classes princi-pales : les logiques malignes et les intrusions. Les logiques malignes sont des fautes internes intentionnelles, qui sont conçues pour provoquer des dégâts (bombes lo-giques) ou pour faciliter les futures intrusions par l’ajout de vulnérabilités. Elles peuvent être introduites dans le système, soit avant sa mise en service (par un concepteur malveillant), soit durant son exploitation à la suite de l’installation d’un cheval de Troie ou d’une intrusion. Le deuxième type de malveillance, l’intrusion, est intrinsèquement lié aux concepts d’attaque et de vulnérabilité :
• Une attaque est une faute d’interaction externe dont le but est de violer un ou plusieurs attributs de sécurité du système. Une attaque résulte obligatoirement d’une volonté de nuire, même si celle-ci est lancée depuis des outils automatiques. Une tentative d’intrusion en est un synonyme.
• Une vulnérabilité est une faute accidentelle ou intentionnelle (avec ou sans volonté de nuire) placée dans les exigences, la spécification, la conception ou la configuration du système, ou dans la manière dont il est utilisé.
• Une intrusion est une faute malveillante interne d’origine externe, résultant d’une attaque qui a réussi à exploiter une vulnérabilité. Elle peut-être ame-née à produire des erreurs pouvant provoquer une défaillance vis-à-vis de la sécurité-immunité, c’est-à-dire une violation de la politique de sécurité du système.
Pour faire face à l’ensemble de ces entraves menaçant la sécurité d’un système informatique, il existe de nombreux moyens pouvant être mis en place dont le but étant, bien entendu, de fournir une protection envers ces menaces. L’objectif de cette protection est double : elle vise d’une part à empêcher les opérations non autorisées dans un système, et d’autre part à limiter la propagation des erreurs dans ce système. Nous pouvons citer par exemple, les mécanismes cryptographiques, les méthodes d’isolation ou de cloisonnement, ainsi que d’autres techniques de tolérance et détection d’intrusions. Dans nos travaux, nous avons choisi de nous concentrer sur les politiques de sécurité.

Politiques de sécurité

La politique de sécurité d’un système est garante du respect des propriétés de sécurité que l’on souhaite assurer pour celui-ci. De plus, elle est aussi chargée de définir la façon dont ces propriétés seront garanties. Plus précisément, les IT-SEC [European Commission 1992] définissent une politique de sécurité comme étant
« l’ensemble des lois, règles et pratiques qui régissent la façon dont l’information sensible et les autres ressources sont gérées, protégées et distribuées à l’intérieur d’un système spécifique ». Il existe trois types de politiques de sécurité dont les secteurs d’applications diffèrent :
• Les politiques de sécurité physique qui s’attardent sur la situation physique du système (vol, catastrophes naturelles, …).
• Les politiques de sécurité administrative qui traitent des considérations de sécurité organisationnelle au sein d’entreprises.
• Les politiques de sécurité logique font référence à la gestion du contrôle d’accès logique des systèmes informatiques. Elles doivent spécifier qui a accès à quoi et dans quelles circonstances. C’est à ce dernier type de politique que nous allons nous intéresser.

Politiques de sécurité logique

Une politique de sécurité logique peut être décomposée en trois sous-parties qui représentent les différentes étapes dont un utilisateur doit s’acquitter pour pouvoir accéder à une information du système. Tout d’abord, un utilisateur devra décliner son identité (identification) et prouver qu’il est bien la personne qu’il prétend être (authentification). Une fois ces deux processus effectués, la liste des actions légi-times que cet utilisateur peut réaliser est définie dans la politique d’autorisation. Cette politique d’autorisation implémente ainsi l’intégralité des contrôles d’accès du système qui peuvent être conceptuellement séparés en deux branches.
D’une part, un ensemble de propriétés de sécurité à satisfaire. Celles-ci portent sur la confidentialité, l’intégrité et la disponibilité, et stipulent de multiples contraintes sur ces propriétés. Par exemple « une information classifiée ne doit pas être transmise à un utilisateur non habilité à la connaître ». D’autre part, un en-semble de règles décrivant les opérations autorisées, interdites ou obligatoires pour tous les acteurs du système, et ce conformément aux propriétés de sécurité établies. Par exemple, « le propriétaire d’une information peut accorder un droit d’accès pour cette information à n’importe quel utilisateur ». L’ensemble de ces règles forme un schéma d’autorisation.
Ainsi, si la politique d’autorisation est cohérente, il ne doit pas être possible, partant d’un état initial sûr (c’est-à-dire satisfaisant les propriétés de sécurité), d’atteindre un état d’insécurité (c’est-à-dire un état où les propriétés de sécurité ne sont pas satisfaites) en appliquant le schéma d’autorisation.
Les politiques de sécurité reposent habituellement sur les notions de sujets, d’objets et de droits d’accès, qui sont notamment utilisés pour définir l’ensemble des règles qui la composent. Un sujet est classiquement défini comme une entité active, correspondant à un processus qui s’exécute pour le compte d’un utilisa-teur. Dans ce contexte, un utilisateur est une personne physique ou morale connue du système informatique et enregistrée comme utilisateur. Un objet est une entité considérée comme « passive » qui contient ou reçoit des informations (données ou méta-données). Ainsi, un sujet a un droit d’accès sur un objet si et seulement si le processus correspondant au sujet est autorisé à exécuter l’opération correspon-dant à ce type d’accès sur cet objet. Cette décision d’autorisation est déterminée par la synthèse des règles (autorisations, interdictions, obligations) de la politique d’autorisation.

Types de schéma d’autorisation

Les politiques de sécurité, ou plus précisément leurs schémas d’autorisation, se classent en deux grandes catégories : les politiques discrétionnaires (nommées DAC pour Discretionary Access Control) et les politiques obligatoires (nommées MAC pour Mandatory Access Control).
Dans le cas d’une politique discrétionnaire, les droits d’accès à chaque infor-mation sont manipulés librement par le responsable de l’information (généralement le propriétaire), à sa discrétion. La gestion des droits d’accès aux fichiers des sys-tèmes d’exploitation UNIX constitue un exemple d’implémentation de politique discrétionnaire, où les utilisateurs peuvent gérer les droits d’accès (lecture, écriture, exécution) des fichiers leur appartenant. Plus précisément, le propriétaire d’un fi- chier peut librement attribuer ou non ces droits d’accès à lui-même, un groupe d’utilisateurs, et aux autres utilisateurs. Un des problèmes des politiques discrétion-naires est que celles-ci ne sont applicables que s’il est possible de faire entièrement confiance aux utilisateurs et aux sujets qui s’exécutent pour leur compte. Celles-ci sont en effet sensibles aux fuites d’informations (un utilisateur qui a le droit de lire une information peut, en général, la retransmettre à n’importe qui) ainsi qu’aux abus de pouvoirs (un cheval de Troie peut modifier les droits d’accès des fichiers de l’utilisateur pour lequel il s’exécute).
Pour répondre à ces problèmes, les politiques discrétionnaires peuvent être uti-lisées conjointement à des politiques obligatoires qui imposent, par leur schéma d’autorisation, des règles incontournables qui viennent s’ajouter aux règles discré-tionnaires. Une politique obligatoire suppose que les utilisateurs et objets aient été étiquetés. Un exemple classique de politique obligatoire est celle du DoD (Depart-ment of Defense), formalisée par Bell et La Padula. Dans celle-ci, chaque objet se voit attribuer une classification représentant la sensibilité de l’information conte-nue, et chaque utilisateur est assigné à une attribution symbolisant son habilitation d’accès aux informations sensibles. En outre, les règles obligatoires définies dans le schéma d’autorisation permettent de valider les propriétés de confidentialité empê-chant notamment un sujet ne possédant pas l’habilitation nécessaire à l’accès à une information sensible.
Il existe également des variantes de ces politiques étudiées pour répondre à des besoins particuliers, comme les politiques obligatoires basées sur la notion de rôles (nommées RBAC pour Role-Based Access Control) visant à faciliter l’administra-tion de la sécurité. Un rôle représente de façon abstraite une fonction identifiée dans l’organisation (par exemple, chef de service, ingénieur d’étude, etc.). À chaque rôle, on associe des permissions (ou privilèges) définissant l’ensemble des droits néces-saires à la réalisation des tâches de chaque rôle. Ainsi les permissions ne sont plus associées d’une façon directe aux sujets, mais à travers des rôles. De plus, un sujet peut être membre de plusieurs rôles et inversement, un rôle peut être exécuté par plusieurs sujets. En outre, les autorisations de ces rôles peuvent être héritées via une hiérarchie de rôles.
D’autres efforts plus récents ont vu naître une autre variante de politiques de sé-curité étant basées sur la notion d’attributs (nommées ABAC pour Attribute-Based Access Control) [Hu 2014]. Plus précisément, les accès du système sont accordés ou refusés en fonction des attributs du sujet, des attributs de l’objet auquel il cherche à accéder, des conditions environnementales, et d’un ensemble de règles conditionnées à partir de ces informations. Cette politique de sécurité peut être discrétionnaire ou obligatoire en fonction de son implémentation. De plus, on note l’apparition de la notion de contexte, qui désigne ici un ensemble de caractéristiques environ-nementales étant indépendantes des sujets ou des objets du système. De manière plus générale, les politiques de sécurité se basant sur l’utilisation du contexte sont regroupés sous l’appellation de politiques sensibles au contexte, ou CAAC pour Context-Aware Access Control.

Mécanismes de contrôle d’accès et moniteur de référence

Pour faire appliquer la politique d’autorisation telle quelle a été conçue, un système a besoin d’implémenter un ensemble de solutions techniques adaptées, que l’on peut aussi appeler mécanismes d’isolation.
Ces mécanismes peuvent être destinés à créer une isolation forte entre plusieurs éléments d’un système. Ainsi, les sujets ne peuvent accéder aux objets dont ils ne possèdent pas les droits d’accès, car l’accès physique ou logique à ces objets ne leur est pas possible. Ce type d’isolation s’appuie sur des mécanismes de cloisonnement, dont le but est de couper les accès aux ressources en question, ou de chiffrement, dont l’isolation est rendue effective par l’inintelligibilité des données appartenant aux ressources.
Une autre famille de mécanismes repose sur l’interception et la médiation de l’ensemble des communications du système. Le ou les composants matériels ou logiciels chargés de cette interception sont appelés moniteur de référence. Ainsi, le but de ce moniteur de référence est d’appliquer les règles de contrôle d’accès de la po-litique d’autorisation. Pour ce faire, un moniteur de référence doit obligatoirement posséder les trois propriétés suivantes :
• Il doit être inviolable, c’est-à-dire qu’il ne doit pas être possible de modi-fier le comportement d’un moniteur de référence lorsque le système est en fonctionnement.
• Il doit être toujours invoqué, c’est-à-dire qu’il ne doit pas être possible pour un sujet d’accéder à un objet du système sans que l’accès ne soit contrôlé par le moniteur de référence.
• Il doit être vérifié correct, c’est-à-dire qu’il doit être suffisamment simple pour être analysé et vérifié.
En outre, le contrôle d’accès implémenté dans ce moniteur de référence peut prendre plusieurs formes. Tout d’abord on retrouve les mécanismes de filtrage dont le fonctionnement peut se rapprocher de celui d’un pare-feu réseau (à états ou non). Par ailleurs, il existe des mécanismes de contrôle de flux dont le but est de suivre la manipulation et le transit de l’information à travers la teinte des données issues des objets ou le suivi de leur utilisation. L’état de l’art des mécanismes d’isolation pour l’environnement Android est détaillé dans la section suivante.

Mécanismes de contrôle d’accès pour Android

Dans cette section, sont présentés les mécanismes d’isolation de l’état de l’art ciblant particulièrement l’environnement Android. Pour observer plus facilement les différences entre cette multitude de solutions, celles-ci sont classifiées en fonction du niveau de privilège du logiciel les hébergeant.

Mécanismes de niveau système

Tout d’abord, certains mécanismes de l’état de l’art prennent place dans les couches logicielles les plus privilégiées, et peuvent par ailleurs exploiter des méca-nismes d’isolation fournis par le matériel. Plus précisément, l’ensemble des travaux déployant ce type de mécanisme d’isolation de « niveau système » sont souvent implémentés au sein d’un hyperviseur, bénéficiant ainsi d’un niveau de privilège supérieur à celui du noyau, et des mécanismes d’isolation matériels offerts par le mode d’exécution EL2 1 [Averlant 2017a].
On peut distinguer deux types de solutions de niveau système :
• Celles s’attachant à l’isolation entre deux environnements d’usages différents, où plusieurs instances d’Android s’exécutent de manière concomitante sur le smartphone.
• Celles dédiées à un environnement n’étant composé que d’un seul système d’exploitation, et dont le but est de fournir des solutions de sécurité pour celui-ci.

Isolation entre deux environnements

Le premier type de solution est notamment référencé dans les travaux ciblant le cas du BYOD. Par exemple, dans les travaux de Lengyel et al. [Lengyel 2014], l’isolation entre plusieurs instances d’Android est assurée par l’hyperviseur Xen. Les différentes instances d’Android sont ainsi lancées dans des machines virtuelles, isolées les unes des autres. Il ne peut y avoir qu’une seule machine virtuelle active dans ce cas, car chacune nécessite l’utilisation des périphériques d’entrées/sorties du smartphone, qui sont virtualisées par l’hyperviseur. L’utilisateur est ensuite capable d’effectuer la transition entre les machines virtuelles à l’aide d’un bouton physique. En outre, des opérations d’introspection sont effectuées par l’hyperviseur sur les dif-férentes instances d’Android lancées sous son contrôle. Ces introspections ont pour but, d’une part de vérifier l’intégrité des instances Android via l’analyse statique des pages mémoire des machines virtuelles, et la reconstruction des données de haut niveau qu’elles contiennent pour leur analyse et, d’autre part de vérifier l’exécution d’instructions ou routines sensibles via le détournement de l’exécution des OS An-droid guests dans l’hyperviseur. L’intégrité de l’hyperviseur est par ailleurs vérifiée par un logiciel s’exécutant dans TrustZone, ainsi que par l’utilisation des Xen Secu-rity Modules, et par la bonne configuration de l’Input–Output Memory Management Unit (IO-MMU).
Une autre approche à ce type de solution concerne l’exécution sécurisée et isolée de code critique. Les moyens mis en œuvre reposent à nouveau sur un hyperviseur bare-metal [Cho 2016] ou sur un logiciel s’exécutant dans TrustZone [Sun 2015]. Dans les deux cas, le code critique n’est en aucun cas accessible par le système Android, mais peut cependant communiquer avec celui-ci par le biais d’APIs spé-cifiques.

Sécurisation d’un système d’exploitation

Concernant le deuxième type de solution, l’hyperviseur est cette fois-ci utilisé, non pas pour héberger de multiples systèmes d’exploitation, mais pour contrôler l’exécution d’une seule instance d’Android de par sa position privilégiée. C’est par exemple le cas des travaux menés par Horsch et al. [Horsch 2015] qui présentent un hyperviseur bare-metal capable de tracer ou d’intercepter et contrôler le flux d’information en provenance du noyau ou de l’espace utilisateur. Pour ce faire, l’hyperviseur joue sur la configuration des droits d’accès des pages de la MMU associées à la mémoire accessible depuis le noyau ou l’espace utilisateur. Ainsi, il est capable de suivre à la trace, de manière assez fidèle, le flux d’exécution des logiciels moins privilégiés, et peut de cette manière intercepter les flux non autorisés.
Un autre exemple d’utilisation d’hyperviseur est employé par Shen et al. [Shen 2018]. Celui-ci, appelé TinyVisor, propose la mise en place d’une intercep-tion des appels systèmes du noyau Linux (avant et après leur exécution) afin de protéger l’intégrité et la confidentialité des transactions du Binder. Là encore cette interception repose sur l’instrumentation dynamique du système d’exploitation An-droid virtualisé.

Table des matières

1 Contexte général, mobilité et écosystème Android 
1.1 Smartphone et mobilité
1.1.1 Matériel embarqué
1.2 L’écosystème Android
1.2.1 Panorama des couches logicielles
1.2.2 Modèle de sécurité existant
1.3 Motivations des attaquants et problématique
1.4 Conclusion
2 État de l’art 
2.1 Terminologie de la sécurité informatique
2.1.1 Sûreté de fonctionnement
2.1.2 Sécurité-immunité
2.1.3 Politiques de sécurité
2.2 Mécanismes de contrôle d’accès pour Android
2.2.1 Mécanismes de niveau système
2.2.2 Mécanismes de niveau OS
2.2.3 Mécanismes de niveau framework
2.2.4 Mécanismes de niveau applicatif
2.3 Politiques d’autorisation pour Android
2.3.1 Considérations relatives à l’environnement Android
2.3.2 Politiques d’autorisation de la littérature
2.4 Conclusion et démarche scientifique
3 Politique de sécurité pour Android sensible au contexte 
3.1 Présentation, objectifs et modèle d’attaque
3.1.1 Objectifs de la solution
3.1.2 Objets considérés par la politique
3.1.3 Types de règles de contrôle d’accès
3.1.4 Contexte nécessaire à l’application des règles
3.1.5 Modèle et scénarios d’attaque
3.2 Format, exemples et distribution
3.2.1 Format des règles de sécurité : le Secure Manifest
3.2.2 Exemples d’utilisation
3.2.3 Distribution des Secure Manifest
3.3 Les conflits et leur gestion
3.3.1 Définition et objectifs de la gestion des conflits
3.3.2 Aspects pratiques
3.3.3 Aspects ergonomiques
3.3.4 Améliorations possibles
3.4 Encourager l’utilisateur à paramétrer la politique
3.5 Conclusion
4 Architecture de sécurité multi-niveau 
4.1 Besoins et contraintes techniques de notre politique
4.1.1 Contrôle d’accès et contexte
4.1.2 Protections contre le modèle d’attaque envisagé
4.1.3 Un moniteur de référence multi-niveau
4.2 Présentation de l’architecture
4.2.1 Aperçu des composants et caractéristiques
4.2.2 Détails des composants
4.3 Mise en oeuvre de la politique
4.3.1 Récupération des Secure Manifest
4.3.2 Génération, activation et mise en application des règles
4.3.3 Gestion des conflits et expérience utilisateur
4.4 Contrôle de l’intégrité de notre solution
4.4.1 Périmètre de la protection
4.4.2 Protection contre les attaques logicielles
4.4.3 Protection contre les attaques matérielles
4.4.4 Protection au démarrage et chaîne de confiance
4.5 Conclusion
5 Prototype et performances 
5.1 Plateformes d’expérimentation
5.1.1 La plateforme de développement 96Boards hikey
5.1.2 L’émulateur Android
5.2 Implémentation
5.2.1 AOSP, base logicielle d’Android
5.2.2 Implémentation du PDA
5.2.3 Implémentation du PHS
5.2.4 Implémentation du SCIH
5.2.5 Implémentation de l’IH
5.2.6 Limitations du prototype
5.3 Mesures de performances
5.3.1 Performances des actions atomiques de notre prototype
5.3.2 Microbenchmarks
5.3.3 Macrobenchmarks
5.4 Validation par scénario
5.4.1 Scénario n°1
5.4.2 Scénario n°2
5.4.3 Mise en relation avec les attaques récentes
5.5 Conclusion
Conclusion 
A Exemples de code
A.1 Modification des droits en écriture d’une page de la MMU pour l’architecture ARMv8
A.2 Introspection de la mémoire du driver du binder
A.3 Makefile de l’IH
A.4 Point d’entrée de l’IH
Bibliographie 

Télécharger le rapport complet