I am about to update the full disk encryption passphrase, to replace the default that was shipped from the vendor and began to wonder when looking into various sources …
What is the CLI command in QubesOS to get an output of all that is supported?
Isn’t what I am looking for likely, and doesn’t work while logged in under that key anyway. Which this is the key I will be replacing eventually once I get my questions answered as to best way to go.
Mainly, I wish to find out what is the highest supported AES standard supported on Star Labs Qubes certificated laptop builds like mine. I know there are higher than AES 256, but is AES 256 the highest supported by my build or can I go higher, e.g. AES 512?
source:
“Check that kernel supports aes-xts-plain64 cipher”
In addition, from my understanding AES is the best from the listed options stated here:
Is my understanding wrong, I been sort of off-and-on over the years following novice encryption threads, and last I checked AES 256 and higher are the best except in the rare Quantum Computing threat scenarios
(which I am currently not worried about as I am not attempting to evade the 5 eyes or 14 eyes governments; merely hardening against extremely advanced targeting by criminal Threat Actors). However, I have never heard of CAST be it cast5 or cast6 so now I am wondering if I missed news articles and if something is actually better than AES as I been lead to believe all these years that AES was the best. Is it?
Is AES 256 the default of LUKS Qubes implantation?
This source post on Qubes Forum makes it sounds like it might be the default:
It’s not Qubes-specific. Sounds like you’re looking for something like this:
No, there’s no such thing. It doesn’t exist.
That seems like an unanswerable question, a bit like asking “Which is the best tool? Is it a hammer or a screwdriver?” The answer is, “It depends on your needs, use case, and criteria.”
Blockquote
If you are unsure, then always choose Argon2id. Only choose Argon2d if you need maximum security at the expense of side-channel risk, and only choose Argon2i if side-channel attacks are the primary threat.
source:
Interesting … thank you for sharing that GitHub discussion thread
Thank you so much for all these cited resources, I am still moving my way through them along with nested cited sources within these sources going down a rabbit hole.
Currently,
I would like to know what CLI command to run so to show me what hash was chosen upon setting up FDE, because my laptop came pre-installed with QubesOS from Star Labs when I bought their only certified Qubes build the StarBook line. I am backtracking, checking all what they did because to my dismay I found out they were sloppy enough to ship a brand new laptop with extremely ancient UEFI versions installed — thus now I want to make sure they didn’t also choose something poorly like sha1 for the AES hashing (because they actually may have if they were willing to ship a new product with an many version ago outdated BIOS omg). My best guess is they went with defaults, but I would prefer to verify for sure.
So how do I check these specs? What are the commands needed in Dom0 and/or as ROOT to see what is the setup for my current LUKS FDE specs? Including seeing the hash cypher type chosen
BUT
the steps aren’t crystal clear for newbies, as it appears it was assumed people knew what they were doing so to follow these steps given so I am slightly confused as to how to input it. I am assuming these are as-is I just have to drop into ROOT or use sudo infront of the commands I am guessing
My understanding thus far is,
ls /lib/modules/$(uname -r)/kernel/crypto/
is the CLI command to list what is supported on my current build.
BUT
it this doesn’t seem to apply to Qubes, I suspect Qubes has a different Path for this Directory?
Or am I supposed to know the Kernel name?
Just as an FYI, some users of this forum interact through email. Updates to posts are not sent to users that are interacting using email. So, when you have new information, it is recommended to submit a new post. (Note: I don’t use the email method, but this is what I have heard)
Your recent update from running lsblk indicates that your LUKS partition is on /dev/nvme0n1p3, so you will use that when running cryptsetup commands.
To view information on your LUKS setup, run sudo cryptsetup luksDump /dev/nvme0n1p3. The output will differ if your system is using LUKS. I believe Qubes R4.2 should install with LUKS2. The top of the output for LUKS2 should look like:
$ sudo cryptsetup luksDump /dev/nvme0n1p3
LUKS header information
Version: 2
In this dump information you should also see several sections
LUKS header information
Data segments
Keyslots
Tokens
Digests
I believe the PBKDF information that you are interested in verifying is for the individual keyslots. Under Keyslots, you should one or more entries that look something like:
(also thank you for informing me about the email update Forum thread stuff too)
I am still reading through and going through your post, but I wanted to stop here at the output as this is the main thing I needed. I see everything but the PBKDF is what I would have chosen. So the defaults are almost all I wanted, and I might keep the PBKDF this default anyway haven’t yet decided.
I do have an additional question regarding this output;
is “Priority” set to “normal” a good choice?
What are the pros and cons to that?
When creating a new FDE before deleting this one, so to change the passphrase … how will I go about also making it a different PBKDF?
Or rather, how would I change the PBKDF?
I have never needed to change the priority of a keyslot and was unfamiliar with this configuration.
From man cryptsetup-config:
--priority <normal|prefer|ignore>
Set a priority for LUKS2 keyslot. The *prefer* priority marked slots are tried before *normal* priority.
The *ignored* priority means, that slot is never used, if not explicitly requested by *--key-slot* option.
This seems like it would only be useful or needed if you had a large number of keyslots. As long as you have only a few or a single keyslot then there should be no reason to configure a prioritized keyslot.
Before I can help you further, I need some clarification on your ultimate goal. Particularly, what do you mean or hope to intend with “creating a new FDE” and “change the passphrase”? Are you looking to change the password that you use unlock your computer’s encrypted drive when you power it on?
I ask this because you may be intending to or want to perform a cryptsetup-reencrypt, which will also reset the LUKS2 master key, and not simply change the passphrase to unlock your computer’s encrypted drive at boot. Given that you receive this laptop prebuilt, I’d probably recommend this step as long as you are comfortable with the possible risks. This resets the “master_key” that is used in the background by LUKS.
Unfortunately, I cannot find a good reference at the moment to explain this. But, there is technically a master_key that is actually used to encrypt and decrypt your disk. The passphrase (and keyslots) that you enter to unlock your encrypted drive are actually unlocking the master_key, which is used to handle drive decryption/encryption.
Passphrase (keyslot) → master_key → LUKS data
Changing your passphrase will not change the master_key. The risk here is that you received this laptop from Star Labs and they may have had access to copy this master_key. You can use cryptsetup-reencrypt to change/reset the master_key.
Yes, because it was shipped by Star Labs with their default very insecure extremely short passphrase. I have the direction to do that, they suggest making a 2nd Key 1st to then proof it works before deleting their Key that the laptops shipped with.
Wait, so then I need to possibly do that rather than this?
Blockquote
sudo cryptsetup luksAddKey /dev/nvme0n1p3
Blockquote
This allows you to check the new additional encryption key works, before removing the generic one. You can add up to 8 keys at one time.
Blockquote
Once you are happy that this is working, remove the original with:
Blockquote
sudo cryptsetup luksRemoveKey /dev/nvme0n1p3
Blockquote
LUKS will prompt you for a password and remove the associated key.
So instead of that
I should do this instead, and even maybe in addition to do this?
cryptsetup-reencrypt
So to,
Oh wow,
I was unaware of this, omg!
Thank you
Then yes, I need to also update the Master Key then too! Thank you so much for catching this oversight as I was completely unaware; and Star Labs did not tell me about this 🫨
and then sudo cryptsetup reencrypt /dev/nvme0n1p3 so it generates a new volume key (note: this op will take a long time).
You can also use luksAddKey instead of luksChangeKey for the first command if you want to retain the old key and verify via a reboot if the new key works before deleting the old key. After that delete your old keyslot (looks like keyslot 0 in your case). And don’t forget to create a LUKS header backup with sudo cryptsetup luksHeaderBackup --header-backup-file my_header_backup_file /dev/nvme0n1p3.
If I understand correctly, every pre-built Qubes OS machine will have an open back door available to the vendor if the master key is unchanged by the user, yes?
Passphrase (keyslot) → master_key → LUKS data
Changing your passphrase will not change the master_key. The risk here is that you received this laptop from Star Labs and they may have had access to copy this master_key. You can use cryptsetup-reencrypt to change/reset the master_key
If they keep a copy of the master key, then obviously yes (they probably don’t, but how would you know?). This is why such vendors usually recommend to re-encrypt the LUKS container after receiving the product in addition to changing the passphrase.
Is such a back door a risk for remote intrusion, or just for physical possession of the device “at rest” as @sm95 briefly informed me about in direct message when I gave an overview of my Threat Model?
Not implying this is not important, it very much is important. I am just wondering is the vendor backdoor executable remotely or not. Like how critical was this type of thing.
Also, this makes me wonder…
In my output I saw that Key Slot 1 and Key Slot 2 were occupied with “boot” stuff.
Does this imply there is likely the same passphrase there too?
But then I saw Star Labs has a new (*)firmware update, which then makes me pause thinking if I do alter the 2 boot slot passphrases will I risk their updates not working or not?
Or is this not applicable if I have a BIOS/UEFI passphrase on the boot like here?
Which I made myself after logging into the BIOS/UEFI without any passphrase and then I gave it a passphrase. I suspect this likely has nothing to do with the LUKS Key Slot 1 & 2, and so the LUKS might override the BIOS passphrase I set through the UEFI, yes/no? Really not sure how this works which is why I am asking.
Sadly it has been 3 business days since I emailed Star Labs about my FDE question and they have not responded, which then makes me wonder are they intentionally NOT informing their customers about the Master Key because in a previous email all they did was send me instructions for only the Key Slots never did they at any time mention their Master Key let alone suggest changing that.
I am growing disappointed with regret, but sadly only Star Labs was within my budget for a “certified Qubes” pre-install build; not a Libre or Purism Laptop as I am operating currently on borrowed funds as I recover from a sophisticated targeted cyber attack and scam that stole over $100K which was everything I had while having no income source then or still yet until I get back online fully as that is how I try to make a living especially given my disability where working from home online is best.
(*) please be aware that for whatever reason Star Labs has attached a “tracking” URL string to the link they sent out in mass email about their firmware update
Nope, those are partitions. Use the sudo cryptsetup luksDump command to view your keyslots.
Those aren’t boot passphrases, but LUKS passphrases…the boot process is prior to the OS being loaded; at the beginning of the OS starting is when you enter the LUKS passphrase. So no, the boot passphrase you set (blue box in screenshot) is something totally different.
Wow, this seems really messed up — or maybe I am misunderstanding this …
So I checked Star Labs StarBook laptop default passphrase on:
• nvme0n1p0 (access is denied, I think is more likely)
• nvme0n1p1 — doesn’t seem to exist (not a valid LUKS device)
• nvme0n1p2 — doesn’t seem to exist (not a valid LUKS device)
• nvme0n1p3 (obviously the one I been on, and is currently running so can’t login as I am already logged-in lol)
So Star Labs shipped the StarBook laptop out with a default “nvme0n1p3” passphrase, and gave me that passphrase obviously and even followed-up eventually admitting how to change it
(was not sent in original instructions, I had to email them to ask how to change it, just wow).
Now, I am realizing that same “default” passphrase is NOT applicable to “nvme0n1p0” and I cannot even access “nvme0n1p0” be it passphrase protected or not. Just says it either doesn’t exist or access is denied. I suspect it is the later, “access denied”
(or do I have the wrong conclusion here?)
My lack of access to “nvme0n1p0” is it because StarLabs restricted access to only them?
OR
Is my lack of access to “nvme0n1p0” because I have enabled a password UEFI boot with AMI (American MegaTrends) which over rides this LUKS KeySlot and so “access denied” is because it isn’t managed under LUKS but under whatever AMI does its key management under?
I am not accusing Star Labs of a KeySlot 0 backdoor, though their lack of informing their customers to change the FDE MasterKey does concern me now as they only ever mentioned and sent instructions only for the KeySlots never ever informing about a MasterKey FDE passphrase. What I am doing is trying to understand why KeySlot 0 is likely “access denied”, while KeySlot 1 & 2 returns as “not a valid device” making it sound like it doesn’t exist; all while implying KeySlot 0 does exist then but access is being denied to not even allow a passphrase to be entered so to block any attempt at all of accessing KeySlot 0.
Is it because I am currently logged into KeySlot 3 and also I guess then currently logged into KeySlot 0 as well due to needing it to enter into the OS? (just thought of this) But then why did it not spit out the same error it did for KeySlot 3, when trying to access KeySlot 0? KeySlot 3 even lets me enter the current passphrase and then returns with an error due to being logged-in, but trying to access KeySlot 0 doesn’t at all behave like the KeySlot 3 input prompt I did.
Please, someone who knows, please clarify what this all means (see screenshots provided).
Just reading this now, I have screenshots now regarding LUKS 0, 1, and 2
I need help understanding what is going on
" Nope, those are partitions. Use the sudo cryptsetup luksDump command to view your keyslots." — @Bearillo
I don’t understand this (also see my previous reply post above this one)
