Skip to content

[Secure Boot KEK Update] MiTAC PK-Signed KEK Update#374

Closed
ZitoChung3 wants to merge 2 commits into
microsoft:mainfrom
ZitoChung3:kek-update/MiTAC
Closed

[Secure Boot KEK Update] MiTAC PK-Signed KEK Update#374
ZitoChung3 wants to merge 2 commits into
microsoft:mainfrom
ZitoChung3:kek-update/MiTAC

Conversation

@ZitoChung3
Copy link
Copy Markdown
Contributor

@ZitoChung3 ZitoChung3 commented Mar 25, 2026

OEM Certificate Submission

OEM Name: MiTAC
Contact Email: zito.chung@mitacmdt.com

Certificate Details

  • Platform Key Thumbprint: NA
  • Expiration Date: 2023-04-25, 2043-07-18

Testing Completed

  • [V] Windows validation
  • Linux validation

Security Review

  • [V] No known security issues

Additional Notes

Upload two KEK signed by different PK keys: one PK expiration is 2023-04-25, and another is 2043-07-18.

@ZitoChung3
Copy link
Copy Markdown
Contributor Author

ZitoChung3 commented Mar 25, 2026 via email

@ZitoChung3
Copy link
Copy Markdown
Contributor Author

ZitoChung3 commented Mar 25, 2026 via email

@Flickdm
Copy link
Copy Markdown
Member

Flickdm commented Mar 25, 2026

FYI @jgeurten @hughsie

@hughsie
Copy link
Copy Markdown

hughsie commented Mar 26, 2026

@Flickdm I normally sync LVFS when it's merged; would you prefer if I synced after the CLA is signed?

@Flickdm
Copy link
Copy Markdown
Member

Flickdm commented Mar 26, 2026

@Flickdm I normally sync LVFS when it's merged; would you prefer if I synced after the CLA is signed?

No thats fine, this is more just an informational message if you didnt see it

@ZitoChung3
Copy link
Copy Markdown
Contributor Author

Do you have an estimated date to merge it to main?

@Flickdm
Copy link
Copy Markdown
Member

Flickdm commented Apr 1, 2026

@ZitoChung3

Thanks! It looks like the PostSignedObjects/KEK/kek_update_map.json has more changes than I expected. Rather than have you fix the file, why don't we drop the changes and I'll fix it up myself after your binaries gets in.

Other than that your auth variable updates looks like it will be successful!

Let me know if you need help with the git commands.

Once you do this, I'll approve and get it merged.

