Sicurezza delle app

Elementi delle app

Android fornisce una piattaforma e un ambiente app open source per i dispositivi mobili. Il sistema operativo di base è basato sul kernel Linux. Le app Android sono spesso scritte 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 estensione APK.

I componenti principali delle 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, broadcast receiver e fornitori di contenuti descritti di seguito) di un'app. Inoltre, specifica quali autorizzazioni sono richieste.

  • Attività: un'attività è in genere il codice di 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 costituisce il punto di contatto con l'app.

  • Servizi: un servizio è un insieme di codice che viene eseguito in background. Può essere eseguita nel suo processo o nel contesto del processo di un'altra app. Altri componenti si "associano" a un servizio e invocano i relativi metodi tramite chiamate di procedura remota. Un esempio di servizio è un media player: anche quando l'utente esce dall'interfaccia utente di selezione dei contenuti multimediali, probabilmente intende comunque continuare a riprodurre la musica. Un servizio mantiene la musica in riproduzione anche al termine dell'interfaccia utente.

  • 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 app. Un'app può registrare un ricevitore per il messaggio di batteria in esaurimento, ad esempio, e modificare il proprio comportamento in base a queste informazioni.

Modello di autorizzazione 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 un numero limitato 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 sono implementate in vari modi. 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 avviene con l'isolamento dello spazio di archiviazione per app. In altri casi, le API sensibili sono destinate all'utilizzo 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 file manifest. Tutte le versioni di Android 6.0 e successive utilizzano un modello di autorizzazioni di runtime. Se un utente richiede una funzionalità di un'app che richiede un'API protetta, il sistema mostra 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, il sistema non informa nuovamente l'utente delle autorizzazioni concesse all'app e le app incluse nel sistema operativo di base o in bundle con un OEM non richiedono autorizzazioni all'utente. Le autorizzazioni vengono rimosse se un'app viene disinstallata, pertanto una successiva reinstallazione comporta di nuovo 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, ad esempio disattivare il GPS, la radio o il Wi-Fi.

Se un'app tenta di utilizzare una funzionalità protetta che non è stata dichiarata nel file manifest dell'app, l'errore di autorizzazione solitamente comporta il lancio di un'eccezione di sicurezza nell'app. I controlli delle autorizzazioni delle API protette vengono applicati al livello più basso possibile per impedire il loro aggiramento. Un esempio di messaggistica per l'utente quando viene installata un'app mentre viene richiesto l'accesso ad API protette è mostrato nella Figura 2.

Le autorizzazioni predefinite di sistema sono descritte all'indirizzo https://developer.android.com/reference/android/Manifest.permission.html. 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 viene definita un'autorizzazione, un attributo protectionLevel indica al sistema in che modo informare l'utente delle app che richiedono l'autorizzazione o chi è autorizzato a detenere un'autorizzazione. I dettagli sulla creazione e sull'utilizzo delle autorizzazioni specifiche per le app sono descritti all'indirizzo https://developer.android.com/guide/topics/security/security.html.

Esistono alcune funzionalità del dispositivo, come la possibilità di inviare intent di trasmissione di SMS, che non sono disponibili per le app di terze parti, ma che 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 chiarire 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. Si tratta del momento in cui l'utente esamina attivamente le informazioni sull'app, sullo sviluppatore e sulla funzionalità per stabilire se corrispondono alle sue esigenze e aspettative. È inoltre importante che non abbiano ancora stabilito un impegno mentale o finanziario nei confronti dell'app e che possano confrontare facilmente l'app con altre app alternative.

Altre piattaforme utilizzano un approccio diverso alla notifica all'utente, richiedendo l'autorizzazione all'inizio di ogni sessione o mentre le app sono in uso. La visione di Android è consentire agli utenti di passare facilmente da un'app all'altra. Fornire conferme ogni volta rallenterebbe l'utente e impedirebbe ad Android di offrire un'esperienza utente eccezionale. Se l'utente esamina le autorizzazioni al momento dell'installazione, ha la possibilità di non installare l'app se non si sente a suo agio.

