BitLockerトラブル

Windows Update KB5012170の失敗でBitLocker 48桁回復キー入力が必要となります。入力できない場合、PCアクセス不能となるトラブルが発生します。

2022年8月9日リリースのセキュリティ更新プログラム:KB5012170不具合が原因で、Windows 11 21H1、Windows 10 21H1などが対象です。0x800f0922エラー発生時には、ご注意ください。

BitLocker目的

Windows Update失敗でBitLockerトラブル発生
Windows Update失敗でBitLockerトラブル発生

BitLockerは、PCのハードディスク/USBメモリなどのデータを暗号化します。第三者によるデータ不正アクセス検出時、48桁の回復キー入力が無ければ、PCアクセス不能とする機能です。

BitLockerの目的は、ノートPC紛失時などに、内蔵データ流出や不正コピーを防ぐことです。

Win11では、デフォルトでBitLocker有効に設定済みです。BitLockerは、TPMを前提条件としています。BitLockerにより、10%未満の処理オーバーヘッドが生じます。

48桁回復キー入力に間違いがある場合も、PCアクセス不可能となるでしょう。パスワード3回入力失敗時と同じです。48桁キー、間違いなく入力できる自信、ありますか?

セキュリティとセーフティ

セキュリティとセーフティの違い(出展:STマイクロ)
セキュリティとセーフティの違い(出展:STマイクロ)

Security(セキュリティ)もSafety(セーフティ)、日本語ではどちらも「安全」と訳されます。しかし、本質的に両者は異なります。

STマイクロの資料P4に、解りやすい説明がありましたので、抜粋します。英語では両者は区別します。

・セキュリティ:外部からの攻撃・脅威に対し、デバイスやハードウェア侵害/ハッキングの防衛対策
・セーフティ:デバイスやソフトウェア誤動作・故障などへの障害対策

MCU開発者には、タンパ検出がセキュリティ、フェールセーフ設計がセーフティと言えば判り易いと思います。

セキュリティ誤検出

セキュリティの誤検出
セキュリティの誤検出

今回のBitLockerトラブルは、セキュリティ更新プログラム:KB5012170不具合がそもそもの原因です。

しかし、MicrosoftのBitLocker回復ガイドを見ると、この不具合以外にも、回復キー入力モードになる様々なイベントがあることが判ります。

当然の事ながら、各イベントに誤検出のリスクもあります。セキュティには、誤検出が避けられません。たとえ誤検出であっても、回復キー入力がPC正常復帰に必要となります。

10%未満とはいえ、BitLockerによるPC「オーバーヘッド増加」対「誤検出リスク」、これらを天秤にかける必要があるでしょう。

ノートPC以外の個人占有デスクトップPCなら、BitLocker無効でもOKだと思います。PC盗難には無力ですが…。

IoT MCUクラウド接続

IoT MCUをクラウド接続する際にも、デバイスのUUID(Universally Unique Identifier)や、クラウド接続を許可するやたらに長いデバイス証明書、秘密/公開鍵をMCU Flashへ書込み、それらをクラウドへ送信する必要があります。

これは、IoT MCUのクラウド接続手続きで、通常、初回接続時のみ入力すれば完了です。

それでもクラウド側の何らかのトラブル発生時、または、IoT MCUソフトウェア変更時など、鍵の再入力を求められる可能性はあります。

はたして、この再入力は、誰(顧客/開発側)が行うのでしょうか?

量子技術が公開鍵暗号方式を破る?

米国土安全保障省サイバーセキュリティ・インフラストラクチャセキュリティ庁
米国土安全保障省サイバーセキュリティインフラストラクチャセキュリティ庁

CISA(米国土安全保障省サイバーセキュリティインフラセキュリティ庁)は、今後10年間の量子コンピューティング進歩により、現状の公開鍵暗号方式が破られる可能性を指摘しています(2022年8月30日@IT記事)。

2024年に根本対策としての新しい量子暗号規格の発表があるそうです。現状対策は、鍵を長くすることでしょうか?

まとめ:秘密鍵保存と間違わない再入力

現状の公開鍵方式でセキュリティを維持するには、英大文字/小文字/数字/空白文字/記号から成る長い秘密/公開鍵の保存、入力が必要です。量子コンピューティングにより、キー長は、更に増える可能性もあります。

問題は、長い鍵の保存方法、誤検出などの鍵再入力時に間違わずに入力できるかです。コピー&ペーストが使えればOKですが、紙を見ながら入力は、可能だとしてもミスを招きます。

IoT MCUのようにクラウド接続時に最初1回のみ入力するとしても、誰が、どのイベントで、どのように間違いなく入力できる鍵やデバイス証明書などの機密情報保存方法について、顧客、開発側双方で検討しておく必要があります。

また、顧客は、IoT MCUセキュリティオーバーヘッド量(PCは10%未満)を求めると思います。元々非力なIoT MCUのセキュリティ対コストは、重要事項です。開発側も把握したいパラメタです。

関連投稿

・公開鍵と秘密鍵の役割が判る、組込み開発基本のキ(暗号技術の仕組み

・Windows 11非対応PCのBitLocker
弊社Win11 TPM 2.0非対応PCは、BitLocker未使用です。本稿BitLockerトラブルとは無縁でした。ノートPC持出しもCOVID-19で激減、新規購入Win11ノートPC BitLockerも検討中です。持出し時にのみBitLocker設定も可能ですが、ディスク暗号化処理に結構時間が掛かります。

・今秋Win11 22H2は、大型更新

WindowsのTPM使い方

Windows 11アップグレート要件のTPM 2.0の使われ方を調査しました。WindowsがどのようにTPMを使っているかを知れば、11アップグレート足切り要件を筆者が納得し、加えて、IoT MCUセキュリティのTrustZone開発工数を顧客へ説明する時、参考になるかもしれないからです。

WindowsのTPM

Windows 10から追加・変更された現行Windows 11の機能は、生産性や弊社ビジネス向上に直結するものは無いと思っています。対処法などは、最悪Windows 11へアップグレードする際に備え収集中です。

アップグレード要件で最も不満な点が、TPM 2.0です。このTPMで何を行い、なぜ要件になったのかを整理してみます。

TPM機能(出展:PC Watch記事)
TPM機能(出展:PC Watch記事)

その結果、TPM 2.0は、11アップグレード要件というよりも、国際標準規格制定団体:Trusted Computing Group(TCG)が2014年10月にリリースし、TPM 2.0としてISO/IEC標準セキュリティ規格となったPCの普及が目的、と結論しました。

来年秋のWindows 11大型更新後、弊社PCの11アップグレート状況が変わるか楽しみです。

TPM利用Windows HelloとBitLocker

暗号化、乱数⽣成、暗号鍵⽣成と保存、デジタル署名がWindowsのTPM 2.0チップ利用箇所で、MacのBoot CampでもWindows 11が動作しない理由は、コチラに良くまとまっています。

ちなみに、TrustZone対象も、TPM 2.0と同様になる可能性も高く、特に、暗号化アルゴリズム可変の機能は、優れています。アルゴリズムを変更するWindowsのOTA相当にも注目しています。

Windowsは、これらTPM機能を利用し、パスワードを使わずにWindowsへサインインする「Windows Hello」や、内部ストレージ暗号化の「BitLocker」を実行します。また、「Microsoft Azure Attestation」(MAA)などにも使うようです。

WindowsのTPM使い方例(出典:セパゴのITブログ)
WindowsのTPM使い方例(出典:セパゴのITブログ:https://www.sepago.de/)

BitLockerやWindows Helloは、Windows 10でも利用した企業向けノートPCユーザもいるかもしれません。ただ、個人ノートPCや自宅PCユーザは、Microsoftアカウントを使うWindows HelloやPINの代わりに、ローカルアカウントの利用者が多いハズです。手間が掛からないことや、PC使用履歴をクラウド記録されるのが嫌だからです。

Windows 11は、Microsoftアカウント利用が基本ですが、アプリケーション個人認証にスマホ併用も必須になりつつあります。例えば、Googleログインも、スマホ2段階認証が有効に変わりました。

Googleログインの2段階認証プロセス
Googleログインの2段階認証プロセス

従って、例えWindows 11でTPMパスワードレス認証後でも、Googleログイン2段階認証は必要になる訳です。一方、TPM 2.0未搭載Windows 10でも、BitLockerやWindows Helloは利用でき、スマホ2段階認証などで様々なアプリケーションのセキュリティにも対応可能です。

つまり、TPMは、Windows 11の技術的アップグレード要件ではなく、OSセキュリティ強化が目的、というのが筆者TPM評価です。

ちなみに、ローカルアカウントによるWindows 11セットアップ方法は、コチラにまとまっています。

TPM理由

Microsoftが強調するOSセキュリティ強化には、TPMと手間暇、処理能力が必要です。処理能力要件が、Windows11対応CPUです。Windows 10が正常に動作するCPUでも、この能力要件を満たさないCPUも多数あります。理由は不明ですが、今回はTPMにフォーカスするため追求しません。

さて、筆者のようなセキュリティ素人には、TPMセキュリティ強化分と便益(手間暇)比を、ゲーム/個人/企業などのPCユースケース毎に評価、公表してほしいです。現行Windows 11は、最強セキュリティを求める企業向けユーザのみを対象にしている気がします。

仮に、Windows 11普及にTPMセキュリティ強化が障害になっているとMicrosoftが判断すれば、コチラの関連投稿2章のユーザアカウント制御のようなセキュリティを弱める対策を打出すと思います。

ユーザアカウント制御の設定
ユーザアカウント制御の設定

好みのセキュリティレベル設定は、個人ユーザに歓迎されるハズです。既に、TPM回避Windows 11インストール公式発表などがその現れです。これは、Windows 10サポート終了2025年10月14日が近づけば、より効果を発揮します。

しかし、Windows 11の魅力が現行のままなら、2025年10月以降は、Mac/Linuxなどの別OSやWindows 365などに乗換えるユーザも少なくないと思います。11乗換魅力の無さが、普及を妨げているからです。

TPM の理由は、最もセキュリティに敏感で、新PC購入/入替えも容易な企業向けPCユーザへ、ISO/IEC標準セキュリティ規格PCへの買換え動機付けだと思います。

TrustZone Cortex-M33はM4比2倍説明応用

TrustZoneとTPMの類似性
TrustZoneとTPMの類似性

IoT MCU顧客へ、Cortex-M33 TrustZone活用開発工数は、Cortex-M4比2倍となる説明が必要と前稿で書きました。

2倍根拠は、Cortex-M33/M4動作周波数比、Secureと通常の2プロジェクト同時開発必須などです。これらは、目に見える差分です。しかし、セキュリティに関しては、リスクが増減という話ばかりで、数値で表せないセキュリティ差分を、顧客に納得してもらえるかは、正直分かりません。

しかも、TrustZone活用には、通常の開発スキルに加え、セキュリティスキルも必要です。組込み開発は、1人で全て担当することも多いので、セキュリティ知識は持てても、利用スキル:暗号化ライブラリ選択やAPI利用法などに限定したいハズです。

セキュリティの詳細内容は、一般的なIoT MCU開発者には背景知識が少ないため、根本理解は困難でしょう。この状況で、セキュリティ利用スキルも必要となるTrustZone活用開発の差分を、顧客に上手く納得してもらうには、開発者として何らかの工夫も有効かもしれません。

Windows 11のTPMも、上記TrustZoneと全く同じ状況だと思います。そこで、現時点のTPMを整理しました。

今後Microsoftが、どのようにTPMの理由をユーザへ説明(12/4更新)していくかを、IoT MCU顧客へのTrustZone Cortex-M33開発工数が、M4比、2倍の説明にも応用したいと考えています。

実務的には、セキュリティの根本理解よりも、この方法の方が近道の気がします😅