La sécurité sous Android

La sécurité sous Android

Comme mentionné précédemment, le système Android est une plateforme open source où les applications sont publiées sur différents marchés sans être surveillées ou analysées pour conserver leur comportement. A ce titre, les mécanismes de protection de la plateforme Android sont utilisés au lieu de ceux du marché (Kim, Yoon, Yi, & Shin, 2012).

Protection par bacs à sable

Le modèle d’application Android garantit aux développeurs un ensemble complet de fonctionnalités et un environnement relativement sécurisé, particulièrement, pour les applications simples. Chaque application sous Android est  » bacs à sable  » dans son propre processus et l’espace du système de fichiers (Schiefer, 2014). Profitant des mécanismes de protection de l’espace de processus du noyau Linux, Android affecte à chaque application installée un ID utilisateur unique. A l’opposé des systèmes d’exploitation de bureau traditionnels (Linux, Windows, Mac, etc.), Android utilise généralement le concept de l’ID utilisateur pour représenter une application plutôt qu’un utilisateur humain. Cela permet au noyau de garder les applications confinées en mémoire, de restreindre d’une part l’accès au matériel ou aux services sous jacents et d’autre part l’accès au système de fichiers sur le périphérique. Par défaut, les données et ressources de chaque application sont hébergées dans un emplacement auquel seuls l’application et le Framework de base peuvent accéder : une conception essentielle pour le modèle de sécurité Android.

Les applications les plus avancées deviennent courantes, ces applications communiquent entre elles ou avec des appareils / serveurs via des réseaux.

Globalement, lors de l’installation des applications Android, chaque application recevra un identifiant utilisateur unique (UID). Le noyau Linux est responsable de l’application du contrôle d’accès aux ressources du système. Aucune application dès lors, ne pourra accéder aux fichiers d’autres applications. Par ailleurs, chaque application est exécutée dans des machines virtuelles distinctes. Ainsi, aucune application vulnérable n’affectera d’autres applications (Karmakar, 2012)

Le modèle des permissions 

Android protège les APIs sensibles en leur attribuant des autorisations afin d’amplifier les privilèges des applications sur l’appareil, y compris l’accès aux données et services stockés, tels que réseau, mémoire, etc. Toutes les autorisations requises pour accéder aux API sont protégées dans le fichier manifeste de chaque application (AndroidManifest.xml). Ils sont définies nécessairement par les développeurs d’application Android.

Les Permissions dans Android sont divisées en groupes d’autorisations organisées qui sont liées aux fonctionnalités d’un périphérique . Sous ce système, les demandes d’autorisation sont gérées au niveau du groupe et un seul groupe d’autorisations correspond à plusieurs déclarations d’autorisations dans le manifeste de l’application. Prenant à titre d’exemple, le groupe SMS qui inclut à la fois les déclarations READ_SMS et RECEIVE_SMS (Google , 2017).

Les permissions Android sont classées en quatre niveaux de protection :
• Permissions de protection normale : Les autorisations normales concernent les APIs dans lesquelles l’application doit accéder à des données ou des ressources en dehors du sandbox de l’application. Cependant, les risques pour la vie privée de l’utilisateur ou le fonctionnement des autres applications est très limité. Par exemple, l’autorisation de définir le fuseau horaire est une autorisation normale. Si une application déclare qu’elle a besoin de cette autorisation, le système accorde automatiquement l’autorisation à l’application.

Lire sur cLicours.com :  Développement Mobile utiliser Google map dans votre application

• Permissions dangereuses : Les permissions dangereuses concernent des domaines dans lesquels l’application cherche à disposer des données ou des ressources qui impliquent des informations privées de l’utilisateur. Ils peuvent aussi affecter les données stockées de l’utilisateur ou le fonctionnement d’autres applications. La possibilité de déceler les contacts de l’utilisateur est par exemple une autorisation dangereuse. Si une application signale qu’elle a besoin d’une autorisation dangereuse, l’utilisateur doit accorder explicitement l’autorisation à l’application.

Table des matières

INTRODUCTION
CHAPITRE 1 SÉCURITÉ SOUS ANDROID
1.1 Introduction
1.2 Le Plateforme Android
1.3 La machine Dalvik
1.4 Les Applications Android
1.5 Les vulnérabilités du système Android
1.6 Les Malwares sur le système Android
1.7 La sécurité sous Android
1.7.1 Protection par bacs à sable
1.7.2 Le modèle des permissions
1.7.3 Le système de permission d’Android Marshmallow
1.8 Récriture des applications Android
1.8.1 La Programmation orientée aspect (AOP)
1.8.2 Le langage Smali
1.9 Les langages de spécifications des politiques
1.9.1 XACML (eXtensible Access Control MarkupLanguage)
1.9.2 UMA (User-Managed Access)
1.10 Conclusion
CHAPITRE 2 REVUE DE LITTÉRATURE
2.1 Introduction
2.2 Détection de divulgation d’informations privées
2.2.1 Attaques des logiciels malveillants
2.2.2 Détection de logiciels malveillants
2.2.3 Détection du reconditionnement des applications
2.3 Atténuation de divulgation d’informations privées
2.3.1 Modification de la plateforme d’Android
2.3.2 Récriture des applications Android
2.4 Discussion
2.5 Conclusion
CHAPITRE 3 ARCHITECTURE ET IMPLÉMENTATION
3.1 Introduction
3.2 Solution proposée
3.3 Langage de politiques de sécurité de contrôle d’accès APSL
3.3.1 Les politiques de sécurité
3.3.2 Les contextes
3.3.3 Les conditions
3.3.4 Conception du langage des politiques de sécurité APSL
3.3.5 Détermination du point de décision de politique avec APSL
3.4 Architecture de la solution proposée
3.4.1 Présentation générale de l’architecture
3.4.2 Demande des autorisations en cours d’exécution
3.4.3 L’interception des décisions de contrôle
3.5 Réécriture des applications
3.6 Contrôleur centralisé des applications
3.6.1 La création textuelle des politiques de sécurités
3.6.2 Sauvegarde des politiques de sécurité
3.6.3 Partager des politiques
3.7 Conclusion
CHAPITRE 4 TEST ET EXPÉRIMENTATIONS
4.1 Introduction
4.2 Réécriture des applications
4.2.1 Temps d’exécution du contrôle des autorisations
4.2.2 Taille des applications
4.3 Contrôleur d’applications
4.3.1 Temps d’exécution de décision de politique
4.3.2 Taille des politiques
4.4 Discussion
CONCLUSION

Cours gratuitTélécharger le document complet

 

Télécharger aussi :

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée.