5 ms·
This is interesting to me, because this is the same sort of thinking that led to the current iteration of Chrome OS devices. While not stateless entirely as the
by Shank 11y ago
This is interesting to me, because this is the same sort of thinking that led to the current iteration of Chrome OS devices. While not stateless entirely as the paper suggests, they clearly have the same train of thought. Without the developer switch flipped, verified boot should entrust that Google (and anyone with its private key) is the sole originator of the code on the device.
I wouldn't suggest using a Chrome OS device for anything where opsec matters, but I find the similarities, at least in thought, striking. Chrome OS's early security benefits were that the device could be trusted if the dev switch wasn't flipped -- and it could be fully wiped and restored on demand if need be. The trusted stick described in the PDF would likely share similar characteristics as far as disposability goes.
- kuschku 11y agoThe issue with ChromeOS is that you know that Google controls everything that’s on it – which is not very useful for someone who wants actual security. A state actor could still force Google to install spyware on the devices. In fact, for chromebooks for education, Google even allows the schools to MitM the traffic of the pupils with no way for the pupil to know it. Which gets risky when the pupils take the device home, and the school still controls it.
- emidln 11y agoHow is that any different than an employer forcing their laptops provided to employees through a VPN (where the user is subject to inspection/blacklist/whitelist/etc) all the time? In both situations you have a machine provided to someone for a specific purpose (business/education) that likely describes extremely particular acceptable use cases. MITM traffic on whatever network seems like a valid way to enforce that. Doing your banking on your own machine.
- kuschku 11y agoBecause in many cases these pupils take it home, and use it for private usage?
- pierrec 11y agoThese forced MitMs are all very similar, though I don't see how that gets us anywhere. It's not a valid way of enforcing any policy no matter how twisted, because people will root their devices and circumvent the lock-down. The reason I call it twisted is because I'm wondering why that lock-down is necessary in the first place: you don't want them to "abuse" the device, causing potential damage? This might be a valid concern with company cars due to the life-threatening aspect of driving, but extending this concept to laptops seems abusive. Either way, the risk posed to the school or company's assets can be effectively taken into account by some kind of insurance policy, not by attempting to lock down the device.
- jackgavigan 11y ago"So how did the hackers get into the corporate network?" "One of our execs downloaded a game from the Internet that contained malware and then he connected his laptop to the corporate network..."
- kuschku 11y agoIf a single person with a laptop can damage your whole network, you have completely different issues.
- anonbanker 11y agoThen install ChromiumOS, which doesn't include the botnet. Or GalliumOS, which is even better. Then replace/restore the write-protection.
- kuschku 11y agoYes, that is one solution. I’m just arguing that Secure Boot or similar solutions don’t mean that you can make sure to always know what’s on the system, but that the person with the keys can. In this case, that’s an employee at Google.