Samsung Knox - Il punto della situazione

Nell’ultimo periodo si è dibattuto molto in merito alle nuove misure di sicurezza introdotte da Samsung. In questo articolo cercherò di fare una panoramica sulla tecnologia Knox, concentrandomi in modo particolare sulle sue conseguenze sull’universo del modding.

Per alcuni dispositivi come il Samsung Galaxy S3, il Samsung Galaxy S4 e il Samsung Galaxy Note 2 Samsung ha recentemente presentato un nuovo sistema di sicurezza, volto ad eliminare quello che spesso viene indicato (soprattutto nei paragoni con iOS) come uno dei punti più critici di Android, ovvero l’esposizione a virus e malware. La ragione che sta alla base di questa implementazione è riconducibile alle crescenti esigenze di sicurezza, avvertite sia in campo privato che, soprattutto, in campo aziendale. Per raggiungere questo obiettivo, il colosso coreano ha optato per una politica di forte chiusura del dispositivo, volta a rendere pressoché impossibile il furto di dati o anche la semplice contaminazione da parte di applicazioni ed estensioni non attendibili. Questo sistema di sicurezza si chiama Samsung Knox e l’ispirazione per questo nome è stata presa dalla riserva militare “Fort Knox”.

A livello di app, Knox si presenta come una sorta di secondo account, accessibile solo ed esclusivamente tramite password, di cui Samsung garantisce un totale isolamento dal profilo principale, grazie ad un sistema di crittografia a 256 bit.

Il conflitto, sorto tra questa tecnologia ed il mondo del modding, nasce dal fatto che un grado di sicurezza così elevato non è raggiungibile attraverso una semplice applicazione, ma richiede invece dei “rinforzi” anche a livello di sistema operativo.

Una prima modifica introdotta da Samsung è l’innalzamento della sicurezza del modello SELinux (ora elevato al suo livello massimo, chiamato “enforcing”). A livello pratico il risultato di questa operazione si traduce in un irrigidimento dei parametri di valutazione di integrità delle applicazioni; in questo modo il sistema (per non rischiare ad esempio di imbattersi in virus) attua un blocco immediato delle richieste di accesso al sistema provenienti da app di terzi che non soddisfano gli standard di sicurezza richiesti.

L’elemento principale su cui ruota l’intera questione è tuttavia l’introduzione di un nuovo bootloader. Data l’importanza rivestita da questo elemento, cercherò di darne una rapida definizione nella speranza di riuscire a rendere più chiaro l’argomento.

Il bootloader è un programma che entra in funzione subito dopo la fase di accensione, ed il suo compito è quello di avviare il sistema operativo; esso dunque non è una prerogativa esclusiva del mondo Android ma è un applicativo presente su tutti i dispositivi dotati di un sistema operativo. Per fare un esempio, nei computer dual boot (con, ad esempio, una partizione con Linux e una con Windows), l’utente ha solitamente a disposizione una interfaccia di scelta del sistema da avviare (Boot Manager), la quale invierà poi la preferenza espressa proprio al bootloader, che, a sua volta, si occuperà di avviare il sistema operativo selezionato.

Anche nel mondo Android esiste una sorta di dual boot, l’unica differenza è che il sistema operativo avviabile è tipicamente uno solo, mentre l’alternativa in fase di boot è rappresentata dalla Recovery Mode.

Il Bootloader è dunque un elemento centrale del dispositivo, e proprio per questo le case produttrici tendono spesso a “bloccarlo” in modo da consentire l’esecuzione dei soli firmware originali (detti anche signed, ovvero dotati di una specifica firma digitale atta a garantirne l’autenticità). Inoltre, per evidenti ragioni di sicurezza, solitamente il bootloader risiede su una partizione “protetta” (cioè non direttamente modificabile dall’utente).

Da questa breve spiegazione, si può capire dunque che lo sblocco del bootloader è fondamentale nel modo del modding in quanto è un passaggio necessario per riuscire ad avviare le Rom modificate, che, altrimenti, non verrebbero lette come valide. È proprio questo processo di sblocco ad invalidare, solitamente, la garanzia dei dispositivi, tuttavia fino ad ora è sempre stato possibile, attraverso Triangle Away, azzerare il counter, riportando così il dispositivo in garanzia.

