HUAWEI MateBook Linux Secure Boot 証明書危機：2026 UEFI CA 期限切れサバイバルガイド

日付： 2026 年 5 月 30 日 プラットフォーム： HUAWEI BoF-XX（MateBook M1010）、12th Gen Intel Core i7-1260P、Ubuntu Resolute Raccoon（Noble）、GNOME 50.0 ステータス： Platform is in Setup Mode、SecureBoot 無効、db 変数欠落

要約

2026 年 6 月 27 日、Microsoft UEFI CA 2011 ルート証明書が期限切れとなる。大多数の Windows ユーザーにとっては単なるバックグラウンド更新である。しかし、サポート外の OEM ハードウェアを使用する Linux ユーザー——特に Linux Vendor Firmware Service（LVFS）と Microsoft ホワイトリストの両方に載っていない HUAWEI MateBook ——にとっては、これはカウントダウン爆弾である。本稿では、危機の技術的全容を記録し、「Linux に Microsoft の署名は不要」という神話を解体し、Setup Mode に置き去りにされ、公式ベンダーのサポートチャネルを持たないデバイスに対して、実戦で検証済みの純 Linux 環境における修復経路を提供する。

1. 期限切れの解剖

1.1 本当に死ぬものは何か

Secure Boot の信頼チェーンは、Microsoft が 2011 年に発行した 3 つの証明書に依存している：

証明書	役割	期限日
`Microsoft Corporation KEK CA 2011`	鍵交換鍵（KEK）— `db`/`dbx` 更新に署名	2026 年 6 月
`Microsoft UEFI CA 2011`	サードパーティ bootloader、ドライバ、Linux shim を検証	2026 年 6 月
`Microsoft Windows Production PCA 2011`	Windows Boot Manager に署名	2026 年 10 月

これらの証明書は ディスク上には存在しない。マザーボードのファームウェア NVRAM 変数（db、KEK、PK、dbx）に格納されている。期限切れ後、X.509 有効期限を厳格に検証するファームウェアは、2011 CA のみで署名されたブートローダー——将来の Linux shim、NVIDIA GPU Option ROM、更新後の Windows Boot Manager を含む——の読み込みを拒否する。

1.2 信頼チェーン（2026 年前）

graph TD
    A[プラットフォームキー / PK<br/>OEM または Microsoft] -->|署名| B[鍵交換キー / KEK<br/>Microsoft KEK CA 2011]
    B -->|署名| C[署名データベース / db<br/>Microsoft UEFI CA 2011]
    C -->|検証| D[shim.efi<br/>Linux Bootloader]
    C -->|検証| E[Windows Boot Manager]
    C -->|検証| F[NVIDIA GOP / Option ROM]
    D -->|検証| G[GRUB2]
    G -->|検証| H[Linux Kernel]
    style C fill:#ff9999,stroke:#cc0000,stroke-width:3px
    style B fill:#ff9999,stroke:#cc0000,stroke-width:3px

図 1：2011 年証明書（赤）がサードパーティの起動チェーン全体を支えている。期限切れ後、すべての下流コンポーネントは検証を失う。

1.3 信頼チェーン（2026 年後、理想状態）

graph TD
    A[プラットフォームキー / PK] -->|署名| B[鍵交換キー / KEK<br/>Microsoft KEK 2K CA 2023]
    B -->|署名| C[署名データベース / db<br/>Microsoft UEFI CA 2023]
    B -->|署名| D[署名データベース / db<br/>Windows UEFI CA 2023]
    C -->|検証| E[shim.efi<br/>2023 署名版]
    D -->|検証| F[Windows Boot Manager<br/>2023 署名版]
    C -->|検証| G[NVIDIA GOP<br/>2023 署名版]
    E -->|検証| H[GRUB2]
    H -->|検証| I[Linux Kernel]
    style C fill:#99ff99,stroke:#009900,stroke-width:3px
    style D fill:#99ff99,stroke:#009900,stroke-width:3px
    style B fill:#99ff99,stroke:#009900,stroke-width:3px

