Debian Secure Boot: To be, or not to be, that is the question!

🔮🧙‍♀️: If you’re here reading this article, it’s because:
A. You’ve encountered a huuuuugeeee problem with your Linux OS because of Secure Boot (most probably your problem is goodbye 🫡 nvidia kernel module (a.k.a driver) after booting with Secure Boot enabled).
B. You’re a security freak and firmly believe that if there’s a security mechanism, it is absolutely UNACCEPTABLE not to use it on your OS! <--- I am here.

If you fall under category B —or if my crystal ball 🔮 is glitching—here are some scenarios that might lead you to start googling "How to Enable Secure Boot on OS X (Debian, I hope)".

While all my articles are about Debian, this article can still be useful for other Linux OSs since it’s focused on the logic behind Secure Boot.

NB! In this article, I will show how to install NVIDIA drivers on a setup with Secure Boot enabled. However, I will not go into details about the NVIDIA driver installation peculiarities. I have published the separate article on this topic. NVIDIA drivers in this article serve as an example of how to install kernel modules signed for Secure Boot.

So, you’re using your OS, enjoying it, 🦄🌈… and then something happens that pushes you to start digging through forums about Secure Boot. Two possible scenarios:

• You’re using a dual boot setup with Windows and recently upgraded to Windows 11. Windows 11's minimum requirements include Secure Boot. As a result, you disable Secure Boot in the BIOS to log into your Debian system, then re-enable it in the BIOS to log back into Windows. And you are fed up doing this.
• To install and play a video game (like Valorant, FIFA), your system needs Secure Boot enabled. In this case, Secure Boot acts as part of the game’s anti-cheat mechanisms.

What is Secure Boot?

UEFI Secure Boot (SB) is a verification mechanism for ensuring that code launched by a computer's UEFI firmware is trusted. It is designed to protect a system against malicious code being loaded and executed early in the boot process, before the operating system has been loaded. (Source)

Let's decompose it. First, what is UEFI?

About UEFI

UEFI stands for Unified Extensible Firmware Interface.

Unified ...

If you have more than one OS on your PC and not even in dual boot (when more than ONE OSs reside on the same storage device disk), you will still see in BIOS* ONLY ONE storage device to boot from. That is because UEFI has one bootable partition (ESP) ** for the whole PC**. Usually, it is created when you install the first OS. And then if you install something on additional disk —the booting will be done from the first disk where the firstly installed OS resides. So, UEFI should be intelligent enough about loading firmware based on the choice where you want to boot. For example, UEFI will have to load one set of firmware for booting Debian and another for Windows.

...Firmware Interface.

So it is about firmware, as you can guess. Why do we talk about firmware? Is it UEFI who messes up your Bluetooth or Wi-Fi dongles? No, it is not that.

First, a quick reminder: what is firmware? Firmware refers to embedded software which controls electronic devices. So your PC is just a bunch of electronic devices — hardware — CPU, motherboard, video card, SSD disks, some ports like USB ports with something, or ports for cables. You plug in your PC, so all these guys get energy to run and do something... but do what?

When you press the power-on button, all these guys do not just start running and doing something. First, of course, they are having a kind of brain—it is the CPU. But what should the CPU do? Okay, you power-on your PC. If you press some combination of keys that depends on your motherboard brand, you GIVE INSTRUCTION to enter BIOS*. Then in BIOS*, you give instruction from which storage device (disk) to boot.

Okay, you selected to boot from SSD1 where you know you have your Debian OS. You exit BIOS* and wait for booting to finish. But what is going on there behind? WHO is instructing what to do, which hardware to use, and the sequence of actions which should be performed to bring UP your OS? Your OS has a bootloader which is stored in /boot directory/partition. So UEFI just executes the "instructions" found there AND provides an access to firmware to employ hardware for this boot process.

I guess you know that the core of the Linux OS is the Linux kernel. Once launched by UEFI, it takes control over UEFI and makes the rest to boot your OS. Key word related to Secure Boot here is "once launched". If UEFI refuses to execute/launch the kernel of your OS, you are not booting anywhere.

Important to know that when you just freshly install Debian, it has ONLY the kernel gently and with love packed for you by Debian devs. BUT eventually, when you start to perform post-installation configuration... you very probably will start installing some kernel modules that are like _additions to your system's Linux kernel that ALLOW you to use some hardware IN A DIFFERENT way from the default one defined by Linux kernel. Sometimes it is about allowing you to use a hardware piece in general, because it is not possible for some reason within default Linux kernel._

When you install such additional kernel modules, they should also be launched during the booting process together with your OS's kernel.

Coming back to the argument of this article, it is UEFI Secure Boot who can completely block your booting process by refusing to load your OS's kernel, or in the most common scenario, it just refuses to load kernel modules that you have installed additionally.

UEFI vs BIOS

If you noticed earlier, whenever I mentioned BIOS, I was adding a ** * **. Now, I’d like to explain why, to avoid any confusion. You see, the term "BIOS" has become a widely used word, often associated with a specific tool that you access mainly to change the booting process—like booting from an installation medium with a new OS or changing the boot order. Over time, the word "BIOS" stuck and is now commonly used in this context. However, from a technical standpoint, it’s not accurate anymore to call this "startup tool" BIOS. BIOS stands for Basic Input/Output System.

The BIOS in older PCs initializes and tests the system hardware components (power-on self-test or POST for short), and loads a boot loader from a mass storage device which then initializes a kernel. (Source)

However, BIOS is a legacy (term used for an "outdated" software that is still in use) for years. If you’re using a relatively modern machine, what you’re actually using is UEFI—the successor to BIOS, designed to overcome its technical limitations. Some operating systems, like Windows 11, have completely dropped support for BIOS firmware and won’t run on older hardware that relies on it. Additionally, all Intel platforms have also discontinued support for BIOS entirely. (source).

When you access the UEFI BIOS on your PC, you can manage via minimalistic graphical user interface (GUI) rather than the terminal-like interface that legacy BIOS had. You can navigate using a mouse, and there might even be graphical metrics displaying your PC's health and performance. At first glance, you might think UEFI is just the "bad guy" who slapped a GUI onto the old BIOS while introducing complexities like Secure Boot or the frustration of a single boot partition (ESP) that impedes you to have "all parts" of OS together on one disk including bootloader - for example, when running multiple operating systems on one PC, UEFI rules out that all bootloaders are stored on the same disk, where the first OS you installed resides.

However, that negative perception of UEFI isn’t accurate. Legacy BIOS, being a pretty old technology, had significant limitations that made it unsuitable for modern hardware. For instance, it couldn’t handle large storage devices (beyond 2TB), relied on MBR instead of GPT partitioning, and made recovery efforts more challenging when things went wrong. BIOS simply couldn’t meet the demands of modern PCs. So, even if it is possible for you to stick with BIOS, there’s really no reason to cling to such an outdated technology.

By now, you’ve probably realized that Secure Boot is an exclusive feature of UEFI—it’s simply not possible with BIOS.

Secure Boot: myths.

First, a more technical elaboration on what Secure Boot actually is:

Secure Boot (SB) works using cryptographic checksums and signatures. Each program that is loaded by the firmware includes a signature and a checksum, and before allowing execution the firmware will verify that the program is trusted by validating the checksum and the signature. When SB is enabled on a system, any attempt to execute an untrusted program will not be allowed. This stops unexpected / unauthorised code from running in the UEFI environment. (SecureBoot - Debian Wiki)

Myth 1: Secure Boot is a sneaky tool developed by Microsoft to block the use and spread of Linux OS.

This perspective can be found all over Google, and the myth might even seem plausible if you explore your UEFI BIOS settings to enable Secure Boot. For instance, on my ASUS motherboard, enabling Secure Boot requires changing the OS type to "Windows OS." By default, it’s set to "Other OS," which essentially means Secure Boot is disabled.

Even if I do not use Windows on my PC, my OS type is set to "Windows OS" to have Secure boot enabled. How does Windows OS or Microsoft enter into the booting process when you enable Secure Boot? I am continuing to quote the Debian documentation on Secure Boot:

Most x86 hardware comes from the factory pre-loaded with Microsoft keys. This means the firmware on these systems will trust binaries that are signed by Microsoft. Most modern systems will ship with SB enabled - they will not run any unsigned code by default. Starting with Debian version 10 ("Buster"), Debian supports UEFI secure boot by employing a small UEFI loader called shim which is signed by Microsoft and embeds Debian's signing keys. This allows Debian to sign its own binaries without requiring further signatures from Microsoft. Older Debian versions did not support secure boot, so users had to disable secure boot in their machine's firmware configuration prior to installing those versions. (SecureBoot - Debian Wiki)

