1

After successfully installing Linux Mint 19.1 Cinnamon for the first time, I went through the recommended steps to take after the installation. Here I also upgraded my system (after checking for and installing drivers). During this upgrade process however, following message popped up:

Your System has UEFI Secure boot enabled. UEFI secure boot is not compatible with the use of third party drivers. The System will assist you in disabling UEFI secure boot. To ensure that this change is being made by you as an authorized user, and not by an attacker, you must choose a password and then use the same password after reboot to confirm the change. If you choose to proceed but do not confirm the password upon reboot, Ubuntu will still be able to boot on your system, but these third party drivers will not be available for your hardware.

I then set a MOK PW and rebootedd the machine, signing the key. However, i don't really know what prompted this message, and what key I signed there. I am thinking it had to do with the third-party Nvidia-driver I had installed before, since I rolled back my system yesterday with timeshift to right after the driver installation (before the system update). Then I disabled the nvidia graphics card (for which the driver was for), and upon updating the system once again, no message which prompted me to sign a key popped up.

One of the currently signed keys, which i suspect it might be, has the following attributes, which sound bad:

X509v3 Basic Constraints critical

CA: False

All in all my main questions are as follows: What does this all mean? What did I actually do with signing said key, and does this affect my system in any negative way? How can i find out what key i originally signed there and if said key is "safe"?

1

In X.509v3 certificate lingo, a certificate extension can be specified as critical if the creator of the certificate (and/or the certifying authority) requires that whoever is validating this certificate must understand this extension or else treat this certificate as not valid.

The "Basic constraints" extension is the most fundamental certificate extension: it determines whether the certificate is a regular certificate ("CA: False") or a Certification Authority certificate ("CA: True", with an optional path length value, i.e. the maximum allowed depth of intermediate CA certificates after this CA certificate).

In all modern systems, the "Basic constraints" certificate extension should always be a critical extension.

So, these attributes:

X509v3 Basic Constraints: critical
CA: False

mean in human terms: "This is not a CA certificate. If it appears in a situation where a CA certificate would be needed, someone is definitely doing something wrong. If you don't understand this restriction, you should not rely on this certificate for any purpose at all." In other words, this is a perfectly normal and expected extension on any non-CA certificate.

A non-critical X.509v3 extension should be safe to ignore if its meaning is not understood by the program attempting to validate the certificate.

Since Secure Boot cannot be expected to check with any Certification Authorities at boot time, these attributes don't really have any meaning to Secure Boot. When Secure Boot is in effect, the firmware is supposed to verify that any requests to change the existing Primary Key (PK) or Key Exchange Keys (KEK) are signed with the private key corresponding to the current PK certificate, and that any requests to update the existing whitelist (db), blacklist (dbx) or timestamp (dbt) keys are signed with a private key corresponding to the current PK certificate or any of the current KEK certificates. At boot time, any executable code loaded should not match any of the blacklist (dbx) entries and should either be signed with a key matching one of the whitelisted (db) certificates, or the executable's cryptographic hash should be included in the whitelist directly. These checks are completely independent of the X.509 PKI hierarchy.

The Secure Boot key certificates can still be part of a company's PKI hierarchy, so that the certificates can be externally verified if necessary, and at that point, the X.509v3 certificate extensions may come into play. But for boot-time Secure Boot checks, any X.509v3 certificate extensions seem to usually be completely ignored.

Because it turned out that some system firmwares don't allow the system owner to modify the Secure Boot keys in a useful way, a shim.efi bootloader was developed. It provides an extension scheme to Secure Boot: the shim.efi is signed by Microsoft, and it provides a second whitelist (MOK, Machine Owner's Key) that is reasonably strongly guaranteed to be independent of firmware control, but otherwise under similar security conditions as the other Secure Boot key variables.

The MOK enrollment process deals with NVRAM variables and shim.efi, so the results of the operation are not stored in regular files that could be rolled back with timeshift or similar. In fact, it looks like that the appropriate NVRAM variables are created with attributes that specify UEFI boot service access only, so only shim.efi or another UEFI boot-time tool could modify them once created... assuming that the firmware works according to the UEFI and Secure Boot standards.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.