Better Living through a Protocol Break

Protocol is the standard set of rules that allow all of us to communicate with each other using the proper procedure for conduct. Not that protocols do not change over time, or that they may be different by culture, but they do establish the norms for a safe and secure method for all of us to get along.

However, if you will allow, let me propose the counter-intuitive argument. Breaking protocol can lead to better living in one area – Ultra-Secure Mobility™.

As we look to how data is transmitted over a network, of course, it is governed by Protocol. This Protocol is a set of communication agreements, which ensure that as long as both sides of a communication channel adhere to it, the data gets delivered correctly. This protocol does two primary things: 1) that the data gets routed in the right direction; and 2) that it is chopped into parts where needed and reassembled again where possible. These protocols can also govern some other very complicated things like compression, tunneling, load balancing, authentication, caching, spooling, and all kinds of things to make the communication go smoothly.

However, these Protocols only work under the condition that both sides are cooperative. Security attackers leverage this ‘trust’ by not being cooperative for the express purpose of working to find an attack vector.

There is an answer. Introduce a Protocol Break.

A protocol break consists of two components that sit between the sender (upstream) and the receiver(downstream) of a message. The first component is a “catcher”, which, while adhering to the protocol, strips all traffic control data from the data it receives, and keeps only the payload data. The second component is a “thrower”. The thrower does the opposite: it takes bare payload data and sends the payload to another system by means of a chosen new protocol. To do this successfully, the thrower does all the complicated things that are necessary to adhere to this new Protocol specification.

For example, in a “protecting secrets” scenario it can generally be assumed that the attacker has access to the upstream network. From the upstream network, the attacker could attack the downstream network by abusing a design flaw in one of the systems on the downstream network. Though the attack may still cause harm in terms of availability on the downstream network, the Protocol Break effectively cuts out those attack vectors which live in the traffic control data from getting downstream.

In our view, Better Living through a Protocol Break can be achieved for the broader market – especially for IoT or Connected Devices.

At Cog Systems, we build solution that rely on a defense-in-depth resilience that includes an architecture that is layered, isolated, and modular, with commercial off-the-shelf hardware and software.

Ultra-Secure Mobility™: The Three Planks

The Ultra-Secure Mobility™ product has been a market need forever in demand by discerning customers that require a scalable, user friendly, and affordable product. At Cog Systems, the standard by which we measure success in this category of Ultra-Secure Mobility™ rests on three planks that fulfill a combination of the following: 1) high assurance, certified security; 2) end-user defined privacy; and 3) a top-notch user experience. Bonus points if it can be delivered on a commercial device that allows for both the obfuscation of the capabilities embedded and at a reasonable price point.

Some past and present build attempts to address this need for an Ultra-Secure Mobility™ product resulted in bespoke devices that rely on security through obscurity, using proprietary hardware and software components from the handset manufacturer. These attempts often lead to transparency issues related to chain of trust, dubious privacy, and almost certainly a clunky user experience. Even in the mass market, where mainstream device manufactures deliver on the user experience by leveraging the Android ecosystem, they often do not support the latest versions of Android or security patches and certainly do not even acknowledge privacy as a basic tenant of their delivery. Whether through bespoke or mainstream devices, the market is left wanting for a true Ultra-Secure Mobility™ solution.

It is our view at Cog Systems, that customers should not have to rely on point solutions that deliver security through obscurity or privacy through open inspection, however, but rather on a defense-in-depth resilience that includes an architecture that is layered, isolated, and modular, with hardened commercial off-the-shelf hardware and software.

Cog Systems is developing a commercial, Ultra-Secure Mobility™ product by building on a foundational approach that leverages type-1 virtualization using formal methods resulting in never-before-seen security, privacy, and a superb user experience – all maintained with three years of guaranteed security patches and android updates.

At Cog, we do not, and will not, compromise in our effort to deliver on the full premise of the ultra-secure mobility promise. It is our view that our approach is the most robust and cost-effective method of delivering the long-awaited solution to the Ultra-Secure Mobility™ segment.

Defence in Depth: How Many Layers is your Cake?

The mobile world today is largely divided into two worlds:  Apple and Android.  While their approach to many things may be different, they do share a common approach to security — think layer cake.  Yes, the one thing that seems to matter most in making a great cake is layers.   Just like your security posture.  Layers add depth, and the more the better.

Three Layer Cake

For Apple, the iPhone has (at least) three layers:  1) Applications; 2) iOS kernel; and 3) an added security chip.  The security chip is unique to Apple, which is a very good thing. However, don’t be misled as it only performs one core function.  The security chip is used for isolating the encryption keys and the use of those keys from the other layers.  The code in the security chip is small, which makes it easy to analyse, thereby validating its integrity.  Thinking in terms of layers, there is the iOS kernel, which focuses on isolating the application leveraging standard approaches to security at this layer.

When you look at Android’s approach, the end point devices don’t historically have a fixed security architecture.  This enables diversity and innovation that allow the chipset vendors do many different things.  However, on a typical ARM-based Android device you will find three security layers:  1) Applications; 2) Linux Kernel; and 3) TrustZone.  The first two layers are very similar to Apple’s approach at a conceptual level.  However, TrustZone is very different to the added Apple security chip.

TrustZone itself can be considered an Operating System (OS) of sorts along with its own inherent internal security separation.  This internal security separation is commonly referred to as a Trusted Execution Environment (TEE), or sometimes as a Secure Payload (SP), and even as Trusted Apps (TA).  TrustZone is where most Android devices keep their encryption keys (i.e. the crown jewels), and it implements the same key use functions that the Apple security chip does.

The huge difference between Apple and Android is the very different security profile of this configuration by Android.  TrustZone shares the same CPU with the Android OS, which leaves it vulnerable to side-channel attacks (i.e. Spectre, DDR Rowhammer, etc.)  TrustZone also has a much larger attack surface than a dedicated security chip.  To add to the risk for TrustZone is that third-party software (TAs) can be loaded and then leveraged to present an even larger attack surface.  Though the TA is supposed to be isolated from the TEE, this new larger attack surface, if compromised, can give the attacker new avenues to attack the TEE and its critical encryption key handling software.  Though, it is not my intent to provide a path forward for malevolent behaviour, there is precedent for successful attacks that lead to the extraction of the encryption keys from TrustZone.

Google has not stood idle. They have updated their security APIs to *require* the keys to be separated from the Kernel (i.e. using TrustZone or elsewhere), but it still only puts the onus for security on Android devices on TrustZone, which does have its issues as stated earlier.

Four Layer Cake

Qualcomm has recognized the danger, and now offers a similar security chip, the Secure Processing Unit (SPU), for the latest devices that performs the same functions as Apple’s security chip.  This does not mean that Android has achieved parity with Apple, but if you are using a Qualcomm-based Android device you now have four layers (apps, kernel, TZ, security chip) of security – which stands up as a much better security posture.

Five Layer Cake

Today, Cog’s security and virtualization APIs are available in select QualComm Snapdragon mobile platforms, including the recently launched Snapdragon 855. This will enable connected devices, such as Android phones and IoT devices, to access Cog’s virtualization based modular security technology, known as D4 Secure.

Given the above, Cog’s value-add vis a vis virtualization is a bit more nuanced, but very much relevant.

  • Firstly, TrustZone is not a friendly place to write apps. TA’s have many restrictions and can’t operate as applications in the usual sense – like an Application on the OS.
  • Second, virtualization solves this, as it provides the ability to add additional virtual machines that can be enabled to run anything from small to very large applications, and even whole operating systems. All of which are running in their own little worlds provided by the hypervisor.
  • Third, many of the things that are being put into TrustZone today would be better suited to run in a virtual machine. Virtualization provides a richer and more flexible environment that makes it much simpler to develop isolated components by putting them into virtual machines, where those components would have far fewer restrictions and greater capability.  Plus, the risk of a hacked component has much less impact on the security within the rest of the system.
  • Fourth, there are other benefits of virtualization, such as the ability to have more oversight on what’s going within each virtual machine and potentially detecting issues in the other virtual machines. A new capability is opened for applications that currently reside in Android due to lack of access to, or the unsuitability of the TrustZone environment, to be run within a VM.
  • Fifth, the Cog on Qualcomm solution offers five full layers of security that will just work right out of the box.

 

Let Them Eat Cake

In summary, if you want to make an even bigger leap to your defence in depth – adding virtualization is akin to adding another layer to your protection profile.  Virtualization offers greater flexibility, improved security, better architecture for secure application development, and new opportunities to move software that currently run (due to no viable alternative) as Apps on the Android system into their own isolated virtual machines.  There’s no reason to be satisfied with just three layers – Cog can help you get greater depth in your defence, regardless of your OS of choice.

 

Cog Q&A: Gernot Heiser, the Godfather of Modularity

For those of us in the business of devices, Gernot Heiser needs no introduction. But for the rest of you, here’s a summary:

Gernot’s primary occupation is leading research in Trustworthy Systems, aiming to make software systems truly trustworthy. He also teaches Advanced Operating Systems at UNSW, which also has its own prize for the best-performing student, the Advanced Operating Systems Alumni Prize.

