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.

Kurt Marko, Contributing Editor

August 1, 2011

4 Min Read

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.

About the Author(s)

Kurt Marko

Contributing Editor

Kurt Marko is an InformationWeek and Network Computing contributor and IT industry veteran, pursuing his passion for communications after a varied career that has spanned virtually the entire high-tech food chain from chips to systems. Upon graduating from Stanford University with a BS and MS in Electrical Engineering, Kurt spent several years as a semiconductor device physicist, doing process design, modeling and testing. He then joined AT&T Bell Laboratories as a memory chip designer and CAD and simulation developer.Moving to Hewlett-Packard, Kurt started in the laser printer R&D lab doing electrophotography development, for which he earned a patent, but his love of computers eventually led him to join HP’s nascent technical IT group. He spent 15 years as an IT engineer and was a lead architect for several enterprisewide infrastructure projects at HP, including the Windows domain infrastructure, remote access service, Exchange e-mail infrastructure and managed Web services.

Never Miss a Beat: Get a snapshot of the issues affecting the IT industry straight to your inbox.

You May Also Like


More Insights