In the last year while talking to respected security-focused engineers & developers, I've come to fully appreciate Google's Chrome OS design. The architecture benefited from a modern view of threat modeling and real-world attacks. For example, Trusted Platform Module (TPM) hardware chips are built into every Chromebook and deeply incorporated into the OS. The design documents go into some detail on the specific protections that TPM provides, particularly around critical encryption functions.

I also learned that Chromebook is the daily driver for many of Google's own senior developers and security engineers. In short, the combination of the underlying Chromebook hardware with the OS architecture makes for a pretty compelling secure development environment.

[...]

It's pretty neat to consider the possibility of pre-travel "power washing" (resetting everything clean to factory settings) on an inexpensive Chromebook and later securely restore over the air once at my destination. Since there is a wide range in Chromebook prices, the engineering challenge here was to find something powerful enough to comfortably use exclusively for several days of coding, writing, and presenting, but also cheap enough that should it get lost/stolen/damaged, I wouldn't lose too much sleep. The threat model here does not include recovery from physical tampering; if the machine were somehow confiscated or otherwise out of my custody, I could treat it as a burner and move on.

* the devices are designed not to hold much data, you're working in the cloud over encrypted links
* the little data that is cached is encrypted anyway, you'd have to attack the OS or live RAM to get at the data
* the linux based OS has a good security record - you don't often see remote websites able to break the local OS and break out of the browser process to steal data
* the basic and foundations are solid - no unknown binaries are run, for example, .. try doing that with Windows / MacOS
* simple minimal OS - means it is easier to manage and secure ... over bloated software is much harder to fully understand and secure
* users dont' and can't install stuff .. not even admin users .. admins are only admins of their google business domains .. not admins over the local software (except those who break the chrome books to install their own OS).
* easy remote device kill (prev the was thing the laptop to a single domain and only valid unsuspended accounts were usable, they may now have remote wipe)
* all this kind f stuff used with the app-level controls like 2-factor auth, shared encrypted cloud data, makes for a quite secure environment overall

trying to meet basic security objectives and apply controls to defend against the most common threats in a corporate environment with windows/macos is complex, expensive, error prone and needs 3rd party tools

there is only 1 wish I have with Chromebook .. it is that Google Apps/Domains be configured to accept connections not just from approved users, but also approved devices.... here is a blog I wrote on this...

This is the first one I have encountered in which the first step is not "Enable Developer Mode".

However, it relies on Termux which in turns requires the Chrome OS - Android "bridge". Many of the devices pre-2015 are not supported by the Chrome-Android bridge even if they have not yet reached their official end-of-life-support date. This includes the Google Pixel 2013.

With increasing airport security measures, I can envision a case for purchasing an inexpensive Chromebook when one arrives at the destination. Even better, one could have a device rental service. Airlines could provide such rental devices as one boards the plane (of course, for a fee) for long flights.

One would just need to carry a removable storage (uSDHC, SDHC, or USB), and a security key to have a truly portable environment.

While not straightforward, it appears feasible to configure the synchronization of the device with one's cloud service while retaining a high level of security of the data and the various accounts and keys used.

From my perspective though, I have yet to see a tutorial which tackles the needs of a non-developer. Engineers, graphic artists, and many others have applications requirements greater than the "Office Suite". Not quite good enough for me yet.

There are companies that do rent chromebooks directly from Google. You won't find this information online because of NDAs mostly.
As soon as chromebooks will become more "usable" by average joe we may see this in "real life" as well.
If security is not that much of an issue you can also use any decent speced smartphone with one USB-C connector for this as well.

With increasing airport security measures, I can envision a case for purchasing an inexpensive Chromebook when one arrives at the destination. Even better, one could have a device rental service. Airlines could provide such rental devices as one boards the plane (of course, for a fee) for long flights.

One would just need to carry a removable storage (uSDHC, SDHC, or USB), and a security key to have a truly portable environment.

A loaner laptop would go against the author's stated security objectives on physical tampering:

The threat model here does not include recovery from physical tampering; if the machine were somehow confiscated or otherwise out of my custody, I could treat it as a burner and move on.

Not that anyone would necessarily care, but from a security standpoint it should be treated as a public device and not a personal device. Heck even brand new devices can be compromised by NSA interdiction, although the average joe is quite unlikely to be a target.

