Samsung Knox Validated and Approved For U.S. Gov Classified UseDoes that mean the Samsung Knox is the most secure way to store important and personal images /videos /docsHow is Samsung Knox vulnerableIn conclusion Ares points out that Samsung Knox is not as secure as it is pointed out to be.Recommendation from Ares
This accomplishment is the direct result of Samsung’s successful testing and certification under the U.S. government’s Common Criteria Mobile Device Fundamental Protection Profile (MDFPP) and VPN Protection Profile (VPNPP) programs. The listed Samsung devices are available for use with classified government networks and data. All devices and capabilities incorporate security features powered by Samsung KNOX. Samsungs own description of its Knox service also points out to the same facts The DISA Approved Products List may be found at: https://www.disa.mil/Services/Network-Services/UCCO.
Does that mean the Samsung Knox is the most secure way to store important and personal images /videos /docs
With the breaches and hacks taking place almost everyday, a user entails serious risks to save personal images/docs or videos online in the clouds. With the iCloud Hacks it was proved that even Celebrities are not safe from hacking. The SnapChat leaks proved that images of 13 to 17 year old kids were prone to being vulnerable to such leaks. The Dropbox leaks proved that saving to Dropbox also entails a relatively high risk. So what do the users do with their images and videos taken in those private moment. With the approval of the US Government for classified use, the Samsung Knox became the first mobile device to be guaranteed as safe from hackers, no less then by the Big Sam himself. With unlimited storage (upto 64GB) capacity aboard many of the Samsung products, you are safe on the space option but is the Samsung Knox really the Fort Knox of storing your private documents/images and videos securely. While the US Government thinks so, a security researcher, Eingestellt von Ares doesnt think so. Infact Ares has demonstrated on his blog as to why Samsung’s Knox is vulnerable and quite easily too.
How is Samsung Knox vulnerable
Ares has given a full PoC about the vulnerability on his blog, which is reproduced here :
Additionally all apps which are installed in the new Knox home screen are located in the standard app installation folder /data/data/ and come with the prefix: com.sec.. Listing all of them here would be too much. After a typical Knox installation there are 139 apps and services installed with the prefix com.sec. Looking a bit deeper in the system, Knox is distributed through the whole system and stores data in a couple of different locations, for example: the encrypted container itself will be stored in /data/.container_* and/data/container/.sdcontainer_1.* Different files and databases for settings are stored in /data/system/secure_storage and /data/system/container. Each analysis of a mobile app starts with a static analysis of the files the app stored after the setup. A good starting point for Android Apps is the app folder under /data/data/. These folders typically have the structure: com.aPackageName |- cache |- databases |- extracted |- lib |- shared_prefs Especially the folders databases and shared_prefs are the ones that deserves the first attention. The ContainerAgent app of Knox (com.sec.knox.containeragent) had some interesting files stored: 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 Yes, guess what is written in the pin.xml file? The pin we had to set during the setup of Knox in cleartext!
Now the Samsung Knox gives a user a maximum of 2o tries for username and password.
In conclusion Ares points out that Samsung Knox is not as secure as it is pointed out to be.
Samsung really tried to hide the functionality to generate the key, following the security by obscurity rule. In the end it just uses the Android ID together with a hardcoded string and mix them for the encryption key. I would have expected from a product, called Knox, a different approach:
So this looks like an AES encrypted string. No we have to decompile the apps to have a deeper look how exactly the encryption of the password works and where the key for the encryption comes from. Samsungs makes use of dex-preoptimization to strip out all classes.dex files (the java code is stored in a file called classes.dex and this file is parsed by the Dalvik JVM) in the Knox apks, thus making reverse engineering a little bit harder. To get the binaries we have to look at /system/app/ and find .odex files (an odex is basically a pre-processed version of an application’s classes.dex that is execution-ready for Dalvik). odex files can be converted back into smali code, which then can be converted back to a dex file. Finally a dex file can be converted into a jar file, which can be decompiled by any Java Decompiler.
Samsung didn’t make any use of code obfuscation but really tried to hide the password storage code within hundreds of java classes, inheritance and proxies. Finally in the Knox Store app the proxy IDataService was implemented which all other apps were constantly calling when handling something password related. So when saving the password the app is doing the following: 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);
} Let’s have a look at each line and the corresponding methods: public long getInputForKeyGenerate() { return Long.parseLong(SecureKeyLoader.getPartialString(getAndroidID()), 16); } private String getAndroidID() { return Settings.Secure.getString(this.mContext.getContentResolver(), “android_id”); } So the input for the key is obviously the unique Android ID which every device has. The 16-Byte ID parsed as Long value is then used as an argument for the function 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 is obfuscating it more and more to hide the real key generation. The method getKeyForPassword is placed in a C written shared library called “mealy”. Let’s grab the library from the device and put it into a disassembler like IDA: The binary has one hardcoded string called “out_char” with the following value: eu>[email protected]*#j9?!ehjl(LHukkA(di^S4UXAChr3B[email protected]*#S&wpfv&# . By looking at the code the method getKeyForPassword gets as an argument the long value of getPartialString(getAndroidID()), holding as variable the out_char String and passes both of them to the subroutine ‘mealymachine’. Let’s have a look at the function getKeyForPassword and the subroutine mealymachine in pseudo code: function Java_com_sec_knox_store_SecurityManager_SecureKeyLoader_getKeyForPassword { r4 = r0; //partialString androidID as long value r0 = r2; //integer = 16 r0 = mealymachine(r0, var_8, next, “eu>[email protected]*#j9?!*ehjl(LHukkA(di^S4UXAChr3B[email protected]#S&wpfv&#”, STK29); r3 = *r4; r2 = (r3 + 0x29c); r0 = (r2)(r4, r0, r2, r3); return r0; } function mealymachine { r6 = r0; //partialString androidID as long value r5 = r1; //var_8 r7 = r2; //next r8 = r3; //eu>[email protected]#j9?!ehjl(LHukkA(di^S4UXAChr3B[email protected]*#S&wpfv&# if (r1 <= 0x64) { r4 = 0x0; [email protected](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>[email protected]*#j9?!*ehjl(LHukkA(di^S4UXAChr3B[email protected]#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; }
By looking at the subroutine it just adds the long value from the Android ID and the hardcoded string. The method getPartialString substractes a part out of the Android ID. Just for the clarification: every app can ask the system for the Android ID by calling: Secure.getString(getContext().getContentResolver(),Secure.ANDROID_ID);
The key should be derived from a Password-Based Key Derivation Function 2(PBKDF2) which generates a much stronger key with more randomness. The fact that they are persisting the key just for the password hint functionality is compromising the security of that product completely. For such a product the password should never be stored on the device. There is no need for it, only if you forget your password. But then your data should be lost, otherwise they are not safe if there is some kind of recovery option.
Recommendation from Ares
Instead of Samsung Knox, use the built-in Android encryption function and encrypt the whole device. Android is using a PBKDF2 function from the encryption password you choose and never persists it on the device. Obviously you can never access the data if you forget your password, but that’s the point of a good encryption. Resource : Mobile Security Blog
