Bluetooth の許可と認証 (FIA_BLT)

または暗号化に使用されるすべての鍵材料をワイプすることによって機微な保存データが 復号されることを防止するものでなければならない (must)。本セクションの導入部で要件 を満たす 2 つの異なるスキームを提供したが、その他のソリューションによって本要件へ 対処してもよい。

評 価 者 は 、 ロ ッ ク 状 態 に あ る 間 に 、 も は や 不 要 と な っ た す べ て の 鍵 材 料 に つ い て

FCS_CKM_EXT.4のテストを実行しなければならず (shall)、また非対称スキームの鍵はロ

ック状態への移行の際に実行されるテストにおいて対処されることを保証しなければなら ない (shall)。

FDP_DAR_EXT.2.3 TSFは、FCS_STG_EXT.2.1の選択2に従って、機微なデータの保護 に使用された非対称鍵の任意の保存されたプライベート鍵及び任意の保存された対称鍵を 暗号化しなければならない (shall)。

適用上の注釈：TSF がロック解除状態にある間に機微なデータの暗号化に使用される対称 鍵は、REK及びパスワードから導出されたKEKによって暗号化され (または、それらによ って暗号化されたKEKへチェインし) なければならない (must)。ロック状態でデータの暗 号化に使用される非対称鍵スキームの保存されたプライベート鍵は、REK 及びパスワード から導出されたKEKによって暗号化され (または、それらによって暗号化されたKEKへチ ェインし) なければならない (must)。

保証アクティビティ：

評価者は、FCS_STG_EXT.2.1 のために要求されるTSSの鍵階層構造セクションに、機微 なデータの暗号化に使用される対称暗号鍵 (DEK) が含まれていることを検証しなければ ならない (shall)。 評価者は、これらのDEKがREK及びパスワードから導出されたKEK によって暗号化され (または、それらによって暗号化された KEK へチェインし) た鍵によ って暗号化されることを保証しなければならない (shall)。

評価者は、非対称鍵スキームを記述するSTのTSSセクションに、非対称ペアの任意のプ ライベート鍵の保護が含まれることを検証しなければならない (shall)。 評価者は、ワイプ されずTSFによって保存される任意のプライベート鍵が、REK及びパスワードから導出さ れたKEKによって暗号化され (または、それらによって暗号化されたKEKへチェインし) た鍵によって暗号化されて保存されることを保証しなければならない (shall)。

FDP_DAR_EXT.2.4 TSFは、ロック状態にある間に受信された機微なデータを、ロック解 除状態への移行の際に、非対称鍵スキームを用いて復号しなければならず (shall)、また対 称鍵スキームを用いてその機微なデータを再度暗号化しなければならない (shall)。

保証アクティビティ：

評価者は、非対称鍵スキームを記述するSTのTSSセクションに、ロック解除状態への移 行の際に TSFによって DAR の目的で取られるアクションの記述が含まれることを検証し なければならない (shall)。これらのアクションには少なくとも、非対称鍵スキームを用い てすべての受信されたデータの復号が行われること、及びデバイスがロック解除状態にあ る間にデータの保存に使用される対称鍵スキームを用いて再度暗号化が行われることが含 まれなければならない (shall)。

FIA_BLT_EXT.1.2 TSF は、以下のBluetoothプロファイル： [割付：Bluetoothプロファ イルのリスト] と関連付けられたサービスへの高信頼リモートデバイスのアクセスを許可 する前に明示的な利用者許可を要求しなければならず (shall)、また以下のBluetoothプロフ ァイル： [割付：Bluetooth プロファイルのリスト] と関連付けられたサービスへの信頼で きないリモートデバイスのアクセスを許可する前に明示的な利用者の許可を要求しなけれ ばならない (shall)。

適用上の注釈：ペアリングに加えて、特定のリモートデバイスによる特定のBluetoothサー ビスへのアクセスを許可する明示的な利用者のアクションを要求することが適切であるか もしれない。TSF は、この追加のアクションをすべてのデバイスについて要求するか、ま たは要求される信頼のレベルを有しないデバイスにのみ要求するか、選んでもよい。

TSFは、特定のデバイスをTOEとの高信頼デバイス関係を持つものとして指定し、それら にすべてのサービスへの「包括的 (blanket)」アクセスを許可するかもしれない。しかし、

そうではなく、それぞれのサービスについてその特定のサービスを利用することが信頼さ れたデバイスのリストをTSFが維持管理することが強く推奨される。

さらに、TSF は特定のサービスについてデバイスを、利用者がそのデバイスにそのサービ スを利用する明示的な許可を与えた後で、信用されないカテゴリから高信頼カテゴリへ移 動させることもあるかもしれない。例えば、初めてオブジェクト転送のためにリモートデ バイスがOBEX サービスを使う前に、利用者が明示的で手作業での許可を与えるよう要求 することが適切であるかもしれない。利用者には、その特定のデバイスによるそのサービ スへの将来の接続を、毎回明示的な許可を要求せずに許可するオプションが提示されるか もしれない。

ST作成者は、リモートデバイスがアクセスを取得する前に明示的な利用者の許可が必要と されるすべてのBluetoothプロファイル及びサービスを列挙しなければならない (shall)。そ のサービスについてデバイスがTOEとの信頼関係を有するかどうかに応じてふるまいの違 いが存在する場合には、それが特定されなければならない (must)。

保証アクティビティ：

評価者は、本要件に従って保護されるサービスのそれぞれについて、以下のテストを実行 しなければならない (shall)：