Debian developers dealt with Microsoft signatures and Debian OS has its UEFI bootloader signed. This means you don’t need to deal with Microsoft to register anything or go through any registration/login ecc processes.

If you’re using the default Debian installer and an "official" Debian Linux kernel (from Debian package repos), Secure Boot shouldn’t pose any problems for booting. However, if your OS doesn’t support Secure Boot or its UEFI loader isn’t signed with Microsoft’s certificates—or if you’re running a custom kernel—this will obstacle the booting process until you have these custom components "signed". However, again, this doesn’t mean that Microsoft is anyhow involved in such signing process.

Secure Boot is about signatures in general, ensuring that only trusted and verified software can run during the boot process.

UEFI Secure Boot is not an attempt by Microsoft to lock Linux out of the PC market here; SB is a security measure to protect against malware during early system boot. Microsoft act as a Certification Authority (CA) for SB, and they will sign programs on behalf of other trusted organisations so that their programs will also run. There are certain identification requirements that organisations have to meet here, and code has to be audited for safety. But these are not too difficult to achieve. (SecureBoot - Debian Wiki)

---

Myth 2: Secure Boot is a security measure you should only consider enabling and configuring if your personal setup is at considerable risk of being physically accessed by unauthorized individuals with the intent to access your data with workaround by booting from external medium or infect your system with malicious kernel/kernel components.

While this statement is partially true—because Secure Boot does indeed protect against physical threats—it’s not limited to that. As I mentioned earlier, one of the reasons you might have found this article is because your NVIDIA drivers aren’t loading after enabling Secure Boot. So, how does that relate to physical access? No one physically implanted those drivers into your system, I assume that you installed them normally while your OS was running. Yet, they’re still being blocked from loading.

That’s exactly what Secure Boot is about: verifying that everything loaded during the boot process (and sometimes even after) is trusted and properly signed. It’s not just about protecting against unauthorized physical access.

Think of it like going to a bank to request a new product. If the bank is reputable, that’s one thing, but in some cases, a bank can overwhelm you with a pile of documents to sign just to get the desirable bank's product. Buried within those documents—perhaps on page N of the nth document—might be a clause stating you agree to an additional product, like a credit card with a sky-high interest rate. The moment you sign, that agreement with the bank takes effect. So, it’s always a good idea to read the details carefully before signing anything.

Secure Boot works in a similar way. UEFI will only load kernels or kernel modules that are signed—anything else gets blocked. Disabling Secure Boot, on the other hand, is like walking into a bank where all their products take effect automatically, no signatures required, just because you asked for them. This lack of "signing step" opens the door to risks.

Above, I’ve mentioned the term kernel modules several times in relation to NVIDIA drivers. But are all your system's drivers kernel modules act and installed in the same way? No. And this is where a potential security gap arises, one that Secure Boot can help protect against. If you’re not sure what exactly you’re installing at certain moment—whether it’s just application software or a kernel module—Secure Boot can step in as a protection layer.

With NVIDIA drivers, it’s a one-way street: you need them to function, so whether they are kernel modules or not, you’re going to install them. But let’s look at another example: imagine your Bluetooth, touch screen, or some other hardware on your laptop isn’t working on a Linux OS. You hit the forums, dig through solutions, and start following instructions: “install this,” “run this command,” “clone this repo,” “build it with make,” and so on. If you don’t fully understand what you’re doing, you’re exposing your system to risks.

Secure Boot won’t protect you from malicious applications you might install, but it will protect your system from malicious kernel additions. If a suspicious or unsigned kernel module tries to load, Secure Boot will block it—end of story.

So, this refusal triggered by Secure Boot can act as a flag, signaling that what you have installed is a kernel module. This gives you the chance to investigate further, understand what you actually installed, and make an informed decision about whether to sign it and enable it or leave it blocked for your safety.

Kernel Modules: Linux Kernel Upstream, DKMS and third party.

Understanding what are the Kernel Modules and where they are coming from is the key in understanding how to make all your OS's components compliant for Secure Boot so they do not fall apart on booting step.