INFO:root:Validating: KEKUpdate_MiTAC_PK1.bin
INFO:root:Verifying authenticated variable: review/KEKUpdate_MiTAC_PK1.bin
INFO:root:[+] Authenticated variable signature is VALID
INFO:root:  Cryptographic Signature: VALID
INFO:root:  Expected Payload: True
{
  "validation_date": "2026-04-01T22:43:41.903144+00:00",
  "file": "review/KEKUpdate_MiTAC_PK1.bin",
  "parameters": {
    "var_name": "KEK",
    "var_guid": "8be4df61-93ca-11d2-aa0d-00e098032b8c",
    "attributes": "NV,BS,RT,AT,AP"
  },
  "result": {
    "filename": "KEKUpdate_MiTAC_PK1.bin",
    "path": "review/KEKUpdate_MiTAC_PK1.bin",
    "valid": true,
    "payload_hash_valid": true,
    "error": null,
    "warnings": [],
    "details": {
      "verified": true
    },
    "payload_hash": "5b85333c009d7ea55cbb6f11a5c2ff45ee1091a968504c929aed25c84674962f",
    "payload_size": 1506
  }
7e3f66f80384f26b1a4ff6a45c7aecc28891bf1250adbbc3e76bb73868dd70fc  review/KEKUpdate_MiTAC_PK1.bin

INFO:root:Validating: KEKUpdate_MiTAC_PK2.bin
INFO:root:Verifying authenticated variable: review/KEKUpdate_MiTAC_PK2.bin
INFO:root:[+] Authenticated variable signature is VALID
INFO:root:  Cryptographic Signature: VALID
INFO:root:  Expected Payload: True
{
  "validation_date": "2026-04-01T22:44:58.663174+00:00",
  "file": "review/KEKUpdate_MiTAC_PK2.bin",
  "parameters": {
    "var_name": "KEK",
    "var_guid": "8be4df61-93ca-11d2-aa0d-00e098032b8c",
    "attributes": "NV,BS,RT,AT,AP"
  },
  "result": {
    "filename": "KEKUpdate_MiTAC_PK2.bin",
    "path": "review/KEKUpdate_MiTAC_PK2.bin",
    "valid": true,
    "payload_hash_valid": true,
    "error": null,
    "warnings": [],
    "details": {
      "verified": true
    },
    "payload_hash": "5b85333c009d7ea55cbb6f11a5c2ff45ee1091a968504c929aed25c84674962f",
    "payload_size": 1506
  }
}
81246715d79dc04d5bf03c4fd6c45dc6f40e1d389cc47c0ef34211e1e702eb1d  review/KEKUpdate_MiTAC_PK2.bin

@ZitoChung3
Copy link
Copy Markdown
Contributor Author

@Flickdm
I'm sorry that I don't understand the next step I should do. Do you mean: I need to modify the binary files and upload again?
Please let me know more information, then I can follow up this task.

Thanks.

Flickdm pushed a commit to Flickdm/secureboot_objects that referenced this pull request Apr 2, 2026
Flickdm pushed a commit to Flickdm/secureboot_objects that referenced this pull request Apr 2, 2026
@Flickdm Flickdm mentioned this pull request Apr 2, 2026
5 tasks
Flickdm pushed a commit to Flickdm/secureboot_objects that referenced this pull request Apr 2, 2026
Flickdm pushed a commit to Flickdm/secureboot_objects that referenced this pull request Apr 2, 2026
Flickdm pushed a commit that referenced this pull request Apr 2, 2026
Flickdm pushed a commit that referenced this pull request Apr 2, 2026
@Flickdm Flickdm closed this Apr 2, 2026
@Flickdm
Copy link
Copy Markdown
Member

Flickdm commented Apr 2, 2026

Merged!

@hughsie
Copy link
Copy Markdown

hughsie commented Apr 7, 2026

I couldn't parse this one for the LVFS upload...

$ fwupdtool firmware-parse PostSignedObjects/KEK/MiTAC/KEKUpdate_MiTAC_PK1.bin auto
failed to import the PKCS7 signature: ASN1 parser: Error in TAG. [-73]

I get the wrapper:

FuStructEfiVariableAuthentication2:
  timestamp: FuStructEfiTime:
  year: 0x7e7
  month: 0x7
  day: 0x12
  hour: 0xf
  minute: 0x25
  second: 0x1c
  nanosecond: 0x0
  timezone: 0x0
  daylight: 0x0
  auth_info: FuStructEfiWinCertificate:
  length: 0x5b1
  revision: 0x200
  certificate_type: 0xef1
  guid: 4aafd29d-68df-49ee-8aa9-347d375665a7

...and then the ASN1 doesn't load.

@ZitoChung3
Copy link
Copy Markdown
Contributor Author

I couldn't parse this one for the LVFS upload...

$ fwupdtool firmware-parse PostSignedObjects/KEK/MiTAC/KEKUpdate_MiTAC_PK1.bin auto
failed to import the PKCS7 signature: ASN1 parser: Error in TAG. [-73]

I get the wrapper:

FuStructEfiVariableAuthentication2:
  timestamp: FuStructEfiTime:
  year: 0x7e7
  month: 0x7
  day: 0x12
  hour: 0xf
  minute: 0x25
  second: 0x1c
  nanosecond: 0x0
  timezone: 0x0
  daylight: 0x0
  auth_info: FuStructEfiWinCertificate:
  length: 0x5b1
  revision: 0x200
  certificate_type: 0xef1
  guid: 4aafd29d-68df-49ee-8aa9-347d375665a7

...and then the ASN1 doesn't load.

May I know what is the possible root cause? How about the result of KEKUpdate_MiTAC_PK2.bin?

Thanks.

@hughsie
Copy link
Copy Markdown

hughsie commented Apr 7, 2026

May I know what is the possible root cause? How about the result of KEKUpdate_MiTAC_PK2.bin?

I'm not entirely sure; KEKUpdate_MiTAC_PK2.bin has the exact same failure: ASN1 parser: Error in TAG. -- @Flickdm do you see anything weird?

@Flickdm
Copy link
Copy Markdown
Member

Flickdm commented Apr 7, 2026

@hughsie Actually I am seeing something odd..

@Flickdm
Copy link
Copy Markdown
Member

Flickdm commented Apr 7, 2026

Analysis

So the reason that firmware-parse dislikes these payloads is that the ASN.1 is wrapped in ContentInfo.

I don't know which tooling @ZitoChung3 used to create these binaries or which flags - but I should review my own instructions to make sure that this is called out.

Most signing tools will natively try to create a signature like

ContentInfo ::= SEQUENCE {
    contentType   id-signedData (1.2.840.113549.1.7.2),
    content [0]   SignedData { ... }
}

Now for reasons I don't understand, when secure boot was first created, they decided to use SignedData directly rather than read the outer byte sequence. I assume this was to save bytes but in practice is confusing and odd.

Now prior to three years ago an Authenticated Variable wrapped in a ContentInfo would silently fail. However, a change was brought in to support this - see:

microsoft/mu_tiano_plus@37d3eb0

What this commit did is any device made and firmware built between 2012-2023 will only support SignedData however devices that are newer than this will support both.

This is why it was successful during testing and why signature validation works (during signature validation we actually have to add the ContentInfo bytes back before verifying). I assume the firmware being tested against is relatively new.

Now if you use the script I include below you will see the following:

Hex Comparison

19 bytes were removed, and WIN_CERTIFICATE.dwLength was updated accordingly (1457 -> 1438).

What Changed

Field Original Stripped
File size 2979 bytes 2960 bytes
WIN_CERTIFICATE.dwLength 0x000005B1 (1457) 0x0000059E (1438)
CertData starts with PKCS#7 ContentInfo wrapper PKCS#7 SignedData directly

The 19 Removed Bytes (offset 0x280x3A)

30 82 05 95 06 09 2a 86 48 86 f7 0d 01 07 02 a0 82 05 86

These are the PKCS#7 ContentInfo ASN.1 envelope that wraps the inner SignedData:

Bytes ASN.1 Meaning
30 82 05 95 SEQUENCE (ContentInfo), length 1429
06 09 2a 86 48 86 f7 0d 01 07 02 OID 1.2.840.113549.1.7.2 (id-signedData) — identifies this as PKCS#7 Signed Data
a0 82 05 86 [0] EXPLICIT context tag, length 1414 — wraps the SignedData

In Plain Terms

The .stripped file removes this outer ContentInfo envelope and stores the SignedData SEQUENCE directly as CertData, starting at 30 82 05 82 02 01 01 ... (version=1, ...).

The dwLength field in WIN_CERTIFICATE was also decremented by 19 to reflect the shorter CertData. Everything else (the EFI_TIME, GUID, SignedData contents, and the variable payload) is byte-identical.

Resolution / Recommendations

  1. @ZitoChung3 - Are you okay with me creating a new PR that makes these conform to the "most compatible" configuration of ASN.1. This won't require recreating the binaries but just to be safe, would you be willing to rerun the binaries once I strip them and upload them as a PR? (You could also use the script below and do this yourself if you want - or I can do it - its fairly easy)

  2. @hughsie - I think I should add a warning but I suspect that since this is valid (for at least new machines) we should think through how we want to handle this moving forward. Its fairly simple to restructure the ASN.1 and as long as the code path is there - both could be supported.


Strip Content Info Script

strip_content_info.py

@Flickdm Flickdm reopened this Apr 7, 2026
@Flickdm
Copy link
Copy Markdown
Member

Flickdm commented Apr 7, 2026

I'm reopening this PR for now until we agree on a resolution

@hughsie
Copy link
Copy Markdown

hughsie commented Apr 7, 2026

I can work around it in fwupd (e.g. fwupd/fwupd#10128) but it's certainly unexpected -- and it's probably a good idea to strip the header for maximum compatibility.

@Flickdm
Copy link
Copy Markdown
Member

Flickdm commented Apr 7, 2026

I can work around it in fwupd (e.g. fwupd/fwupd#10128) but it's certainly unexpected -- and it's probably a good idea to strip the header for maximum compatibility.

Yeah I agree - the challenge for the OS is that the OS has no ability to know if the firmware supports this or not.

I can see some devices could be built during the time period that I mentioned before where one firmware version does not support ContentInfo and the next supporting it. I think practically speaking stripping off that section is the only real solution until there is enough saturation in the market.

@ZitoChung3
Copy link
Copy Markdown
Contributor Author

@Flickdm
I use openssl to replace signtool. Below command comes from Gemini:

# To replace below signtool command with openssl
# signtool.exe sign /v /p7ce DetachedSignedData /p7co "1.2.840.113549.1.7.1" /fd SHA256 /f .\path\to\PlatformKey.pfx /p7 .\kek-update .\kek-update\KEK.signable.bin


# Extract private key
openssl pkcs12 -in MiTAC_PK_subject.pfx -nocerts -nodes -out pk_key.pem

# Extract public key certificate
openssl pkcs12 -in MiTAC_PK_subject.pfx -nokeys -out pk_cert.pem

# Generate Detached PKCS#7 signature
openssl smime -sign -binary -md sha256 -signer pk_cert.pem -inkey pk_key.pem -in .\kek-update\KEK.signable.bin -out .\kek-update\KEK.p7 -outform DER

Please open new PR, then strip and upload these files. I'm OK to rerun the binaries after that.

Thanks.

Flickdm added a commit to Flickdm/secureboot_objects that referenced this pull request Apr 8, 2026
Ref: microsoft#374

These files were uploaded originally with the following ASN.1 structure,
which includes an outer `ContentInfo` SEQUENCE:

```
ContentInfo ::= SEQUENCE {
    contentType   id-signedData (1.2.840.113549.1.7.2),
    content [0]   SignedData { ... }
}
```

This is problematic because until recently, this was not supported by
EDK2 based firmware.

microsoft/mu_tiano_plus@37d3eb0

To achieve the most compatibility with existing firmware, the files have
been stripped of  the outer ContentInfo envelope and stores the
**SignedData** SEQUENCE directly as `CertData`, starting at
`30 82 05 82 02 01 01 ...` (version=1, ...).

The `dwLength` field in `WIN_CERTIFICATE` was also decremented by 19 to
|reflect the shorter `CertData`. Everything else
(the `EFI_TIME`, GUID, `SignedData` contents, and the variable payload)
is byte-identical.
Flickdm added a commit to Flickdm/secureboot_objects that referenced this pull request Apr 8, 2026
Ref: microsoft#374

These files were uploaded originally with the following ASN.1 structure,
which includes an outer `ContentInfo` SEQUENCE:

```
ContentInfo ::= SEQUENCE {
    contentType   id-signedData (1.2.840.113549.1.7.2),
    content [0]   SignedData { ... }
}
```

This is problematic because until recently, this was not supported by
EDK2 based firmware.

microsoft/mu_tiano_plus@37d3eb0

To achieve the most compatibility with existing firmware, the files have
been stripped of  the outer ContentInfo envelope and stores the
**SignedData** SEQUENCE directly as `CertData`, starting at
`30 82 05 82 02 01 01 ...` (version=1, ...).

The `dwLength` field in `WIN_CERTIFICATE` was also decremented by 19 to
|reflect the shorter `CertData`. Everything else
(the `EFI_TIME`, GUID, `SignedData` contents, and the variable payload)
is byte-identical.
@Flickdm
Copy link
Copy Markdown
Member

Flickdm commented Apr 8, 2026

@ZitoChung3 can you test these and once you come back I'll close this?

#390

@ZitoChung3
Copy link
Copy Markdown
Contributor Author

@ZitoChung3 can you test these and once you come back I'll close this?

#390

@Flickdm we have tested it today under Windows and it works fine.
Please help merge the changes for the two binaries.

Do you know: when does the binaries add into Windows update?

Flickdm added a commit that referenced this pull request Apr 9, 2026
Ref: #374

These files were uploaded originally with the following ASN.1 structure,
which includes an outer `ContentInfo` SEQUENCE:

```
ContentInfo ::= SEQUENCE {
    contentType   id-signedData (1.2.840.113549.1.7.2),
    content [0]   SignedData { ... }
}
```

This is problematic because until recently, this was not supported by
EDK2 based firmware.

microsoft/mu_tiano_plus@37d3eb0

To achieve the most compatibility with existing firmware, the files have
been stripped of  the outer ContentInfo envelope and stores the
**SignedData** SEQUENCE directly as `CertData`, starting at
`30 82 05 82 02 01 01 ...` (version=1, ...).

The `dwLength` field in `WIN_CERTIFICATE` was also decremented by 19 to
|reflect the shorter `CertData`. Everything else
(the `EFI_TIME`, GUID, `SignedData` contents, and the variable payload)
is byte-identical.
@Flickdm
Copy link
Copy Markdown
Member

Flickdm commented Apr 9, 2026

My understanding is that these are being pulled in right now - but I dont specifically know which windows release it will make be in.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants