Re: LUKS2 support for null/plaintext target

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Monday, December 16, 2019 6:24 PM, Chris Murphy <lists@xxxxxxxxxxxxxxxxx> wrote:

> On Mon, Dec 16, 2019 at 10:08 AM Jordan Glover
> Golden_Miller83@xxxxxxxxxxxxx wrote:
>
> > On Sunday, December 15, 2019 8:49 PM, Chris Murphy lists@xxxxxxxxxxxxxxxxx wrote:
> >
> > > On Sun, Dec 15, 2019 at 10:51 AM Jordan Glover
> > > Golden_Miller83@xxxxxxxxxxxxx wrote:
> > >
> > > > I think encrypting previously unencrypted data on the same disk
> > > > doesn't guarantee that old data won't be recoverable especially
> > > > on ssd/nvme which are ubiquitous today. Officially supporting
> > > > such case on LUKS will give users false sense of security of
> > > > their data.
> > >
> > > This problem exists even in the backup and restore to LUKS encrypted
> > > volume case. In fact it's less reliable because there's no assurance
> > > with backup->restore method that all previously occupied LBAs are
> > > overwritten, whereas an inplace conversion can assure that all LBAs in
> > > the previous range are read and encrypted. It's a matter of
> > > implementation, there's the potential for false sense of security
> > > regardless.
> > > Chris Murphy
> >
> > AFAIK simply overwriting data isn't reliable method for cleaning ssd/nvme.
> > For those either ATA SECURE ERASE[1] or blkdiscard[2] should be used.
> > Unless I'm mistaken, inplace conversion does neither while user can run
> > them manually during backup/restore.
>
> Without testing, which would be make/model/firmware specific, it's not
> certain what really happens on flash memory chips themselves. ATA
> Secure Erase is probably the better recommendation but as both
> ultimately depend on drive firmware to fulfill the operation, it's
> really a big shrug and therefore I reject the idea that there is a
> clear line in the sand. It should be true and probably is true that
> Secure Erase Enhanced or Sanitize are better than blkdiscard. But if
> it's uncertain, on what basis is a line drawn? Upstreams can state
> the facts including the unknowns, and help user and distros draw their
> own line.
>

>From my own testing I could trivially recover files after overwrite but
not after blkdiscard. I can't rule out that some hardware hackers can
recover data after blkdiscard or secure erase but for me the line in the
sand lies between hardware hackers and average Jane that uses google.

> But consider that as a direct consequence of the burden to
> backup->luksFormat>restore, quite a lot of users opt out of encryption
>
> entirely. The point of in-place conversion isn't perfect security.
> It's to get more users to opt in, by reducing the penalty of opting
> in.
>
> False sense of security? We have this problem already with cryptsetup
> --allow-discards leaking fs specific locality in combination with
> fstrim. And fscrypt() leaks quite a lot of metadata. And the ATA spec
> allows reserve and overprovision areas to not be erased with Secure
> Erase, where either Secure Erase Enhanced and Sanitize should cover
> those areas.
>

allow-discards downsides are in different league that recovering
unencrypted data. I believe users will be better off while not using
encryption and knowing that than using encryption in insecure way without
knowing that.

> In place conversion can be better supported in more sophisticated
> environments. Linux installers are already overly complicated and soak
> limited resources maintaining them Opting into encryption right now
> essentially requires either installer support or the burden of backup
> restore. That's not great choices. And what installers provide an ATA
> Secure Erase or Sanitize option? I don't know of any.
>
> Conversely, Windows and macOS use comparatively brain dead installers
> (very simplistic UI, perhaps a few choices at most, pretty much
> amounting to point at a target and push a button). Easy to install.
> Easy to make the encryption decision later without the penalty of
> backup restore. Perfectly secure encryption? I don't know. But the
> barrier to entry is low.
>

I believe referring to Windows as role example undermines your arguments
rather than making  them more compelling. Windows has history of "user
friendliness" like preferring hardware encryption which ended as security
failure:

https://portal.msrc.microsoft.com/en-us/security-guidance/advisory/ADV180028

It also leverages beloved tpm module:

https://pulsesecurity.co.nz/articles/TPM-sniffing

Whatever windows do with encryption it's anti-pattern and cryptsetup should
stay away from that.

Even on linux the "user friendly" installers were storing luks key
in plaintext accessible to anyone:

https://calamares.io/calamares-3.2.11-is-out/

> It is a very different problem where to find the resources to build
> in-place conversion. But I think it's unwittingly asking more users to
> forgo encryption at all to argue against it on the basis that it's
> somehow a significant security risk. How many hours, days or weeks of
> typical usage do you think takes before all cells have either been
> erased or overwritten by encrypted data? There is interim exposure,
> that some use case will care about, but some won't. And that might be
> more useful in assessing a personal line in the sand than
> categorically saying in-place conversion gives a false sense of
> security.
>
> Chris Murphy

I agree that security is hard and users are unsophisticated but I'm not
convinced what you propose will help those people rather than hurt them.
It's easy to imagine that people will believe that their data is encrypted
after install if they use luks and miss the fact that some action is needed
to actually enable encryption.

Jordan
_______________________________________________
dm-crypt mailing list
dm-crypt@xxxxxxxx
https://www.saout.de/mailman/listinfo/dm-crypt



[Index of Archives]     [Device Mapper Devel]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Packaging]     [Fedora SELinux]     [Yosemite News]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux