::: success
# SSN Lab № 2 Assignment: UEFI Secure Boot
**Name: Khasan Abdurakhmanov**
:::

1. Microsoft signs Canonical's “shim” 1st stage bootloader with their “Microsoft Corporation UEFI CA”. When the system boots and Secure Boot is enabled, firmware verifies that this 1st stage bootloader (from the “shim-signed” package) is signed with a key in DB (in this case “**Microsoft Corporation UEFI CA**”)
2. The second stage bootloader (grub-efi-amd64-signed) is signed with Canonical's “Canonical Ltd. Secure Boot Signing” key. The shim 1st stage bootloader verifies that the 2nd stage grub2 bootloader is properly signed.
3. The 2nd stage grub2 bootloader boots an Ubuntu kernel (as of 2012/11, if the kernel (linux-signed) is signed with the “Canonical Ltd. Secure Boot Signing” key, then grub2 will boot the kernel which will in turn apply quirks and call ExitBootServices. If the kernel is unsigned, grub2 will call ExitBootServices before booting the unsigned kernel)
4. If signed kernel modules are supported, the signed kernel will verify them during kernel boot”

<center>

### Task 1 - Firmware Databases
</center>

**1. Extract the Microsoft certificate that belongs to the key referred to in Step 1 from the UEFI firmware, and show its text representation.**

To extract the Microsoft certificate associated with the key mentioned in step 1 from the UEFI firmware, we have the option of utilizing **efitools** and **openssl x509**.
First of all we should install the efitools package on our system. We'll use this command:
<center>

**sudo apt-get install efitools**

Figure 1: Installing efitools package

</center>

After that we should find the key identifier of UEFI variables and use this command:
<center>

**sudo efi-readvar**

Figure 2: UEFI variables
</center>

In this process, we are using the **efi-readvar** command to list all available UEFI variables in the terminal and find the key identifier for the Microsoft certificate that belongs to the key referred to in Step 1. We are running the command sudo efi-readvar to display a list of UEFI variables with their attributes.

<center>

Figure 3: Microsoft Corporation UEFI CA 2011
</center>

Once we have the key identifier, we can use the efi-readvar command again to extract the key.

<center>

Figure 4:Saving the values into files

Figure 5: We got 4 files

</center>

> efi-readvar -v PK -o PK.esl # **Platform Key (PK).**
> efi-readvar -v KEK -o KEK.esl # **Key Exchange Key (KEK).**
> efi-readvar -v db -o db.esl # **Signature Database (DB); aka Allow list database.**
> efi-readvar -v dbx -o dbx.esl # **Forbidden Signature Database (DBX); aka Deny list database.**

*After that we should convert them into compatible **.der** or **.hash** files*

<center>

Figure 6 : Converting process

Figure 7: We'll get these files
</center>

and then use openssl x509 to extract the Microsoft certificate that belongs to the key.
<center>


Figure 8: Microsoft Certificate
</center>

**2. Is this certificate the root certificate in the chain of trust? What is the role of the Platform Key (PK) and other variables?**

> A **Root certificate** is a self-signed certificate that follows the standards of the X.509 certificate. A multi-level hierarchical chain of trust enables web clients and applications to verify a trusted source has validated the identity of the end-entity.

We can tell a root certificate from an intermediate one by inspecting the certificate itself. If the Issued to and Issued by fields are identical, then it's a root certificate, as only a valid certificate authority can issue trusted roots; otherwise, it's an intermediate.

We can tell a root certificate from an intermediate one by inspecting the certificate itself. If the Issued to and Issued by fields are identical, then it's a root certificate, as only a valid certificate authority can issue trusted roots; otherwise, it's an intermediate.

<center>

Figure 9:The Root Certificate
</center>

* **PK (Platform Key)** - This is the primary (single) key of the system. It is often the key of the hardware manufacturer.
* **KEK (Key Exchange Keys)** - A key used for key exchange. There can be several of these keys.
* **db (database of allowed keys)** - This list contains the very keys that are used to verify the signature of UEFI programs loaded by UEFI.
* **dbx (revoked keys database)** - This is where compromised keys are stored. Program code signed with such keys will not be loaded and executed.

<center>

### Task 2 - SHIM
</center>

**1. Verify that the system indeed boots the shim boot loader in the first stage. What is the full path name of this bootloader?**

We can verify that the system boots the shim boot loader in the first stage by using the **efibootmgr** command.

<center>

Figure 10: Shim boot loader
</center>

This command displays a list of boot options, including their boot order, boot mode and file path.
Full path of bootloader is : **File(\EFI\ubuntu\shimx64.efi)**

**2. Verify that the shim bootloader is indeed signed with the “Microsoft Corporation UEFI CA” key.**

To verify that the shim bootloader is signed with the "**Microsoft Corporation UEFI CA**" key, we can use the **sbverify command**. First, we need to extract the public key of the "**Microsoft Corporation UEFI CA**" key in **PEM** format. We can do this by running the following command:
<center>

**sudo sbsign --cert /boot/efi/EFI/ubuntu/shimx64.efi > db-chain.pem**
Figure 11: Extracting the public key
</center>

After we can verify that the shim bootloader is signed with the "**Microsoft Corporation UEFI CA**" key:
<center>

Figure 12: Process of verifying
</center>

**5. What is the exact name of the part of the binary where the actual signature is stored?**

