QUBES 4.0: How to change LUKS Full Disk Encryption password?

[Michael]

I have just installed Qubes 4.0 but I want to change my full disk encryption password as it is very weak, how would I do that through the dom0 terminal?

[donoban]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

You can add a new password on an empty slot and then remove the old
password.

(From AEM README)

* determine the path to LUKS-encrypted disk (usually /dev/sda2)
* add a new password with `sudo cryptsetup luksAddKey <disk>`
* remove old one with `sudo cryptsetup luksRemoveKey <disk>`

If you have an SSD:

Beware that solid-state devices will most likely NOT overwrite the
LUKS header, but rather write the new one into another memory cell
(due to wear leveling algorithms designed to prolong SSD life).
If you're worried about this and have recent-enough backups (as
you always should), perform an ATA secure erase of the whole SSD
using a live CD and then reinstall Qubes OS.
https://ata.wiki.kernel.org/index.php/ATA_Secure_Erase

I do not know if there is some way to force it to be deleted or if
this is not relevant for recent SSD drives.
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEznLCgPSfWTT+LPrmFBMQ2OPtCKUFAls/w0oACgkQFBMQ2OPt
CKVbpRAAi7seR8ZW7YACIH3PoLYyruPa6njqeJ+UVDeSRKPQGNnTPbwiqtvdu70f
bTvFIJ8Iuwajzms2fqM/MCI2teF1Iw2YPWuQ1fBv9tU9YtPoi11Mw3c4Ds4njMVK
z6WL6yItYz348ZUbKd92umbZFris8NcGxQ6c7BX1A3obyoQvo7XlGVlOxfeHYlkU
tAPNe3IvwFbegYLMhbMHuDm43dQt7GLXVPy4AEP1GsrLzsNT3lMHkO+clswb9IwZ
pbMlhaqbD0FvuQubafI0C4UKckJRU36EeiR+LdZ5mHGRk/KaKlF4j7NqJqyj4Hg8
ipmvzSoLX835ODEoRZYDzZNVx4z0/HGqkmWMh6GvfS5mSxX8XyaR/GzHW1E1y9OP
33++loWwo48MrVQngnTSBm367JclsokWVL70ynqygkTenHJQS73FUoFNOdqgSr58
vaV+OxOOJ/5VIU89LFOwYCIK2d1Kf5aUl08JH82teoPgSxT6mA0bhAfW2hbDQvLx
mQzO/gWO1Ee3hLplcHNzJLJP1ZZSSK96orrVnh/u8WPEvmfyE1ByzB4AFvcr1ovN
QydXZA2OG7nGyHU+U+E4Q1RWqpyQvLxUsunXk3iWwLf4FkJ4I3g5S5KtVN7AWIj1
zVSlerZdAGOrcEaHPE/C73ZJhY6HWvih3cFoUyxMSD9a/xhEasI=
=obJQ
-----END PGP SIGNATURE-----

[brenda...@gmail.com]

On Friday, July 6, 2018 at 3:30:28 PM UTC-4, donoban wrote:
> -----BEGIN PGP SIGNED MESSAGE-----

> If you have an SSD:
>
> Beware that solid-state devices will most likely NOT overwrite the
> LUKS header, but rather write the new one into another memory cell
> (due to wear leveling algorithms designed to prolong SSD life).
> If you're worried about this and have recent-enough backups (as
> you always should), perform an ATA secure erase of the whole SSD
> using a live CD and then reinstall Qubes OS.
> https://ata.wiki.kernel.org/index.php/ATA_Secure_Erase
>
> I do not know if there is some way to force it to be deleted or if
> this is not relevant for recent SSD drives.

Unfortunately, the erase block size is usually 4MB or so. Therefore, while it's *better* to do a full trim of all logical volumes/partitions on the drive immediately after deleting and/or "overwriting" sensitive data you wish to be erased, it's very difficult to really erase "overwritten" data on the drive. That's why I always recommend using both software encryption (LUKS) and hardware encryption (an OPAL supporting SSD with either OPAL enabled via sedutil or ATA password under the OPAL compliance requirements).

As implied above, trim does not guarantee immediate erasure. However, it increases the likelihood of the block in question being erased sooner by ensuring:
a) that part of the block is marked as no longer in use and
b) as many other blocks are marked as no longer in use as possible.

The background "ssd filesystem layer processes"* on contemporary drives seeks out partially used flash blocks and, for slowly-changing data areas, combines them into more fully used blocks, reaping the remaining no-longer-used 4MB content by erasing the physical flash blocks. This assures a higher amount of empty, fully-writable flash blocks available for the next peak write session.

If you're paranoid (and some should be) - rather than reinstall, I'd recommend the following:
a) ata secure erase or ata sanitize a new SSD drive of the same size and type;
b) make the LUKS password change as above;
c) clone your current drive onto the new, erased drive (don't reverse this by accident...);
d) swap the new drive for the old drive;
e) boot up the new drive a few times and use it for a while to make sure it works;
f) ata secure erase and/or ata sanitize the old drive. I usually do an ATA Secure erase, an ATA Sanitize Crypto Scramble and then another ATA secure erase. Very quick.**
g) validate that the old drive is erased.

Brendan

*this is the internal filesystem of the drive that maps physical flash blocks into a series of logical blocks to optimize wear leveling, avoid write amplification, etc..., not your user-exposed filesystem.

** when thinking more paranoid, I do: a) ata secure erase, b) write data to a randomly-chosen block x, c) ata sanitize crypto scramble, d) verify that many sample blocks are still zero but block x and sometimes some adjacent blocks (depending on manufacturer/controller) now appear to have non-zero randomized data in it/them because the drive's user area key has been changed, e) ata secure erase.

[Bill]

It's not /dev/sda2. Could you help me with getting this figured out? I did a 'lsblk' on dom0 and the luks is attached to nvme0n1 > nvme0n1p1 > nvme0n1p2. Is any of these the partition? If not how can I determine this correctly?

Thank you.

[awokd]

On Wed, July 25, 2018 3:37 am, Bill wrote:

>
> It's not /dev/sda2. Could you help me with getting this figured out? I
> did a 'lsblk' on dom0 and the luks is attached to nvme0n1 > nvme0n1p1 >
> nvme0n1p2. Is any of these the partition? If not how can I determine this
> correctly?

sudo cryptsetup status <LUKS-UUID>

[Bill]

Thank you