Samsung Knox approuvé par le gouvernement américain pour une utilisation classifiée, mais est-il vraiment sûr ?

Table des matières

• Samsung Knox validé et approuvé pour une utilisation classifiée par le gouvernement américain
• Cela signifie-t-il que Samsung Knox est le moyen le plus sûr de stocker des images / vidéos / documents importants et personnels
• Comment Samsung Knox est vulnérable
• En conclusion, Ares souligne que Samsung Knox n’est pas aussi sécurisé qu’il est prétendu l’être.
• Recommandation d’Ares

Samsung Knox validé et approuvé pour une utilisation classifiée par le gouvernement américain

Samsung Electronics a annoncé que ses solutions ont été approuvées par le gouvernement des États-Unis en tant que premiers appareils mobiles grand public validés par le NIAP pour gérer l’ensemble des informations classifiées. Après avoir complété dix protocoles d’accord (MOA), le gouvernement a ajouté le Galaxy S4, Galaxy S5, Galaxy Note 3, Galaxy Note 4, Galaxy Note 10.1 (édition 2014), Galaxy Note Edge, Galaxy Alpha, Galaxy Tab S 8.4, Galaxy Tab S 10.5 et le client VPN (réseau privé virtuel) Galaxy IPSEC à la liste des composants du programme Commercial Solutions for Classified (CSfC).

Cet accomplissement est le résultat direct des tests et de la certification réussis de Samsung sous les programmes Common Criteria Mobile Device Fundamental Protection Profile (MDFPP) et VPN Protection Profile (VPNPP) du gouvernement américain. Les appareils Samsung répertoriés sont disponibles pour une utilisation avec des réseaux et des données gouvernementaux classifiés. Tous les appareils et capacités intègrent des fonctionnalités de sécurité alimentées par Samsung KNOX.

La propre description de Samsung de son service Knox souligne également les mêmes faits

“Le conteneur KNOX Workspace améliore l’expérience utilisateur, fournissant une sécurité pour les données d’entreprise en créant une zone sécurisée dans l’appareil de l’employé pour les applications d’entreprise, et en chiffrant les données d’entreprise à la fois au repos et en mouvement. Le conteneur KNOX Workspace offre aux utilisateurs un environnement isolé et sécurisé au sein de l’appareil mobile, complet avec son propre écran d’accueil, lanceur, applications et widgets pour une opération plus facile, plus intuitive et plus sûre. Les applications et les données à l’intérieur du conteneur sont séparées.”

La liste des produits approuvés par la DISA peut être trouvée à l’adresse : https://www.disa.mil/Services/Network-Services/UCCO.

Cela signifie-t-il que Samsung Knox est le moyen le plus sûr de stocker des images / vidéos / documents importants et personnels

Avec les violations et les piratages qui se produisent presque tous les jours, un utilisateur court des risques sérieux en sauvegardant des images / documents ou vidéos personnels en ligne dans le cloud. Avec les hacks d’iCloud, il a été prouvé que même les célébrités ne sont pas à l’abri des piratages. Les fuites de SnapChat ont prouvé que les images d’enfants de 13 à 17 ans étaient susceptibles d’être vulnérables à de telles fuites. Les fuites de Dropbox ont prouvé que sauvegarder sur Dropbox comporte également un risque relativement élevé.

Alors que font les utilisateurs avec leurs images et vidéos prises dans ces moments privés ? Avec l’approbation du gouvernement américain pour une utilisation classifiée, Samsung Knox est devenu le premier appareil mobile à être garanti comme sûr contre les pirates, rien de moins que par le Big Sam lui-même.

Avec une capacité de stockage illimitée (jusqu’à 64 Go) à bord de nombreux produits Samsung, vous êtes en sécurité sur l’option d’espace, mais Samsung Knox est-il vraiment le Fort Knox pour stocker vos documents / images et vidéos privées en toute sécurité ? Alors que le gouvernement américain le pense, un chercheur en sécurité, eingestellt par Ares, ne le pense pas.

En fait, Ares a démontré sur son blog pourquoi le Knox de Samsung est vulnérable et assez facilement aussi.

Comment Samsung Knox est vulnérable

Ares a donné un PoC complet sur la vulnérabilité sur son blog, qui est reproduit ici :

Le téléphone Samsung est préinstallé avec deux applications : Knox et Knox EMM. Knox EMM est une solution de gestion basée sur le cloud pour les appareils mobiles qui ne faisait pas partie de cette analyse. L’accent a été mis sur l’application Knox, qui fournit le conteneur Knox et un écran d’accueil séparé (sécurisé) avec ses propres applications. La configuration de Knox est assez facile, vous devez simplement définir un mot de passe et un code PIN pour l’application Knox. En regardant les internes du système, Knox installe pas mal de choses sur votre téléphone. Applications liées à Knox dans /data/data/:
com.samsung.klmsagent
com.samsung.knoxemm.mdm
com.sec.knox.app.container
com.sec.knox.containeragent
com.sec.knox.eventsmanager
com.sec.knox.seandroid
com.sec.knox.store De plus, toutes les applications qui sont installées dans le nouvel écran d’accueil Knox se trouvent dans le dossier d’installation standard des applications /data/data/ et portent le préfixe : com.sec.. Les lister toutes ici serait trop. Après une installation typique de Knox, 139 applications et services sont installés avec le préfixe com.sec.* En regardant un peu plus profondément dans le système, Knox est distribué à travers tout le système et stocke des données à plusieurs emplacements différents, par exemple : le conteneur chiffré lui-même sera stocké dans /data/.container_ et /data/container/.sdcontainer_1. Différents fichiers et bases de données pour les paramètres sont stockés dans /data/system/secure_storage et /data/system/container. Chaque analyse d’une application mobile commence par une analyse statique des fichiers que l’application a stockés après la configuration. Un bon point de départ pour les applications Android est le dossier de l’application sous /data/data/. Ces dossiers ont généralement la structure : com.aPackageName |- cache |- databases |- extracted |- lib |- shared_prefs En particulier, les dossiers databases et shared_prefs sont ceux qui méritent la première attention. L’application ContainerAgent de Knox (com.sec.knox.containeragent) avait quelques fichiers intéressants stockés : Activation.xml ContainerActivator.xml ContainerType.xml CreateSettings.xml DB_BRIDGE_INIT_SYNC.xml DB_BRIDGE_ISCHNDUOS.xml DB_BRIDGE_ONCHANGE_CONTACTS.xml DB_BRIDGE_ONCHANGE_EVENT.xml KLMSLicenseStatus.xml Pref.xml PrivacyPolicy.xml bno.xml com.sec.knox.containeragent_preferences.xml pin.xml Oui, devinez ce qui est écrit dans le fichier pin.xml ? Le code PIN que nous devions définir lors de la configuration de Knox en texte clair ! Maintenant, Samsung Knox donne à un utilisateur un maximum de 20 essais pour le nom d’utilisateur et le mot de passe.*

**

