====== Model de seguretat d'Android ====== El model de seguretat d'Android és complex i contempla moltes vessants. En aquest article es resumeixen les principals mesures de seguretat que proporciona a nivell de sistema operatiu i a nivell d'aplicació. {{tag> android ciberseguretat #Ciber #CiberMp03 #Ceti #CetiMp03 #Dam #DamMp08 #DamMp08Uf01 #DamMp08Uf01 }} \\ ===== Seguretat del sistema operatiu ===== El nucli d'Android es basa en branques de suport a llarg termini (LTS) del nucli Linux. En conseqüència, la seguretat d'Android es fonamenta en les següents funcions clau de seguretat del nucli de Linux: * Aïllament de processos (//Sandboxing//) * Model de permisos basat en l’usuari * Comunicació entre processos (IPC) \\ ==== Sandboxing ==== La plataforma Android utilitza el model de permisos basat en l’usuari de Linux per aïllar els recursos de les aplicacions. Aquest procés és anomenat //sandbox// de l’aplicació, i té per objectiu evitar que programes externs maliciosos interactuïn amb aplicacions protegides i que les vulnerabilitats exposades per una aplicació no es puguin explotar per accedir al sistema. La protecció basada en l'usuari de Linux garanteix una comunicació segura entre aplicacions. Android utilitza el concepte d'ID d'usuari (UID) per gestionar el control d'accés de les aplicacions, no dels usuaris del sistema. Està prohibit que les aplicacions accedeixin a dades d'altres aplicacions o funcions del sistema sense els permisos necessaris. L'aplicació està aïllada a nivell del nucli, per la qual cosa es garanteix que l'aplicació està aïllada de la resta del sistema. \\ ==== Rooting ==== En un sistema Linux, //root// és el nom del compte que té accés a tots els fitxers i ordres. Com que està basat en Linux, Android també té aquest concepte. Per motius de seguretat, el propietari del dispositiu NO és root, doncs si ho fos les aplicacions malicioses podrien obtenir més fàcilment el control de tot el sistema enganyant els usuaris perquè els concedissin els mateixos permisos. Per superar les limitacions del model sandbox, l'usuari pot fer root al dispositiu. Ara bé, el rooteig no és recomanable, doncs després de rootejar ja no podem confiar en les mesures de seguretat aplicades pel sistema operatiu. A més, el rooteig pot fer que la garantia del dispositiu quedi anul·lada. \\ ==== Verified Boot ==== L’arrencada verificada és un procés que garanteix que el dispositiu arrenqui el sistema operatiu original i el codi del sistema relacionat, en lloc d'una còpia maliciosa. De manera similar a la tecnologia Blockchain, el Verified Boot estableix una cadena de confiança entre els múltiples components que poden ser alterats, començant pel maquinari fins a les particions verificades. Si s'altera algun dels components de la cadena, tota la cadena s'invalida i s'avisa l'usuari. L'arrel de confiança és una clau criptogràfica utilitzada per signar la còpia d'Android que s'executa al dispositiu. Aquesta clau forma part de la verificació d'arrencada. Android ofereix contínuament actualitzacions de seguretat menors juntament amb les principals que venen amb cada nova versió d'Android. Les actualitzacions menors solen "parxejar" les vulnerabilitats descobertes. Un atacant podria intentar rebaixar la versió d'Android que s'executa al dispositiu per explotar les vulnerabilitats aplicades. Aquest tipus d'atacs es mitiga amb la protecció contra retrocessos. Aquesta protecció forma part del procés d'arrencada verificada. \\ ===== Seguretat d'aplicació ===== \\ Els aspectes més rellevants de seguretat a nivell d'aplicació són els següents: \\ ==== Permisos ==== En Android, la privacitat de l’usuari està protegida mitjançant els permisos. Les aplicacions en Android requereixen el consentiment de l’usuari per a realitzar accions que puguin tenir impacte en altres, en el sistema operatiu o en el propi usuari. Els permisos necessaris de cada aplicació estan declarats en el fitxer //AndroidManifest.xml//. Cada permís s’especifica amb la seva pròpia etiqueta //uses-permission//. Alguns permisos es concedeixen a l’aplicació per defecte quan s’especifiquen. Tanmateix, hi ha una categoria de permisos que requereix un consentiment especial de l'usuari, com per exemple l'accés a la càmera o a la geolocalització. Quan una aplicació demana un permís, l'usuari rep un diàleg. Aquests permisos solen sol·licitar-se quan cal la funcionalitat corresponent. Per exemple, s'ha de sol·licitar un permís de càmera abans que l'usuari intenti fer una captura. {{ :android_demanant_permisos_2.png?200 |}}

Android demanant permisos (font: developer.android.com)

\\ ==== Emmagatzematge de dades ==== L’emmagatzematge de dades és, a priori, el camp més sensitiu de la seguretat d’Android, doncs les dades són l’objectiu més important d’un atacant. Android s’ha d’assegurar per tant que cada opció d’emmagatzematge de dades estigui degudament assegurada en funció de la sensibilitat de les dades guardades. Segons la [[https://developer.android.com/training/data-storage?hl=es-419|documentació oficial d'Android sobre emmagatzematge]], hi ha tres maneres de desar les dades al dispositiu: * **Emmagatzematge intern**: Les dades emmagatzemades aquí només són visibles per a l'aplicació corresponent. Altres aplicacions no tenen accés als fitxers emmagatzemats al directori de l'aplicació. Quan l'aplicació es desinstal·la, totes les dades emmagatzemades aquí s'esborren. * **Emmagatzematge extern**: Les dades emmagatzemades a l'emmagatzematge extern són globalment llegibles i escrivibles. Això significa que qualsevol aplicació pot llegir o escriure els fitxers emmagatzemats aquí. Per tant, cal que la informació sensible de l'aplicació s'emmagatzemi a l'emmagatzematge intern, no a l'extern. Cal tindre en compte que la informació guardada da l'emagatzematge extern pot haver estat alterada per altres aplicacions o atacants, i no podem estar segurs que les dades que escrivim prèviament no s'hagin transformat en un codi maliciós de càrrega dinàmica. * **Proveïdors de contingut**: Proporcionen una abstracció sobre les dades emmagatzemades. Amb l’ús de proveïdors de contingut, tenim més control sobre els permisos de lectura i escriptura. Si desenvolupem diverses aplicacions sota la mateixa signatura, podem compartir dades entre elles amb un proveïdor de contingut, de manera que les dades siguin visibles només entre les nostres aplicacions. A més, si volem emmagatzemar persistentment parells clau-valor, podem utilitzar l'API ''SharedPreferences'' proporcionada per Android. Un hàbit comú dels desenvolupadors és emmagatzemar les credencials de l'usuari al ''SharedPreferences''. Per afegir una capa extra de seguretat podem xifrar les dades emmagatzemades. Per xifrar les dades, Android proporciona la llibreria Security que inclou, entre d'altres, dues classes per al xifratge de dades (''EncryptedFile'' i ''EncryptedSharedPreferences'') \\ ==== Comunicació entre processos ==== Els mecanismes IPC (//inter-process communication//) d'Android ens permeten aplicar polítiques de seguretat basades en la relació entre la nostra aplicació i altres processos. Android proporciona les classes següents que faciliten la comunicació entre processos: * ''Intent'' * ''Binder'' * ''Messenger'' Els intents són el mecanisme de pas de dades. Els intents poden ser explícits o implícits. Els explícits estan dissenyats per ser rebuts per un component explícit, per això el seu nom. D'aquesta manera, podem estar segurs que les dades enviades des de l'aplicació A són rebudes únicament per l'aplicació B. A més, els intents explícits poden ser utilitzats per enviar dades entre activitats dins les nostres aplicacions. En canvi, els intents implícits especifiquen una acció que cal fer sense concretar quina altra aplicació ha de fer-la. Solen usar-se quan la nostra aplicació no pot fer una acció i volem delegar-la a una aplicació de tercers. Seria el cas per exemple d'una aplicació que vol obrir un arxiu PDF i envia un intent implícit al sistema operatiu per a que alguna aplicació doni aquest servei. Les classes Binder i Messenger s’usen per a implementar les trucades a procediments remots en Android (//Remote Procedure Call - RPC - //). Proporcionen una interfície que facilita la comunicació segura entre una aplicació i un servei. \\ ==== Signatura d'aplicacions ==== La signatura de codi ofereix als desenvolupadors la possibilitat d'identificar l'autor d'una aplicació i actualitzar-la sense problemes, sense necessitat de processos molestos. Les aplicacions que no estan signades per un desenvolupador no es poden penjar a Google Play. Fins i tot si un paquet d'aplicacions sense signar acaba al dispositiu, l'aplicació no es pot instal·lar perquè el gestor de paquets comprova si el paquet està signat o no abans d'instal·lar qualsevol aplicació. La signatura d'aplicacions és el primer pas del mecanisme de sandbox d'aplicacions. S'assigna un UID basat en el certificat utilitzat per signar l'aplicació. Les aplicacions tenen la capacitat de crear permisos de seguretat protegits per la signatura. Així, les aplicacions signades amb el mateix certificat, sota diferents UIDs i sandboxs d'aplicació, poden accedir a funcionalitats restringides exposades per un o altre. [[https://github.com/dogriffiths/HeadFirstAndroid/wiki/How-Android-Apps-are-Built-and-Run|Aquest article mostra el procés d'empaquetament i signatura de codi de les aplicacions Android]], a més de la posada en marxa per part del sistema operatiu. \\