← 2025-12-26 の一覧へ戻るホーム
**ダシャロ・トラストルート短命キーインシデント**

2025/12/22 23:04

**ダシャロ・トラストルート短命キーインシデント**

RSS: https://news.ycombinator.com/rss

元のHacker News記事へ ↗
要約▶

Japanese Translation:

## Summary
Dasharo Security Bulletin DSB‑001 は、リリースエンジニアリングのミスにより、意図しない **ephemeral testing key** で署名されたファームウェアバイナリが特定の NovaCustom V540TU と V560TU デバイスに組み込まれたことを報告しています。2025年10月24日から12月5日までの間、ユーザーは Dasharo Tools Suite (DTS) を使用してフュージング操作を実行しました。DTS は Yocto ベースのミニマル Linux ディストリビューションであり、低レベルのメンテナンスデータを OTP レジスタに書き込むものです。不正なバイナリはアーティファクト公開時のファイル名類似性によって公開されました。

誤ったバイナリは SoC の **Field Programmable Fuses (FPF)** にフュージングされ、Intel Boot Guard が使用する OEM RSA 公開鍵の不変 SHA‑384 ハッシュを格納します。プログラムされた後、FPFs は EOM ビットでロックされ、再書き込みはできません。その結果、製造キーで署名されたファームウェアはすべて拒否されるようになり、デバイスは **アップデート不可・実質的にブリック状態** になります。

OTP フュージの変更が不可能なため、ソフトウェアによる復旧は不可能です。唯一の対処法はメインボード（TPM も交換される）を物理的に交換することであり、その際ユーザーは秘密情報をバックアップしなければなりません。

Dasharo はヒューマンエラーに責任を認め、影響を受けたユーザーへ謝罪し、社内レビュー後に追加の安全策を公開します。ユーザーには DTS の `btg_key_validator` スクリプトを実行して、自分のデバイスが影響を受けているかどうかを確認するよう推奨しています。

本文

導入

注：即時のガイダンスを求めている影響を受けたユーザーは、
Dasharo Security Bulletin DSB‑001 をご参照ください。
本ブログ記事では追加の技術的背景と詳細情報をご提供します。

概要

このレポートは、2025年12月5日に発生し、NovaCustom V540TU と V560TU プラットフォーム向け Dasharo ファームウェアに影響を与えた重大インシデントの開示と事後分析です。リリースエンジニアリング上のミスにより、一時的テストキーで署名されたファームウェアイメージ が、本来はプロダクションキーで署名されるべき Dasharo TrustRoot 統合操作用に公開されてしまいました。

2025年10月24日から12月5日の間に統合作業を実施したユーザーは、誤った暗号鍵ハッシュを SoC の Field Programmable Fuses (FPF) に永続的に書き込んでいる可能性があります。これらのフューズはワンタイムプログラム（OTP）であり、一時キーの秘密部がもはやアクセスできないため、影響を受けたデバイスは将来のファームウェア更新を受け取れません。

Dasharo Tools Suite (DTS)

  • DTS は Dasharo ファームウェアイメージの配布と保守を担います。
  • Yocto Project をベースにした最小限の Linux ディストリビューションとして構築されています。
  • 標準 OS 内からは不可能な低レベル保守タスクを実行するため、ターゲットハードウェア上で直接ブートします。
  • SPI フラッシュコントローラー、Embedded Controller (EC)、Intel Management Engine と連携します。
  • 最近追加された機能の一つがデバイスベンダーキーの統合です。

統合作業はチップセット内の OTP レジスタに書き込みます。DTS はこの複雑さをユーザーフレンドリーなワークフローへ抽象化しています。本件では DTS が統合操作を正しく実行したものの、選択されたファームウェアイメージが誤っていたことが原因です。

オーナー制御セキュリティ

Dasharo のモデルでは、ユーザーは自分自身でプラットフォームを統合（ファクトリー最終組立手順）することを選択できます。これにより、その操作のペイロードを供給するサプライチェーンに大きな信頼性負担が課せられます。本インシデントではその期待が破られました。

