Mòdul 2: Models de Seguretat i Estàndards
Estàndards internacionals, arquitectura de defensa en capes i mecanismes de protecció del sistema Android.
L'Estàndard OWASP Mobile Application Security (MAS)
Davant la fragmentació de dispositius i fabricants, l'organització OWASP ha creat un marc de referència neutral considerat la "bíblia" per als professionals de la seguretat mòbil. Es divideix en dos pilars complementaris:
📋 MASVS — Verification Standard
Una llista de control de seguretat dividida en àrees crítiques. Defineix què s'ha de protegir:
- MASVS-STORAGE: Protecció de dades sensibles en repòs (base de dades, fitxers).
- MASVS-CRYPTO: Ús correcte de la criptografia industrial (no reinventar la roda).
- MASVS-NETWORK: Seguretat en el trànsit de dades (TLS, certificate pinning).
- MASVS-PLATFORM: Ús segur de les funcions del sistema (permisos, IPC).
- MASVS-CODE: Bones pràctiques en el codi i polítiques d'actualització.
- MASVS-RESILIENCE: Protecció contra enginyeria inversa i manipulació.
🔬 MASTG — Testing Guide
Un conjunt de manuals tècnics que expliquen com testejar cada punt del MASVS usant eines específiques.
- Guies pas a pas per a Android i iOS.
- Eines recomanades: Frida, MobSF, apktool.
- Casos pràctics de vulnerabilitats reals.
- Complement directe al MASVS: cada control té el seu test associat.
Arquitectura i Model de Seguretat d'Android
Android no és un sistema "lliure" pur, sinó un ecosistema complex basat en capes superposades, on cadascuna afegeix una barrera de seguretat addicional. Comprometre una capa no implica comprometre les superiors.
Nucli — Linux Kernel
La base del sistema. Gestiona el hardware (drivers), la memòria, els processos i el control d'energia. Proporciona l'aïllament entre processos a través dels UIDs de Linux.
HAL — Hardware Abstraction Layer
Exposa les funcions del hardware (càmera, Bluetooth, sensors) a les capes superiors mitjançant APIs estandarditzades, sense que l'app hagi de conèixer el maquinari concret.
Android Runtime (ART)
On s'executen les apps. Utilitza màquines virtuals que aïllen el codi de l'aplicació del hardware real, compilant el bytecode a codi natiu en instal·lar l'app (AOT).
Java API Framework
Proporciona les llibreries que usen els desenvolupadors: gestió de finestres, notificacions, gestors de contingut, etc. És la "porta d'entrada" estàndard per accedir al sistema.
La imatge mostra les capes apilades d'Android de baix a dalt: el Kernel Linux al fons gestiona el maquinari; sobre ell, la capa HAL actua d'intermediari amb els sensors i perifèrics; l'ART executa les apps de forma aïllada; i el Java API Framework ofereix les eines als desenvolupadors. Cada capa és una barrera de seguretat independent.
Aïllament o Sandboxing
Un dels pilars fonamentals de la seguretat d'Android és que les aplicacions s'executen en "caixes de sorra" o Sandboxes. Cada app viu en el seu propi món aïllat:
Identitat d'Usuari (UID)
Cada aplicació instal·lada rep un UID (User ID) de Linux únic i independent. Per al kernel, cada app és com un usuari diferent del sistema.
Aïllament de Memòria
Cap aplicació pot accedir a l'espai de memòria d'una altra. Els processos estan completament separats a nivell de kernel.
Emmagatzematge Privat
Cada app té una carpeta de dades exclusiva (/data/data/nom.app/) on
només ella pot llegir i escriure sense permisos especials.
El diagrama representa dues apps corrent en paral·lel. L'App 1 (UID 10000) i l'App 2 (UID 10001) existeixen en espais de memòria completament separats i cadascuna té el seu directori de dades privat. La línia divisòria del kernel impedeix físicament que una app pugui llegir o modificar les dades de l'altra, fins i tot si s'executen al mateix temps.
🔐 Verified Boot
Mecanisme criptogràfic que assegura que el sistema operatiu carregat és l'original del fabricant i no ha estat manipulat. Si detecta modificacions, atura l'arrencada.
🛡️ SELinux
Mòdul de seguretat del kernel que reforça l'aïllament. Defineix regles estrictes de qui pot fer què, impedint que fins i tot processos privilegiats (root) facin operacions no autoritzades.
El Model de Permisos
Android ha evolucionat d'un model rígid a un de dinàmic per protegir millor la privacitat de l'usuari. Gestionar els permisos correctament és una de les mesures de seguretat més importants per a qualsevol app:
⚠️ Permisos Estàtics (Antic)
S'acceptaven tous de cop en instal·lar l'app. L'usuari veia la llista però havia d'acceptar-los tots o cap. Sense control granular ni visibilitat sobre quan s'usaven.
Problema: Una app podia demanar accés al micròfon sense que l'usuari sabés mai quan l'usava realment.
✅ Permisos Dinàmics (Android 6.0+)
L'app demana permís en el moment que necessita la funció. Per exemple, demana accés al micròfon quan es prem el botó de gravar.
Avantatge: Millora la transparència, la seguretat i la confiança de l'usuari. Es pot revocar en qualsevol moment des de Configuració.
La captura mostra el diàleg típic d'Android quan una app sol·licita accés a un recurs sensible (en aquest cas, el micròfon). L'usuari ha d'acceptar o denegar explícitament en el moment en què l'app necessita el permís, no en instal·lar-la. Això dóna control real a l'usuari i permet a Android registrar quines apps accedeixen a cada sensor.
Principi de mínim privilegi
Una app ben dissenyada només demana els permisos que realment necessita. Demanar permisos innecessaris és un senyal d'alarma per als usuaris i pot portar al rebuig de l'app a les botigues oficials.
Integritat i Signatura Digital
Totes les aplicacions Android han d'estar signades digitalment pel desenvolupador. La signatura no serveix per identificar la identitat de la persona, sinó per garantir tres propietats fonamentals:
Integritat
Si algú modifica el codi de l'APK (per exemple, per inserir un virus), la signatura es trenca i el sistema no permetrà la instal·lació.
Autenticació de l'Origen
Garanteix que l'app prové del mateix desenvolupador original. Cap altre actor pot suplantar el publicador legítim.
Actualitzacions Segures
Android només permet actualitzar una app si la nova versió ve signada amb la mateixa clau privada que l'original. Ningú pot publicar una "actualització" maliciosa.
El diagrama mostra dues fases. A l'esquerra, el procés de signatura: el fitxer APK passa per una funció hash (SHA-256) que genera una "empremta digital" única del contingut, que després s'encripta amb la clau privada del desenvolupador per crear la signatura. A la dreta, la verificació: el dispositiu receptor calcula el hash del fitxer rebut i el desencripta amb la clau pública; si coincideixen, la instal·lació és segura.
El flux mostra tot el cicle de vida d'una app publicada: el desenvolupador signa l'APK amb la seva clau privada i la puja a Google Play, que valida i redistribueix l'app. Quan l'usuari la descarrega, el sistema Android verifica automàticament la signatura amb la clau pública abans de permetre la instal·lació. Si en algun punt del camí l'APK ha estat modificada, la verificació falla.
La responsabilitat de la clau privada
És vital que l'empresa desenvolupadora conservi de forma segura la seva clau privada (keystore). Si es perd, no es podran publicar actualitzacions de l'app a Google Play sense canviar el nom del paquet, perdent tots els usuaris i valoracions acumulades.
Encriptació de Dades en Repòs
Android protegeix les dades del disc per evitar que siguin llegides si algú roba el telèfon físicament i intenta accedir-hi sense el PIN. Hi ha hagut dues generacions d'encriptació:
🐌 Full-Disk Encryption (FDE)
Antic (fins Android 5.x): Encripta tot el disc com un únic bloc. Molt lent en l'arrencada i no permet que res funcioni fins que l'usuari introdueix el PIN.
Problema: Les alarmes i les trucades d'emergència no funcionaven fins que es desbloquegessin.
⚡ File-Based Encryption (FBE)
Modern (Android 7.0+): Encripta arxius de forma individual amb claus diferents. Permet el "Direct Boot": funcions bàsiques (alarmes, trucades d'emergència) funcionen abans de posar el PIN, sense comprometre les dades personals.
🔑 Android Keystore System
Per als desenvolupadors, Android proporciona el Keystore System: un magatzem segur on guardar claus criptogràfiques. Les claus es generen i s'emmagatzemen dins d'un entorn d'execució segur (Trusted Execution Environment, TEE), de manera que mai surten del dispositiu en text pla, ni tan sols l'app que les va crear pot extreure-les directament.
- Ús recomanat: Emmagatzemar tokens d'autenticació, claus de xifratge i credencials.
- Mai fer: Guardar contrasenyes o claus en SharedPreferences o en fitxers de text.