Another issue is that internet bandwidth is still not sufficiently reliable (or abundant) in flight. On a coast to coast jetblue flight recently, internet outages were announced via redirection pages saying "the internet is currently unavailable..." and offered wifi users an inflight amazon shopping portal instead. This is annoying for normal users, but even more problematic for cloud based users.

With respect to a "rental chromebook", and from the renter's point of view, how the security model would be different than for the chromebooks currently in schools and shared by the students?

From the user's view point, any interchange of information over the cloud/network could potentially be intercepted and un-encrypted. And, unless there are back-doors in Chrome OS, the risk of the operating system having been tempered should be low.

Rental units could have a hardware "wipe" button. A security conscious user would engage this hardware wipe after receiving the unit and before returning it. The rental company would have, in theory, protocols for doing the same.

Another approach might be the possibility to purchase "travel chromebooks" in the secure area of airport. This would allow use during the outgoing flight and at the destination. However, what to do with the unit for the return trip without being wasteful?

As for wifi interruptions, Chrome OS could conceivably implement a local work space with automatic synchronization to the cloud whenever in range with a wifi connection of sufficient bandwith to have a high probability of doing it properly.

With respect to a "rental chromebook", and from the renter's point of view, how the security model would be different than for the chromebooks currently in schools and shared by the students?

I'm not really familiar with this. As I understand it some schools buy a laptop for each student and don't share them, but in other places they are shared. I don't even know how or if they ever get wiped clean, or inspected for hardware bugs (I very much doubt the schools would have the resources to do this, it seems far fetched, but nevertheless within the means of a mischievous student, haha).

From the user's view point, any interchange of information over the cloud/network could potentially be intercepted and un-encrypted. And, unless there are back-doors in Chrome OS, the risk of the operating system having been tempered should be low.

Well, IMHO the main problem is keyloggers and convincing users to disclose their credentials (id/pin/password/fingerprints/etc) such that they could then be impersonated elsewhere.

We're thinking mainly about students here, but just think how a school employee or even administrator (or flight attendant, etc) could be fooled into compromising their own accounts with a convincing login form and clever social engineering on a "rental" device.

Rental units could have a hardware "wipe" button. A security conscious user would engage this hardware wipe after receiving the unit and before returning it. The rental company would have, in theory, protocols for doing the same.

It's not a bad idea to wipe the devices back to a known state, I wonder how long this would take.

As a tangent: Cloning is sometimes discouraged on SSDs because it adversely reduces the number of limited P/E cycles and the limited effectiveness of NAND write leveling in this use case. If the wipes are going to be done on a routine basis, some kind of "rsync" might be better, but care would need to be taken with things like immutable files that might survive through the "wipe".

Another approach might be the possibility to purchase "travel chromebooks" in the secure area of airport. This would allow use during the outgoing flight and at the destination. However, what to do with the unit for the return trip without being wasteful?

You know, this would be impractical for most owners, but at the airport they could actually xray the devices and compare the before/after images to see that no bugs were planted. Ideally this could all be done automatically by the TSA's existing equipment (although bureaucracy would surely get in the way).

Still, in general I feel the question shouldn't be if it can be compromised, but how expensive it would be to do so. No system can guaranty absolute security. A sophisticated attacker could de-solder the chips and replace/reprogram them with compromised chips, which might not show up on an xray. Obviously we're not talking about "script kiddies" here, but I think we need to concede we can't have absolute security.

As for wifi interruptions, Chrome OS could conceivably implement a local work space with automatic synchronization to the cloud whenever in range with a wifi connection of sufficient bandwith to have a high probability of doing it properly.

Yeah, I think that's what jetblue had in mind when they redirected us to an amazon portal (I'm sure jetblue gets paid by amazon). If they had a chromebook loaner program they might do something similar with google.

It its normal (user) mode, a chromebook has a multi-layered self-consistency check on boot. Under such security umbrella, it would be quite difficult for a key-logger to insert it-self into the user interface.

As for social engineering of hooks to get users to disclose their credentials, user awareness and education have been, and will remain, the prime line of defense.

There used to be white-hacker contests to break into various operating systems. Was there ever one involving chromebooks as target? Should there be one?