Repeating: when it comes to hardware devices, it’s about drivers, not just software or apps. And drivers on Linux are kernel modules:

Linux device drivers come in the form of kernel modules - object files which may be loaded into the running kernel to extend its functionality. (Debian: Managing the kernel modules)

In case of Debian, where do these drivers come from? Who adds them to the OS?

_Under Debian, the module can be installed from three different kind of sources:

• Upstream Linux kernel modules: Those are shipped in the linux-image-* kernel packages.
• Extra modules, that's aren't in the upstream Linux kernel. Those are usually built using dkms. The available modules can be listed by running apt rdepends dkms.
• Others, like third party, proprietary and other or binary blobs modules... You should not install such modules on your system except when you have no other choice. (Modules - Debian Wiki)_

Most of your PC's hardware relies on drivers from the upstream Linux kernel modules, which are included in the linux-image-* Debian package, which is installed during OS installation, has a version as any other packages and can be upgraded.

Them, there's the DKMS source of kernel modules. NVIDIA drivers, for example, fall into this category. They are third-party kernel modules built using DKMS (Dynamic Kernel Module Support), so they aren’t included directly in the upstream kernel, but neither they are just binary blobs. This makes them part of the second category, not the third, in the list of driver sources I mentioned above.

What is DKMS?

DKMS (Dynamic Kernel Module Support Framework) is a framework designed to allow individual kernel modules to be upgraded without changing the whole kernel. It is also very easy to rebuild modules as you upgrade kernels (Debian - Details of package dkms in bookworm).

Kernel modules in this category can be found in Debian repos, however maybe not always in main component of repo, but also in such components as non-free, contrib and non-free-firmware. (If you do not know how Debian ships its software and you do not know what are Debian repos and how to manage them you can check these articles 1, 2). In most cases, you can find drivers that can be build with DKMS in Debian repos.

Third-party binaries that build kernel modules for you may come on your horizon when some hardware pieces of your machine don’t work on your Debian setup, and drivers aren’t available in Debian’s package repositories. This often happens with Intel wireless adapters, Realtek WiFi chipsets, Bluetooth devices, input devices like keyboards or mice, USB storage devices, and so on.