図 2：2023 年証明書（緑）は、前方互換性を維持するために 2026 年 6 月までに db に存在しなければならない。

2. HUAWEI の罠：更新エコシステムから見捨てられる

2.1 OEM ホワイトリスト問題

HUAWEI は厳格で限定的な SKU ホワイトリストを維持しており、これらのモデルのみが Windows Update を通じて証明書のローテーションを受けられる。HUAWEI 公式サポート文書によると、Windows Update から 2023 証明書を 確実に 受信できるのは 19 の特定 SKU のみである：

MateBook X Pro 2024 / 2022
MateBook 14 2023（非 S）
MateBook D16 2024
MateStation S（特定ロット）
……（他 15 モデル）

本稿の主役である MateBook 14 2022（BoF-XX / M1010） は明らかにリストに含まれていない。つまり、Windows 11 をインストールしても、Secure-Boot-Update スケジュールタスクがトリガーされない可能性が高く、ファームウェアが変数書き込みを拒否する可能性もある。

2.2 LVFS の欠如

graph LR
    subgraph ベンダーファームウェア更新エコシステム
        A[Windows Update] -->|証明書をプッシュ| B[OEM ファームウェア<br/>Dell, Lenovo, HP]
        C[LVFS / fwupd] -->|.cab をプッシュ| D[Linux Vendor Firmware Service]
        D -->|サポート| E[Dell XPS]
        D -->|サポート| F[Lenovo ThinkPad]
        D -->|サポート| G[System76]
        D -->|サポート| H[Framework]
        D -.->|不在| I[HUAWEI MateBook]
    end
    style I fill:#ff9999,stroke:#cc0000,stroke-width:3px

図 3：HUAWEI は LVFS にファームウェア更新を公開していない。Linux ユーザーは fwupdmgr で公式 BIOS や証明書の更新を取得できない。

2.3 「Fedora が自動で証明書を更新してくれた」という誤謬

コミュニティの議論でよく聞かれる反論——「Fedora がファームウェア更新を自動プッシュしてくれた。Linux に Microsoft の署名は不要だ」。

これは 生存者バイアス である。Fedora の fwupd が機能するのは、以下の条件が揃っているからだ：

ハードウェアベンダー（例：Lenovo）が新しい証明書を含む capsule 更新を LVFS にアップロードしている。
そのベンダーのファームウェアが OS 側からの変数書き込みを許可している（すべてのベンダーが許可するわけではない——HP や富士通は db 書き込みのロックで知られている）。
デバイスのモデルがベンダーのサポートマトリックスに含まれている。

HUAWEI MateBook ユーザーにとっては、上記の条件はすべて満たされない。証明書はファームウェア NVRAM に存在しており、/boot/efi にはない。どの Linux ディストリビューションも、OEM が許可せず、ファームウェアが受け付けない証明書を「魔法のように」注入することはできない。

3. Setup Mode という救命ロープ

3.1 黄金状態の発見

筆者の HUAWEI MateBook M1010 で以下の診断コマンドを実行した：

$ sudo mokutil --sb-state
SecureBoot disabled
Platform is in Setup Mode

$ ls /sys/firmware/efi/efivars/ | grep -i db
dbDefault-8be4df61-93ca-11d2-aa0d-00e098032b8c
dbx-d719b2cb-3d3a-4596-a3bc-dad00e67656f
dbxDefault-8be4df61-93ca-11d2-aa0d-00e098032b8c

重要な発見：

SecureBoot disabled：起動チェーンは現在未検証。
Platform is in Setup Mode：PK（プラットフォームキー）変数が空。
db 変数が欠落：署名データベースが NVRAM に存在しない——出荷時デフォルトの dbDefault のみが残っている。

3.2 Setup Mode がスーパーパワーである理由

User Mode（通常操作）では、db への書き込みには署名済み .auth ファイルが必要である。署名は既存の KEK によって検証されなければならない——そして KEK の秘密鍵は Microsoft が独占している。個人ユーザーは有効な署名を生成できない。

Setup Mode（PK が空）では、ファームウェアは変数書き込みに対する署名検証を 強制しない。つまり、未署名の生の .esl（EFI Signature List）ファイルを db、KEK、PK に直接書き込むことができる。

stateDiagram-v2
    [*] --> SetupMode: 出荷時リセット / PK 削除
    [*] --> UserMode: 通常起動、PK 登録済み

    SetupMode --> UserMode: PK.auth を書き込み（自己署名）
    UserMode --> SetupMode: PK 削除 / 出荷時キーに復元

    state SetupMode {
        [*] --> db_write_unsigned
        db_write_unsigned --> [*]: efi-updatevar -f file.esl db
        note right of db_write_unsigned
            署名不要。
            KEK 秘密鍵不要。
            NVRAM に直接書き込み。
        end note
    }

    state UserMode {
        [*] --> db_write_signed
        db_write_signed --> [*]: efi-updatevar -f file.auth db
        note right of db_write_signed
            KEK 署名済み .auth ファイルが必要。
            KEK 秘密鍵は Microsoft のみが保持。
            個人ユーザーは実行不可。
        end note
    }

    style SetupMode fill:#99ff99,stroke:#009900
    style UserMode fill:#ffcccc,stroke:#cc0000

図 4：UEFI Secure Boot 変数アクセス状態遷移図。Setup Mode（緑）は、個人ユーザーが Microsoft の秘密鍵なしで証明書を書き込める唯一の状態である。

4. リスクモデリング：なぜ「Linux に署名は不要」は間違っているのか

4.1 脅威面

(R) を総起動時間リスクとし、次のように分解する：

[ R = R_{bootkit} + R_{compat} + R_{maint} ]

ここで：

(R_{bootkit})：ファームウェアレベルのマルウェア感染確率（BlackLotus、CosmicStrand 等）
(R_{compat})：署名検証による将来のシステム更新失敗確率
(R_{maint})：非標準的な起動チェーンを手動管理する保守コスト

Secure Boot が無効で 2011 証明書が期限切れになった後：

[ R_{bootkit}^{(post)} = R_{bootkit}^{(pre)} \times \delta^{-1}, \quad \delta \in (0,1) ]

dbx（失効リスト）が更新されないということは、既知の脆弱性を持つ bootloader や shim のバージョンを ファームウェアがブラックリスト化できない ことを意味する。システムの免疫システムが永久に凍結される。

4.2 互換性リスクマトリックス

シナリオ	2011 証明書のみ	2023 証明書登録済み	SecureBoot 無効
現在の Linux 起動	✅	✅	✅
将来の shim 更新（2023 署名）	❌	✅	✅
新しい NVIDIA ドライバ（GOP 2023 署名）	❌	✅	N/A
Windows デュアルブート（将来のインストール）	❌	✅	✅
`dbx` 失効リスト更新	❌	✅	N/A
Bootkit 防御能力	低	高	無

表 1：互換性とセキュリティマトリックス。「2011 証明書のみ」列は 2026 年 6 月以降の座礁状態を示す。

5. 純 Linux 修復：ステップバイステップ

5.1 前提条件

対象 Linux システムの root 権限
efitools、openssl、uuid-runtime がインストール済み
ネットワーク接続（Microsoft 公開の 2023 証明書をダウンロード可能）
現在の NVRAM 変数のバックアップ（存在する場合）

5.2 フェーズ 1：証明書の取得

# 作業ディレクトリを作成
mkdir -p ~/secureboot && cd ~/secureboot

# Microsoft UEFI CA 2023 をダウンロード（DER 形式）
wget -O MicUEFICA2023.der \
  "https://go.microsoft.com/fwlink/?linkid=2239872"

# Windows UEFI CA 2023 をダウンロード（DER 形式）
wget -O WinUEFICA2023.der \
  "https://go.microsoft.com/fwlink/?linkid=2239776"