Les autres fichiers n’ont pas révélé d’autres choses intéressantes. Mais revenons au fichier pin.xml. Quel est le but du code PIN dans Knox de toute façon ? Si vous allez démarrer Knox, vous devez fournir votre mot de passe pour accéder aux données et à l’écran d’accueil de Knox. Mais il y a un petit bouton sous le champ de texte appelé “Mot de passe oublié ?”. En appuyant dessus, vous devez fournir votre code PIN. Si le code PIN est correct, l’application Knox vous montrera un petit indice de mot de passe (le premier et le dernier caractère de votre mot de passe !! + la longueur originale de votre mot de passe !). Donc maintenant, il est assez évident que Samsung Knox va stocker votre mot de passe quelque part sur l’appareil ! Comme mentionné ci-dessus, Knox ne stocke pas seulement les paramètres dans /data/data/, dans le dossier /data/system/container, il y a un fichier appelé containerpassword_1.key [sic!] stocké. Le contenu est une chaîne cryptée : 72C9EE6D56CB15916A4CAB01814F978FA1E2689D (j’ai modifié la chaîne pour des raisons évidentes ;)). Donc, cela ressemble à une chaîne chiffrée AES. Maintenant, nous devons décompiler les applications pour avoir un aperçu plus approfondi de la façon dont exactement le chiffrement du mot de passe fonctionne et d’où vient la clé pour le chiffrement. Samsung utilise dex-préoptimisation pour supprimer tous les fichiers classes.dex (le code java est stocké dans un fichier appelé classes.dex et ce fichier est analysé par la Dalvik JVM) dans les apks Knox, rendant ainsi l’ingénierie inverse un peu plus difficile. Pour obtenir les binaires, nous devons regarder dans /system/app/ et trouver des fichiers .odex (un odex est essentiellement une version prétraitée des classes.dex d’une application qui est prête à être exécutée pour Dalvik). Les fichiers odex peuvent être convertis en code smali, qui peut ensuite être reconverti en un fichier dex. Enfin, un fichier dex peut être converti en un fichier jar, qui peut être décompilé par n’importe quel décompilateur Java. Samsung n’a pas utilisé d’obfuscation de code mais a vraiment essayé de cacher le code de stockage du mot de passe dans des centaines de classes java, d’héritages et de proxys. Enfin, dans l’application Knox Store, le proxy IDataService a été implémenté, que toutes les autres applications appelaient constamment lors de la gestion de quelque chose lié au mot de passe. Donc, lors de la sauvegarde du mot de passe, l’application fait ce qui suit :
public boolean setData(String paramAnonymousString) {
this.keyGenInput = DataService.this.mPasswordUtil.getInputForKeyGenerate();
String str = SecureKeyLoader.getKeyForPassword(this.keyGenInput, this.bit_size);
return DataService.this.mEncryptDecrypt.encryptAndSave(paramAnonymousString, str);
}
Jetons un coup d’œil à chaque ligne et aux méthodes correspondantes :
public long getInputForKeyGenerate()
{
return Long.parseLong(SecureKeyLoader.getPartialString(getAndroidID()), 16);
}
private String getAndroidID()
{
return Settings.Secure.getString(this.mContext.getContentResolver(), “android_id”);
}
Donc, l’entrée pour la clé est évidemment l’ID Android unique que chaque appareil possède. La valeur Long de 16 octets analysée est ensuite utilisée comme argument pour la fonction getKeyForPassword :
public class SecureKeyLoader
{
static
{
System.loadLibrary(“mealy”);
}
public static native String getKeyForPassword(long paramLong, int paramInt);
public static native String getPartialString(String paramString);
} Ok, Samsung l’obscurcit de plus en plus pour cacher la véritable génération de clé. La méthode getKeyForPassword est placée dans une bibliothèque partagée écrite en C appelée “mealy”. Prenons la bibliothèque de l’appareil et mettons-la dans un désassembleur comme IDA :
Le binaire a une chaîne codée en dur appelée “out_char” avec la valeur suivante : eu>q5b0KPlLwyb@#j9?!ehjl(LHukkA(di^S4UXAChr3B`_xf+@h#S&wpfv&# . En regardant le code, la méthode getKeyForPassword reçoit comme argument la valeur longue de getPartialString(getAndroidID()), tenant comme variable la chaîne out_char et passe les deux à la sous-routine ‘mealymachine’. Jetons un coup d’œil à la fonction getKeyForPassword et à la sous-routine mealymachine en pseudo-code : function Java_com_sec_knox_store_SecurityManager_SecureKeyLoader_getKeyForPassword { r4 = r0; //partialString androidID comme valeur longue r0 = r2; //entier = 16 r0 = mealymachine(r0, var_8, next, “eu>q5b0KPlLwyb@#j9?!ehjl(LHukkA(di^S4UXAChr3B_xf+@h*#S&wpfv&#”, STK29);* *r3 = *r4;* *r2 = *(r3 + 0x29c);* *r0 = (r2)(r4, r0, r2, r3);* *return r0;* *}* *function mealymachine {* *r6 = r0; //partialString androidID comme valeur longue* *r5 = r1; //var_8* *r7 = r2; //next* *r8 = r3; //eu>q5b0KPlLwyb@*#j9?!*ehjl(LHukkA(di^S4UXAChr3B_xf+@h#S&wpfv&#
if (r1 <= 0x64) {
r4 = 0x0;
memset@PLT(0x2144, 0x0, 0x64);
r1 = r4;
do {
if (r4 >= r5) {
break;
}
r0 = r6 & 0x1;
r6 = r6 >> 0x1;
(int8_t )(r4 + 0x2144) = (int8_t )(r0 + r8 + r1); //AndroidID + eu>q5b0KPlLwyb@#j9?!ehjl(LHukkA(di^S4UXAChr3B`_xf+@h#S&wpfv&# + var_8 r4 = r4 + 0x1; r1 = (r0 0x4 + r7 + r1); } while (true); r0 = 0x2144;* (int8_t )(r0 + (r5 & !r5)) = 0x0;
return r0;
}
else {
r0 = 0x0;
return r0;
} return r0; } En regardant la sous-routine, elle ajoute simplement la valeur longue de l’ID Android et la chaîne codée en dur. La méthode getPartialString soustrait une partie de l’ID Android. Juste pour clarification : chaque application peut demander au système l’ID Android en appelant : Secure.getString(getContext().getContentResolver(),Secure.ANDROID_ID);*

En conclusion, Ares souligne que Samsung Knox n’est pas aussi sécurisé qu’il est prétendu l’être.

Samsung a vraiment essayé de cacher la fonctionnalité de génération de la clé, suivant la règle de la sécurité par l’obscurité. En fin de compte, il utilise simplement l’ID Android avec une chaîne codée en dur et les mélange pour la clé de chiffrement. Je m’attendais à ce qu’un produit appelé Knox adopte une approche différente :

La clé devrait être dérivée d’une fonction de dérivation de clé basée sur un mot de passe 2 (PBKDF2) qui génère une clé beaucoup plus forte avec plus d’aléa.
Le fait qu’ils persistent la clé juste pour la fonctionnalité d’indice de mot de passe compromet complètement la sécurité de ce produit. Pour un tel produit, le mot de passe ne devrait jamais être stocké sur l’appareil. Il n’y a pas besoin de cela, sauf si vous oubliez votre mot de passe. Mais alors vos données devraient être perdues, sinon elles ne sont pas sûres s’il y a une sorte d’option de récupération.

Recommandation d’Ares

Au lieu de Samsung Knox, utilisez la fonction de chiffrement intégrée d’Android et cryptez l’ensemble de l’appareil. Android utilise une fonction PBKDF2 à partir du mot de passe de chiffrement que vous choisissez et ne le persiste jamais sur l’appareil. Évidemment, vous ne pouvez jamais accéder aux données si vous oubliez votre mot de passe, mais c’est le but d’un bon chiffrement.

*Ressource : Mobile Security Blog