What Can Chromebook Teach Us About Mobile Security?
Whatever the Google device's fate in the market, it could well serve as a test lab for innovative security techniques.
Google's Chromebook, which could be considered the first mobile thin client aimed at consumers, arrived to reviews that ranged from "nice try, but back to the drawing board" to "you've got to be kidding." When mainstream PC makers are offering full-blown Windows 7 laptops for $500, it's hard to understand why someone would pay the same amount for what amounts to a netbook with one application: a browser (admittedly somewhat harsh, since in Chrome the browser serves as a meta-application for a host of Web-based apps). But whatever the Chromebook's fate in the market, whether it heralds a new era of hassle-free mobile computing or joins the Amiga, Newton, and OS/2 in the tech industry's historical ash heap, it could well serve as a test lab for innovative techniques to improve mobile device security. This potential was illustrated in a recent Google posting outlining Chromebook's security features.
Much of Chromebook's security strategy centers on the runtime environment, protecting the browser with things like app sandboxing, improvements to SSL certificate validation, and barriers to cross-site scripting attacks -- strategies that should be (and are) employed in all mobile browsers, whether it's Safari on the iPhone and iPad or Android's version of Chrome. What's more interesting about the Chromebook are the measures to protect the device itself from attack -- to prevent modifications to the OS kernel, i.e. what iPhone hackers call jailbreaking.
Chromebook uses two cryptographic techniques to defend against attacks both remote (malware distributed via the browser) and local (hackers with physical access to external ports). First, like many enterprise PCs, the Chromebook incorporates a Trusted Platform Module, a tamperproof chip that can securely generate and store cryptographic keys (note, this is the same device used by Windows BitLocker to encrypt system volumes). Next, Chromebook stores its firmware in a custom chip with two partitions: a fixed, read-only volume and a modifiable read/write section. In an innovative twist, this secondary partition is encrypted using a very large RSA key (8192 bits, to be exact) stored on the read-only partition. Only after this two-step firmware verification process does the device boot the OS. But here again, the Chromebook incorporates a code-validation step called Verified Boot that "strives to ensure that all executed code comes from the Chromium OS source tree, rather than from an attacker or corruption." The goal "is to provide cryptographic assurances that the system code hasn’t been modified by an attacker."
The Chromebook thus places several security layers between its pristine, approved OS code and any attackers trying modify it; however, what about when this hedgerow of defenses fails? Here's where so-called recovery mode, part of the read-only firmware, comes in. As Google's post describes it, "Recovery mode lets you install a fresh, up-to-date version of the operating system from a recovery device plugged into the USB port. That means if an attacker manages to install malicious software, you can still use recovery mode to help remove it and return your Chromebook back to the way it was." Coincidentally, Apple's latest OS X release, Lion, incorporates a new Internet Recovery mode that is remarkably similar. When coupled with Chrome's automatic system updates (now a feature of all modern operating systems), this means that even a badly compromised device, with its OS and even read/write firmware altered, can be restored with relative ease.
So what can Chromebook teach us about securing mobile operating systems? First, sandboxing apps to limit interprocess communication (a common malware propagation vector) is a no-brainer, but here iOS and Apple's tighter control over the app ecosystem probably does a better job than Chrome or its cousin, Android. Next, having a fail-safe read-only firmware volume, with just enough intelligence to update the remaining firmware and OS from a trusted source, is a great idea. The codgers among us are experiencing a sense of deja vu, since, absent the Internet update capability, having a rich firmware stack in hardware ROM, in contrast to the minimalist PC BIOS, was a distinguishing characteristic of the original Macs. Finally, protecting the firmware, OS, and user file system with tamper-resistant hardware cryptography adds a significant hurdle for potential hackers. It's not a perfect defense, since any key can be extracted while in system memory (witness the recent FireWire vulnerability allowing access to OS X passwords), but it significantly raises the technological threshold attackers must cross.
While the Chromebook may well turn into a market flop, it contains a number of innovative security ideas that should influence the design of future mobile devices.
See the latest IT solutions at Interop New York. Learn to leverage business technology innovations--including cloud, virtualization, security, mobility, and data center advances--that cut costs, increase productivity, and drive business value. Save 25% on Flex and Conference Passes or get a Free Expo Pass with code CPFHNY25. It happens in New York City, Oct. 3-7, 2011. Register now.
InformationWeek Elite 100Our data shows these innovators using digital technology in two key areas: providing better products and cutting costs. Almost half of them expect to introduce a new IT-led product this year, and 46% are using technology to make business processes more efficient.
The UC Infrastructure TrapWorries about subpar networks tanking unified communications programs could be valid: Thirty-one percent of respondents have rolled capabilities out to less than 10% of users vs. 21% delivering UC to 76% or more. Is low uptake a result of strained infrastructures delivering poor performance?
InformationWeek Tech Digest August 03, 2015The networking industry agrees that software-defined networking is the way of the future. So where are all the deployments? We take a look at where SDN is being deployed and what's getting in the way of deployments.