テスト1：評価者は、サービスがTOE上のアプリケーションによってアクティブに使用中 である間に、そのサービスを利用するために要求される信頼のレベルを有さないリモート デバイスから (要件の 2番目のリストにある) 「保護された」Bluetooth サービスへのアク セスの取得を試行しなければならない (shall)。 評価者は、TOE によって利用者へ、その 特定のリモートデバイスにサービスへのアクセスを許すための許可が明示的に求められる ことを検証しなければならない (shall)。 評価者は、TOE 上で許可を拒否し、サービスへ アクセスするためのリモート試行が許可の欠如のため失敗することを検証しなければなら ない (shall)。

テスト2：評価者は、テスト1を繰り返し、権限付与を許可し、リモートデバイスがサービ スへのアクセスに成功することを検証しなければならない (shall)。(信頼されないリモート デバイスがTOEとまだペアリングされたことがない場合、本接続はペアリングを要求して もよいことに注意されたい。)

テスト3：利用者の許可が要求されるかどうか決定するにあたり、TSFの実装が信頼された デバイスと信頼されないデバイスとを区別している場合、要件の 2 番目のリスト中に表れ る (最初のリストではなく) サービスと、そのサービスを利用するために要求される信頼の レベルを有するデバイスを用いて、テスト 1 を繰り返す。評価者は、利用者が明示的な許

可のためにプロンプト表示されないこと、及びサービスへの接続が成功することを検証し なければならない (shall)。

テスト4：利用者の許可が要求されるかどうか決定するにあたり、TSFの実装が信頼された デバイスと信頼されないデバイスとを区別している場合、要件の最初のリスト中に表れる サービスと、そのサービスを利用するために要求される信頼のレベルを有するデバイスを 用いて、テスト1を繰り返す。 評価者は、利用者がその特定のリモートデバイス用のサー ビスへのアクセスを許すために、TOE による許可が明示的に求められることを検証しなけ ればならない (shall)。 評価者は、TOE 上で許可を拒否し、許可がないためにサービスへ アクセスするためのリモートからの試行が失敗することを検証しなければならない (shall)。

テスト5：利用者の許可が要求されるかどうか決定するにあたり、TSFの実装が信頼された デバイスと信頼されないデバイスとを区別している場合、要件の最初のリスト中に表れる サービスと、そのサービスを利用するために要求される信頼のレベルを有するデバイスを 用いて、テスト2を繰り返す。 評価者は、利用者が明示的に許可を提供した場合、そのリ モートデバイスがサービスへのアクセスに成功することを検証しなければならない (shall)。

D.4.1.2 Bluetooth認証

FIA_BLT_EXT.1 拡張：Bluetooth認証

FIA_BLT_EXT.2.1 TSFは、Bluetoothリンク上でのあらゆるデータ転送の前に、デバイス

間のBluetooth相互認証を要求しなければならない (shall)。

適用上の注釈：デバイスがペアリング済みでない場合、ペアリング処理が開始されなけれ ばならない (must)。デバイスがペアリング済みの場合、あらゆるデータがリンク上を通過 する前に現在のリンク鍵に基づく相互認証が成功しなければならない (must)。

保証アクティビティ：

評価者は、Bluetoothペアリングが完了する前に、任意の種別のデータ転送が防止される方 法についてTSSに記述されていることを保証しなければならない (shall)。 TSSには、任 意のサポートされるRFCOMM及びL2CAPデータ転送メカニズムが明確に記述されなけれ ばならない (shall)。 評価者は、Bluetooth デバイスがペアリングされ相互認証された後に のみデータ転送が完了されることを保証しなければならない (shall)

評価者は、以下のテストを実行しなければならない (shall)：

テスト1：評価者は、OBEX Object Pushサービスを用いたTOEファイルへのアクセスを 試行するためにBluetoothツールを利用し、アクセスが許される前にTOEによりペアリン グと相互認証が要求されることを検証しなければならない (shall)。 (OBEX Object Pushサ ービスがTOE上でサポートされない場合、Bluetooth L2CAP及び／またはRFCOMM上で データを転送する異なるサービスが本テストで使用されてもよい。)

FIA_BLT_EXT.2.2 TSF は、現在の接続がすでに存在する Bluetooth デバイスアドレス

(BD_ADDR) からの接続試行を破棄しなければならない (shall)。

適用上の注釈：TOE がすでにリモート Bluetooth デバイスとの接続を有する場合、同じ

Bluetoothデバイスアドレスを主張するデバイスからの新たな接続試行は悪意のある可能性

があり、拒否／無視されるべきである (should)。 単一のリモートBD_ADDRへは、同時に 1つの接続のみがサポートされる。

本要件は、セクション5に移動される予定であり、また2015年の第3四半期以降に評価に 入る製品については、必須とされることになる。

保証アクティビティ：

評価者は、同じBluetoothデバイスアドレスを持つ2つのデバイスが同時に接続されること なく、また最初の接続が任意の後続の接続試行により上書きされることなく、Bluetooth接 続が維持管理される方法について TSS に記述されていることを保証しなければならない (shall)。

評価者は、以下のテストを実行しなければならない (shall)：

テスト1：評価者は、以下のステップを実行しなければならない (shall)：

ステップ1 - TOEと既知のアドレス (BD_ADDR1) に対応するリモートBluetoothデバイス

との間でBluetooth接続を行う。

ステップ2 - BD_ADDR1と一致するBluetoothデバイスアドレスを持つと主張する第2の

リモートBluetoothデバイスからの同じTOEへの接続を試行する。

ステップ3 - Bluetoothプロトコルアナライザを用いて、第2の接続試行がTOEにより無視

され、BR_ADDR1を持つデバイスへの最初の接続が影響されないことを検証する。