# efitools で処理するため PEM 形式に変換
openssl x509 -in MicUEFICA2023.der -inform DER \
  -out MicUEFICA2023.pem -outform PEM

openssl x509 -in WinUEFICA2023.der -inform DER \
  -out WinUEFICA2023.pem -outform PEM

5.3 フェーズ 2：EFI 署名リストの生成

# 署名リスト所有者用にランダム GUID を生成
uuidgen --random > guid.txt
GUID=$(cat guid.txt)

# 証明書を ESL（EFI Signature List）に変換
cert-to-efi-sig-list -g "$GUID" \
  MicUEFICA2023.pem MicUEFICA2023.esl

cert-to-efi-sig-list -g "$GUID" \
  WinUEFICA2023.pem WinUEFICA2023.esl

5.4 フェーズ 3：NVRAM への注入（Setup Mode）

プラットフォームが Setup Mode にあるため、未署名の .esl ファイル を直接書き込む。.auth 署名は不要である。

# db 変数を初めて作成（-a フラグなし）
sudo efi-updatevar -f MicUEFICA2023.esl db

# 2 つ目の証明書を追加（-a フラグ）
sudo efi-updatevar -a -f WinUEFICA2023.esl db

検証：

sudo mokutil --db

期待される出力の抜粋：

[...]
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            33:00:00:02:5a:76:fb:8f:76:14:44:3b:91:00:00:00:02:5a:76
        Signature Algorithm: sha384WithRSAEncryption
        Issuer: C = US, O = Microsoft Corporation, CN = Microsoft UEFI CA 2023
[...]

5.5 フェーズ 4：Setup Mode からの脱出（推奨だが必須ではない）

システムを Setup Mode のままにしておくのは危険である——任意の OS や悪意ある bootloader が db を変更できてしまう。個人のプラットフォームキー（PK）を生成して User Mode に切り替えつつ、Secure Boot は 無効のまま 維持する。

# 自己署名プラットフォームキーを生成
openssl req -new -x509 -newkey rsa:2048 \
  -subj "/CN=Personal MateBook PK/" \
  -keyout PK.key -out PK.pem \
  -days 3650 -nodes

# ESL 処理用に DER 形式に変換
openssl x509 -in PK.pem -out PK.der -outform DER

# ESL を生成
cert-to-efi-sig-list -g "$GUID" PK.der PK.esl

# PK を書き込んで Setup Mode から脱出
sudo efi-updatevar -f PK.esl PK

# 状態遷移を確認
sudo mokutil --sb-state
# 期待値: "SecureBoot disabled" + "Platform is in User Mode"

5.6 完全フローチャート

flowchart TD
    A[開始: HUAWEI MateBook<br/>純 Linux 環境] --> B{状態確認}
    B -->|mokutil --sb-state| C[Setup Mode か？<br/>PK は空か？]
    C -->|はい| D[Microsoft<br/>2023 証明書を<br/>ダウンロード]
    C -->|いいえ| E[BIOS に入る → PK を削除<br/>→ Linux に再起動]

    D --> F[変換 DER → PEM → ESL]
    F --> G[efi-updatevar -f cert.esl db]
    G --> H{検証<br/>mokutil --db}
    H -->|2023 証明書が存在| I[個人 PK を生成]
    H -->|欠落| J[デバッグ: dmesg を確認<br/>efivarfs 権限]

    I --> K[efi-updatevar -f PK.esl PK]
    K --> L[Setup Mode から脱出<br/>User Mode へ移行]
    L --> M[将来に備えて:<br/>db に 2023 証明書が存在<br/>SecureBoot は無効のまま]

    style C fill:#99ff99,stroke:#009900
    style H fill:#ffcc66,stroke:#cc9900
    style M fill:#99ff99,stroke:#009900

図 5：HUAWEI MateBook デバイスにおける Setup Mode での純 Linux 修復の決定フロー。

6. 境界ケースと障害モード

6.1 `efi-updatevar` が `Permission denied` を返す場合

