On Wednesday, December 4, 2019 12:38:20 PM MST Przemek Klosowski via devel wrote: > - stolen/lost laptop: I think this is the most important one for most > people; it is mitigaged by a trusted-network-based decryption, unless > the device is in unencrypted sleep mode and the new 'beneficial owner' > manages to read the disk before the system goes down. That may be the case for home users, but not for businesses. Let's take this example. Employee A has files from a given project, but Employee B doesn't have access to that project. Employee B is malicious, and takes Employee A's laptop, gets it on the network, it unencrypts itself and then takes it. The data is not Employee B's. > - someone breaks into your home/office/hotel room and extracts the data: > important to some people but not very common scenario. This is important to most businesses. > You are correct that it's hard to mitigate both of those threats, but I > think the first one is the primary concern. > > To be clear, I was suggesting a network scheme where your device > authenticates from e.g. a trusted subnet to a known server IP with a > specific certificate associated with this IP. To defeat this, you can't > just set up a a fake IP network ---you would have to somehow break into > (physically or at least electronically) the trusted subnet. Right, of course. The only method for network based decryption that I am aware of is a server that you must set up. I don't think a > By the way, as I said. Android/IOS solved those issues by having a > secure boot process, There's nothing inherently "secure" about Android's boot process, though I'm not familiar with that of iOS. Depending on the version, and this is different in the most popular fork, a key is either immediately requested to decrypt the system or the system itself is unencrypted to begin with, and key is requested to decrypt user data. > so the OS can fully boot and will keep the secrets > until local ( or possibly remote) authentication. See above. > So this is a solved problem, and perhaps we should be looking into securing > the full boot process instead of trying to mitigate threats resulting from > the holes in it. Well, it really isn't a "solved problem". Most of these "secure boot" solutions don't actually do anything that makes them inherently secure, vboot included. They're just trusting a vendor key, by default. -- John M. Harris, Jr. Splentity _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
