Sicurezza delle app

Questa pagina descrive vari aspetti della sicurezza delle app.

Elementi delle app

Android fornisce una piattaforma open source e un ambiente app per dispositivi mobili. Il sistema operativo principale è basato sul kernel Linux. Le app per Android sono scritte più spesso nel linguaggio di programmazione Java e vengono eseguite nella macchina virtuale Android Runtime (ART). Tuttavia, le app possono essere scritte anche in codice nativo. Le app vengono installate da un singolo file con l'estensione APK.

I componenti principali per la creazione di app per 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 trasmissioni e fornitori di contenuti descritti di seguito) in un'app. Specifica anche le autorizzazioni richieste.

• Attività:un'attività è, in genere, il codice per una singola attività incentrata sull'utente che utilizza la classe Activity. Un'attività in genere include la visualizzazione di un'interfaccia utente per l'utente, ma non è obbligatorio; alcune attività non visualizzano mai interfacce utente. In genere, una delle attività dell'app è il punto di accesso a un'app.

• Servizi:un servizio è un insieme di codice che viene eseguito in background, in base alla classe Service. Può essere eseguito nel proprio processo o nel contesto del processo di un'altra app. Gli altri componenti si legano a un servizio e richiamano i metodi tramite chiamate di procedura remota. Un esempio di servizio è un lettore multimediale: anche quando l'utente esce dall'interfaccia utente di selezione dei contenuti multimediali, probabilmente intende continuare ad ascoltare la musica. Un servizio mantiene la musica in riproduzione anche quando l'interfaccia utente è stata completata.

• Broadcast receiver: un broadcast receiver è un oggetto della classe BroadcastReceiver. Viene creata un'istanza quando un meccanismo IPC noto come intent, un'istanza della classe Intent, viene emesso dal sistema operativo o da un'altra app. Un'app può registrare un ricevitore per il messaggio di batteria scarica, ad esempio, e modificare il proprio comportamento in base a queste informazioni.

Modello di autorizzazioni Android: accesso alle API protette

Tutte le app su Android vengono eseguite in una sandbox applicazioni. Per impostazione predefinita, un'app per Android può accedere solo a una gamma limitata di risorse di sistema. Il sistema gestisce l'accesso delle app per Android alle risorse che, se utilizzate in modo errato o dannoso, potrebbero influire negativamente sull'esperienza utente, sulla rete o sui dati sul dispositivo.