技術的背景：Intel Boot Guard

Intel Boot Guard は、OS がロードされる前にファームウェアの改ざんを防ぐハードウェア支援型ルートオブトラストです。PCH 内の FPF（ワンタイムプログラム可能な e‑fuse）に OEM の RSA 公開鍵（OEM Public Key Hash）の SHA‑384 ハッシュを格納し、これが書き込まれた後は戻せません。

検証チェーンの主要ポイント

  1. CPU の Authenticated Code Module (ACM) がファームウェアから Key Manifest (KEYM) を読み取り、含まれる公開鍵をハッシュ化して FPF と比較します。
  2. ハッシュが一致すれば ACM は KEYM を信頼し、Boot Policy Manifest (BPM) を検証します（BPM もそのキーで署名）。
  3. BPM はブートポリシーを定義し、Initial Boot Block (IBB) のハッシュを含みます。

このチェーンに一致するファームウェアのみが実行されます。

ファームウェア検証フロー（通常運用）

[Boot] → ACM reads KEYM → hash public key → compare to FPF
        |                                   |
        v                                   v
     Match? ------------------------> Verify BPM
        |                                     |
        v                                     v
   Trust KEYM → Execute firmware         Reject boot

製造モードから本番モードへの移行

製造時は「Manufacturing Mode」で FPF がエミュレートされ、変更可能です。Dasharo TrustRoot 統合では OEM Public Key Hash を FPF に書き込み、End of Manufacturing (EOM) ビットを設定します。これによりフューズが永久ロックされ、以降のブートで Boot Guard ポリシーが強制されます。

何が起こったか

  1. リリースプロセス
    NovaCustom ファームウェアのリリースは 3mdeb（開発）と NovaCustom（プロダクションキー管理）の協調で行われます。製造用キーはベンダーが保持し、ハードウェアトラストアンカーをコントロールします。開発段階ではテスト用の一時キーで署名されます。

  2. 成果物公開失敗
    リリースエンジニアがファイル名の類似性により、ephemeral キーで署名されたバイナリを誤ってアップロードしました。標準プロトコルにもかかわらず、最終公開ステップで手動ミスが発生しました。

  3. 結果としてのフューズプログラミング
    統合作業を行ったユーザーは一時キーのハッシュを FPF に書き込みました。既に削除されたキーであるため、将来プロダクションキーで署名されたファームウェアは検証に失敗し、デバイスが機能不全（ブリック）状態になります。

ソフトウェアによる復旧が不可能な理由

  • FPF はワンタイムプログラム
    EOM ビット設定後はフューズへの変更を永久にブロックします。ハッシュを書き換えることはできません。
  • 外部プログラマ（例：CH341a）は SPI フラッシュのみ書き込み可能
    CPU/PCH のフューズにはアクセスできず、プロダクション署名済みイメージを外部でフラッシュしても ACM がハッシュ不一致で拒否します。
  • 物理的な交換が必要
    マザーボードを交換しないと更新機能は回復できません。

今後の取り組みとフォローアップ

社内レビューを進め、追加の安全策やリリース活動の改善点をまとめたフォローアップ記事を公開予定です。オンラインプレゼンテーションも提供し、コミュニティに対して変更内容とその根拠を明確に示します。

あなたは影響を受けていますか？

btg_key_validator スクリプト（Dasharo Tools Suite 内）で確認できます：

  1. DTS にブート
  2. S キーでシェルモードへ移行
  3. btg_key_validator
    を実行

可能な出力例

  • 署名に使用されたキーが正しい場合

    Reading flash...
Extracting key manifest...
Key matches NovaCustom Meteor Lake signing key.

  • 署名に使用されたキーが不正の場合

    Reading flash...
Extracting key manifest...
Key does not match NovaCustom Meteor Lake signing key!

スクリプトで不一致と報告され、統合を実施した場合はデバイスが影響を受けており、ハードウェア交換対象です。

btg_key_validator スクリプトに関する詳細情報は [ここ] にあります。