Low cost chromebooks have plastic shells for a designed life expectancy of maybe three years in the hands of an owner-user. Renter-users tend to be not so gentle with what they rent and there is a high probability that the life expectancy of a rental chromebook would be at the most one year. Physical end-of-life is likely to occur much earlier than wear-exhaustion of the flash chips.

One thing I was forgetting. So far Chrome OS has been relatively unfriendly regarding multi-language capabilities. Smooth switching from a base language (most likely English) to another one would be required for a chromebook rental scheme to even be practical for international flights.

Implementation details of any rental scheme would be most crucial for the concept to be viable.

It its normal (user) mode, a chromebook has a multi-layered self-consistency check on boot. Under such security umbrella, it would be quite difficult for a key-logger to insert it-self into the user interface.

As for social engineering of hooks to get users to disclose their credentials, user awareness and education have been, and will remain, the prime line of defense.

Well, you wouldn't necessarily need to compromise the local machine to display a fraudulent authentication box, it could happen from a user app (even a legitimate one in the app store) or maybe even a webpage. It could even trick a knowledgeable tech person who's let their guard down - and before you judge, how many times do you seriously pay attention to the login screen? It's so routine that it's practically instinctive, and the vast majority of the time it is fine. I think most of us could be caught off guard with a well executed fake...

Mind you I'm not trying to imply it's a bad idea, just trying to highlight potential risks.

Well, you wouldn't necessarily need to compromise the local machine to display a fraudulent authentication box, it could happen from a user app (even a legitimate one in the app store) or maybe even a webpage. It could even trick a knowledgeable tech person who's let their guard down - and before you judge, how many times do you seriously pay attention to the login screen? It's so routine that it's practically instinctive, and the vast majority of the time it is fine. I think most of us could be caught off guard with a well executed fake...

Ideally yes, but I don't like your answer because it assumes the problem is "solved" and doesn't ask the question "what would it take to break it".

We need to be honest here, it still happens to people who let their guard down because the authentication box might legitimately already be open. Or may be logging into a school portal, etc. Especially if the intruder social engineers a scenario that the teachers/staff legitimately encounter anyways then they'll be compromised just by doing the same thing they did a day earlier.

If I were a hacker I would be looking for outside of the box approaches. Without ECC ram (which is generally reserved for expensive server boards) there are viable ways to achieve privilege escalation just by intentionally overheating ram chips and inducing bit errors into the system. To be sure this is a hardware hack and not a software hack, but never the less once pwned you could run an alternative distro that mimicks the login, including ctrl-alt-del for example. Or for something simpler, remove the conductive membrane under the control key, thereby allowing CTRL-ALT-DEL key to be intercepted by a web page, for example. Is the staff going to be checking for that? Hell it would fool 99% of us if we weren't expecting it.

That's the thing, even if we have security procedures and follow them consistently, the unverified assumptions will still leave us vulnerable to certain attacks. In these environments where devices are in the control of potential saboteurs, it can be very easy to become overconfident in the presumed level of security.

Just to reiterate the main point here: we should never assume it's "solved", rather the question needs to be what level of sophistication would be required to compromise it.

The main problem with Chromebooks is insurmountable - they rely on a high speed data connection.

If you live in Australia your Chromebook is basically useless outside of the workplace. The absolutely disastrous home National Broadband Network (NBN) can be as slow as 1MB/s in the evenings. 4G data is far too expensive (~AUD10/GB) and geographically limited to be of any practical use.

Until Chromebooks provide a decent amount of onboard storage and full Android app support they will (IMO) be little more than fancy paperweights.

Maybe Google should send its Chrome OS development team for a code-in sprint in an area of the world with an abyssal broadband speed. This would force the development of an interaction model less dependent on the underlying network.

As I remember the stories from the first years chromebooks were deployed in schools, the major complaint was that the "cloud" traffic was so high that it often brought the school network to its knees. Since then, a hybrid approach allowing/promoting local storage for in-progress documents has been implemented.

It is worth mentioning, as a side bar, that MS Office and Windows it-self are becoming more and more reliant on the underlying network to function properly. Even for the stand-alone version, most of the help information is on-line; no network, no help! I don't know about OS X and how much it relies on the underlying network.

There may be good lessons to be learned about networking in areas with limited network infrastructure from the One Laptop Per Child (OLPC) project.

