3 FR

Sécurité mobile
Introduction
PhD. Mohammed-Amine KOULALI
m.koulali@ump.ac.ma
1 Sécurité de la plate-forme Android
Low-level System Security
Amorçage vérifié & dm-verity
Système de chiffrement
Full Disk Encryption
Sécurité Android
Sandboxing
SELinux
Multi-utilisateur
Chiffrement
1 Sécurité de la plate-forme Android
Low-level System Security
Amorçage vérifié & dm-verity
Sécurité Android
Sandboxing
SELinux
Multi-utilisateur
Chiffrement
ISSIC4-M1 - Sécurité Android M.-A. KOULALI 10/11/2020 3 / 24
Architecture de la Securité dans Android

Amorçage vérifié (Verified Boot)

Amorcage ou boot : est quand on demarre notre telephone
chaine de confiance stocker physiquement sur telephone sert a dire que le system d'exploitation
n'estpas modifier
● Chaîne de confiance entre le bootloader et l’image système
● Vérification d’intégrité temps réel pour périphériques de type bloc.
– Protection contre les rootkits persistants

● Basée sur l’option Device Mapper verity (dm-verity) du noyau li-
nux.
– Protection effective uniquement si on peut faire confiance au noyau.
● Clés non modifiables gravés dans l’appareil pour vérifier la signa-
ture de la partition de démarrage.
Amorçage vérifié (demarage de telephone)
1 ere etape le demarage
est ce que tel est verouiller
mot pass
entrer correct
dm-verity un module du noyau dont l'amorcage verifier (le demmarage verifier ) est basée sur
Arbre de Merkel
L1 L2 L3 L4 un ensemble de bloc par exemple du image loader(image android apparutau
amorcage ou au demmarage) qui constitut un sugnature si un hacker va modifier un block
le hach racine va changer
la signature du hash racine peuvent nous indiquer si

On hache les blocs pour les blocs sont vrais (vrai android ) ou modifier
les chiffreron les
transformes en bits
dm-verity
Arbre de Merkel
● Les Hashs sont stockées dans un arbre

● La modification d’un bloc quelconque change le hash racine.
● La signature du bloc hash racine peut être vérifié par une clé publi-
la signature
que incorporée dans la partition d’amorçage. du bloc hash
● Par conséquent seule le bloc hash racine doit être vérifiée pour faire confirme si
c'est le vrai
confiance au reste de l’arbre. android qui
est loader
● un bloc racine validée est une confirmation que la partition système
n’a pas été modifiée.
dm-verity
Limitations
● Pour les partitions read-only uniquement

– Les partitions read-write mettent à jour les metadata quand les fichiers
sont lues.
● Efficace pour la partition /system
Présentation
● Système de chiffrement
– Naissance avec Android 3.0
– 4.4: Replacement de PBKDF2 avec scrypt
– 5.0: Stockage Hardware pour les clés
– 7.0: Introduction du chiffrement file-based
● Full Disk Encryption
– Utilise dm-crypt
– Opère à l’échelle du bloc
– Génère une clé déchiffrement disc (disk encryption key (DEK)) aléato-
ire de taille 128 bits.
• < 5.0: Le fichier de la clé est protégé uniquement par le mot de passe de
l’écran de verrouillage
• Actuellement: Le fichier de la clé est stocké sur une puce sécurisée
Full Disk Encryption (FDE)

les cles de chiffrement en + Android 3.0 sont generer âr la methode mot pass (une cle
derive puis cle asymetrique ou AES puis cle symetrique)
● Android 3.0: PBKDF2 avec 2000 itérations, salt aléatoire , SHA-1.

– Attaques par Bruteforce.
● Android 4.0: scrypt KDF au lieu de PBKDF2, fonction de hachage
basée sur Salsa20.
● Android 5.0:
– Support des motifs et du chiffrement sans mot de passe
– Stockage des clés de chiffrement sur hardware avec TEE
FDE
5.0
128 bits gener par moteur aleatoire

par salt
kek : clé asymetrique de chiffrement

de la dek
DEK : clé symetrique de chiffrement

FDE
● la clé de chiffrement de la clé (KEK) est stockée dans la TEE est

requiert les identifiants de l’utilisateur pour y accéder
● La clé de chiffrement du disque (DEK) est utilisée pour chiffrer le
contenu des fichiers en utilisant des clés différentes par fichier
● AES-ECB permet de dérivé la clé de chiffrement de fichier
Architecture Android
les application
qu'on telecharge
nous meme sont
ecrite en
javaseront execute
sur une machine
vertuel appele
dalvik ou android
runtime
L' access des
applicationsinsatelle par
nous memedans le
dalvik au
camerastockage ect
n'est pas codemais fait
par des API des
bibliotaque android
Modèle de sécurité Android