ノートパソコンの送付前に

  • マザーボード交換 → TPM モジュールも同時に交換され、そこに保存された全秘密情報が失われます。
    TPM ベースのストレージ（例：LUKS, BitLocker）を使用している場合は重要データをバックアップしてください。

  • Windows 11 & BitLocker – Windows 11 はデフォルトで BitLocker を有効にすることがあります。不明な場合は提供された手順で確認してください。

結論

本件はハードウェアセキュリティ操作における精度の重要性を示しています。単一のヒューマンエラー（プロダクションバイナリとテストバイナリの入れ替え）が、ユーザーに対してハードウェア強制的なメンテナンスロックアウトへと波及しました。

  • 統合は正しく実行されました（EOM ビットは意図通り設定）。
  • ペイロード自体が欠陥でした（一時キーで署名されたバイナリ）。
  • 責任は私たちにあります：手動アップロード時の誤ったファイル選択は防止すべきでした。

影響を受けたユーザーには深くお詫び申し上げるとともに、ハードウェア交換でのサポートを専念します。デジタル主権への道を共に歩み続ける中で、ご理解いただければ幸いです。

著者

  • Michał Kopeć – 3mdeb のファームウェアエンジニア。coreboot と EDKII ベースの x86 ファームウェアを担当。オープンソース愛好家で、余暇にコンピュータを壊すことを楽しむ。
  • Maciej Pijanowski – 3mdeb のエンジニアリングマネージャー。エンジニアリング・マネジメント経験豊富。オープンソース貢献者で、組み込みシステム、ビルドシステム、セキュリティに関心がある。

同じ日のほかのニュース

一覧に戻る →

2025/12/26 8:13

おそらく、デフォルト設定が高すぎる可能性があります。

## Japanese Translation: **（すべての重要ポイントを統合し、明確さを保つ）** --- ### 要約 著者は『ロード・オブ・ザ・リング』を声に出して読むことに二か月を費やし、第1部の終わりまで達しました。文ごとに「通常の時間の3倍」を意図的に遅く読むことで、口速で読むアプローチが急ぎを防ぎ、興味を高め、理解・没入・楽しみを深めることに気づきました。トールキンのイメージとムードは、ゆっくり読んだときにのみ心に完全に広がります。 彼はこの洞察を読み以外にも拡張します。食事を通常の速度の1/3または半分に遅らせると、食べ物への感謝が増し、掃除機をかけたり、メールをチェックしたり、リストを書いたりする際も急いで行うより満足度が高くなります。現代生活の無限の消費物は、高速摂取を促進し、本や食べ物、情報の完全な鑑賞を損ないます。「少ないほど良い」という格言は、過剰に早く消費するとその影響力を失います。 著者は、遅らせることで味覚と好みが変わり、濃密な文学作品や自家製料理が加工品より豊かになることもあると指摘します。今日の文化的規範はTikTokクリップ、加工食品、CGI映画などの高速で光沢のある消費を優先し、深い関与を犠牲にしています。 彼は読者に対して、通常速度の約1/3程度と極端に遅く消費する実験を行い、報酬が増える体験を促します。Raptitude読者向けに「アルコール・ソーシャルメディア・スナックなどを一か月間やめる」討論フォーラムを開設し、多くの人が1月に同様のイニシアチブへの関心を示しています。

2025/12/26 10:02

**MiniMax M2.1:** *実世界の複雑タスクに対応するために設計された―多言語プログラミング*

