目次


OpenPOWERセキュア・ブートとトラステッド・ブート パート1:IBM OpenPOWERにおけるトラステッド・ブートの使用

Comments

翻訳: Takeshi Yoshio

このドキュメントは、OpenPOWER secure and trusted boot, Part 1: Using trusted boot on IBM OpenPOWER serversを翻訳したものです。更新の有無や内容の確認のためには、最新の英語バージョンを参照してください。

はじめに

OpenPOWERサーバーには、トラステッド・ブートと呼ばれるファームウェア・レベルのセキュリティ機能があります。トラステッド・ブートによって、IBMまたは信頼できるベンダーが提供する、許可されたファームウェア・コンポーネントだけが、サーバー上で稼働していることを検証できるようになります。これによって、ブート・コードがサイバー攻撃(信頼できるファームウェアを悪意のあるコードで置き換えること)を検出し、対処できます。もし、攻撃者が悪意のあるコードを、ファームウェア・レベルで注入できるならば、オペレーティング・システムでどのような防御を行なったとしても、攻撃者がサーバを乗っ取る事を防ぐことはできません。

トラステッド・ブートによって、ブート・コードに対するサイバー攻撃(信頼できるファームウェアを悪意のあるコードで置き換えること)を、検出できます。

TPMとPCR、そして保全性の計測

トラステッド・ブートは、サーバーのブート時にファームウェアが一連の記録や 計測 を行うことで実現されています。ここでいう計測とは、ブート・コードの各コンポーネント(実行可能なファームウェア・イメージ)のセキュア・ハッシュ(例えばSHA, SHA256, あるいはSHA512)の計算です。フラッシュ・メモリーからコンポーネントをロードして、システム・プロセッサーがそれを実行する前に、この計測を行います。各実行可能イメージは、次イメージに制御を渡す前に、計測を行います。計測は重要な構成データのハッシュであることもあります。例えば、サーバーのデフォールトのブート・デバイスを決めるためのプロパティなどです。

計測結果はトラステッド・プラットフォーム・モジュール (Trusted Platform Module: TPM)と呼ばれる、専用のセキュリティ・プロセッサーに記録されます。計測結果は(次のリブートまで)削除できず、偽造されない方法でTPMが安全に保管します。TPMにはPlatform Configuration Register(PCR)と呼ばれる専用レジスター群があり、計測結果が保管されます。PCRに 拡張 した全ての計測履歴が(ハッシュの形式で)暗号化され、各PCRが保持します。拡張 とは、PCRに計測結果を追加するために、TPMが使用する特殊な操作です。拡張 については、この後で触れます。重要なことは、TPMが特定の計測を正しい順序で行えば、常に同じPCR値(ダイジェスト値)を生成するということです。あるダイジェスト値に対して、TPMが厳密に同じ計測の拡張を同じ順序で実行する以外には、その値を生成することは現実的には不可能です。

サーバーがターゲットOSやハイパーバイザーまでブートすると、ネットワーク越しにこのサーバーに接続して、全PCR値のリストとTPMが記録した全計測結果のリストを要求することができます。計測結果のリストは ブート時の計測結果リスト、あるいは イベント・ログ と呼ばれ、PCRダイジェスト値のリストは PCRダイジェスト・リスト と呼ばれます。TPMにこのデータを要求するプロセスを、クォート の要求と表現します。

トラステッド・プラットフォーム・モジュール(Trusted Platform Module: TPM)は、保全性の計測結果を保持するために設計された、専用セキュリティ・プロセッサーです。

TPMがクォートを作成する時、ダイジェスト・リスト に暗号的な署名を行いますが、この署名は別個に検証できます。このとき、署名には鍵が用いられ、この鍵はクォートを作成したTPMが所有しているものとして検証されます。この鍵はさらに鍵によって署名され、それはTPM製造者あるいはベンダーに関連付けられます。TPMをベンダーに関連付ける鍵は、承認鍵(Endorsement Key: EK)として知られています。また、クォートを作成するために使用される鍵は、認証鍵(Attestation Key: AK)として知られています。

