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