Samsung Knox inserisce una forma aggiuntiva di controllo chiamata “knox warranty void” (visualizzabile mettendo il dispositivo in download mode) che, in caso di assenza di modifiche, presenta il valore di 0x0, se invece sono state effettuate operazioni di modding, il valore passa immediatamente a 0x1. Il problema è che ad oggi non è conosciuto nessun metodo per riportare questa voce al valore iniziale, una volta ottenuto il valore 1. Lo stesso Chainfire ha espresso opinioni pessimistiche attraverso il proprio profilo G+, manifestando il timore (finora ancora non confermato) che il bootloader possa essere stato integrato con la tecnologia efuse, ovvero un sistema basato su chip non riprogrammabili, che quindi non permetterebbe l’azzeramento della voce incriminata.

Ora che abbiamo inquadrato il problema, occorre specificare che, per il momento, la discussione è molto accesa e che queste innovazioni sono ancora in fase di studio da parte di sviluppatori ed appassionati di modding. Non potendo quindi descrivere ogni aspetto con completezza assoluta, in attesa di futuri sviluppi, ritengo possa essere utile cercare di fare il punto della situazione elencando le certezze più significative che sono attualmente conosciute:

• Il flash tramite Odin di firmware originali DOTATI di tecnologia Knox, NON comporta alcun problema relativamente al Warranty Void;
• Non è possibile effettuare il downgrade del firmware ad una versione, sempre originale, ma senza knox (Odin si blocca ed emette un messaggio di errore);
• La voce “Warranty Void” non è un contatore, ma è un semplice flag (può essere o 0x0 o 0x1);
• Il root del dispositivo causa l’alterazione del Knox Warranty (0x1). Sembrerebbero fare eccezione alcuni metodi specifici di ottenimento dei privilegi di amministratore (ad esempio Root de La Vega), i quali tuttavia sono fortemente criticati per la loro complessità e per la loro scarsa affidabilità;
• Il flash di una rom cucinata o anche solo di una recovery modificata, genera la temuta voce 0x1.

Un elemento che comporta spesso grandi fraintendimenti è la versione del firmware da cui è iniziata l’introduzione della tecnologia Knox. Spesso infatti si identifica (erroneamente) la diffusione del nuovo bootloader con l’installazione del firmware stock 4.3, mentre in realtà l’introduzione è iniziata già in precedenza (per quanto riguarda l’S4, ad esempio, è iniziata con la versione 4.2.2).

L’unico modo per controllare la versione del proprio bootloader consiste nell’avviare il dispositivo in download mode per poi andare a leggere le piccole scritte che compaiono sullo schermo. Il bootloader knox è riconoscibile dalla presenza di due voci specifiche:

• Knox kernel lock
• Knox warranty void

Vecchio Bootloader

A livello pratico, la presenza del nuovo bootloader non pregiudica nulla in termini di operazioni di modding, il problema è principalmente relativo al solo ripristino della garanzia, una volta ottenuto il valore 0x1.

Per concludere questa panoramica, penso sia doveroso riportare che alcuni utenti di XDA, nel raccontare la propria esperienza diretta, hanno accennato all’esistenza di un tool (a detta loro presente nei centri specializzati Samsung), che permetterebbe l’azzeramento della voce Knox Warranty Void. Un altro utente ha inoltre raccontato, sempre in un post su XDA, di avere assistito direttamente non solo al ripristino del valore 0x0, ma anche al ripristino del vecchio bootloader, il tutto in soli 10 minuti.

Queste esperienze, che certo possono lasciare in vita qualche speranza, non devono tuttavia dare false illusioni: ad oggi non c’è ancora nessun metodo per ripristinare il valore 0x0 e, soprattutto, nessuno sviluppatore affidabile ha rilasciato dichiarazioni ufficiali relative alla sua esistenza, almeno fino ad oggi.

Sperando di avere al più presto chiarimenti in merito vi saluto e vi do appuntamento alla prossima!