Free Republic
Browse · Search
General/Chat
Topics · Post Article

Skip to comments.

After U.S. government approval, Samsung Knox security for Android is "completely compromised"
Apple Insider ^ | By Daniel Eran Dilger

Posted on 10/24/2014 10:46:28 PM PDT by Swordmaker

Samsung's Knox security layer for Android generates weak encryption keys, stores passwords locally and gives users login hints in a fatal "security by obscurity" design "compromising the security of the product completely," a researcher has detailed.

Samsung ships its Knox software on the company's higher-end Android-based Galaxy smartphones, phablets and tablets, aimed at enabling sales to enterprise and government clients who have sensitive security needs, in a bid to take on Apple's extensive lead in enterprise sales.

Two days ago, Samsung announced that the U.S. government had approved a series of new devices "for use with classified government networks and data. All devices and capabilities incorporate security features powered by Samsung KNOX," and were added to the "Commercial Solutions for Classified (CSfC) Program Component List."

The company's chief executive JK Shin stated in a press release that "the inclusion of Samsung mobile devices on the CSfC list proves the unmatched security of Samsung Galaxy devices supported by the KNOX platform."

Jacob Kleinman, writing for TechnoBuffalo, stated that "it looks like Samsung's hard work developing its Knox security software is paying off," while Jennifer Baker of the UK site The Register reported, "U.S. spooks will be allowed to access sensitive government information on their KNOX-locked Samsung gadgets from now on. The South Korean company has been heavily pushing its new KNOX security product and it looks as though its efforts have paid off."

Wait, stop, come back

Earlier today, however, a software researcher published findings showing that Samsung's Knox app stores the user's password "hint" PIN in plain text on the device.Samsung Knox users log into the Knox app using a password and PIN, which is then written into a "pin.xml" file in cleartext.

The Knox app establishes a "Knox Container" with its own home screen for launching secured apps, which do not mingle with the user's own private apps and data. This design attempts to work around the wide open design of Android, which has no effective app security, much like an iOS device that has been jailbroken.

However, Samsung Knox users log into the Knox app using a password and PIN, which is then written into a "pin.xml" file in cleartext, available to anyone looking at the file system. The user (or anyone else who reads the cleartext PIN) can enter the PIN to gain a "password forgotten?" hint.

As the research describes, upon entering the PIN, "the Knox app will show you a little password hint (the first and the last character of your password!! + the original length of your password!)"

This "hangman game" style password security is not the extent of the problem.

"It is pretty obvious that Samsung Knox is going to store your password somewhere on the device," the researcher noted, further detailing that "in the Folder /data/system/container there is a file called containerpassword_1.key," which stores the user's encryption key.

Samsung Knox 'compromised completely'

The research further examined Samsung Knox, looking for "how exactly the encryption of the password works and where the key for the encryption comes from."

The article noted, "Samsung 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. "the fact that they are persisting the key just for the password hint functionality is compromising the security of that product completely"

"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."

What he ultimately discovered was that Knox simply uses the device's Android ID, a serial number any app can request from the system, "together with a hardcoded string and mix them for the encryption key. I would have expected from a product, called Knox, a different approach."

He further points out, "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." In conclusion he recommends, "Instead of Samsung Knox, use the built-in Android encryption function and encrypt the whole device."

Fortunately, few are actually trying to use Knox

Samsung first unveiled Knox in early 2013 as part of an effort to add "fundamental security and management enhancements" in order "to address the shortcomings of the current open source Android platform."

Before Knox was even available, Samsung immediately began advertising it as part of its "SAFE" initiative (short for "SAmsung For Enterprise") via billboards portraying Samsung devices running mockups of business presentation and project management software that doesn't really exist.

Shortly after Knox was first introduced on the Galaxy Note 3 last year, Mordechai Guri, a researcher at Ben-Gurion University's Cyber Security Lab described a vulnerability that he detailed would "would allow a hacker to 'easily intercept' secure data of a user of a Knox-enabled Galaxy smartphone."Of the 87 million devices that shipped with Knox, only 1.8 million were actually using it.

In a worst-case scenario, Guri stated, "a hacker could modify data and even insert hostile code that could run amok within the secured network."

Six months later, the Wall Street Journal described the issue as "a possible security gap" and said that Samsung had "clarified" that the issue "is not specific to Samsung devices."

