Ok, here comes a massive post, enjoy reading I sometimes use UEFI, Microsoft and Windows in my explanation, but of course this can by anything. To understand digital signatures, you first need to understand how asymmetrical encryption works. To explain that I'll first explain how symmetrical encryption works. SYMMETRICAL ENCRYPTION Symmetrical encryption is what you will most likely think of when you're talking about encryption. It uses only 1 key, that key is used to encrypt AND to decrypt. A visual example: MESSAGE --encryptWithKeyA--> ENCRYPTED MESSAGE --decryptWithKeyA--> ORIGINAL MESSAGE Here is one major security problem: they key needs to be exchanged between the 2 parties that send messages to each other. This however doesn't matter much here, so I won't talk about that now. ASYMMETRICAL ENCRYPTION Asymmetrical encryption isn't as straid forward as symmetrical encryption, but I won't go into details. It uses 2 keys (A and B). If a message is encrypted with key A, it can be decrypted ONLY with key B. If a message is encrypted with key B it can ONLY be decrypted with key A. This might sound weird, but it's possible because there exists a relationship between the 2 keys. That relationship is based on 2 very large prime numbers, but that will again bring us to far. A visual example: MESSAGE --encryptWithKeyA--> ENCRYPTED MESSAGE --decryptWithKeyB--> ORIGINAL MESSAGE This way of encrypting has 1 major disadvantage: it's slow as s**t compared to symmetrical encryption. But of course there's a good reason for it's invention. If 1000 parties want to send data to for exaple MS, and none of the other 999 parties should be able to read the data, there would be 1000 keys needed for symmetrical encryption. With asymmetrical encryption there's only 1 keypair needed. All 1000 parties encrypt with the public key (which is known by all parties). The data can't be decrypted again with that key, so other parties can't read it. The only key that can decrypt the data is MS' private key (only known by MS). So 2 advantages: - Only 1 keypair. - MS only needs to remember it's own private key instead of all 1000 keys. VERIFYING DATA USING ASYMMETRICAL ENCRYPTION Asymmetrical encryption can be used to encrypt data, but it's used reversed form as explained above. For example MS encrypts data with it's private key (secret). The public key is known by everyone. Now if you need to know if a file is valid, you simple decrypt it with the public key. If the decrypted form is correct, that means that the public key was the correct key. Now that again means that the data was encrypted with MS's private key. That again means that the data did indeed come from MS and is valid. If the decrypted form makes no sence at all, it means that the public key you used to decrypt wasn't the correct one. That can mean 2 things: - The data wasn't encrypted using MS' private key. - The encrypted data got corrupted. There are glitches in this method though. If the data is an executable or dll or whatever, it would need to be decrypted each time if parts of it are needed. A second thing is that it's, as already said, very slow. It also makes no sence to encrypt all the data, afterall it was just to check if it was valid, not to hide the data for other parties. DIGITAL SIGNATURES Because the above method for data validation isn't practical, that's where digital signatures are good for. When using digital signatures, the data itself is left alone, that's ok cause it doesn't need to be kept a secret. Instead a checksum or hash is generated from the data. I think most of the time SHA1 hashes are used. MS then encrypts the hash with it's private key. The encrypted hash is the digital signature. The file and the signature are then combined to 1 file. If you wan't to check if the file is valid, you split the actual file and signature again. Then you decrypt the signature with the public key. The decrypted form is then the hash. You also calculate the hash of the actual file. If the hashes match then you know the file is OK. Of the hashes don't match, there are agian 2 possibilities: - The signature is moddified, which causes the encrypted form to be wrong too. - The file itself was modded (hacked/patched). WHY PATCHING FILES ISN'T POSSIBLE If you patch a signed file, the hash also changes, the signature doesn't match -> windows/UEFI/whatever will know it's patched and block it if it wants too. So you'd say you patch the signature also with the new hash. But that's not possible cause you need to sign it with the key that only MS or the UEFI organization or whatever knows. You have to use that key, cause otherwise the decrypted signature will still be invalid when decrypted with the public key.
There is a good scheme at 27.2.1 (UEFI_2_3_1_Errata_A.pdf). Also workflow 27.7.3.3 Authorization Process. Another thing: Lets say w8 only runs its signed bootloader. A bootloader can be configured (for instance to run w7 additionally) and hence the bootloader data itself change when written (multi boot). How does UEFI know it's an allowed probable config. and no tampered bootloader?
Because the bootloader is always the same and it reads the configuration from a config file. That configfile can only be edited through windows, and windows knows if you,re trying to add "malicious" stuff to the bootconfig. They could do it like that, the only problem is how the bootloader knows if the config file is edited by something else than windows 8.
Or they will only sign the bootloader itself, not the config file, since it is the bootloader that is modified, no? (BOOTx64.efi or BOOTMGR). The BCD file is just a "store" file.
Thats what I mean. The bootloader is signed and always the same. It reads all info about what other oses to boot or other bootloaders to chainload from a config file which is not signed. Uefi only needs to trust the code it directly executes (signed bootloader). For uefi it doesn't matter what's in the config file. That means that something else needs to make sure no "malicious" loaders or stuff get into the config file so the signed loader chainloads them. Cause the oem + signed stuff is for win8, only win8 and maybe 7 and vista with an update should be able to edit the config file. But then the signed loader verifies the config file's signature with a key baked into it. We can't change that key cause that would break the uefi protection stuff and make it unbootable. The vulnerability: fool the win8 config editor to think that the "malicious" code is ok. This could be done by filepatching, cause the file can be restored after the file is edited. When the patched file is restored no spp stuff can say somethig is wrong. But this is all speculation about a possible approach that ms may use... But if we have solutions now already for as much as possible approaches we can think off, the easiest will it be when it's released. Sorry fo this messy post, but the text editor of vbulletin doesn't work that good in the android default browser.
Oh, thanks, how could I miss that? lol... Pretty interesting, looked in two diff. Intel bios's, at first glance it looks like in Intel EFI MSOA is handled by two modules with GUIDs 16D0A23E-... and 4C494E55-..., and what's added for OA3.0 is that it uses familiar looking "MSDMOemTableId", "MSDMOemId", "DmiData" and more suspiciously looking "MSDMData" along with some weird X.X-type numbers,lol. I hope our disassembler-wise guys can tell a bit more...
a quick disassembly an interesting function in the module with GUID of 4C494E55-5849-5342-4554-544552212121 I'm pretty certain that it is building and installing an ACPI table with the signature of MSDM the interesting thing is that MSDMData appears to have a length to 0x31 bytes (49d). Code: ACPI_Install_MSDM proc near; DATA XREF: DllEntryPoint+2Do var_A8= qwordptr -0A8h var_98= qwordptr -98h var_90= byte ptr -90h var_88= qwordptr -88h var_80= byte ptr -80h var_78= byte ptr -78h arg_10= byte ptr 18h arg_17= byte ptr 1Fh arg_18= byte ptr 20h pushrbx pushrbp pushrdi pushr12 pushr13 pushr14 movr11, rsp subrsp, 98h learax, [r11+50h] movrdi, rcx lear9, [r11-68h] mov[r11-78h], rax movrax, cs:EFI_RUNTIME_SERVICES lear8, [r11+48h] leardx, MSDMOemId_GUID learcx, aMsdmoemid; "MSDMOemId" movr13d, 6 movqword ptr [r11-58h], 0 movqword ptr [r11-50h], 0 movdword ptr [r11+48h], 7 mov[r11-68h], r13 callqword ptr [rax+48h] ; EFI_GET_VARIABLE movr14, 8000000000000005h ; EFI_BUFFER_TOO_SMALL cmprax, r14 movr12, 8000000000000000h ; EFI_SUCCESS jnzshort loc_1000038F movrcx, [rsp+0C8h+var_98] callAllocatePool movr10, cs:EFI_RUNTIME_SERVICES lear9, [rsp+0C8h+var_98] lear8, [rsp+0C8h+arg_10] leardx, MSDMOemId_GUID learcx, aMsdmoemid; "MSDMOemId" movrbx, rax mov[rsp+0C8h+var_A8], rax callqword ptr [r10+48h] ; EFI_GET_VARIABLE testr12, rax jnzloc_10000551 learax, [rsp+0C8h+arg_18] xoredx, edx mov[rsp+0C8h+var_98], r13 subrbx, rax loc_1000036D:; CODE XREF: ACPI_Install_MSDM+E5j learax, [rbx+rdx] incrdx cmprdx, r13 movcl, [rsp+rax+0C8h+arg_18] mov[rsp+rdx+0C8h+arg_17], cl jbshort loc_1000036D mov[rsp+rdx+0C8h+arg_18], 0 loc_1000038F:; CODE XREF: ACPI_Install_MSDM+78j learax, [rsp+0C8h+var_90] lear9, [rsp+0C8h+var_98] lear8, [rsp+0C8h+arg_10] mov[rsp+0C8h+var_A8], rax movrax, cs:EFI_RUNTIME_SERVICES leardx, MSDMOemTableId_GUID learcx, aMsdmoemtableid ; "MSDMOemTableId" movebp, 8 mov[rsp+0C8h+var_98], rbp callqword ptr [rax+48h] ; EFI_GET_VARIABLE cmprax, r14 jnzshort loc_10000436 movrcx, [rsp+0C8h+var_98] callAllocatePool movr10, cs:EFI_RUNTIME_SERVICES lear9, [rsp+0C8h+var_98] lear8, [rsp+0C8h+arg_10] leardx, MSDMOemTableId_GUID learcx, aMsdmoemtableid ; "MSDMOemTableId" movrbx, rax mov[rsp+0C8h+var_A8], rax callqword ptr [r10+48h] ; EFI_GET_VARIABLE testr12, rax jnzloc_10000551 learax, [rsp+0C8h+var_90] xoredx, edx mov[rsp+0C8h+var_98], rbp subrbx, rax loc_1000041D:; CODE XREF: ACPI_Install_MSDM+18Fj learax, [rbx+rdx] incrdx cmprdx, rbp movcl, [rsp+rax+0C8h+var_90] movbyte ptr [rsp+rdx+0C8h+var_98+7], cl jbshort loc_1000041D mov[rsp+rdx+0C8h+var_90], 0 loc_10000436:; CODE XREF: ACPI_Install_MSDM+12Bj learax, [rsp+0C8h+var_78] lear9, [rsp+0C8h+var_98] lear8, [rsp+0C8h+arg_10] mov[rsp+0C8h+var_A8], rax movrax, cs:EFI_RUNTIME_SERVICES leardx, MSDMData_GUID learcx, aMsdmdata; "MSDMData" movebx, 31h mov[rsp+0C8h+var_98], rbx callqword ptr [rax+48h] ; EFI_GET_VARIABLE testr12, rax jnzloc_10000551 movrax, cs:EFI_BOOT_SERVICES lear8, [rsp+0C8h+var_88] ;buffer to recieve acpi support learcx, EFI_ACPI_SUPPORT_GUID xoredx, edx callqword ptr [rax+140h] ; EFI_LOCATE_HANDLE_BUFFER testr12, rax jnzloc_10000551 movrax, cs:EFI_BOOT_SERVICES leardx, [rsp+0C8h+arg_18] learcx, unk_10001C3A movr8, r13 movcs:dword_10001C30, 4D44534Dh ; "MSDM" movcs:dword_10001C34, 55h movcs:byte_10001C38, 3 movcs:byte_10001C39, 0 callqword ptr [rax+160h] ; EFI_COPY_MEM movrax, cs:EFI_BOOT_SERVICES leardx, [rsp+0C8h+var_90] learcx, unk_10001C40 movr8, rbp callqword ptr [rax+160h] ; EFI_COPY_MEM learcx, unk_10001C54 leardx, [rsp+0C8h+var_78] movr8, rbx movcs:dword_10001C48, 34h movcs:dword_10001C4C, 20494D41h ; "AMI " callsub_10000E67 movrax, [rsp+0C8h+var_88] ; move acpi support to RAX lear11, [rsp+0C8h+var_80] lear9d, [rbx-13h] leardx, dword_10001C30 movrcx, rax movr8b, 1 mov[rsp+0C8h+var_A8], r11 callqword ptr [rax+8] ; call EFI_ACPI_SET_ACPI_TABLE movrax, cs:EFI_BOOT_SERVICES movrcx, rdi callqword ptr [rax+70h] ; EFI_CLOSE_EVENT loc_10000551:; CODE XREF: ACPI_Install_MSDM+B5j ; ACPI_Install_MSDM+168j ... addrsp, 98h popr14 popr13 popr12 poprdi poprbp poprbx retn ACPI_Install_MSDM endp
The MP Configuration Table usually has the signature PCMP. At offset 28 it can have a pointer to a OEM specified table. Maybe there it points to the new table MSDM. Licensing could happen by using an OEM specified MSDM table. The data size of the table is small, though. So probably MP config table is used to setup a TPM chip (multi processor) and the MSDM data comes from it?????
There is posted about Gigabyte GA-970A-D3 board. BIOS revision (yes BIOS no UEFI) F6 has in the changelog: Modify TPM compatibility. The I/O devices listed: 1 x serial port header 1 x front panel audio header 1 x 24-pin ATX main power connector 6 x SATA 6Gb/s 1 x front panel header 1 x CPU fan header 1 x clearing CMOS jumper 3 x USB 2.0/1.1 2 x system fan headers 1 x 8-pin ATX 12V power connector 1 x power fan connector 1 x Trusted Platform Module (TPM) header TPM function is optional due to different regional policy 1 x SPDIF out In the ACPI module there is the MSDM table 55h byte of size. Data area also 31h bytes.(zeros) Code: Offset 0 1 2 3 4 5 6 7 8 9 A B C D E F 00000260 4D 53 44 4D 55 00 MSDMU. 00000270 00 00 03 00 47 42 54 20 20 20 47 42 54 55 41 43 ....GBT GBTUAC 00000280 50 49 31 2E 30 42 47 42 54 55 01 01 01 01 00 00 PI1.0BGBTU...... 00000290 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000002A0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000002B0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ............... Unfortunately there is no dump somewhere and the table in the ACPI module of the BIOS is 'empty'. WoW, this probably means: OA3.0 will use a TPM chip and no UEFI necessarily. It might be the TPM chip stores the encrypted data for activation...I hadn't expected to find the MSDM table in a BIOS. Anybody with a Gigabyte GA-970A-D3 board and can post an rw everything report? At least we'd see how it's linked.
I have evaluated my thoughts. It seems the MSDM table and the TPM work together. But if OA3.0 uses UEFI specifications additionally cannot be excluded, though. It also could be the TPM is used to decrypt the data of the MSDM table. All is unsure, but we are collecting info.
Could it be that it's either BIOS + TPM of UEFI without TPM? I mean that MS prefers UEFI, but eventually a BIOS could be used if the mainboard builder adds a TPM?
Lol, no surprise. Everyone expects the OA mimicking will become hard / impossible. What's bitter is that the legit user will have to pay the costs for (anti)pirating. (TPM implementation) when buying a preinstalled OEM PC. :crystal: MSDM will become the successor of the SLIC. It's an ACPItable placed in the BIOS /UEFI. It contains an encrypted 'SLIC'. When mapped encrypted to ACPI namespace windows won't activate. Secure boot will prevent a loader additionally. Each OEM has its own MSDM table in their BIOS /UEFI. Together with a matching certificate and serial on the TPM, the TPM will decrypt the MSDM data and stores it on the TPM. 41 bytes should be no problem and will happen fastly. It works like a smartcard when decrypting a TV broadcast. So the MSDM replaces the SLIC and the TPM the COA licensing sticker. How can I be surprised? Lol. -End of story-