In 2006 he founded Open Kernel Labs (OK Labs) for commercializing L4 microkernel technology developed in his research lab. He served as Chief Technology Officer from 2006–2010, and as a Director from 2006 until OK’s acquisition by General Dynamics in August 2012.

Gernot’s trailblazing work in the microkernel industry has led some of us around here to nickname him the “Godfather of Modularity,” and I had the privilege to catch up with him for a quick conversation.

Gernot, care to weigh in on the monolithic vs. modularity debate for device design?

Sure, that’s easy. The monolithic OS design model, used by Linux, Windows, macOS, is fundamentally and irreparably broken from the security standpoint.

Security is only achievable with a microkernel design, that minimizes the “trusted computing base” (TCB), i.e. the part of the system on which security depends. Ideally the microkernel is verified, mathematically proved correct, as in seL4. That is only feasible with a really small system. Systems like Linux have a TCB that is far too large and complex to get right, they are inherently full of security holes. Their use in security- or safety-critical applications is at best grossly negligent and should be considered professional malpractice. It must stop.

And you have some serious research to back this up. Tell us about it.

Absolutely. I recently performed an analysis of Linux vulnerabilities listed as critical – meaning it is easy to exploit and leads to full system compromise, including full access to sensitive data and full control over the system.

For each of those vulnerabilities we analyzed how it would be affected if the attack were performed against a feature-compatible, componentized OS. In other words, an application running on this OS should only be dependent on a minimum of services required to do its job, and no others.

We evaluated all Linux vulnerabilities that had been classified “critical”, a total of 112 vulnerabilities.

You have my attention – what was the result?

Well, for starters, only 5 compromises (4%) were not affected by OS structure.

29% were eliminated simply by implementing the OS as a componentized system on top of a microkernel! The example I like to give is if a Linux USB device driver is compromised, the attacker gains control over the whole system, because the driver runs with kernel privileges. In a well-designed microkernel-based system, only the driver process is compromised, but since our application does not require USB, it remains completely unaffected.

Wow. What else did you uncover?

A further 11% of the vulnerabilities are eliminated if the underlying microkernel is formally verified (proved correct), as we did with seL4. These are exploits against functionality, such as page-table management, that must be in the kernel, even if it’s a microkernel. A microkernel could be affected by such an attack, but in a verified kernel, such as seL4, the flaws which these attacks target are ruled out by the mathematical proofs.

So, taken with the previously mentioned 29%, we proved that 40% of the exploits would be completely eliminated by an OS designed based on seL4.

So, the case for modularity keeps building.

Definitely. We also found that another 17% of exploits are strongly mitigated. These are the kinds of attacks where a required component, such as NIC driver or network stack, is compromised, and as a result compromising the whole Linux system, while on the microkernel it might lead to the network service crashing without being able to compromise any data.

So if my math is correct, 57% of attacks are either completely eliminated or reduced to low severity?

That’s absolutely correct.

Gernot, thanks for your time and data as it relates to device vulnerability. Where can readers learn more about what you’re up to?

Thanks, Carl. People can find me at https://microkerneldude.wordpress.com/

WARNING: A Cybersecurity Revolution is Upon Us, With Consumers Taking the Power Seat

The world today has entered into a new era where consumers and enterprise alike have come to expect cyber attacks. However, as attacks become more severe with greater reach, a power shift is occurring among consumers who are losing trust in the enterprise and government to protect their privacy and data. Now, consumers are choosing to leverage their power and make choices based on their confidence in security.

 Increased Attacks and Lack of Trust are Fueling the Revolution

The PwC survey conducted in 2017 measuring consumer perceptions around cybersecurity and privacy risks demonstrates that a revolution is upon us and the findings are telling:

  • Just 25% of respondents believe most companies handle their sensitive personal data responsibly. Even fewer—only 15%—think companies will use that data to improve their lives.
  • Only 10% of consumers feel they have complete control over their personal information.
  • 88% of respondents say the amount of data they share with a company depends on how much they trust it.

So how could this revolution impact you? Manufacturers and enterprises serving these consumers will pay the ultimate price as 85% of respondents surveyed say they will not do business with a company if they have concerns about its security practices.

Prioritizing Cybersecurity

I’ve said it before and I’ll say it again: today’s manufacturers and enterprises can no longer afford apathy and lip service when it comes to cybersecurity. It needs to be in the forefront of your business strategy, which should include adopting and implementing proven security tactics that address consumer concerns to gain their loyalty. This applies to mobile, but especially IoT.

At Cog, we firmly believe that the world’s connected and IoT devices can be secured by leveraging virtualization at the architecture level . This is the only way to engineer tomorrow’s connected marketplace to deliver security and productivity.