TPMからクォートを取得してEKとAKを検証したら、想定されたブート・コードと構成を用いてサーバーがブートしたことを、PCRデータを用いて検証することができます。想定と異なるブートが実行されると、予期しないPCRダイジェスト値が生成され、想定しないイベント・ログが生成される可能性があります。これはクォートの検査時に検出されます。クォートを取得・検証するプロセスを、リモート認証 と呼びます。

トラステッド・ブートによる保護

では、なぜこれによってシステムが保護されていることが、確かなものになるのでしょうか。想定したブート・コードと想定した構成でシステムが実行しているならば、少なくともブート・コードに関しては、システムは改ざんされていないと言えます。TPMとクォートを取り出すプロセスは、これが正しいことを示します。想定外のイメージや構成をロードしたら、TPMによって、本来とは異なるダイジェスト値が1つ以上のPCR(Platform Configuration Register)に生成されます。

この逆、つまり「想定外の計測結果は、システムが侵入されたことを意味する」ということが常に成り立つわけではありません。システムは有効なファームウェア・イメージでブートしたが、それが想定していたものではなかった(例えば、許可されているが異なるバージョンのイメージ)だけかもしれません。また、違いが構成変更によるものだった場合、変更がシステムの立ち上げ方に違いを生むとは限りません。例えば、システムをネットワークからのブートにセットしているが、PXEサーバーが見つからない場合、システムは次の選択肢に進んで、以前使用されたメディアでブートするでしょう。このように、変更が あったこと を知るだけでなく、厳密に 何が 変わったかを知ることは有益です。これについては、リモート認証のところで詳しく説明します。

もし、機器が信頼できるファームウェアのみを実行したことを検証できるなら、ブート中に機器は改ざんされていないことが分かります。

ブート・コードやブート構成の変更が、1つあるいは複数のPCRの値に変化をもたらし、それはクォート内で検出できるということを理解してください。

TPMには通常24あるいはそれ以上のPCRがあります。そのうち最初の16個は、システム・プロセッサーをリセットする以外には、リセットする方法がありません。例えば、コールド・ブート時にリセットが行われます。クォートは要求された全てのPCR値を戻します。これは通常PCR [0-15]で、署名済みダイジェスト・リスト内にあります。ダイジェスト・リストを、良好であることが明確な構成(参照 構成あるいは ゴールデン 構成と呼ばれます)と紐付けることができます。リモート認証によって、システムがブートした方法と該当システムの参照構成を比較し、それが一致すればブートは改ざんされていないと言えます。

拡張オペレーション

ここで、拡張 オペレーションがどのように行われるかを見ていきましょう。TPMは、いくつかの特殊な特徴を持つ暗号プロセッサーです。特徴の一つは、TPMのPCRには直接書き込みができないということです。PCRは、拡張 オペレーションによってのみ更新できます。拡張 オペレーションは、データの塊(通常コンポーネントのイメージあるいはファイルの計測結果=ハッシュ)を、更新するPCRとともにTPMに送ります。TPMは、新しいデータとレジスター内の現行データを連結し、ハッシュ(SHA1, SHA256あるいはSHA512のようなアルゴリズムを用います)を実行し、結果をPCRに書き戻します。これにより、新しいPCRの値は、常に以前の値に依存するようになります。これが、同じ結果を得るためには、同じ順序を辿らなければならないということの理由です。拡張オペレーションは、以下のように記述できます:

digest new ≔ hash (digest old || data new)

ここで hash() はセキュア・ハッシュ・アルゴリズムを、 || は連結を表します。

