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 e vengono eseguite nella macchina virtuale Android Runtime (ART). Tuttavia, le applicazioni possono anche essere scritte in codice nativo. Le applicazioni vengono installate da un singolo 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 fornitori di contenuti descritti di seguito) in un'applicazione. Specifica anche quali autorizzazioni sono necessarie.
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 di un'applicazione.
Servizi : un servizio è un corpo di codice eseguito in background. Può essere eseguito nel proprio processo o nel contesto del processo di un'altra applicazione. Altri componenti si "associano" a un servizio e invocano metodi su di esso tramite chiamate di procedura remota. Un esempio di servizio è un lettore multimediale: anche quando l'utente esce dall'interfaccia utente di selezione multimediale, probabilmente desidera comunque che la musica continui a essere riprodotta. Un servizio mantiene la musica attiva anche quando l'interfaccia utente è stata completata.
Broadcast Receiver : un BroadcastReceiver è un oggetto che viene istanziato quando un meccanismo IPC noto come Intent viene emesso dal sistema operativo o da un'altra applicazione. Un'applicazione può registrare un ricevitore per il messaggio di batteria scarica, ad esempio, e modificare il suo comportamento in base a tale informazione.
Il modello di autorizzazione Android: accesso alle API protette
Tutte le applicazioni su Android vengono eseguite in un'Application Sandbox . Per impostazione predefinita, un'applicazione Android può accedere solo a una gamma limitata di risorse di sistema. Il sistema gestisce l'accesso delle applicazioni Android alle risorse che, se utilizzate in modo errato o dannoso, potrebbero avere un impatto negativo sull'esperienza dell'utente, sulla rete o sui dati sul dispositivo.
Queste restrizioni sono implementate in una varietà di forme diverse. Alcune funzionalità sono limitate da una mancanza intenzionale di API per le funzionalità sensibili (ad esempio non esiste un'API Android per manipolare direttamente la scheda SIM). In alcuni casi, la separazione dei ruoli fornisce una misura di sicurezza, come nel caso dell'isolamento dello storage per applicazione. In altri casi, le API sensibili sono destinate all'utilizzo da parte di applicazioni attendibili 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 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 chiede all'utente di negare o consentire l'autorizzazione.
Una volta concesse, le autorizzazioni vengono applicate all'applicazione finché è installata. Per evitare confusione nell'utente, il sistema non notifica nuovamente all'utente le autorizzazioni concesse all'applicazione e le applicazioni incluse nel sistema operativo principale o fornite in bundle 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.
Nelle impostazioni del dispositivo, gli utenti possono visualizzare le autorizzazioni per le applicazioni installate in precedenza. Gli utenti possono anche disattivare alcune funzionalità a livello globale quando lo desiderano, ad esempio disabilitare GPS, radio o Wi-Fi.
Nel caso in cui un'applicazione tenti di utilizzare una funzionalità protetta che non è stata dichiarata nel manifest dell'applicazione, la mancata autorizzazione comporterà in genere la restituzione di un'eccezione di sicurezza all'applicazione. I controlli delle autorizzazioni API protette vengono applicati al livello più basso possibile per impedire l'elusione. Nella Figura 2 è illustrato un esempio di messaggistica utente quando viene installata un'applicazione durante la richiesta di accesso alle API protette.
Le autorizzazioni predefinite del sistema sono descritte su 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 come 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 delle autorizzazioni specifiche dell'applicazione sono descritti all'indirizzo https://developer.android.com/guide/topics/security/security.html .
Alcune funzionalità del dispositivo, come la possibilità di inviare intenti di trasmissione SMS, non sono disponibili per applicazioni di terze parti, ma 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 chiarire agli utenti quando interagiscono con applicazioni di terze parti e a informare l'utente delle funzionalità 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 nuovamente richiesto di confermare le autorizzazioni.
Esistono molti motivi per mostrare le autorizzazioni immediatamente prima del momento dell'installazione. Questo è il momento in cui l'utente esamina attivamente le informazioni sull'applicazione, sullo sviluppatore e sulla funzionalità per determinare se soddisfa le sue esigenze e aspettative. È anche importante che non abbiano ancora stabilito un impegno mentale o finanziario nei confronti dell'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 facilmente da un'applicazione all'altra a piacimento. Fornire conferme ogni volta rallenterebbe l'utente e impedirebbe ad Android di offrire un'esperienza utente ottimale. 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 all'utente importanti informazioni sulla sicurezza, 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 sono importanti, è più probabile che l'utente pensi a ciò che 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 funzionalità dell'applicazione. Sebbene non sia possibile per tutti gli utenti prendere sempre decisioni pienamente informate, il modello di autorizzazioni di 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 cruciali sulla funzionalità dell'applicazione e a condividere le proprie preoccupazioni in luoghi come Google Play dove sono visibili a tutti gli utenti.
| Autorizzazioni per l'installazione dell'applicazione - Google Translate | 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 o i segnali. Tuttavia, le autorizzazioni Linux continuano ad essere valide.
Android fornisce anche nuovi meccanismi IPC:
Binder : un meccanismo leggero di chiamata di procedura remota basato su funzionalità progettato per prestazioni elevate durante l'esecuzione di chiamate in-process e tra processi. Binder è 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.
Intenti : un intento è un semplice oggetto messaggio che rappresenta un'"intenzione" di fare qualcosa. Ad esempio, se la tua applicazione desidera visualizzare una pagina Web, esprime il suo "Intent" per visualizzare l'URL creando un'istanza di Intent e trasmettendola al sistema. Il sistema individua qualche 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 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 tutti, 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à della sicurezza.
API sensibili ai costi
Un'API sensibile ai costi è qualsiasi funzione che potrebbe generare un costo per l'utente o 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'uso degli SMS. Android fornirà una notifica se un'applicazione tenta di inviare SMS a un codice breve che utilizza servizi premium che potrebbero causare costi aggiuntivi. L'utente può scegliere se consentire all'applicazione di inviare il messaggio oppure 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. Inoltre, le applicazioni non possono accedere ai comandi AT, poiché 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 utente nel set di API protette. Con l'utilizzo normale, i dispositivi Android accumuleranno dati utente anche 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 potrebbe 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.
Per impostazione predefinita, tutte le applicazioni che raccolgono informazioni personali avranno 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 le autorizzazioni al meccanismo IPC imposte 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, deve prima essere esplicitamente fornito l'accesso da parte dell'utente tramite l'uso delle autorizzazioni del sistema operativo Android. Al momento dell'installazione, il programma di installazione richiederà all'utente di richiedere l'autorizzazione per il sensore per nome.
Se un'applicazione desidera 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 alcuna applicazione acceda alla propria posizione, può eseguire l'applicazione "Impostazioni", andare su "Posizione e sicurezza" e deselezionare "Utilizza 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 che potrebbero rivelare indirettamente caratteristiche dell'utente, preferenze dell'utente e 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 dell'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 una serie di autorità di certificazione del sistema installate, affidabili a livello di sistema. Prima di Android 7.0, i produttori di dispositivi potevano modificare il set di CA fornite sui propri dispositivi. Tuttavia, i dispositivi con versione 7.0 e successive avranno un set uniforme di CA di sistema poiché la modifica da parte dei produttori del dispositivo non è più consentita.
Per essere aggiunta come nuova CA pubblica al set stock di Android, la CA deve completare il processo di inclusione della CA di Mozilla e quindi presentare una richiesta di funzionalità contro Android ( https://code.google.com/p/android/issues/entry ) per aggiungere la CA alla CA Android standard impostata nel progetto Android Open Source (AOSP).
Esistono ancora CA specifiche del dispositivo e che non dovrebbero essere incluse nel set principale di CA AOSP, come le CA private degli operatori che potrebbero essere necessarie per accedere in modo sicuro ai componenti dell'infrastruttura dell'operatore, come i gateway SMS/MMS. I produttori di dispositivi sono incoraggiati a includere le CA private solo nei componenti/app che devono fidarsi di queste CA. Per ulteriori dettagli, vedere Configurazione della sicurezza di rete .
Firma dell'applicazione
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 installarsi senza essere firmate vengono rifiutate da Google Play o dal programma di installazione del pacchetto sul dispositivo Android.
Su Google Play, la firma delle applicazioni unisce la fiducia che Google ha nei confronti dello sviluppatore e la fiducia che lo sviluppatore ha nella sua applicazione. Gli sviluppatori sanno che la loro applicazione viene fornita senza modifiche al 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 sandbox dell'applicazione. Il certificato dell'applicazione firmata 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, il Package Manager verifica che l'APK sia stato firmato correttamente 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 applicazioni possono essere firmate da terzi (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 inoltre in grado di dichiarare autorizzazioni di sicurezza al livello di protezione della firma, limitando l'accesso solo alle applicazioni firmate con la stessa chiave mantenendo UID e sandbox dell'applicazione distinti. Una relazione più stretta con una sandbox dell'applicazione 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 loro manifest.
Verifica della domanda
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 dai diritti in base ai vincoli di licenza associati al contenuto. Il framework DRM supporta molti schemi DRM; quali schemi DRM supportati da un dispositivo vengono lasciati al produttore del dispositivo.
Il framework DRM Android è implementato in due livelli architettonici (vedi figura sotto):
Un'API del framework DRM, esposta alle applicazioni tramite il framework delle applicazioni Android e eseguita tramite ART VM per le applicazioni standard.
Un gestore DRM in codice nativo, che implementa il framework DRM ed espone un'interfaccia per plug-in DRM (agenti) per gestire la gestione dei diritti e la decrittografia per vari schemi DRM
Figura 3. Architettura della gestione dei diritti digitali su piattaforma Android