The actual signature of a binary file is stored in the **"Attribute Certificate Table" (ACT)** structure within the binary. This table contains one or more attribute certificates. Each attribute certificate contains information about the signer and the signature, including the signature itself. The ACT structure is part of the binary's header, and its location and size are specified in the binary's optional header.

**6. In what standard cryptographic format is the signature data stored?**
The signature date store in format "**Cryptographic Message Syntax
Standard**"
> The Cryptographic Message Syntax (CMS) is an internationally recognized standard developed by the Internet Engineering Task Force (IETF). Its primary objective is to ensure the utmost security and integrity of cryptographic messages. It is used by cryptographic systems and protocols to digitally sign, hash, authenticate, or encrypt various forms of digital information.

* **Start pyew from the command line with the full name of the shim binary as argument.**

<center>

Figure 13: Pyew command
</center>

* **Wait for the pyew prompt to appear (it will do an analysis on the binary which you can interrupt with Ctrl-C if it takes too long)**

* **Type pyew.pe.OPTIONAL HEADER.DATA DIRECTORY to get a listing of all data directory entries.**

<center>

Figure 14: Listing of all data directory entries
</center>

* **Locate the one called IMAGE DIRECTORY ENTRY SECURITY. The location and size are given as the “VirtualAddress:” and “Size:” field**

*<Structure: [IMAGE_DIRECTORY_ENTRY_SECURITY] 0x128 0x0 VirtualAddress: 0xE8270 0x12C 0x4 Size: 0x2568>,*

* VirtualAddress: **0xE8270 0x12C 0x4**
* Size: **0x2568**

**7. Extract the signature data from the shim binary using dd. Add 8 bytes to the location as given in the data directory to skip over the Microsoft WIN CERTIFICATE structure header (see page 14 of the specification if you are interested).**

<center>

Figure 15:
</center>

**8. Show the subject and issuer of all X.509 certificates stored in the signature data. Draw a diagram relating these certificates to the “Microsoft Corporation UEFI CA” certificate.**

<center>

Figure 16: Extracting the certificates

Here we got the files in this folder "**_signature.bin.extracted**"

Figure 17: Location of certificates
</center>

And after we use the oppenssl x509 command opened each of these certificates:
<center>

Figure 18: 15CF Certificate

Figure 19: 475 Certificate

Figure 20: EBB Certificate
</center>

**Subject and Issuer of X.509 Certificates:**

- Subject: C = US, ST = Washington, L = Redmond, O = Microsoft Corporation, CN = Microsoft Root Certificate Authority 2010
Issuer: C = US, ST = Washington, L = Redmond, O = Microsoft Corporation, CN = Microsoft Root Certificate Authority 2010
- Subject: C = US, ST = Washington, L = Redmond, O = Microsoft Corporation, CN = Microsoft Time-Stamp PCA 2010
Issuer: C = US, ST = Washington, L = Redmond, O = Microsoft Corporation, CN = Microsoft Root Certificate Authority 2010
- Subject: C = US, ST = Washington, L = Redmond, O = Microsoft Corporation, CN = Microsoft Corporation Third Party Marketplace Root
Issuer: C = US, ST = Washington, L = Redmond, O = Microsoft Corporation, CN = Microsoft Corporation Third Party Marketplace Root
- Subject: C = US, ST = Washington, L = Redmond, O = Microsoft Corporation, CN = Microsoft Corporation UEFI CA 2011
Issuer: C = US, ST = Washington, L = Redmond, O = Microsoft Corporation, CN = Microsoft Corporation Third Party Marketplace Root

<center>

Figure 21: it shows the relationship between the certificates
</center>

<center>

### Task 3 - GRUB (BONUS)
</center>

**9. Using your new knowledge about Authenticode binaries, extract the signing certificates from the GRUB boot loader, and show the subject and issuer.**
<center>

Figure 22: Using pyew command
</center>
**<Structure: [IMAGE_DIRECTORY_ENTRY_SECURITY] 0x128 0x0 VirtualAddress: 0x279000 0x12C 0x4 Size: 0x788>,**

<center>

Figure 23: Using pyew.pe.OPTIONAL_HEADER.DATA_DIRECTORY

</center>

<center>

Figure 24: Byte offset
</center>

The command is used to copy data from the file **/boot/efi/EFI/ubuntu/shimx64.efi** to a file named **signature_.bin**. The data is read starting at byte offset **0x279000 + 0x12C + 0x4 + 8** and continues for a length of **0x788 - 8 bytes**.

> You now know that the GRUB binary is indeed signed, but how does shim verify this
> signature? To do so shim needs a certificate that it trusts and which must not be modifiable
> by an external party without detection. The solution chosen by Ubuntu is to store a
> certificate in the shim binary. We will call this certificate X.

<center>

Figure 25: Secure certificate
</center>

**10. Why is storing the certificate X in the shim binary secure?**

Storing the certificate X within the shim binary is secure because the shim binary itself is signed by a known and trusted certificate authority. Any alterations made to the shim binary, such as attempting to modify or replace the embedded certificate X, will result in the signature chain being disrupted and cause the bootloader to fail in loading. This ensures that only trusted code can be executed at boot time, providing a higher level of security for the system.

**11. What do you think is the subject CommonName (CN) of this X certificate?**

I think it might be **"Canonical Ltd. Secure Boot Signing "**

**12. Obtain the X certificate used by the shim to verify the GRUB binary.**