AlgoBuzz Blog

Everything you ever wanted to know about security policy management, and much more.

Generic filters
Exact matches only
Search in title
Search in content
Search in excerpt
Search in comments
Filter by Custom Post Type

Secure containers and BYOD: Fort KNOX on your phone?


As businesses implement BYOD strategies, and allow staff to use their personal devices for work, there is a particular set of security challenges to contend with.  For example, how should the enterprise apps and data on a smartphone, which need enterprise-level security, be insulated from the ‘Wild West’ world of both intentional and unintentional jailbreaks, exploits, bugs and vulnerabilities that a typical consumer smartphone operates in?

Several companies offer solutions for this problem.  Google, for example, offers Android for Work; Samsung’s is called KNOX, and it’s installed on millions of mobile devices globally. These technologies are ‘secure containers’ – isolated environments that provide safe storage of data, allow for confined execution of enterprise applications, and controlled management of resources.

But how robust are these containers? In my other job – a Professor of Electrical Engineering at Tel Aviv University, I worked with a graduate student, Uri Kanonov, to conduct a systematic assessment of a secure container solution for Android, using reverse engineering and attacker-inspired methods. We chose Samsung devices because of their huge popularity. It’s also interesting to note that two years ago the US Department of Defense, approved the use of  Samsung KNOX devices on unclassified networks – making KNOX a good subject for our research.

How does KNOX work?

A major selling point for Samsung KNOX is that the container has been developed by the device manufacturer itself.  The KNOX architecture looks like this:  inside the Android device smartphone, its CPU is split into two worlds – a ‘normal world’ running Android, and a ‘secure world’ running inside ARM® TrustZone®.  TrustZone is a separate environment that runs security-dedicated apps and functions, parallel to the Android OS and separated from it by a hardware barrier.  Each of these ‘worlds’ has its own set of resources (such as flash, memory, CPU caches, etc.), but only the ‘secure world’ can access both its own and ‘normal world’ resources (RAM and disk).  Applications in the ‘normal world’ can only request services from inside the TrustZone using a specific interface. The KNOX container is designed to rely on the TrustZone as a “root of trust” and to implement sensitive operations.

Through our research we identified several design weaknesses and vulnerabilities in KNOX, which we shared with the vendor and detailed in a research paper.  Here is an overview of what we found, and the security implications for enterprise BYOD programs.

Opening the container

By using hacking tools and technologies, we found three key vulnerabilities where information inside the KNOX container could be extracted across to the regular Android environment. In other words, enterprise data and applications could be transferred from the secure container to the far less secure standard Android environment, enabling data exfiltration and exploitation of the device.  Two of these vulnerabilities were already in the process of being fixed by Samsung when we reported them, and the third was duly resolved following our report.

As serious as this might sound, the process that we and Samsung followed is normal ‘white hat’ ethical hacking – researchers identify vulnerabilities and notify the vendor, who then fixes the flaws.  In fact, at Samsung’s request, we withheld publication of one of the vulnerabilities to provide the vendor with enough time to issue a fix. This is how device and application security is enhanced and kept robust; it is how the information security industry works.

Takeaways for BYOD programs

The more concerning observation here was that Samsung had made some design choices during the original development of KNOX, that risked compromising its integrity – such as the sharing of system services code between KNOX and user applications. While this enables simpler design and implementation, it also creates a potential for security vulnerabilities. The existence of a secure container on a device is not enough:  to gain the level of protection that these solutions promise, all of their features have to be properly implemented and used, without any short-cuts that compromise security.

This obviously has some implications for organizations’ BYOD initiatives.  First, it’s important to note that the original version of KNOX (1.0, the version that my colleague and I examined) was not patched to fix the issues we found:  Samsung simply recommended that users should upgrade to the latest KNOX version (2.3). As this is a major upgrade that needs to be initiated by the devices’ users, there will be many Samsung devices out there that have not been upgraded.  So if your organization operates a BYOD program using KNOX, it’s worth checking users’ phones and tablets to ensure that they are running the latest version, along with the latest OS and application patches – which is good security practice for any device accessing your network.

Secondly, we’ve blogged in the past about the key steps that organizations should follow to run secure BYOD schemes, and this advice still stands.  And to tie this back to my day job as AlgoSec’s CTO, an intelligently segmented network, with properly configured firewalls preventing individual users’ devices from accessing parts of the corporate infrastructure that they should not be able to, also goes a long way to mitigating potential BYOD security risks.

Subscribe to Blog

Receive notifications of new posts by email.