Linked by Thom Holwerda on Fri 28th Jul 2017 19:44 UTC
Google

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.

Interesting guide on how to turn an inexpensive Chromebook into a burner developer device safe for international travel.

Thread beginning with comment 647279
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[4]: Practical tutorial
by BlueofRainbow on Sat 29th Jul 2017 21:15 UTC in reply to "RE[3]: Practical tutorial"
BlueofRainbow
Member since:
2009-01-06

Alfman:

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.

Reply Parent Score: 2

RE[5]: Practical tutorial
by Alfman on Sat 29th Jul 2017 22:00 in reply to "RE[4]: Practical tutorial"
Alfman Member since:
2011-01-28

BlueofRainbow,

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.

Reply Parent Score: 2

RE[6]: Practical tutorial
by Megol on Sun 30th Jul 2017 12:20 in reply to "RE[5]: Practical tutorial"
Megol Member since:
2011-04-11


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...


CTRL+ALT+DEL solves that problem.

Reply Parent Score: 2