一部の OEM（HP、富士通、および将来の HUAWEI ファームウェアバージョン）は、Setup Mode でもファームウェアレベルで NVRAM 書き込みをロックする。以下のエラーが発生した場合：

Error: Could not update variable: Permission denied

代替手段： efitools パッケージに含まれる KeyTool.efi を EFI shell または起動メニューから直接起動する。GUI ベースの証明書登録フローを提供し、OS レベルのシステムコール制限を回避できる。

6.2 `db` 変数が既に存在する場合

ls /sys/firmware/efi/efivars/ で db-8be4df61-93ca-11d2-aa0d-00e098032b8c ファイル（標準 EFI グローバル変数 GUID）が表示される場合、すべての書き込みは追加フラグを使用する：

sudo efi-updatevar -a -f MicUEFICA2023.esl db
sudo efi-updatevar -a -f WinUEFICA2023.esl db

6.3 NVIDIA GPU ブラックスクリーンリスク

一部の旧型 NVIDIA GPU（GTX 600/700/900 シリーズおよび初期 10 シリーズ）に搭載されている UEFI GOP ドライバは、Microsoft UEFI CA 2011 によってのみ署名されている。2026 年 6 月以降に Secure Boot を有効にし、かつ 2023 CA を登録していない場合、これらの GPU がディスプレイを初期化できず、OS が引き継ぐ前に ブラックスクリーン になる可能性がある。

緩和策： 本稿の手法では、2023 証明書を登録しつつ、Secure Boot は 無効のまま 維持する。これにより、将来の互換性を確保しながら、起動時の GPU Option ROM 検証をトリガーしない。

7. 結論

2026 年の UEFI 証明書期限切れは Windows の問題ではない——これは ファームウェア層の信頼アンカーの問題 である。純 Linux 環境で HUAWEI MateBook を使用するユーザーにとって、LVFS の非対応と Microsoft ホワイトリストからの除外が、真のメンテナンス崖を生み出している。

しかし、デバイスが Setup Mode で座礁していることを発見できれば、一見不可能に見えたプラットフォームロックシナリオが、直接的な NVRAM 注入問題に変わる。2023 証明書は、純 Linux 環境で、Windows を使わず、Microsoft の秘密鍵を必要とせず、fwupd も不要で、efitools だけでネイティブに登録できる。

「Linux に Microsoft の署名は不要」は、今日の起動には技術的に正しくとも、明日のメンテナンスにとっては壊滅的な誤りである。 今すぐ 2023 証明書を登録しておくことは、将来の shim 更新、GPU ファームウェア、デュアルブートシナリオに対する保険である——それらはすべて、2011 年の信頼アンカーのみに依存したまま静かに機能しなくなる。

付録 A：クイックリファレンスコマンド

# 現在の状態を確認
sudo mokutil --sb-state
sudo mokutil --db | grep -i "2023"
ls /sys/firmware/efi/efivars/ | grep -i db

# ダウンロードと変換
wget https://go.microsoft.com/fwlink/?linkid=2239872 -O MicUEFICA2023.der
wget https://go.microsoft.com/fwlink/?linkid=2239776 -O WinUEFICA2023.der
openssl x509 -in MicUEFICA2023.der -inform DER -out MicUEFICA2023.pem -outform PEM
openssl x509 -in WinUEFICA2023.der -inform DER -out WinUEFICA2023.pem -outform PEM

# 生成と書き込み
uuidgen --random > guid.txt
cert-to-efi-sig-list -g "$(cat guid.txt)" MicUEFICA2023.pem MicUEFICA2023.esl
cert-to-efi-sig-list -g "$(cat guid.txt)" WinUEFICA2023.pem WinUEFICA2023.esl
sudo efi-updatevar -f MicUEFICA2023.esl db
sudo efi-updatevar -a -f WinUEFICA2023.esl db

付録 B：用語集

