Elementi di applicazioni
Android fornisce una piattaforma open source e un ambiente applicativo per dispositivi mobili. Il sistema operativo principale è basato sul kernel Linux. Le applicazioni Android sono spesso scritte nel linguaggio di programmazione Java ed eseguite nella macchina virtuale Dalvik. Tuttavia, le applicazioni possono anche essere scritte in codice nativo. Le applicazioni vengono installate da un unico file con estensione .apk.
I principali elementi costitutivi dell'applicazione Android sono:
AndroidManifest.xml : il file AndroidManifest.xml è il file di controllo che indica al sistema cosa fare con tutti i componenti di primo livello (in particolare attività, servizi, ricevitori di trasmissione e provider di contenuti descritti di seguito) in un'applicazione. Questo specifica anche quali autorizzazioni sono richieste.
Attività : un'attività è, generalmente, il codice per una singola attività incentrata sull'utente. Di solito include la visualizzazione di un'interfaccia utente per l'utente, ma non è necessario: alcune attività non visualizzano mai le interfacce utente. In genere, una delle attività dell'applicazione è il punto di ingresso a un'applicazione.
Servizi : un servizio è un corpo di codice che viene eseguito in background. Può essere eseguito nel proprio processo o nel contesto del processo di un'altra applicazione. Altri componenti "si legano" a un servizio e invocano metodi su di esso tramite chiamate di procedure remote. Un esempio di servizio è un lettore multimediale: anche quando l'utente esce dall'interfaccia utente di selezione dei media, è probabile che l'utente desideri continuare a riprodurre la musica. Un servizio mantiene la musica attiva anche quando l'interfaccia utente è stata completata.
Broadcast Receiver : un BroadcastReceiver è un oggetto di cui viene creata un'istanza quando un meccanismo IPC noto come Intento viene emesso dal sistema operativo o da un'altra applicazione. Un'applicazione può, ad esempio, registrare un ricevitore per il messaggio di batteria scarica e modificarne il comportamento in base a tali informazioni.
Il modello di autorizzazione Android: accesso alle API protette
Tutte le applicazioni su Android vengono eseguite in un'applicazione Sandbox . Per impostazione predefinita, un'applicazione Android può accedere solo a un intervallo limitato di risorse di sistema. Il sistema gestisce l'accesso delle applicazioni Android alle risorse che, se utilizzate in modo errato o dannoso, potrebbero influire negativamente sull'esperienza dell'utente, sulla rete o sui dati del dispositivo.
Queste restrizioni sono implementate in una varietà di forme diverse. Alcune funzionalità sono limitate da una mancanza intenzionale di API alla funzionalità sensibile (ad es. non esiste un'API Android per manipolare direttamente la scheda SIM). In alcuni casi, la separazione dei ruoli fornisce una misura di sicurezza, come con l'isolamento dell'archiviazione per applicazione. In altri casi, le API sensibili sono destinate all'uso da parte di applicazioni affidabili e protette tramite un meccanismo di sicurezza noto come Autorizzazioni.
Queste API protette includono:
- Funzioni della fotocamera
- Dati sulla posizione (GPS)
- Funzioni Bluetooth
- Funzioni di telefonia
- Funzioni SMS/MMS
- Connessioni di rete/dati
Queste risorse sono accessibili solo tramite il sistema operativo. Per utilizzare le API protette sul dispositivo, un'applicazione deve definire le funzionalità di cui ha bisogno nel suo manifest. Tutte le versioni di Android 6.0 e successive utilizzano un modello di autorizzazioni di runtime . Se un utente richiede una funzionalità da un'app che richiede un'API protetta, il sistema visualizza una finestra di dialogo che richiede all'utente di negare o consentire l'autorizzazione.
Una volta concesse, le autorizzazioni vengono applicate all'applicazione finché è installata. Per evitare confusione da parte dell'utente, il sistema non notifica nuovamente all'utente le autorizzazioni concesse all'applicazione e le applicazioni incluse nel sistema operativo principale o raggruppate da un OEM non richiedono autorizzazioni all'utente. Le autorizzazioni vengono rimosse se un'applicazione viene disinstallata, quindi una successiva reinstallazione comporterà nuovamente la visualizzazione delle autorizzazioni.
All'interno delle impostazioni del dispositivo, gli utenti possono visualizzare le autorizzazioni per le applicazioni che hanno installato in precedenza. Gli utenti possono anche disattivare alcune funzionalità a livello globale quando lo desiderano, come disabilitare il GPS, la radio o il Wi-Fi.
Nel caso in cui un'applicazione tenti di utilizzare una funzionalità protetta che non è stata dichiarata nel manifest dell'applicazione, l'errore di autorizzazione comporterà in genere un'eccezione di sicurezza restituita all'applicazione. I controlli delle autorizzazioni API protette vengono applicati al livello più basso possibile per prevenire l'elusione. Nella Figura 2 è mostrato un esempio della messaggistica dell'utente quando un'applicazione viene installata mentre si richiede l'accesso alle API protette.
Le autorizzazioni predefinite del sistema sono descritte all'indirizzo https://developer.android.com/reference/android/Manifest.permission.html . Le applicazioni possono dichiarare le proprie autorizzazioni per l'utilizzo da parte di altre applicazioni. Tali autorizzazioni non sono elencate nella posizione sopra.
Quando si definisce un'autorizzazione, un attributo protectionLevel indica al sistema in che modo l'utente deve essere informato delle applicazioni che richiedono l'autorizzazione o chi è autorizzato a detenere un'autorizzazione. I dettagli sulla creazione e l'utilizzo di autorizzazioni specifiche dell'applicazione sono descritti all'indirizzo https://developer.android.com/guide/topics/security/security.html .
Esistono alcune funzionalità del dispositivo, come la possibilità di inviare intenti di trasmissione SMS, che non sono disponibili per applicazioni di terze parti, ma che possono essere utilizzate da applicazioni preinstallate dall'OEM. Queste autorizzazioni utilizzano l'autorizzazione signatureOrSystem.
Come gli utenti comprendono le applicazioni di terze parti
Android si impegna a rendere chiaro agli utenti quando interagiscono con applicazioni di terze parti e a informare l'utente delle capacità di tali applicazioni. Prima dell'installazione di qualsiasi applicazione, all'utente viene mostrato un messaggio chiaro sulle diverse autorizzazioni richieste dall'applicazione. Dopo l'installazione, all'utente non viene più chiesto di confermare le autorizzazioni.
Ci sono molte ragioni per mostrare le autorizzazioni immediatamente prima del tempo di installazione. Questo è quando l'utente sta esaminando attivamente le informazioni sull'applicazione, lo sviluppatore e la funzionalità per determinare se soddisfano le proprie esigenze e aspettative. È anche importante che non abbiano ancora stabilito un impegno mentale o finanziario per l'app e possano facilmente confrontare l'applicazione con altre applicazioni alternative.
Alcune altre piattaforme utilizzano un approccio diverso alla notifica dell'utente, richiedendo l'autorizzazione all'inizio di ogni sessione o mentre le applicazioni sono in uso. La visione di Android è quella di consentire agli utenti di passare senza problemi da un'applicazione all'altra a piacimento. Fornire conferme ogni volta rallenterebbe l'utente e impedirebbe ad Android di offrire un'esperienza utente eccezionale. Avere le autorizzazioni di revisione dell'utente al momento dell'installazione offre all'utente la possibilità di non installare l'applicazione se si sente a disagio.
Inoltre, molti studi sull'interfaccia utente hanno dimostrato che sollecitare eccessivamente l'utente fa sì che l'utente inizi a dire "OK" a qualsiasi finestra di dialogo visualizzata. Uno degli obiettivi di sicurezza di Android è trasmettere in modo efficace importanti informazioni di sicurezza all'utente, cosa che non può essere eseguita utilizzando finestre di dialogo che l'utente sarà addestrato a ignorare. Presentando le informazioni importanti una volta, e solo quando è importante, è più probabile che l'utente pensi a cosa sta accettando.
Alcune piattaforme scelgono di non mostrare alcuna informazione sulla funzionalità dell'applicazione. Questo approccio impedisce agli utenti di comprendere e discutere facilmente le capacità dell'applicazione. Sebbene non sia possibile per tutti gli utenti prendere decisioni sempre pienamente informate, il modello di autorizzazioni Android rende le informazioni sulle applicazioni facilmente accessibili a un'ampia gamma di utenti. Ad esempio, richieste di autorizzazioni impreviste possono indurre gli utenti più sofisticati a porre domande critiche sulla funzionalità dell'applicazione e condividere le proprie preoccupazioni in luoghi come Google Play , dove sono visibili a tutti gli utenti.
| Autorizzazioni all'installazione dell'applicazione -- Google Maps | Autorizzazioni di un'applicazione installata -- Gmail |
 |  |
Figura 1. Visualizzazione delle autorizzazioni per le applicazioni
Comunicazione tra processi
I processi possono comunicare utilizzando uno qualsiasi dei tradizionali meccanismi di tipo UNIX. Gli esempi includono il filesystem, i socket locali oi segnali. Tuttavia, le autorizzazioni Linux sono ancora valide.
Android fornisce anche nuovi meccanismi IPC:
Raccoglitore : un meccanismo di chiamata di procedura remota basato su capacità leggero progettato per prestazioni elevate durante l'esecuzione di chiamate in-process e cross-process. Raccoglitore viene implementato utilizzando un driver Linux personalizzato. Vedi https://developer.android.com/reference/android/os/Binder.html .
Servizi : i servizi (discussi sopra) possono fornire interfacce accessibili direttamente utilizzando il raccoglitore.
Intento : un intento è un semplice oggetto messaggio che rappresenta un'"intenzione" di fare qualcosa. Ad esempio, se l'applicazione desidera visualizzare una pagina Web, esprime il suo "Intento" per visualizzare l'URL creando un'istanza di Intento e consegnandola al sistema. Il sistema individua un altro pezzo di codice (in questo caso, il browser) che sa come gestire quell'intento e lo esegue. Gli intenti possono essere utilizzati anche per trasmettere eventi interessanti (come una notifica) a livello di sistema. Vedi https://developer.android.com/reference/android/content/Intent.html .
ContentProvider : un ContentProvider è un archivio di dati che fornisce l'accesso ai dati sul dispositivo; l'esempio classico è il ContentProvider che viene utilizzato per accedere all'elenco dei contatti dell'utente. Un'applicazione può accedere ai dati che altre applicazioni hanno esposto tramite un ContentProvider e un'applicazione può anche definire i propri ContentProvider per esporre i propri dati. Vedi https://developer.android.com/reference/android/content/ContentProvider.html .
Sebbene sia possibile implementare IPC utilizzando altri meccanismi come socket di rete o file scrivibili da tutto il mondo, questi sono i framework IPC Android consigliati. Gli sviluppatori Android saranno incoraggiati a utilizzare le migliori pratiche per proteggere i dati degli utenti ed evitare l'introduzione di vulnerabilità di sicurezza.
API sensibili ai costi
Un'API sensibile ai costi è qualsiasi funzione che potrebbe generare un costo per l'utente o per la rete. La piattaforma Android ha inserito le API sensibili ai costi nell'elenco delle API protette controllate dal sistema operativo. L'utente dovrà concedere un'autorizzazione esplicita alle applicazioni di terze parti che richiedono l'uso di API sensibili ai costi. Queste API includono:
- Telefonia
- SMS/MMS
- Rete/Dati
- Fatturazione in-app
- Accesso NFC
Android 4.2 aggiunge ulteriore controllo sull'utilizzo degli SMS. Android fornirà una notifica se un'applicazione tenta di inviare SMS a un codice funzione che utilizza servizi premium che potrebbero causare costi aggiuntivi. L'utente può scegliere se consentire all'applicazione di inviare il messaggio o bloccarlo.
Accesso alla scheda SIM
L'accesso di basso livello alla scheda SIM non è disponibile per le app di terze parti. Il sistema operativo gestisce tutte le comunicazioni con la carta SIM compreso l'accesso alle informazioni personali (contatti) sulla memoria della carta SIM. Le applicazioni inoltre non possono accedere ai comandi AT, in quanto questi sono gestiti esclusivamente dal Radio Interface Layer (RIL). Il RIL non fornisce API di alto livello per questi comandi.
Informazione personale
Android ha inserito le API che forniscono l'accesso ai dati degli utenti nel set di API protette. Con il normale utilizzo, i dispositivi Android accumuleranno anche i dati degli utenti all'interno di applicazioni di terze parti installate dagli utenti. Le applicazioni che scelgono di condividere queste informazioni possono utilizzare i controlli delle autorizzazioni del sistema operativo Android per proteggere i dati da applicazioni di terze parti.
Figura 2. L'accesso ai dati utente sensibili è disponibile solo tramite API protette
I fornitori di contenuti di sistema che potrebbero contenere informazioni personali o di identificazione personale come contatti e calendario sono stati creati con autorizzazioni chiaramente identificate. Questa granularità fornisce all'utente una chiara indicazione dei tipi di informazioni che possono essere fornite all'applicazione. Durante l'installazione, un'applicazione di terze parti può richiedere l'autorizzazione per accedere a queste risorse. Se viene concessa l'autorizzazione, l'applicazione può essere installata e avrà accesso ai dati richiesti in qualsiasi momento durante l'installazione.
Tutte le applicazioni che raccolgono informazioni personali avranno, per impostazione predefinita, tali dati limitati solo all'applicazione specifica. Se un'applicazione sceglie di rendere i dati disponibili ad altre applicazioni tramite IPC, l'applicazione che concede l'accesso può applicare autorizzazioni al meccanismo IPC che vengono applicate dal sistema operativo.
Dispositivi di input di dati sensibili
I dispositivi Android forniscono spesso dispositivi di input di dati sensibili che consentono alle applicazioni di interagire con l'ambiente circostante, come fotocamera, microfono o GPS. Affinché un'applicazione di terze parti possa accedere a questi dispositivi, è necessario prima fornire esplicitamente l'accesso dall'utente tramite l'uso delle autorizzazioni del sistema operativo Android. Al momento dell'installazione, l'installatore chiederà all'utente di richiedere l'autorizzazione al sensore per nome.
Se un'applicazione vuole conoscere la posizione dell'utente, l'applicazione richiede un'autorizzazione per accedere alla posizione dell'utente. Al momento dell'installazione, il programma di installazione chiederà all'utente se l'applicazione può accedere alla posizione dell'utente. In qualsiasi momento, se l'utente non desidera che nessuna applicazione acceda alla sua posizione, può eseguire l'applicazione "Impostazioni", andare su "Posizione e sicurezza" e deselezionare "Usa reti wireless" e "Abilita satelliti GPS" . Ciò disabiliterà i servizi basati sulla posizione per tutte le applicazioni sul dispositivo dell'utente.
Metadati del dispositivo
Android si impegna inoltre a limitare l'accesso ai dati che non sono intrinsecamente sensibili, ma possono rivelare indirettamente caratteristiche dell'utente, preferenze dell'utente e il modo in cui utilizza un dispositivo.
Per impostazione predefinita, le applicazioni non hanno accesso ai registri del sistema operativo, alla cronologia del browser, al numero di telefono o alle informazioni di identificazione hardware/rete. Se un'applicazione richiede l'accesso a queste informazioni al momento dell'installazione, il programma di installazione chiederà all'utente se l'applicazione può accedere alle informazioni. Se l'utente non concede l'accesso, l'applicazione non verrà installata.
Autorità di certificazione
Android include un set di Autorità di certificazione di sistema installate, che sono affidabili a livello di sistema. Prima di Android 7.0, i produttori di dispositivi potevano modificare l'insieme di CA fornite sui propri dispositivi. Tuttavia, i dispositivi che eseguono 7.0 e versioni successive avranno un insieme uniforme di CA di sistema poiché la modifica da parte dei produttori di dispositivi non è più consentita.
Per essere aggiunta come nuova CA pubblica al set di azioni Android, la CA deve completare il processo di inclusione della CA di Mozilla e quindi presentare una richiesta di funzionalità su Android ( https://code.google.com/p/android/issues/entry ) per aggiungere la CA alla CA Android di serie impostata nell'Android Open Source Project (AOSP).
Esistono ancora CA che sono specifiche del dispositivo e non dovrebbero essere incluse nel set principale delle CA AOSP, come le CA private dei gestori che potrebbero essere necessarie per accedere in modo sicuro ai componenti dell'infrastruttura del gestore, come i gateway SMS/MMS. I produttori di dispositivi sono incoraggiati a includere le CA private solo nei componenti/app che devono considerare attendibili queste CA. Per maggiori dettagli, vedere Configurazione della sicurezza di rete .
Firma della domanda
La firma del codice consente agli sviluppatori di identificare l'autore dell'applicazione e di aggiornare la propria applicazione senza creare interfacce e autorizzazioni complicate. Ogni applicazione eseguita sulla piattaforma Android deve essere firmata dallo sviluppatore. Le applicazioni che tentano di installare senza essere firmate vengono rifiutate da Google Play o dal programma di installazione del pacchetto sul dispositivo Android.
Su Google Play, la firma dell'applicazione unisce la fiducia che Google ha con lo sviluppatore e la fiducia che lo sviluppatore ha con la sua applicazione. Gli sviluppatori sanno che la loro applicazione è fornita, non modificata, sul dispositivo Android; e gli sviluppatori possono essere ritenuti responsabili del comportamento della loro applicazione.
Su Android, la firma dell'applicazione è il primo passaggio per inserire un'applicazione nella relativa sandbox dell'applicazione. Il certificato dell'applicazione firmato definisce quale ID utente è associato a quale applicazione; applicazioni diverse vengono eseguite con ID utente diversi. La firma dell'applicazione garantisce che un'applicazione non possa accedere a nessun'altra applicazione se non tramite IPC ben definito.
Quando un'applicazione (file APK) viene installata su un dispositivo Android, Package Manager verifica che l'APK sia stato correttamente firmato con il certificato incluso in quell'APK. Se il certificato (o, più precisamente, la chiave pubblica nel certificato) corrisponde alla chiave utilizzata per firmare qualsiasi altro APK sul dispositivo, il nuovo APK ha la possibilità di specificare nel manifest che condividerà un UID con l'altro in modo simile APK firmati.
Le domande possono essere firmate da una terza parte (OEM, operatore, mercato alternativo) o autofirmate. Android fornisce la firma del codice utilizzando certificati autofirmati che gli sviluppatori possono generare senza assistenza o autorizzazione esterna. Le domande non devono essere firmate da un'autorità centrale. Android attualmente non esegue la verifica CA per i certificati delle applicazioni.
Le applicazioni sono anche in grado di dichiarare autorizzazioni di sicurezza a livello di protezione della firma, limitando l'accesso solo alle applicazioni firmate con la stessa chiave mantenendo distinti UID e Sandbox delle applicazioni. Una relazione più stretta con un'applicazione sandbox condivisa è consentita tramite la funzionalità UID condiviso in cui due o più applicazioni firmate con la stessa chiave sviluppatore possono dichiarare un UID condiviso nel proprio manifest.
Verifica dell'applicazione
Android 4.2 e versioni successive supportano la verifica dell'applicazione. Gli utenti possono scegliere di abilitare "Verifica app" e far valutare le applicazioni da un verificatore di applicazioni prima dell'installazione. La verifica delle app può avvisare l'utente se tenta di installare un'app che potrebbe essere dannosa; se un'applicazione è particolarmente dannosa, può bloccare l'installazione .
gestione dei diritti digitali
La piattaforma Android fornisce un framework DRM estensibile che consente alle applicazioni di gestire i contenuti protetti da diritti in base ai vincoli di licenza associati al contenuto. Il framework DRM supporta molti schemi DRM; quali schemi DRM supportati da un dispositivo è lasciato al produttore del dispositivo.
Il framework Android DRM è implementato in due livelli architetturali (vedi figura sotto):
Un'API del framework DRM, che è esposta alle applicazioni tramite il framework dell'applicazione Android e viene eseguita tramite Dalvik VM per le applicazioni standard.
Un gestore DRM del codice nativo, che implementa il framework DRM ed espone un'interfaccia per i plug-in DRM (agenti) per gestire la gestione dei diritti e la decrittografia per vari schemi DRM
Figura 3. Architettura di Digital Rights Management su piattaforma Android