TPM 2.0とTPM 1.2の違いは、TPM 2.0では複数のPCRバンクをサポートすることです。各バンクは異なるハッシュ・アルゴリズムをサポートします。ブート・プロセスの初期段階で、1つ以上のバンクをアクティブ 状態にします。計測結果をTPMに記録する時、全てのアクティブなバンクに対して 拡張 オペレーションを行います。

PCRの使用方法

ファームウェ計測用に予約されているTPM PCRの標準的な使用方法は、Trusted Computing Group(TCG)によって PC Client Platform Firmware Profile Specification として定義されています。低位のPCR [0-7] は、一般に pre-OS 環境と呼ばれる分野のために予約されています。高位のPCR [8-15] は、ホスト・プラットフォームのターゲット・オペレーティング・システム、あるいは 静的なOS のために予約されています。

表1は低位のPCR [0-7] の使用方法です。最初の2つのPCR [0-1] は、基本ファームウェアのコンポーネントの計測に使われ、それにはUnified Extensible Firmware Interface(UEFI)や、OpenPOWERファームウェアが含まれます。PCR [0-1] は、プラットフォーム・ベンダー管理 下にあると言えます。PCR [2-3] は、サード・パーティのファームウェアの計測に使用されます。それには、UEFIドライバーやIBM POWER8® プロセッサーのシステムで使用されるIBM Coherent Accelerator Processor Interface(CAPI)マイクロコードが含まれます。これは、Add-inベンダー管理 下にあると言えます。PCR [4-5] は、ターゲットOSやハイパーバイザーに加えて、関連するブートローダー・コード(ブート状態遷移 と呼ばれる)の計測に特化されています。

UEFIとOpenPOWERでは、PCR [6-7] の使い方が若干異なります。UEFIでは、PCR [6] はプラットフォーム・ベンダーの一般的な使用のために予約され、PCR [7] はSecure Boot Policyのために予約されています。OpenPOWERでは、PCR [6-7] は将来のIBM POWER® プロトコルのために予約されています。

表1. OpenPOWERでのPCRの使用

PCRの役割PCR番号PCR使用目的
ホスト・プラットフォーム・ベンダー管理0Hostbootや他のファームウェア・コンポーネント
1構成データとファームウェア・コンテナのメタデータ
アド・イン・コンポーネントのベンダー管理2CAPIコード
3CAPI データ
ブート状態遷移4OPALファームウェア、静的OS(Linux kernelとinitramfs)
5TPM使用可能フラグ、OPALコンテナ・メタデータ、ブート順序、静的OS構成(Linux kernelコマンド・ライン)
予約済み6将来の使用のため予約済み
7将来の使用のため予約済み

信頼の基点のコア(Core Root of Trust)の確立

これまでに明確になったことは、これらの計測結果を生成するコンポーネントが信頼できなければならないということです。さもなくば、クォートを取得したシステムがすでに改ざんされており、計測結果を偽っているかもしれません。この問題は、ハードウェアで裏付けされる、計測に対する信頼の基点のコア(Core Root of Trust for Measurement: CRTM)を確立することによって解決されます。図1はOpenPOWERでCRTMの確立が行われる方法を簡略化したものです。

ブート・プロセスは、POWER8マスター・プロセッサーのオン・チップ上のワンタイムPROM (one-time programmable read only memory: OTPROM)の、微小なプログラム・コードを実行することで始まります。このコードはセルフ・ブート・エンジン(Self Boot Engine: SBE)と呼ばれ、POWER8プロセッサーのパワーオン・リセット・エンジン(Power On Reset Engine: PORE)の一部です。これはOTPROM上に存在するため、変更不可能であり、攻撃者は上書きすることができません。

Core Root of Trust for Measurement(CRTM)は、マシンのブート・ファームウェアに対する基本レベルの信頼を提供します。

OTPROMコードは、もう一つの実行可能SBEイメージのエントリー・ポイントを提供します。このSBEイメージは、POWER8プロセッサー・モジュール上のシリアルEEPROM(Serial electrically erasable programmable read-only memory: SEEPROM)に保管されています。このSBEは、プロセッサー・ベースのNORフラッシュ・メモリー(PNOR)から、追加の実行イメージのロードを開始します。ロードされる最初のコンポーネントは、 Hostboot と呼ばれます。Hostbootは、TPMへの拡張オペレーションを行う最初のファームウェア・コンポーネントで、トラステッド・ブートの計測はここから始まります。

重要なのは、最初に走る微小なプログラム・コード(OTPROM内のSBE)は、ハードウェアに焼き付けられ、攻撃者が書き換えることができないということです。これに対する信頼の度合いは、ハードウェアを信頼する度合い、つまり信頼できるベンダーが純正IBM PowerPC® プロセッサーを組み込んで提供するサーバーへの信頼の度合い、と同じです。これが、CRMを ハードウェアが裏付けする と言う意味です。しかし、これ以降に実行されるコードは、不揮発性ストレージからロードされ、それは侵入者によって書き換えられているかもしれません。そのため、Hostbootの前に実行される各コンポーネントの妥当性を確認できる方法が必要です。これを実現するためには、まだ議論していないセキュア・ブートの機能が必要となります。

セキュア・ブートはファームウェアの検証のために暗号署名を使用します。

重要なファームウェア・コンポーネントの妥当性確認に使われるという点で、セキュア・ブートはトラステッド・ブートに類似しています。セキュア・ブートでは、ブートの最中に確認され、確認に失敗すれば停止します。それに対して、トラステッド・ブートでは、コンポーネントの計測結果を後で確認するために記録しておき、何を計測してもブートを継続します。この記事で記述されているように、トラステッド・ブートは重要です。しかし、ブート・プロセスは、まだ計測結果を記録できるところまで来ていないので、最初はセキュア・ブートに依存せざるを得ません。セキュア・ブートは、暗号署名を使用してコンポーネントの検証を行います。OpenPOWERでは、それは以下のように動作します:

プロセッサーのSEEPROMに保管されているのは、ハードウェア・ルート鍵 の公開鍵のハッシュです。対応する秘密鍵は、プラットフォーム・ベンダー(IBMやOEMベンダー)が保持しています。そしてそれらはホスト・プラットフォーム向けの、許可されたファームウェアの署名に使われます。正確に言えば、ハードウェア(HW)ルート鍵は、ファームウェア鍵のセットに署名し、ファームウェア鍵はファームウェア・イメージの実体に署名します。SBEによってロードされる各ファームウェア・イメージは、実行前に署名が検証されなければなりません。これを行うために、SBEは書き換え不可能なROM内の微小な確認用プログラム・コードを使用します。各実行モジュールは、次のイメージに制御を渡す前に、署名の確認をしなければなりません。もし確認が失敗すると、セキュア・ブートはブートを停止します。ブートが成功すれば、(ハードウェア・ルート鍵を信頼できることと同じ程度に)各モジュールは検証済みで信頼できます。システムがHostbootまでブートした時点で、計測を行うプログラム・コードの真正性が検証され、TPMに書かれている内容を信頼することができます。これが、CRTMを確立する方法です。

図 1. CRTM確立プロセス

細かい点ですが、SEEPROM内のSBEコードの検証方法が、図には示されていません。このコードは署名データを含んでいません(SEEPROMスペースは限られています)。しかし、このSBEコードのコピーがPNORに保管されており、コピーは署名データを含んでいます。ブートがHostbootのところまで進んできたら、HostbootはSEEPROMコードとPNOR内にあるコピーを照合します。両者が一致しなければ、HostbootはPNOR内にある検証済みコードでSEEPROMを書き換え、即座にシステムをリブートします。次のブートで、Hostbootは再び同じ照合を行います。今度は照合はパスし、システムが信頼できるSBEコードを実行します。

コンポーネントのコンテナ化

先の議論から抜けている点は、CRTMコンポーネント用署名データが、ブート時に利用可能になる仕組みです。コンポーネントは コンテナ化 されています。つまり、コンポーネントは、そのハッシュ値とハッシュに対する署名を含むメタデータとともに、PNORフラッシュに保管されています。それぞれのコンポーネントは、次のイメージをロードする時に、ハッシュを確認して署名の妥当性を確認します。前述のように、HWルート鍵はファームウェア鍵に署名し、ファームウェア鍵は同様にペイロード・ハッシュに署名します。これらの公開鍵はコンテナのメタデータに含まれ、ブート時に署名の確認をするために利用できます。実行可能コンポーネントが、フラッシュ・メモリーからロードされる時、コンテナ・ヘッダー内のHW鍵のハッシュがSEEPROM内のハッシュとマッチしなければ、ブート・シーケンスは停止します。

コンテナ・メタデータは、秘密鍵やシークレットを含みません。署名されたコンポーネントが信頼チェーンを確立するために十分な公開情報のみが、含まれていることに注意してください。ファームウェア秘密鍵はファームウェア提供者が保持し、HWルート秘密鍵はプラットフォーム提供者(IBMあるいはOEMベンダー)が保持します。

リモート認証

これでCRTMが確立され、TPMがクォートを送られるようになったので、システムがブートした時の多くの情報を得ることができます。クォートの取得・解析を行うプロセスは、リモート認証 として知られています。

リモート認証はクライアント・サーバー型プロトコルです。クライアント(場合によって エージェント と呼ばれる)は、検証の対象となるノード上で動作するコンポーネントです。クライアントはTCGソフトウェア・スタック(TCG Software Stack: TSS)として知られるAPIを通してローカルTPMにアクセスし、TPMに現行のPCR値の署名済みリストの作成を要求し、認証サーバーに送付します。クライアントは、ファームウェアが生成するイベント・ログを取得し、クォートと共に送付する責任があります。認証サーバーは、ネットワーク上の信頼された独立したノード(例えば管理サーバー)上で稼働します。そして、クォートの検証と、取得したPCRダイジェスト・リストとイベント・ログの処理を行う責任があります。それがどのように行われるかは、この記事の範囲を超えていますが、簡単に触れておきます。ここでの記述は、オープン・ソースの "IBM TPM 2.0 Attestation Client Server" に基づいています。

IBM TPM 2.0 Attestation Client Serverを使えば、TPMから計測結果を取り出して検証することができます。コードはCで書かれ、MySQLデータベースとPHP webインターフェースを使用します。本文書作成時点では、IBM TPM 2.0 Attestation Client Serverは アルファ 開発段階で、どのLinuxディストリビューションにも含まれていません。しかし、これは容易にビルドや構成を行え、Linux・Apache・MySQL・PHP(LAMP)スタックと同様な環境で実行することができます。

リモート認証を用いることで、保全性の計測結果をTPMから取得し、検証することができます。

ここで、TPMがどのようにして鍵を扱うかについて、もう少し詳しく見ていく必要があります。前述のように、それぞれのTPMは、TPMベンダーが所有するルート承認鍵を用いて署名された、焼き付けられた固有の承認鍵(EK)を持っています。TPMのEK公開鍵に対する署名はX509証明書に保管され、TPMに事前導入されています。そしてこれがクォートを送る際に、クライアントが認証サーバーに送る最初の情報です。ルートEK証明書は公的に利用可能なX509証明書で、それはTPMベンダーから入手可能であり、認証サーバーのトラストストアにインポートできます。クライアントがEK証明書をを送ると、認証サーバーはルートEK証明書と照合し、鍵がこのベンダーによって製造されたTPMのものであることを検証できます。(サーバーは、現時点でこの鍵がどのTPMに属するかを知りません。分かっていることは、このベンダーから来たものであることだけです)

TPMはクォートに署名するためにはEKを使いません。この目的のために、認証鍵(AK)を生成します。クライアントはEK証明書を送るのと同じタイミングで、AKの公開鍵を認証サーバーに送ります。

EKとAK、これら二つの秘密鍵はTPM内に置かれ、取り出せないことに注意してください。TPM設計者が意図した方法によってのみ、TPMはこれらの鍵を使用します(これこそが、TPMが信頼されたベンダーが提供していることが重要な理由です)。仮にこれらの鍵を取り出すことができ、外部で使用できるなら、TPMと同様の機能を持った何かがTPMを偽装し、クォート要求された情報への信憑性を壊すことができてしまいます。

認証サーバーがEKとAKの公開鍵を受け取ったら、チャレンジを作成することで、このクライアントTPMが本当にこれらの鍵の持ち主であることを検証できます。これによって、サーバーは図2にある 登録(enrollment) と呼ばれる処理を完了します。要約すると、チャレンジは、クライアントが両方の秘密鍵部分を持っていることで初めて完了するように作成されます。さらに、チャレンジは、クライアントのTPMだけで完了するように行われます。これは、クライアント上にあるソフトウェアでは、この処理を 行えない ことを意味します。

チャレンジに含まれるのは、クライアントのEK公開鍵を用いて暗号化された シークレット です。また、チャレンジにはクライアントのAK公開鍵への参照も含まれ、鍵の 名前 と呼ばれます。クライアントTPMは、名前 がクライアントの正しいAKと一致しなければ、チャレンジを拒否します。クライアントがシークレットを復号して返信することで、信頼できるベンダーの純正TPMでクライアントが操作を行っており、認証鍵が信頼できることを、認証サーバーは確認できます。これが完了したら、クライアントは認証サーバーに 登録 されます。この様子が図2に示されています。

図 2. リモート認証登録(enrollment)プロセス

このTPMがAKの所有者であるということを、認証サーバーが特定できたとしても、システムが信頼可能であることを知る方法はありません。この場合の信頼とは、システムがこの組織のものであり、ネットワーク上に存在しても良いという意味です。将来的には、何らかの組織ルート鍵でクライアントを署名をする方法が、必要となるでしょう。そして、クライアントを信頼するために、認証サーバーのトラストストアに何らかの組織証明書が導入される必要があります。当面の間は、何らかの外部のステップでクライアントを信頼する仕組みが必要です。そして、クライアントが信頼されていることをサーバーに反映させるか、あるいは、クォートを送る各クライアントを暗黙的に信頼する必要があります。

これで、クライアントからの署名済みクォートの検証と、(CRTMによって)計測結果を生成したコンポーネントを信頼するために必要なインフラが整ったので、必要に応じてクォートを要求できます。また、クォートは現行のPCR値を含んでいるので、直近のクォート以降に変更があれば簡単に知ることができます。

イベント・ログの再生と妥当性の確認

クォートはPCRのダイジェスト・リストと、ブート時のイベント・ログを含んでいると説明しました。ダイジェスト・リストはTPMによって生成され、クォートを送る時にTPMによって署名されます。しかし、TPMはイベント・ログを管理しません。イベント・ログは、プラットフォーム・ファームウェア・スタック(つまりx86ならばUEFI、PowerPCならばOpenPOWERファームウェア)が管理します。このため、しばしば ファームウェア・イベント・ログ と呼ばれます。UEFIシステム上では、イベント・ログはAdvanced Configuration and Power Interface (ACPI) テーブル内に保管され、TPMはACPI デバイス・オブジェクト として表現されます。OpernPOWERシステム上では、イベント・ログは保護された主システム・メモリーで管理され、TPMはオープン・ファームウェアのデバイス・ツリーのエントリーとして表現されます。

UEFIとOpenPOWER システムは、TCGによって標準化されたTPM2.0用 Crypto Agile イベント・ログ・フォーマットを用いいます。仕様の全記述を "Trusted Computing Group EFI Protocol Specification" で確認することができます。各イベント・ログのレコードは、PCRに拡張した値(計測イベント)、あるいは非拡張イベントとしてブート・ステージ間のセパレータやエラー・マーカーを含みます。UEFIシステムでは、EFI TCGプロトコルを通して、ファームウェア・イベント・ログを取得します。OpenPOWERシステムでは、デバイス・ツリーのエントリーを経由して、イベント・ログを取得します。

イベント・ログの再実行で、イベント・ログの妥当性を検証します。そのために、期待されるPCRの値を導出し、TPM内の実際の値と比較します。

PCRダイジェスト・リストはTPMによって署名されますが、ファームウェア・イベント・ログはそうではありません。しかし、署名されたPCRダイジェスト・リストがあれば、イベント・ログの正確さ度合いを確認する方法があります。これは、イベント・ログの 再生 と呼ばれ、以下のように動作します。

各イベント・ログのエントリーはハッシュ値を持ち、そのハッシュは計測が行われた時に範囲をPCRに拡張されています。ファームウェア設計上重要なことは、PCRへの拡張オペレーションが行われると、必ず イベント・ログのエントリーが作成されることです。前述のように、拡張 オペレーションは、入力のハッシュ値とPCRダイジェストの現行の値を用いて、PCRを更新します。もし拡張オペレーションの完全なリストが存在し(全てのイベント・ログがあれば存在するはずです)、PCRダイジェストのスタート時の値を知っていれば(TPMリセット後に計測が開始されていればゼロ)、イベント・ログを 再生 するために十分な情報を持っており、期待するPCR値を再生成することができます。この再生はどこででも行うことができるので、クライアントTPM、あるいはどのような形態のTPMも不要です。拡張オペレーションのリストを、正しい順序でウォーク・スルーするという簡単なことで、あるべき最終のPCR値を計算できます。もし、計算した値がクォートに含まれる実際の値と一致すれば、イベント・ログはこのPCR用の拡張オペレーションの正しいリストを 必ず 含んでいます。もし、これを各PCRに対して行えば、イベント・ログの妥当性を確認したことになります。IBM TPM 2.0 Client Serverは、クォートを要求されたらいつでもこの再生を行います。もし再生が失敗すれば、認証サーバーはイベント・ログを無効としてフラグをつけます。

図3は、PCRダイジェスト・リストとイベント・ログ取得のための、クライアントとサーバーのやりとりを示しています。簡単のために、図ではいくつかの細かい点を省いています。例えば、クォートを要求するとき、認証サーバーは nonce と呼ばれる32バイトのランダムなデータを送ります。クライアントは、nonceを署名済みデータに入れて、サーバーに送ります。サーバーはデータを復号する際、送付したnonceと一致することを確認します。これによって、クォートが最新のものであることが確実になり、攻撃者が最新ではないクォートを送ってくることを防ぎます。

リモート認証クォート・プロセス

PCRスナップショットによる妥当性の確認

これでクライアントから署名済みクォートを得られるので、システムの妥当性を確認する方法が分かります。クォートはPCR ダイジェスト・リスト を含んでおり、それはTPMの全PCRの現行値でした。これらの値は一連の 計測結果 をPCRに 拡張 することによって、作成されました。全ての重要なファームウェア・コンポーネントと、システムのブート方法を管理する任意の構成データの計測を、セキュア・ハッシュで行います。したがって、PCR ダイジェスト・リスト は、基本的にシステムのブート時に何を実行したかを記録したものです。

前述のように、もしファームウェアが同じ計測結果のセットを同じ順序でPCRに拡張したら、結果として生成されるPCRダイジェストは、同じものになります。そしてそれこそが、UEFIあるいはOpenPOWERサーバーがブートした時に起きるであろうことです。PCR [0-7] がどのように使用されるかを、思い出してください。もし、同じファームウェア・コンポーネントのセットで、同じブート構成を用いてシステムをブートしたら、あるブートのPCR [0-1] とPCR [2-3] の値は、次のブートでも同じになります。そしてシステムがそのまま同じターゲットOSを同じメディアからブートすると、同様にPCR [4-5] の値は同じになるはずです。

これによって、システムの保全性を簡単に確認できます。いつでも好きなときにTPMにクォートを要求でき、TPMは直近のブートにおけるPCR値を返します。もし、以前のブートで生成された値と一致すれば、このシステムが以前のブートと厳密に同じようにブートされたことを知ることができます。もし、良好であることが確実な(つまり、システムが想定したハードウェアと構成のみを用いてブートしたということが明確な)システムのPCR値のスナップショットがあれば、そのスナップショットを 参照 状態または ゴールデン 状態として指定することができます。これを将来の保全性の確認に使用することができます。

PCRスナップショットを用いて、参照状態やゴールデン状態と比較することで、ファームウェアの保全性を検証できます。

この方法の欠点は、PCR値が参照状態と一致しない場合、変更された内容を知ることが難しいことです。それは、許可されていないコンポーネントをロードしたのかもしれません。あるいは、システム・セキュリティ上全く影響の無いような、単純な構成変更かもしれません。

また、この方法では事前に記録された、基準となる参照状態が必要です。良好であることが明確なシステム状態のスナップショットを 必ず 取得し、それは改ざんされていないことが確実である必要があります。コンポーネントの更新やシステムのブート構成の変更があれば、新しいスナップショットを記録しなければならず、それは改ざんされていないことが確実でなければなりません。これを行うために、現在のシステムが以前の状態とマッチすることを確認し、その後で変更を行い、新しいスナップショットを記録しなければなりません。そしてこれを アトミック な方法、つまり途中で意図しない変更が発生しないことが確実な方法で、行わなければなりません。このためには、この操作を行う際に、本番ネットワークからシステムを切り離さなければならないかもしれません。

この新しい参照状態の記録は、システムのライフサイクルを通じて行う必要があります。システムの最初の導入時に、初期の参照状態を取得するのは簡単かもしれませんが、システムが本番運用されてしばらく経っていればどうでしょう。どのような時でも、妥当性の確認ができるでしょうか。あるいは、それを行うのは、システム・ライフサイクルの最初に参照状態を記録した時だけに限定できるでしょうか。このような疑問に答えるためには、クォートと共に取得されたファームウェア・イベント・ログを精査する必要があります。これらのトピックは、今後の記事で取り扱います。

まとめ

OpenPOWERのトラステッド・ブートを用いることで、ファームウェアの保全性と真正性を検証し、サーバーが安全にブートしたことを確認することができます。リモート認証を使用することで、サーバーが、IBMや信頼できるプラットフォーム・ベンダーが提供した、許可されたファームウェアのみで稼働していることを確認できます。この記事では、信頼の基点のコア(Core Root of Trust) を確立する方法、保全性の計測結果がトラステッド・プラットフォーム・モジュール(TPM)に記録される方法、これらの計測のために IBM TPM 2.0 Attestation Client Server を使用する方法を見てきました。計測された値と直前のブートで記録されたものを比べることによって、サーバーが良好な参照状態でブートされたかどうかを確認することができます。

今後の記事でセキュア・ブートについて詳細に検討し、ブート時の計測結果のリストの重要性について説明します。

謝辞

著者は以下のIBMメンバーの有益な議論とテクニカル・レビューに対して感謝の意を表します: Warren Grunbok, Nayna Jain, Elaine Palmer, George Wilson, and Mimi Zohar.


ダウンロード可能なリソース


コメント

コメントを登録するにはサインインあるいは登録してください。

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Linux
ArticleID=1066802
ArticleTitle=OpenPOWERセキュア・ブートとトラステッド・ブート パート1:IBM OpenPOWERにおけるトラステッド・ブートの使用
publish-date=09192019