Maybe Google should send its Chrome OS development team for a code-in sprint in an area of the world with an abyssal broadband speed. This would force the development of an interaction model less dependent on the underlying network.

Yes they could have architected it to support local domain controllers and software repositories using a tiny fraction of WAN resources. It would be much faster, more reliable, and cheaper for many districts. It could be more flexible and potentially even more secure too. These are things that google's product engineers certainly would have discussed from early phases of development. Moreover google didn't design chromebooks in a vacuum they would have had lots of "active directory" engineers on hand, which is the technology used by windows domains and is extremely robust and mature with regards to all these scenarios. So I don't think the dependencies were an engineering oversight, rather I think it was quite deliberate and that google didn't actually want chromebooks running off of networks outside it's control.

I'm not against "cloud features" per say, but how I wish they would be using open protocols and that the owners would be able to elect where to host them (including self hosting) rather than being tightly locked into a hardcoded/proprietary service.

I must comes across as so cynical sometimes, haha. But just so you understand where I'm coming from: there are only a handful of major technology platforms, and I worry about those platforms tightly locking users into their own cloud services, it leaves independent service providers with a substantially unfair disadvantage and owners without sufficient choice over where to host their services (like chromebook being vendor-locked to google). We should not allow one form of monopoly to turn into another using vendor locking.

It is worth mentioning, as a side bar, that MS Office and Windows it-self are becoming more and more reliant on the underlying network to function properly. Even for the stand-alone version, most of the help information is on-line; no network, no help! I don't know about OS X and how much it relies on the underlying network.

Yes, windows 10 is pushing hard in that direction too. Apple's been ignoring OSx for years, but I kind of suspect if it has another push it could go closer to IOS in terms of control and apple store integration. Although I have no particular insights to make such a claim, haha.

One issue with the big three - Apple, Google, and Microsoft - is that they are based in the USA. Thus, they see the world through the inherent filter associated with this base.

Another issue is that advertisement, app stores, and storage services are very lucrative. Like the food counter in a movie theater, the big three have only incentives to "tie" their customers to only their offerings.

Maybe, using the Chromium OS project, one could jump onto non-proprietary services?

The point is 500GB is a very useful amojnt of storage. It would take DAYS to download/upload that much data on the average Australian home connection. It would cost 5 GRAND to download it on 4G.

Having external drives and dongles totally defeats the whole low cost, portability and simplicity paradigm that a Chromebook is meant to provide. You may as well buy a decent laptop and install Linux instead.

The article is about setting up a chromebook as a secure coding platform within the context of the new air travel security measures requiring electronic devices to be checked-in rather than allowed to be carried on.

The chromebook had to be inexpensive enough so that its owner would not cry if it was destroyed or stolen during luggage handling at the airport. As a side note, an inexpensive chromebook is not as tempting as a shinny ultrabook.

Having a 500 GB spinning hard drive, which could be removed from the chromebook and installed in a cryptography cracking system, would defeat the security requirement.

From another angle, how many of the files stored on a drive are truly active - having been accessed, created, or edited in the last couple weeks? Is-it 1%, 10%, 25%? While the actual percentage will vary according to the habits and requirement of any given user, it is much less than the total capacity of the drive.

One great consumer of drive space is media: music, photos, videos. Having the media on removable storage appears to make sense. This approach would allow replacing a destroyed/lost/stolen chromebook with an inexpensive one and avoid having to re-gathered the media collection from the cloud.

Each user will have a preference about internal drive capacity and flexibility with respect to cloud/memory card/USB drive storage. I don't think we are collectively at the state in which the current operating systems smoothly enables this flexibility.

The article is about setting up a chromebook as a secure coding platform within the context of the new air travel security measures requiring electronic devices to be checked-in rather than allowed to be carried on.

I agree with unclefester that most of the chromebooks have inadequate storage for the OS, apps and media. But you are right too, the author clearly intended the laptop to be disposable and obviously didn't intend to keep much on it. IMHO only a privileged person would ever purchase a laptop only to throw it away though. Most people would probably be better suited with something that could last several years, I would think 100GB would be a good minimum for moderate games, videos and pictures on it. I remember years back when hard disks were in the 20-80GB range and running out of space and having to make decisions about what I wanted to keep. 400GB laptops are normal and 1TB+ upgrades are available. Of course it's all about how much we are willing to pay.