Inoltre, molti studi sull'interfaccia utente hanno dimostrato che se si chiede troppo all'utente, quest'ultimo inizia a rispondere "Ok" a qualsiasi finestra di dialogo visualizzata. Uno degli scopi della sicurezza di Android è comunicare efficacemente all'utente informazioni importanti sulla sicurezza, cosa che non è possibile fare utilizzando finestre di dialogo che l'utente imparerà a ignorare. Se le informazioni importanti vengono presentate una sola volta e solo quando sono importanti, l'utente è più propenso a riflettere su cosa sta accettando.

Alcune piattaforme scelgono di non mostrare alcuna informazione sulla funzionalità delle app. Questo approccio impedisce agli utenti di comprendere e discutere facilmente delle funzionalità dell'app. Sebbene non sia possibile per tutti gli utenti prendere sempre decisioni pienamente informate, il modello di autorizzazioni di Android rende le informazioni sulle app facilmente accessibili a una vasta gamma di utenti. Ad esempio, le richieste di autorizzazioni impreviste possono indurre gli utenti più esperti a porre domande fondamentali sulla funzionalità dell'app e a condividere i loro dubbi in luoghi come Google Play, dove sono visibili a tutti gli utenti.

Autorizzazioni all'installazione dell'app - Google Traduttore Autorizzazioni di un'app installata: Gmail
Autorizzazioni all'installazione dell'applicazione - Google Traduttore Autorizzazioni di un'applicazione installata: Gmail

Figura 1. Visualizzazione delle autorizzazioni per le app

Comunicazione tra processi

I processi possono comunicare utilizzando uno qualsiasi dei meccanismi di tipo UNIX tradizionali. Alcuni esempi sono il file system, le socket locali o gli indicatori. Tuttavia, le autorizzazioni Linux rimangono valide.

Android fornisce anche nuovi meccanismi IPC:

  • Binder: un meccanismo di chiamata di procedura remota basato su funzionalità leggero, progettato per prestazioni elevate durante l'esecuzione di chiamate in-process e tra processi. Binder 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 direttamente accessibili utilizzando il binder.

  • Intent: un Intent è un semplice oggetto 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'istanza di Intent e passandola 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. Vedi https://developer.android.com/reference/android/content/Intent.html.

  • ContentProvider: un ContentProvider è un magazzino di dati che fornisce accesso ai dati sul dispositivo. L'esempio classico è il ContentProvider utilizzato per accedere all'elenco di contatti dell'utente. Un'app può accedere ai dati esposti da altre app tramite un ContentProvider e 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 l'IPC utilizzando altri meccanismi come socket di rete o file con accesso di scrittura per tutti, questi sono i framework IPC Android consigliati. Gli sviluppatori Android saranno incoraggiati a utilizzare le best practice per proteggere i dati degli utenti ed evitare l'introduzione di vulnerabilità di sicurezza.

API sensibili ai costi

Un'API sensibile al costo è qualsiasi funzione che potrebbe generare un costo per l'utente o per la rete. La piattaforma Android ha inserito le API sensibili al costo nell'elenco delle API protette controllate dal sistema operativo. L'utente dovrà concedere l'autorizzazione esplicita alle app di terze parti che richiedono l'utilizzo di API sensibili al costo. Queste API includono:

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

Android 4.2 aggiunge un ulteriore controllo sull'utilizzo degli SMS. Android invierà una notifica se un'app tenta di inviare un SMS a un codice corto che utilizza servizi premium che potrebbero comportare costi aggiuntivi. L'utente può scegliere se consentire o bloccare l'invio del messaggio da parte dell'app.

Accesso alla scheda SIM

L'accesso a 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 Radio Interface Layer (RIL). RIL non fornisce API di alto livello per questi comandi.

Informazioni personali

Android ha inserito le API che forniscono l'accesso ai dati utente nell'insieme di API protette. Con un utilizzo normale, i dispositivi Android accumulano anche i dati degli utenti 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.

Accesso ai dati utente sensibili disponibili solo tramite API protette

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 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 possono essere fornite all'app. Durante l'installazione, un'app di terze parti potrebbe richiedere l'autorizzazione per accedere a queste risorse. Se l'autorizzazione viene concessa, l'app può essere installata e avrà accesso ai dati richiesti in qualsiasi momento.

Per impostazione predefinita, tutte le app che raccolgono informazioni personali hanno questi dati limitati solo all'app specifica. Se un'app sceglie di rendere disponibili i dati ad altre app tramite IPC, l'app che concede l'accesso può applicare le autorizzazioni al meccanismo IPC applicate dal sistema operativo.

Dispositivi di immissione di dati sensibili

I dispositivi Android forniscono spesso dispositivi di inserimento di dati sensibili che consentono alle app di interagire con l'ambiente circostante, ad esempio la fotocamera, il microfono o il GPS. Affinché un'app di terze parti possa accedere a questi dispositivi, deve prima essere fornito esplicitamente l'accesso dall'utente tramite l'utilizzo delle autorizzazioni del sistema operativo Android. Al momento dell'installazione, il programma di installazione chiederà all'utente di autorizzare il sensore per 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 a "Posizione e sicurezza" e deselezionare "Usa reti wireless" e "Attiva i satelliti GPS". Verranno disabilitati 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 potrebbero rivelare indirettamente caratteristiche dell'utente, le sue preferenze 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 hardware / di rete. Se un'app richiede l'accesso a queste informazioni al momento dell'installazione, il programma di installazione chiederà 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 considerate 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 versioni 7.0 e 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 Android, la CA deve completare la procedura di inclusione della CA di Mozilla e poi inviare una richiesta di funzionalità per Android ( https://code.google.com/p/android/issues/entry) per richiedere l'aggiunta della CA al set di CA di Android nell'Android Open Source Project (AOSP).

Esistono ancora CA specifiche per il dispositivo che non devono essere incluse nell'insieme di base delle CA AOSP, come le CA private degli operatori che potrebbero essere necessarie per accedere in sicurezza ai componenti dell'infrastruttura dell'operatore, ad esempio i gateway SMS/MMS. I produttori di dispositivi sono invitati a includere le CA private solo nei componenti/nelle app che devono considerarle attendibili. Per maggiori dettagli, consulta 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 del pacchetto sul dispositivo Android.

Su Google Play, la firma dell'app colma il divario di fiducia tra Google e lo sviluppatore e tra lo sviluppatore e la sua app. Gli sviluppatori sanno che la loro app viene fornita non modificata sul 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 nella relativa sandbox. Il certificato dell'app firmato 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 nessun'altra app, tranne tramite IPC ben definiti.

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 al suo interno) corrisponde alla chiave utilizzata per firmare qualsiasi altro APK sul dispositivo, il nuovo APK ha la possibilità di specificare nel file manifest che condividerà un UID con gli altri APK firmati in modo simile.

Le app possono essere firmate da terze parti (OEM, operatore, mercato alternativo) o essere 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 dell'autorità di certificazione per i certificati delle app.

Le app sono inoltre in grado di dichiarare le autorizzazioni di sicurezza a livello di livello di protezione della firma, limitando l'accesso solo alle app firmate con la stessa chiave, mantenendo al contempo UID e sandbox dell'applicazione distinti. È consentito un rapporto più stretto con una sandbox dell'applicazione condivisa tramite la funzionalità UID condiviso, in cui due o più app firmate con la stessa chiave sviluppatore possono dichiarare un UID condiviso nel file manifest.

Verifica app

Android 4.2 e versioni successive supportano la verifica dell'app. Gli utenti possono scegliere di attivare "Verifica app" e di far valutare le app da un verificatore di app prima dell'installazione. La verifica delle 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. I schemi DRM supportati da un dispositivo dipendono dal produttore del dispositivo.

Il framework DRM Android è implementato in due livelli di architettura (vedi la figura seguente):

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

  • Un gestore DRM in codice nativo, che implementa il framework DRM e mette a disposizione un'interfaccia per i plug-in DRM (agenti) per gestire la gestione dei diritti e la decrittografia per vari schemi DRM

Architettura della gestione dei diritti digitali sulla piattaforma Android

Figura 3. Architettura del DRM sulla piattaforma Android