This May, however, Samsung executive Rhee In-jong, appearing in another Wall Street Journal article—which sought to distract attention away from Apple's Touch ID fingerprint sensor by talking about vaporware plans for "iris scanning" biometrics—noted that of the 87 million devices that shipped with Knox, only 1.8 million were actually using it: only about 2 percent.

Android 5.0 Lollypop gets Knoxed up


Sundar Pichai

In June, Google's head of Android development Sundar Pichai announced plans for Android 5.0 "Lollypop," with a security layer for enterprise users provided by Samsung's "contribution" of Knox.

The shotgun wedding of Lollypop and Knox appeared to be a compromise between Google and Samsung, which—according to a report by The Information—had been involved in a tense standoff since January, when Samsung demonstrated its own new user interface dubbed "Magazine UX," which Pichai viewed as a direct threat to Google's control over and monetization of Android.

Pichai was reportedly "prepared to forbid" Samsung from using the ostensibly open Android operating system unless it fell into line with Google's requirements. That demand makes more sense given Google's announcements of a second attempt at delivering its own cohesive user interface for Android, an web-inspired initiative it calls "Material Design."

The standoff also explains how Samsung could be strong-armed into "contributing" Knox, a significantly differentiating feature that has made some of Samsung's products at least possible for government and corporate users to buy, while other Android vendors have been virtually shut out of the enterprise entirely, as alluded to by IDC's Mobility Research Director Ryan Reith.

After Google introduced Knox as its solution for securing Android in June, Bluebox Security detailed severe new flaws in Android itself, tied to the fact that the operating system simply failed to verify apps' cryptographic signatures, essentially allowing any app—even one given no special access permissions—to falsely pass itself off as a trusted app and gain extensive control over the user's apps and data.

The "Fake ID" vulnerability can exploit Android's webview, infecting a wide variety of third party apps that incorporate it, and can also target trusted Google software including its broadly installed NFC Wallet app or remnants of the 3LM device management tool, which appears on a wide variety of Android phones from HTC, Pantech, Sharp, Sony Ericsson, and Motorola.Apple has seized upon Android's security and privacy problems to emphasize that iOS is designed "with security at its core."

The majority of Android devices making up the platform's "80 percent share" of smartphones globally have still not been updated to fix the Fake ID flaw. Additionally, while Google has made efforts to scan Google Play apps for malicious code, a variety of app stores operating overseas—including in China, where Google maintains little control over Android—have not.

Earlier this year, Pichai outlined Google's a very different approach to security in Android, staying, "we do not guarantee that Android is designed to be safe; its format was designed to give more freedom. When they talk about 90% of malicious programs for Android, they must of course take into account the fact that it is the most used operating system in the world. If I had a company dedicated to malware, I would also send my attacks to Android."

Apple has seized upon Android's security and privacy problems to emphasize that iOS is designed "with security at its core."

In a white paper detailing the security of iOS—including Touch ID and the Secure Enclave of its latest 64-bit Application Processors—the company stated, "when we set out to create the best possible mobile OS, we drew from decades of experience to build an entirely new architecture. We thought about the security hazards of the desktop environment, and established a new approach to security in the design of iOS. We developed and incorporated innovative features that tighten mobile security and protect the entire system by default. As a result, iOS is a major leap forward in OS security."


TOPICS: Business/Economy; Computers/Internet
KEYWORDS:

1 posted on 10/24/2014 10:46:28 PM PDT by Swordmaker
[ Post Reply | Private Reply | View Replies]

To: Swordmaker

The government screws up everything it even gets close to. They could screw up a rock fight.


2 posted on 10/24/2014 11:04:06 PM PDT by DesertRhino (I was standing with a rifle, waiting for soviet paratroopers, but communists just ran for office.)
[ Post Reply | Private Reply | To 1 | View Replies]

To: Swordmaker

From reading through the article, it sounds like Samsung doesn’t even know the fundamentals of how to implement security.

Granted, android was notdesigned specifically with security in mind. This makes it harder, but not impossible. From what I’ve read the cryptography deployed to encrypt a device is good, if you use a decent key. I don’t understand how they can be so stupid.