Queste limitazioni vengono implementate in varie forme. Alcune funzionalità sono limitate da una mancanza intenzionale di API per la funzionalità sensibile (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 con l'isolamento dello spazio di archiviazione per app. In altri casi, le API sensibili sono destinate all'uso da parte di app attendibili e protette tramite un meccanismo di sicurezza noto come autorizzazioni.

Queste API protette includono:

• Funzioni della videocamera
• 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'app deve definire le funzionalità di cui ha bisogno nel 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 chiede all'utente di negare o consentire l'autorizzazione.

Una volta concesse, le autorizzazioni vengono applicate all'app finché è installata. Per evitare confusione tra gli utenti, il sistema non li avvisa di nuovo delle autorizzazioni concesse all'app e le app incluse nel sistema operativo principale o raggruppate da un OEM non richiedono autorizzazioni all'utente. Le autorizzazioni vengono rimosse se un'app viene disinstallata, quindi una successiva reinstallazione comporta nuovamente la visualizzazione delle autorizzazioni.

Nelle impostazioni del dispositivo, gli utenti possono visualizzare le autorizzazioni per le app che hanno installato in precedenza. Gli utenti possono anche disattivare alcune funzionalità a livello globale quando vogliono, ad esempio disattivare il GPS, la radio o il Wi-Fi.

Nel caso in cui un'app tenti di utilizzare una funzionalità protetta che non è stata dichiarata nel manifest dell'app, l'errore di autorizzazione in genere comporta la generazione di un'eccezione di sicurezza per l'app. I controlli delle autorizzazioni API protette vengono applicati al livello più basso possibile per impedire l'elusione. Un esempio di messaggio per l'utente quando un'app viene installata durante la richiesta di accesso alle API protette è mostrato nella Figura 2.

Le autorizzazioni predefinite del sistema sono descritte in Manifest.permission. Le app possono dichiarare le proprie autorizzazioni per l'utilizzo da parte di altre app. Queste autorizzazioni non sono elencate nella posizione sopra indicata.

Quando definisci un'autorizzazione, un attributo protectionLevel indica al sistema in che modo l'utente deve essere informato delle app che richiedono l'autorizzazione o chi è autorizzato a detenere un'autorizzazione. I dettagli sulla creazione e sull'utilizzo delle autorizzazioni specifiche dell'app sono descritti nella lista di controllo della sicurezza.

Alcune funzionalità del dispositivo, come la possibilità di inviare intent di trasmissione SMS, non sono disponibili per le app di terze parti, ma possono essere utilizzate dalle app preinstallate dall'OEM. Queste autorizzazioni utilizzano l'autorizzazione signatureOrSystem.

Come gli utenti comprendono le app di terze parti

Android si impegna a rendere chiaro agli utenti quando interagiscono con app di terze parti e a informarli delle funzionalità di queste app. Prima dell'installazione di qualsiasi app, all'utente viene mostrato un messaggio chiaro sulle diverse autorizzazioni richieste dall'app. Dopo l'installazione, all'utente non viene più chiesto di confermare le autorizzazioni.

Esistono molti motivi per mostrare le autorizzazioni immediatamente prima dell'installazione. È il momento in cui l'utente esamina attivamente le informazioni sull'app, sullo sviluppatore e sulle funzionalità per determinare se corrispondono alle sue esigenze e aspettative. È anche importante che non abbiano ancora stabilito un impegno mentale o finanziario con l'app e che possano confrontarla facilmente con altre app alternative.

Alcune piattaforme utilizzano un approccio diverso per la notifica agli utenti, richiedendo l'autorizzazione all'inizio di ogni sessione o durante l'utilizzo delle app. La visione di Android è quella di consentire agli utenti di passare facilmente da un'app all'altra a loro piacimento. Fornire conferme ogni volta rallenterebbe l'utente e impedirebbe ad Android di offrire un'esperienza utente ottimale. La revisione delle autorizzazioni da parte dell'utente al momento dell'installazione gli offre la possibilità di non installare l'app se non si sente a suo agio.

Inoltre, molti studi sull'interfaccia utente hanno dimostrato che le richieste eccessive all'utente lo inducono a fare clic su Ok in qualsiasi finestra di dialogo visualizzata. Uno degli obiettivi di sicurezza di Android è comunicare in modo efficace all'utente informazioni importanti sulla sicurezza, cosa che non può essere fatta utilizzando finestre di dialogo che l'utente è abituato a ignorare. Presentando le informazioni importanti una sola volta e solo quando è necessario, l'utente ha maggiori probabilità di riflettere su ciò che sta accettando.

Alcune piattaforme scelgono di non mostrare alcuna informazione sulle funzionalità dell'app. Questo approccio impedisce agli utenti di comprendere e discutere facilmente le funzionalità dell'app. Sebbene non sia possibile per tutti gli utenti prendere sempre decisioni pienamente informate, il modello di autorizzazioni Android rende le informazioni sulle app facilmente accessibili a un'ampia gamma di utenti. Ad esempio, le richieste di autorizzazioni impreviste possono spingere gli utenti più esperti a porre domande critiche sul funzionamento dell'app e a condividere le proprie preoccupazioni in luoghi come Google Play, dove sono visibili a tutti gli utenti.

Autorizzazioni durante l'installazione dell'app: Google Traduttore	Autorizzazioni di un'app installata: Gmail

Figura 1. Visualizzazione delle autorizzazioni per le app.

comunicazione tra processi

I processi possono comunicare utilizzando uno qualsiasi dei meccanismi tradizionali di tipo Unix. Alcuni esempi includono il file system, i socket locali o i segnali. Tuttavia, le autorizzazioni Linux rimangono valide.

Android fornisce anche nuovi meccanismi IPC:

• Binder:un meccanismo di chiamata di procedura remota basato sulle funzionalità leggero progettato per prestazioni elevate durante l'esecuzione di chiamate in-process e cross-process. Binder viene implementato utilizzando un driver Linux personalizzato. Per una descrizione della classe, vedi Raccoglitore.

• Servizi:i servizi possono fornire interfacce direttamente accessibili tramite binder. Per una descrizione più dettagliata, vedi Elementi delle app

• Intent:un intent è un semplice oggetto di messaggio che rappresenta un'intenzione di fare qualcosa. Ad esempio, se la tua app vuole visualizzare una pagina web, esprime la sua intenzione di visualizzare l'URL creando un intent e passandolo al sistema. Il sistema individua un altro frammento di codice (in questo caso, il browser) che sa come gestire l'intent e lo esegue. Gli intent possono essere utilizzati anche per trasmettere eventi interessanti (ad esempio una notifica) a livello di sistema. Per una descrizione del corso, vedi Scopo.

• Fornitori di contenuti:un fornitore di contenuti è un archivio di dati che fornisce l'accesso ai dati sul dispositivo; l'esempio classico è il fornitore di contenuti che viene utilizzato per accedere all'elenco dei contatti dell'utente. Un'app può accedere ai dati che altre app hanno esposto con un content provider e un'app può anche definire il proprio content provider per esporre i propri dati. Per una descrizione della classe, vedi ContentProvider.

Sebbene sia possibile implementare l'IPC utilizzando altri meccanismi come i socket di rete o i file scrivibili a livello globale, questi sono i framework IPC di Android consigliati. Gli sviluppatori Android sono invitati a utilizzare le best practice 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 per la rete. La piattaforma Android ha inserito le API sensibili ai costi nell'elenco delle API protette controllate dal sistema operativo. L'utente deve concedere l'autorizzazione esplicita alle app di terze parti che richiedono l'utilizzo di API sensibili ai costi. Queste API includono:

• Telefonia
• SMS/MMS
• Rete/Dati
• Fatturazione in
• Accesso NFC

Android 4.2 aggiunge un ulteriore controllo sull'utilizzo degli SMS. Android mostra una notifica se un'app tenta di inviare SMS a un codice breve che utilizza servizi premium che potrebbero comportare costi aggiuntivi. L'utente può scegliere se consentire all'app 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 scheda SIM, incluso l'accesso alle informazioni personali (contatti) nella memoria della scheda SIM. Inoltre, le app non possono accedere ai comandi AT, in quanto sono gestiti esclusivamente dal livello di interfaccia radio (RIL). La RIL non fornisce API di alto livello per questi comandi.

Informazioni personali

Android ha inserito le API che forniscono l'accesso ai dati utente nel set di API protette. Con il normale utilizzo, i dispositivi Android accumulano anche dati utente all'interno di app di terze parti installate dagli utenti. Le app che scelgono di condividere queste informazioni possono utilizzare i controlli delle autorizzazioni del sistema operativo Android per proteggere i dati dalle app di terze parti.

Figura 2. L'accesso ai dati utente sensibili è disponibile solo tramite API protette.

I fornitori di contenuti di sistema che probabilmente contengono informazioni personali o che consentono l'identificazione personale, come contatti e calendario, sono stati creati con autorizzazioni chiaramente identificate. Questa granularità fornisce all'utente un'indicazione chiara dei tipi di informazioni che potrebbero essere fornite all'app. Durante l'installazione, un'app di terze parti potrebbe richiedere l'autorizzazione ad accedere a queste risorse. Se viene concessa l'autorizzazione, l'app può essere installata e avere accesso ai dati richiesti in qualsiasi momento dopo l'installazione.

Per impostazione predefinita, tutte le app che raccolgono informazioni personali limitano i dati alla sola app specifica. Se un'app sceglie di rendere i dati disponibili ad altre app tramite IPC, l'app 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 app di interagire con l'ambiente circostante, ad esempio fotocamera, microfono o GPS. Affinché un'app di terze parti possa accedere a questi dispositivi, l'utente deve prima concedere esplicitamente l'accesso tramite l'utilizzo delle autorizzazioni del sistema operativo Android. Al momento dell'installazione, il programma di installazione chiede all'utente l'autorizzazione per il sensore in base al nome.

Se un'app vuole conoscere la posizione dell'utente, richiede un'autorizzazione per accedere alla posizione dell'utente. Al momento dell'installazione, il programma di installazione chiede all'utente se l'app può accedere alla sua posizione. In qualsiasi momento, se l'utente non vuole che nessuna app acceda alla sua posizione, può eseguire l'app Impostazioni, andare su Posizione e sicurezza e deselezionare Usa reti wireless e Attiva satelliti GPS. In questo modo vengono disattivati i servizi basati sulla posizione per tutte le app sul dispositivo dell'utente.

Metadati del dispositivo

Android si impegna inoltre a limitare l'accesso ai dati che non sono intrinsecamente sensibili, ma che possono rivelare indirettamente caratteristiche dell'utente, preferenze dell'utente e il modo in cui utilizza un dispositivo.

Per impostazione predefinita, le app non hanno accesso ai log del sistema operativo, alla cronologia del browser, al numero di telefono o alle informazioni di identificazione dell'hardware o della rete. Se un'app richiede l'accesso a queste informazioni durante l'installazione, il programma di installazione chiede all'utente se l'app può accedere alle informazioni. Se l'utente non concede l'accesso, l'app non verrà installata.

Autorità di certificazione

Android include un insieme di autorità di certificazione di sistema installate, che sono attendibili 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 con Android 7.0 e versioni successive hanno 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 CA di Android, la CA deve completare la procedura di inclusione di CA di Mozilla e poi presentare una richiesta di funzionalità per Android ( https://code.google.com/p/android/issues/entry) per far aggiungere la CA al set di CA di Android in Android Open Source Project (AOSP).

Esistono ancora CA specifiche per i dispositivi che non devono 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 invitati a includere le CA private solo nei componenti/app che devono considerare attendibili queste CA. Per maggiori dettagli, vedi Configurazione della sicurezza di rete.

Firma dell'app

La firma del codice consente agli sviluppatori di identificare l'autore dell'app e di aggiornarla senza creare interfacce e autorizzazioni complicate. Ogni app eseguita sulla piattaforma Android deve essere firmata dallo sviluppatore. Le app che tentano di installarsi senza essere firmate vengono rifiutate da Google Play o dal programma di installazione dei pacchetti sul dispositivo Android.

Su Google Play, la firma dell'app colma il divario tra la fiducia che Google ha nei confronti dello sviluppatore e quella che lo sviluppatore ha nei confronti della sua app. Gli sviluppatori sanno che la loro app viene fornita, senza modifiche, al dispositivo Android e possono essere ritenuti responsabili del comportamento della loro app.

Su Android, la firma dell'app è il primo passaggio per inserire un'app nel relativo sandbox dell'app. Il certificato dell'app firmata definisce quale ID utente è associato a quale app; app diverse vengono eseguite con ID utente diversi. La firma dell'app garantisce che un'app non possa accedere a qualsiasi altra app se non tramite IPC ben definito.

Quando un'app (file APK) viene installata su un dispositivo Android, Package Manager verifica che l'APK sia stato firmato correttamente con il certificato incluso nell'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 condivide un UID con gli altri APK firmati in modo simile.

Le app 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 app non devono essere firmate da un'autorità centrale. Al momento Android non esegue la verifica della CA per i certificati delle app.

Le app possono anche dichiarare autorizzazioni di sicurezza a livello di protezione della firma, limitando l'accesso solo alle app firmate con la stessa chiave, mantenendo al contempo UID e sandbox delle applicazioni distinti. Una relazione più stretta con una sandbox delle app condivisa è consentita tramite la funzionalità UID condiviso, in cui due o più app firmate con la stessa chiave dello sviluppatore possono dichiarare un UID condiviso nel manifest.

Verifica app

Android 4.2 e versioni successive supportano la verifica delle app. Gli utenti possono scegliere di attivare Verifica app e far valutare le app da un verificatore di app prima dell'installazione. La verifica app può avvisare l'utente se tenta di installare un'app potenzialmente dannosa; se un'app è particolarmente dannosa, può bloccarne l'installazione.

Gestione dei diritti digitali

La piattaforma Android fornisce un framework DRM (Digital Rights Management) estensibile che consente alle app di gestire i contenuti protetti dai diritti in base ai vincoli della licenza associati ai contenuti. Il framework DRM supporta molti schemi DRM; quali schemi DRM supporta un dispositivo dipende dal produttore del dispositivo.

Il framework DRM Android è implementato in due livelli architetturali (vedi Figura 3):

• Un'API framework DRM, esposta alle app tramite il framework delle app Android e in esecuzione tramite la VM ART per le app standard.

• Un gestore DRM di 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 DRM sulla piattaforma Android.