However, when a hardware piece does not work/function well on your PC, it’s important to understand this difference: driver ≠ firmware! If firmware is missing on your OS, Debian usually informs you (Warning message in dmesg, journalctl, or when you update your kernel. If Debian informs you, that means that it did not manage to fetch it from any repo you have enabled for apt. You may need to add additional repositories (like bookworm-backports) or add components to the stable package repo (contrib, non-free, non-free-firmware). As a last resort, you can fetch a missing firmware directly from the Linux repository(example of available firmware for Realtek WiFi chipsets). Firmware is tightly connected to the hardware device itself, essentially controlling the small controllers and metal chips within the hardware. The firmware is called upon by the driver when the device is in use.

So, if you have firmware but no driver for the device, you won’t be able to use it. Conversely, if there’s a working driver but it can’t find the correct firmware—or the firmware in use is faulty—the device won’t function properly.

For Secure Boot, you don’t need to sign firmware (.fw files), but kernel modules-drivers (.ko files) installed separately (that are not shipped with your OS from the start) do require signing. This is because firmware is invoked by kernel modules, and if those modules are untrusted or not loaded by UEFI, the firmware becomes irrelevant—no one calls or uses it.

With that said, let me conclude about third-party binaries that build kernel modules: use them only in cases of absolute necessity. Don’t resort to them to make some dubious Aliexpress USB “Super Mega Ultra Cool SSD 1,000,000 TB USB3.0” or a random WiFi/Bluetooth USB device work, do not pull something weird on your OS to play with LED colours of your keyboard following a first found guide. While it’s fine for experimental purposes, such as learning how hardware integrates with an OS, I strongly advise against using these solutions for long-term purposes. If something goes wrong, at best, you risk breaking your OS; at worst, you expose you breach security of your system.

Secure Boot Setup: your own signatures

So, now that I’ve hopefully explained the details about Secure Boot, I can proceed with setting it up. In the end, it all comes down to ensuring that your system’s kernel and kernel modules are signed—either with Microsoft signatures or manually using your own signature. A signature, in the context of Secure Boot, essentially is a key.

If you’re a software developer, you may already be familiar with the concept of keys. For example, authentication on GitHub uses ssh keys, or when you need to secure your app’s traffic over the HTTPS protocol, this involves generation of certificates and keys. Similarly, some applications with high-security access use this method of authentication, where access to certain resources is allowed only from specific devices. In such cases, you, the owner of device (PC), generate a key pair—public and private keys—and share the public key with the provider (app's owner). This key is then enrolled in their authentication system, allowing the server to use your shared public key to authenticate your private key when you connect. Your private key always remains only on your device (PC); it should never be shared and must be stored securely. But if you store it securely, there needs to be a system that manages your keys. Otherwise, when a request is sent, it’s not like the authentication mechanism of an app X will search through all the directories on your PC to find a matching private key. Instead, keys need to be created, registered, and enrolled in a structured way.

On Linux OSs, for Secure Boot all "signatures"-keys are managed by shim.

shim is a simple software package that is designed to work as a first-stage bootloader on UEFI systems.
A key part of the shim design is to allow users to control their own systems. The distro CA key is built in to the shim binary itself, but there is also an extra database of keys that can be managed by the user, the so-called Machine Owner Key (MOK for short).(SecureBoot - Debian Wiki)

Decomposing it: Machine is your PC. Machine Owner is you. If you’re using a Linux distro that managed to obtain a Microsoft signature (like Debian OS), your system’s bootloader is already signed (with distro CA key) and compatible with Secure Boot—but not by you, the machine owner. This means that the kernel and the kernel modules that came as part of your distro by default are already signed and you will be booted by Secure Boot with no problem.

However, any kernel module you install or build manually after the initial installation must be signed by you, using your own key—the Machine Owner Key.

Secure Boot Setup: enabling Secure Boot.

Secure Boot is possible only if it is enabled and only on UEFI BIOS. To check this, go to your BIOS* before booting into any installed OS. Look at the title—if you see "UEFI," you’re good to go. However, if your BIOS* has a terminal-like, scary interface and you only see "BIOS" in the titles—sorry, this is the end of the story for you. No Secure Boot.

Anyway, I’ll assume you have a UEFI BIOS. How to enable Secure Boot depends on the brand of your motherboard, as each manufacturer designs it differently. My motherboard is ASUS, so I simply searched online for "enable Secure Boot ASUS motherboard." For me, the guide is this one.

Remember, if you’re using a custom kernel or a distro that doesn’t support Secure Boot by default, you won’t be able to boot once you enabled Secure Boot. Unfortunately, I can’t provide a guide for that case. I’m a Debian girl and I don’t use any other distro (except for Arch ho-ho). However, if you are in that situation, the idea is to do the steps I will describe below before enabling Secure Boot (not only that, however, you will have to deal also with GRUB). Once everything is signed for UEFI Secure Boot, you can enable it in BIOS*.

Disclaimer: For the next steps, I’m not reinventing the bicycle—I’m simply following the Debian Guide on Secure Boot.

Secure Boot Setup: MOK

Let’s align our starting point: there are two possible scenarios:

Scenario 1. You have a fresh install and are about to install some drivers—a kernel module, most likely NVIDIA drivers. In this case, you have two options. Remember the DKMS source for your kernel modules? You can configure DKMS to sign all modules it builds a prescindere (by default). Once that’s done, any module built with DKMS—like NVIDIA drivers on Debian—will already be signed.
Scenario 2. You already have NVIDIA drivers installed, but they don’t work because of Secure Boot. Here, you have two ways to fix this:

• Configure DKMS to sign your modules and then reinstall the drivers.
• Manually sign the kernel modules that are already installed.

I will cover both scenarios.

After enabling Secure Boot in UEFI BIOS, boot into your Debian and check if Secure Boot enabled:

$ sudo mokutil --sb-state
SecureBoot enabled

You can check the list of already enrolled keys with command sudo mokutil --list-enrolled

If you haven't try to do something with key enrollment before, you will most probably see two enrolled keys: one is the Debian key, and the other is the Debian DKMS module signing key. However, even if this key appears in the list, it does not mean that it will automatically be used to sign any additional kernel modules you are about to build (or install). While there is functionality to export the enrolled MOKs for manipulation, using mokutil --export will export all enrolled keys in .der format, and a .der key is similar to .pub keys - they are "public" by nature. mokutil --export will never be able to extract for you private keys that were paired with .der keys. And without a private key, matching to any extracted .der key you will not be able to sign anything.

Therefore, you will need to generate a new MOK for manually signing additional kernel modules you are about to install. By the way, the keys currently enrolled in UEFI, if you did not enroll anything before, are not MOK keys—they are owned by Debian, not you.

In this article, I will be installing the nvidia-driver package from the Debian bookworm repository. NVIDIA drivers are kernel modules, and they require a signature to be loaded under Secure Boot. NVIDIA kernel modules are built using DKMS, if installed with nvidia-driver Debian package.

First, you have to create your first MOK - Machine Owner Key:

$ su - #if you are logged
# mkdir -p /var/lib/shim-signed/mok/
# cd /var/lib/shim-signed/mok/
# openssl req -nodes -new -x509 -newkey rsa:2048 -keyout MOK.priv -outform DER -out MOK.der -days 36500 -subj "/CN=My Name/"
# openssl x509 -inform der -in MOK.der -out MOK.pem

Then, you have to enroll this newly generated key, so it becomes acknowledged by shim and then by UEFI after reboot:
NB! store securely input password, you will need it later!

# exit 
$ sudo mokutil --import /var/lib/shim-signed/mok/MOK.der # prompts for one-time password
sudo reboot

At the reboot, the device firmware should launch it's MOK manager and prompt you to review the new key and confirm it's enrollment (Press any key and then select "Enroll MOK" option, then "continue", then "yes", insert the password you have chosen when you enrolled the key with mokutil --import, then "Reboot"). After this, when you boot again, you can verify:

$ sudo mokutil --list-enrolled
$ sudo mokutil --test-key /var/lib/shim-signed/mok/MOK.der
/var/lib/shim-signed/mok/MOK.der is already enrolled

Secure Boot Setup: Scenario 1 - Fresh install of NVIDIA drivers; configuring DKMS to automatically sign kernel modules.

If you have been following the official Debian guide on NVIDIA drivers installation, you have probably come across the note about Secure Boot. If you clicked on link with "detailed instaructions", you were redirected to the page about Secure Boot and DKMS. However, if you are here reading this article, it probably didn’t work for you.

I installed my Debian system using the netinstall .iso with minimal installation, including only the standard system utilities. I had the kernel and the default kernel modules installed. However, I did not have the kernel headers installed, nor did I have DKMS installed.

To check if your system has the dkms package installed, use the following command:

sudo dpkg -l | grep dkms

If this package is not installed on your system of course you will not be able to "sign" it. When you run 'sudo apt install nvidia-driver', this package as a dependency will bring for you also dkms package. But after doing so, it will immediately proceed with building kernel modules without any signing (not what you want!).

However, if you have dkms package already installed, and if you list the content of directory /var/lib/dkms with ls and you see there keys, you can follow this simple procedure, indicated by Debian devs (you will have to enroll existing automatically generated key):

$ sudo mokutil --import /var/lib/dkms/mok.pub # prompts for one-time password
$ sudo mokutil --list-new # recheck your key will be prompted on next boot

<rebooting machine then enters MOK manager EFI utility: enroll MOK, continue, confirm, enter password, reboot>

$ sudo dmesg | grep cert # verify your key is loaded

However, if /var/lib/dkms is empty or does not even exist you should generate new MOK and then enroll it (with the commands from the previous step).

If your system does not have dkms package installed, you have to install it manually. Pay attention to the dependencies—notice that kernel headers and other kernel related components are included there. Be cautious if you previously upgraded your kernel from the Bookworm backports! In that case, you must also install dkms from the backports; otherwise, your kernel version and kernel-related packages (as headers) will not match.

sudo apt install dkms
#if you installed linux-image-* from bookworm-backports(kernel version >6.1.x)
#sudo apt install -t bookworm-backports dkms
sudo reboot

After rebooting, go to /etc/dkms and run ls—you should see the file framework.conf. Use cat to view its contents, and you will find the mok_signed_key and mok_certificate fields pointing to /var/lib/... However, if these directories are empty, it means there are no keys! In that case, you simply need to modify these lines, and point dkms to existing and enrolled MOK key pair.

ls /etc/dkms
cat /etc/dkms/framework.conf
sudo vim /etc/dkms/framework.conf
#delete '#' in the beginning of the lines!
mok_signing_key="/var/lib/shim-signed/mok/MOK.priv" 
mok_certificate="/var/lib/shim-signed/mok/MOK.der"

Now, you can proceed with NVIDIA drivers installation:

sudo apt install nvidia-driver
sudo reboot

nvidia-smi
modinfo nvidia-current

VOILA!

Secure Boot Setup: Scenario 2 - NVIDIA drivers are already installed; using your MOK to sign installed kernel modules.

If you have already installed NVIDIA drivers and they worked perfectly before enabling Secure Boot but stopped working afterward, you have to repeat the steps mentioned above - generate MOK key-pair and enroll this MOK. Then, if you want that in future all kernel modules built with DKMS are automatically signed, you have to add path to your key pair into the DKMS configuration file. However, if you have installed NVIDIA drivers before, this DKMS config documentation will not have a reverse effect—kernel modules that have already been built and installed will not be signed. You have to sign those kernel modules manually, or reinstalled (rebuild) them. Additionally, if for some reason you plan to install kernel modules that will not be built with DKMS, they will also remain unsigned, and you will have to sign them manually.

For this example, I have installed NVIDIA drivers, but I did not sign anything. Therefore, after I boot, NVIDIA drivers are not available.
I see errors in the dmesg logs from the boot process: in lsmod, I do not see any loaded NVIDIA kernel module, and nvidia-smi shows an error:

However, the drivers are definitely installed! All kernel modules are located in /lib/modules. If you periodically update your kernel version and install a newer version, you will see more than one subdirectory there. I am using the latest kernel, and what I need to check for are updates to this kernel—because when I installed the NVIDIA kernel modules, and since I built the NVIDIA kernel with DKMS, I go to the /dkms subdirectory. Here they are! My NVIDIA driver kernel modules:

So, these kernel modules I have to sign, to make them work under Secure Boot. This is the method indicated by the Debian developers:

#first, you need to create these kernel package-related variables:
$ VERSION="$(uname -r)"
$ SHORT_VERSION="$(uname -r | cut -d . -f 1-2)"
$ MODULES_DIR=/lib/modules/$VERSION
$ KBUILD_DIR=/usr/lib/linux-kbuild-$SHORT_VERSION
$ cd "$MODULES_DIR/updates/dkms" # For dkms packages

#you have to use passphrase you used for enrollment of MOK
$ echo -n "Passphrase for the private key: "
$ read -s KBUILD_SIGN_PIN
$ export KBUILD_SIGN_PIN
#simple bash loop to sign all kernel modules found in the current directory
$ find -name \*.ko | while read i; do sudo --preserve-env=KBUILD_SIGN_PIN "$KBUILD_DIR"/scripts/sign-file sha256 /var/lib/shim-signed/mok/MOK.priv /var/lib/shim-signed/mok/MOK.der "$i" || break; done
#or you can sign modules below the current directory one by one:
$ sudo --preserve-env=KBUILD_SIGN_PIN "$KBUILD_DIR"/scripts/sign-file sha256 /var/lib/shim-signed/mok/MOK.priv /var/lib/shim-signed/mok/MOK.der nvidia-curernt.ko
...
$ sudo update-initramfs -k all -u
$ sudo reboot

Here is my result:

VOILA!

Summarizing (my personal advices):

🦄 Do not neglect this security mechanism; it is neither as scary nor as hard to configure as it may seem.
🦄 Do not disable Secure Boot carelessly.
🦄 Secure Boot protects you not only during the boot process but beyond.
🦄 Adapting your system to be compatible with Secure Boot is simply a matter of generating your Machine Owner Key (MOK), enrolling it (making it visible to UEFI), and then using it to sign your kernel modules or show the software that builds them for you (DKMS) where your enrolled keys are.
🦄 If you are a software developer and still find Secure Boot challenging or restrictive, I advise to reconsider it. Adapting your system for UEFI Secure Boot is an excellent exercise and an opportunity to deepen your understanding of keys, certificates, and key-based signatures—concepts you will undoubtedly encounter frequently in your developer career.