用語	定義
PK	Platform Key（プラットフォームキー）— Secure Boot 変数更新の信頼ルート
KEK	Key Exchange Key（鍵交換キー）— `db` と `dbx` の更新に署名
db	Signature Database（署名データベース）— 起動許可 bootloader/ドライバのホワイトリスト
dbx	Forbidden Signature Database（禁止署名データベース）— 失効署名のブラックリスト
Setup Mode	PK が空、ファームウェアが変数書き込みの署名検証を強制しない状態
User Mode	PK が登録済み、すべての変数更新に暗号署名が必要な状態
shim	第一段階 Linux bootloader、Microsoft UEFI CA によって署名される
LVFS	Linux Vendor Firmware Service — Linux 向け集中型ファームウェア配布サービス

ドキュメントバージョン：1.0.0
実証プラットフォーム：HUAWEI BoF-XX（M1010）、Ubuntu Resolute Raccoon、kernel 7.0.0-12-generic

HUAWEI MateBook Linux Secure Boot 証明書危機：2026 UEFI CA 期限切れサバイバルガイド

要約

1. 期限切れの解剖

1.1 本当に死ぬものは何か

1.2 信頼チェーン（2026 年前）

1.3 信頼チェーン（2026 年後、理想状態）

2. HUAWEI の罠：更新エコシステムから見捨てられる

2.1 OEM ホワイトリスト問題

2.2 LVFS の欠如

2.3 「Fedora が自動で証明書を更新してくれた」という誤謬

3. Setup Mode という救命ロープ

3.1 黄金状態の発見

3.2 Setup Mode がスーパーパワーである理由

4. リスクモデリング：なぜ「Linux に署名は不要」は間違っているのか

4.1 脅威面

4.2 互換性リスクマトリックス

5. 純 Linux 修復：ステップバイステップ

5.1 前提条件

5.2 フェーズ 1：証明書の取得

5.3 フェーズ 2：EFI 署名リストの生成

5.4 フェーズ 3：NVRAM への注入（Setup Mode）

5.5 フェーズ 4：Setup Mode からの脱出（推奨だが必須ではない）

5.6 完全フローチャート

6. 境界ケースと障害モード

6.1 `efi-updatevar` が `Permission denied` を返す場合

6.2 `db` 変数が既に存在する場合

6.3 NVIDIA GPU ブラックスクリーンリスク

7. 結論

付録 A：クイックリファレンスコマンド

付録 B：用語集

このページをシェア

WeChat で共有するためにスキャン

HUAWEI MateBook Linux Secure Boot 証明書危機：2026 UEFI CA 期限切れサバイバルガイド

要約

1. 期限切れの解剖

1.1 本当に死ぬものは何か

1.2 信頼チェーン（2026 年前）

1.3 信頼チェーン（2026 年後、理想状態）

2. HUAWEI の罠：更新エコシステムから見捨てられる

2.1 OEM ホワイトリスト問題

2.2 LVFS の欠如

2.3 「Fedora が自動で証明書を更新してくれた」という誤謬

3. Setup Mode という救命ロープ

3.1 黄金状態の発見

3.2 Setup Mode がスーパーパワーである理由

4. リスクモデリング：なぜ「Linux に署名は不要」は間違っているのか

4.1 脅威面

4.2 互換性リスクマトリックス

5. 純 Linux 修復：ステップバイステップ

5.1 前提条件

5.2 フェーズ 1：証明書の取得

5.3 フェーズ 2：EFI 署名リストの生成

5.4 フェーズ 3：NVRAM への注入（Setup Mode）

5.5 フェーズ 4：Setup Mode からの脱出（推奨だが必須ではない）

5.6 完全フローチャート

6. 境界ケースと障害モード

6.1 efi-updatevar が Permission denied を返す場合

6.2 db 変数が既に存在する場合

6.3 NVIDIA GPU ブラックスクリーンリスク

7. 結論

付録 A：クイックリファレンスコマンド

付録 B：用語集

このページをシェア

6.1 `efi-updatevar` が `Permission denied` を返す場合

6.2 `db` 変数が既に存在する場合