Chaque app contient un uid et un et et une autre couche de securite mac de
systeme d'exploitation linux, UID pour dire que
tel fichier est a proprie a l'application de UID= et gid =
● Sandbox applicatifs
– Discretionary Access Control (DAC): contrôle d’accès basé sur UID,
GID and Mandatory Access Control(MAC) (SELinux type enforcement)
– User IDentifier (UID) par application
● Inter Process Communications (IPC) sécurisées (sockets locales, Bin-
der, intents)
● Les applications s’exécutent avec privilèges réduits.
● Siganture dcu code
– Application packages (APKs)
– OS update packages (OTA packages)
● Permissions: Système et personnalisée (par application)
Sandboxing des applications

Sandboxing : un systeme de securite means qu'au niveau du kernel chaque
application est separee d'une autre application chacune est isolée et chacune est
execute isolé de l'autre
● Android attribut un UID unique pour chaque application
– Séparation des processus
– Sandboxing des applications au niveau du kernel
● Au niveau des processus, la sécurité est renforcée via les mécanis-
mes linux standards (UID, GID)
● Le modèle de sécurité s’étend au code natif et aux applications du
SE
● Les permissions au niveau du système de fichiers permettent la sé-
paration des fichiers et dossiers entre applications
chaque a un GID au but de donnée acces a certain features de l'application ou fichier
auapplication de meme GID (les apps de meme gid ne peuvent pas aacceder au dossiers
d'autres applications)
Sandboxing
Sandboxing
● A l’installation d’une nouvelle application, un nouveau dossier est
crée : /data/data/<Packagename>/
– Exemple :/data/data/com.whatsapp/
● Pour qu’une application puisse accéder au dossier d’une autre ap-
plication elle doivent :
– Avoir le même UID
– Etre signées par le même certificat du développeur
– Explicitement partager l’UID dans AndroidManifest.xml
1 < manifest ⤦
Ç xmlns : android = " http :// schemas . android . com / apk /
res / android "
3 package = " ma . ensao . sse " /data/data/ma.sse
android : sharedUserId = " ma . ensao . sse " >
5 ...
</ manifest >
Security-Enhanced Linux pour Android

SELinux
● Depuis Android 4.3: les périmètres des applications sont définis

avec SELinux
● SELinux propose deux modes différents.
– Dans le mode strict (Enforcing), les accès sont restreints en fonction
des règles SELinux en vigueur sur la machine.
– Le mode permissif (Permissive) peut être considéré comme un mode
de débogage. Les règles SELinux sont interrogées, les erreurs d’accès
sont enregistrées dans les logs, mais l’accès ne sera pas bloqué.
● Depuis Android 5 seul le mode strict est disponible
SELinux
SELinux
Exemple de règles
● Pas de ptrace
● No device node creation
● Pas d’accès à /data/security et /data/misc/keystore
● Pas d’accès à /dev/mem ou /dev/kmem
● Restrictions sur le montage de systèmes de fichiers
● Pas d’accès aux fichiers GPS
● SELinux ne peut pas être désactivé
Multi-utilisateur une meme application peux avoir plusieur utulisateur
● Initialement pour tablets uniquement, depuis Android 5.0 les smartp-

hones supportent le multi-utilisateur.
● Séparation des utilisateurs par UID/GID
● Dossiers de configuration et dossier des applications séparés.
– Dossiers système : /data/system/users/<userID>/
– Dossier d’applications : /data/user/<userID>/<pkgname>/
● Les applications ont des UID différents
– App UID: uid = userId * 10000 + (appId % 10000)
Multi-utilisateur
Types d’utilisateurs
● Utilisateur primaire (propriétaire)

– Contrôle total de l’appareil
● Utilisateur secondaire
– Profile restreint
• Partage les applications avec l’utilisateur primaire
– Profile géré (managed)
• Applications et données séparées mais UI partagée avec l’utilisateur pri-
maire
● Utilisateur invité
– Accès temporaire restreint à l’appareil
Chiffrement
Merci pour votre Attention!

3 FR

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

3 FR

Transféré par

Droits d'auteur :

Formats disponibles

Sécurité mobile

Architecture de la Securité dans Android

Amorçage vérifié (Verified Boot)

– Protection contre les rootkits persistants

Amorçage vérifié (demarage de telephone)

1 ere etape le demarage

est ce que tel est verouiller

la signature du hash racine peuvent nous indiquer si

● Les Hashs sont stockées dans un arbre

● Pour les partitions read-only uniquement

Full Disk Encryption (FDE)

● Android 3.0: PBKDF2 avec 2000 itérations, salt aléatoire , SHA-1.

128 bits gener par moteur aleatoire

kek : clé asymetrique de chiffrement

DEK : clé symetrique de chiffrement

Full Disk Encryption

● la clé de chiffrement de la clé (KEK) est stockée dans la TEE est

Modèle de sécurité Android

Sandboxing des applications

Security-Enhanced Linux pour Android

● Depuis Android 4.3: les périmètres des applications sont définis

Multi-utilisateur une meme application peux avoir plusieur utulisateur

● Initialement pour tablets uniquement, depuis Android 5.0 les smartp-

● Utilisateur primaire (propriétaire)

Vous aimerez peut-être aussi