## Japanese Translation: ```markdown ## Summary MiniMaxは新しいM2.1 AI‑nativeモデルをリリースし、Rust、Java、Go、C++、Kotlin、Objective‑C、TypeScript、JavaScriptなど複数言語にわたる実世界のプログラミングとオフィス作業で明確なパフォーマンス向上を提供します。 主な強みは以下の通りです： - **多言語マスタリー**：Claude Sonnet 4.5およびGemini 3 Proを上回るベンチマークスコアを持ち、マルチランゲージコーディングタスクで最高レベル。全体的にはClaude Opus 4.5に近い性能。 - **WebDev & AppDevの進化**：ネイティブAndroid/iOS開発サポート、デザイン理解と美的表現の向上、3D科学シミュレーション、高品質ビジュアライゼーションによる持続可能なワークフロー。 - **インタリーブド・シンキング**：複合指示処理が改善され、オフィス環境での使い勝手を向上。 - **トークン効率的返信**：トークン消費を削減し応答時間を短縮、コーディングワークフローの効率化。 M2.1はまたVIBEベンチマーク（Web, Simulation, Android, iOS, Backend）も導入し、平均スコア88.6でClaude Opus 4.5にほぼ匹敵し、多くのサブセットでSonnet 4.5を上回ります。 Factory、Fireworks、Cline、Kilo、RooCodeなど国際AIプラットフォームからは速度、信頼性、多言語安定性、コスト効率が高いと評価されています。 モデルは2つのAPIバージョンで利用可能です：**M2.1**（フル機能）および **M2.1‑lightning**（同じ結果を持ちつつ高速推論）。どちらも自動キャッシュをサポートし、開発者体験をスムーズにします。 オープンソースウェイトはHugging Faceにホストされており、MiniMaxはさらにオープンソースの提供拡大とエージェントフレームワークやコンテキスト管理ツールへのサポート拡充を計画しています。 開発者と企業向けにM2.1はより効率的なコーディング支援、トークンコストの削減、および強化された多言語機能を提供し、ソフトウェア納品タイムラインの加速やAI開発エコシステムにおける運用費用の低減を可能にします。 ```

2025/12/25 22:02

Windows x86‑64 用の Python 3.15 インタプリタは、ほぼ 15 ％速くなる見込みです。

## Japanese Translation: ## Summary Ken Jinは、macOS AArch64（XCode Clang）およびWindows x86‑64（MSVC）のCPythonのターミナル呼び出しインタープリターに関する以前の実績主張を部分的に撤回したものの、測定可能な速度向上を報告しています。macOSでは約5 %、Windowsでは実験的な内部MSVCビルドで最大15–16 %の改善が確認されています。ベンチマークは、「tail‑call threaded」インタープリターが従来のcomputed‑gotoループよりも優れていることを示しています。現代のコンパイラではその差は縮小しますが、実験的なVS 2026ビルドでは幾何平均で約16 %の利得が確認されています。この改善は、短いインタープリター・ループによりコンパイラがヘルパー関数（例：`PyStackRef_CLOSE_SPECIALIZED`）をインライン化し、レジスタ圧力を減らすことから生じています。 ターミナル呼び出しは、Josh HabermanのProtobufブログとHaoran XuによるClangの `__attribute__((musttail))` を使用したコピー＆パッチ手法で広まりました。XCode Clangが修正されたCPython 3.14/3.15ではmacOS上で約5 %の速度向上が示され、Python 3.15「What's New」には長いスクリプトに対して最大40 %の速度向上が記載されています。MSVCチーム（Chris Eibl、Brandt Bucher）がリリースしたVisual Studio 2026はターミナル呼び出しをサポートし、具体的な利得をもたらします：spectralnorm_tc 1.48倍速、nbody_tc 1.35倍速、bm_django_template_tc 1.18倍速、xdsl_tc 1.14倍速。 速度向上はPython 3.15まで継続すると予想されます。機能がロールバックされない限り、macOSのバイナリにはターミナル呼び出しが有効化された状態で配布され、VS 2026を使用したWindowsビルドでも同様の利得が期待できます。CPythonコミュニティはさらにビルドフラグ（`--tail-call-interp`）を洗練させ、プロファイルガイド付き最適化（PGO）を統合して性能を向上させる可能性があります。 CPUバウンドのPythonワークロード（科学計算、ウェブフレームワークなど）を実行するユーザーは、わずかな速度改善に気付くかもしれません。Pythonバイナリを配布する企業はコード変更なしで高速な実行ファイルを提供でき、Visual Studioを使用するWindowsの開発者もランタイム効率の向上から恩恵を受けるでしょう。

**ダシャロ・トラストルート短命キーインシデント** | そっか～ニュース