3 posted on 10/24/2014 11:04:35 PM PDT by zeugma (The act of observing disturbs the observed.)
[ Post Reply | Private Reply | To 1 | View Replies]

To: zeugma
Granted, android was notdesigned specifically with security in mind. This makes it harder, but not impossible. From what I’ve read the cryptography deployed to encrypt a device is good, if you use a decent key. I don’t understand how they can be so stupid.

Everything is done in software, so they have to keep the keys in files, somewhere on the phone. Apple has custom hardware that allows the keys to be hashes, and a specific hardware storage that is not accessible from off the iPhone. But, using fixed size passwords? And giving hints that show both first and last plus the length? Then storing the password in plain text? Then relying on hiding the password in oceans of other text of Java Code? Given what they've provided, a Java script could find it in seconds. Stupid. Sheer stupidity.

These flaws have existed for months and our GOVERNMENT APPROVED this for secure uses??? As one comment put it on the thread at AppleInsider either;

1: Samsung paid somebody off
2: The NSA really wants to spy on every other part of our government.
3: Our government is totally incompetent

To which another replied:

4: All of the above!

I kind of lean to #4

4 posted on 10/24/2014 11:20:29 PM PDT by Swordmaker (This tag line is a Microsoft insult free zone... but if the insults to Mac users continue...)
[ Post Reply | Private Reply | To 3 | View Replies]

To: DesertRhino
The government screws up everything it even gets close to. They could screw up a rock fight.

Hell, Desert, THIS administration could screw up a pillow fight. They'd require the use of regulation pillows, and checking of the filling before the onset of the fight. There's be a fee for such examination. . . and a fine for non-compliance.

5 posted on 10/24/2014 11:23:14 PM PDT by Swordmaker (This tag line is a Microsoft insult free zone... but if the insults to Mac users continue...)
[ Post Reply | Private Reply | To 2 | View Replies]

To: Swordmaker

UNBELIEVABLY STUPID!!!

lol!!!

(....and I tend to favor Samsung devices)

Really, I don’t do/say anything on a smartphone that I don’t assume that someone else is going to see anyway. I have ZERO pretense of privacy when using any form of communications today.


6 posted on 10/24/2014 11:25:48 PM PDT by KoRn (Department of Homeland Security, Certified - "Right Wing Extremist")
[ Post Reply | Private Reply | To 1 | View Replies]

To: KoRn

No device is 100% secure. This reads like a hit piece though, you’d almost think apple and Samsung don’t get along.


7 posted on 10/25/2014 2:48:10 AM PDT by driftdiver (I could eat it raw, but why do that when I have a fire.)
[ Post Reply | Private Reply | To 6 | View Replies]

To: zeugma
it sounds like Samsung doesn’t even know the fundamentals of how to implement security.

To be fair, this wasn't Samsung's ball to drop. Samsung implemented new hardware abstraction layer security to complement some of the next-gen security technologies. Unfortunately, when you're running on software made by Google, you're bound to be compromised by either poor coding or a very robust and curious community of rooters and hackers.

The reason iOS "works" is that Apple's tied down their OS to their hardware. Proprietary software on proprietary hardware means that software is as safe as the developer wants to make it.

Google's open source development, while admirable for its customizability, is never going to be as secure as iOS or even Windows phone since the latter two are wholly owned by their parent companies while Google's community develops most of the APIs for their otherwise lackluster kernel.

8 posted on 10/25/2014 3:53:02 AM PDT by rarestia (It's time to water the Tree of Liberty.)
[ Post Reply | Private Reply | To 3 | View Replies]

To: Swordmaker
To which another replied:

4: All of the above!

I kind of lean to #4

As do I.

I'll be reallly interested in Schneier's take on this.

9 posted on 10/25/2014 9:52:27 AM PDT by zeugma (The act of observing disturbs the observed.)
[ Post Reply | Private Reply | To 4 | View Replies]

Disclaimer: Opinions posted on Free Republic are those of the individual posters and do not necessarily represent the opinion of Free Republic or its management. All materials posted herein are protected by copyright law and the exemption for fair use of copyrighted works.

Free Republic
Browse · Search
General/Chat
Topics · Post Article

FreeRepublic, LLC, PO BOX 9771, FRESNO, CA 93794
FreeRepublic.com is powered by software copyright 2000-2008 John Robinson