クラス：暗号サービス (FCS)

D.2.1 暗号鍵の管理 (FCS_CKM)

D.2.1.1 暗号鍵生成 (WLAN)

FCS_CKM.1(3) 暗号鍵生成

FCS_CKM.1.1(3) TSFは、以下の[IEEE 802.11ac-2013]に合致するFCS_RBG_EXT.1で 特 定 さ れ た ラ ン ダ ム ビ ッ ト 生 成 器 を 用 い て 、 指 定 さ れ た 暗 号 鍵 生 成 ア ル ゴ リ ズ ム

[PRF-704] 及び指定された暗号鍵長 [256ビット] に従い、対称暗号鍵を生成しなければな

らない (shall)

適用上の注釈：IEEE 802.11ac-2013 (セクション11.6.1.2) によって要求されWPA2認定で 検証される暗号鍵導出アルゴリズムは、HMAC-SHA-384関数を用いて704ビットを出力す るPRF-704である。

本要件は、クライアントが認証された後にアクセスポイントとクライアントとの間の通信 のために生成／導出される鍵にのみ適用される。これはPMK からのPTK の導出を指すも のであり、本 PP で特定される RBG によって生成される乱数値、本 PP で特定される

SHA-384 を用いた HMAC 関数、及びその他の情報を用いて行われる。これは、IEEE

802.11ac-2013の主に11章に特定されている。

保証アクティビティ：

暗号プリミティブは、本PPの別の場所で特定される保証アクティビティによって検証され ることになる。評価者は、本PPによって定義され実装されるプリミティブが無線クライア ントへのセキュアな接続性を確立し維持するために TOE によって使用される方法が TSS に記述されていることを検証しなければならない (shall)。またTSSには、開発者の実装が 暗号標準に準拠していることを保証する開発者の 1 つまたは複数の方法の記述が提供され なければならない (shall)。これには、開発組織によって行われたテストだけではなく、行 われたサードパーティテスト (例えばWPA2認定) が含まれる。評価者は、テスト方法論の 記述が十分に詳細であって、プロトコル規定の詳細がテストされた範囲を判断できること を保証しなければならない (shall)。

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

ステップ1 - 評価者は、無線アクセスポイントとTOEとの間にパケットスニフィングツー ルを用いなければならない (shall)。評価者は、パケットスニフィングツールをオンにして、

アクセスポイントへのTOEの接続を成功させなければならない (shall)。

ステップ2 – 評価者は、キャプチャされた802.11ビーコン及びプローブ応答メッセージ中 で、サポートされている Authentication and Key Management (AKM) スイートとして

00-0F-AC:12をアドバタイズし、またサポートされている暗号スイートとして00-0F-AC:9

または00-0F-AC:10のいずれかをTOEがアドバタイズしていることを検証しなければなら

ない (shall)。

D.2.1.2 暗号鍵生成 (Bluetooth)

FCS_CKM_EXT.7 拡張：Bluetooth鍵生成

FCS_CKM_EXT.7.1 TSFは、[割付：新たな鍵ペア生成の頻度またはその基準あるいはその 両方] ごとに公開／プライベート ECDH 鍵ペアをランダムに生成しなければならない (shall)。

適用上の注釈：ECDH 鍵ペアを適切にフレッシュに保つための受け入れ可能な方法は、例 えば24時間を超えて同一の鍵ペアが使われないような時間ベースのアプローチを含め、複 数存在することだろう。あるいは、その基準は合格または失敗した認証試行の回数と関連 しているかもしれない。合理的な認証試行ベースの置換基準を判断する出発点として、

Bluetooth規格 (v4.1, Vol. 2, 5.1) では、任意のBD_ADDRからの3回の認証試行失敗後、

任意のBD_ADDRからの10回のペアリング成功後、または任意の3回のペアリング成功を

1 回のペアリング失敗と数えてこれらの組み合わせの後にデバイスのプライベート鍵を変 更することによって、認証試行の繰返しを低減することを推奨している。

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

保証アクティビティ：

評価者は、新たなECDH公開／プライベート鍵ペアを生成する頻度を決定するために使用 される基準がTSSに記述されていることを保証しなければならない (shall)。特に、評価者 はその実装が静的な ECDH 鍵ペアの使用を許可しないことを保証しなければならない (shall)。

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

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

ステップ1 - TOEをリモートBluetoothデバイスとペアリングし、TOEによってその時点で

使用中の公開鍵を記録する。(この公開鍵は、Bluetoothプロトコルアナライザを用いてペア リング中に交換されるパケットを検査することによって取得できる。)

ステップ2 - 新たなECDH公開／プライベート鍵ペアを生成するために必要なアクション

を行う。(このテストの手順は、新たなECDH公開／プライベート鍵ペアを生成する頻度を 決定するために使用される基準がどのようにTSSに記述されているかに依存することに注 意されたい。)

ステップ3 - TOEをリモートBluetoothデバイスとペアリングし、TOEによってその時点で

使用中の公開鍵を再び記録する。

ステップ4 - ステップ1の公開鍵が、ステップ3の公開鍵と異なっていることを検証する。

D.2.2 ランダムビット生成 (FCS_RBG)

FCS_RBG_EXT.1 拡張：暗号操作 (ランダムビット生成)

FCS_RBG_EXT.1.4 TSF は 、 ア プ リ ケ ー シ ョ ン が SP 800-90A に 定 義 さ れ る

Personalization Stringを用いて決定論的RBGへデータを追加することを許可しなければな

らない (shall)。

適用上の注釈：SP 800-90Aで指定されるように、TSFはアプリケーションから入力された データを、FCS_RBG_EXT.1 によって要求されるエントロピーにカウントしてはならない

(shall not)。したがって、TSFはRBGシードへの唯一の入力がアプリケーションからのも のとなることを許可してはならない (shall not)。

保証アクティビティ：評価者は、この機能がRBGへのインタフェースとして附属書Eによ って要求される文書に含まれていること、及びこのインタフェースの呼び出しに続くRBG のふるまいが記述されていることを検証しなければならない (shall)。評価者は、SP

800-90Aが指定するDRBGへのPersonalization Stringの入力に関して、利用の条件と取り

得る値がRBGの文書に記述されていることについても検証しなければならない (shall)。評 価者は、以下のテストについても実行しなければならない (shall)。

テスト1：評価者は、Personalization Stringを介してRBGへデータを追加するアプリケー ションを書くか、または、開発者がそのようなアプリケーションへのアクセスを提供しな ければならない (shall)。 評価者は、その要求が成功することを検証しなければならない (shall)。

FCS_RBG_EXT.1.5 TSF は、電源断時に決定論的 RBG の状態を保存しなければならず

(shall)、また起動時にこの状態を決定論的 RBG への入力として用いなければならない

(shall)。

適用上の注釈：電源断時に保存された状態をRBGへの入力として追加する機能は、エント ロピーの収集が低速な RBG が、リブートのたびに同一の出力を作成することを防止する。

状態が保存される際に保護が提供されるという保証はない (あるいは、そのような保護に関 する要件もない) ため、その状態は「既知」であるとみなされ、したがってRBGへのエン トロピーには寄与できないが、RBG の初期値が予測できず悪用できないようにするために 十分な変動を導入することはできる。

保証アクティビティ：

本要件の保証アクティビティは、附属書EのRBG文書中に取り込まれる。評価者は、次回 起動時に利用できるようにするべくその状態を生成する方法、その状態がDRBGへの入力 としての利用方法、そしてTOEが電源断の間にその状態に対して使用されるあらゆる保護 対策が、その文書に記述されていることを検証しなければならない (shall)。

D.2.3 暗号アルゴリズムサービス (FCS_SRV)

FCS_SRV_EXT.1 拡張：暗号アルゴリズムサービス

FCS_SRV_EXT.1.2 TSFは、アプリケーションが、セキュアな鍵ストレージに保存された 鍵によって、TSF が以下の暗号操作を実行するよう要求するメカニズムをアプリケーショ ンに提供しなければならない(shall)：

 FCS_COP.1(1) におけるアルゴリズム

 FCS_COP.1(3) におけるアルゴリズム

これらは、セキュアな鍵ストレージに格納された鍵によるものとする。

適用上の注釈：将来、TOEは、TOE上で動作するアプリケーションを含め、TOE以外へ平 文鍵材料を送信することが許されなくなる。 したがってTOEは、TOEのセキュアな鍵ス トレージに格納された鍵を用い、アプリケーションを代行して暗号操作を行うことが要求 されることになる。

保証アクティビティ：

評価者は、セキュアな鍵ストレージに関する API 文書に、格納された鍵による暗号操作が 含まれることを検証しなければならない (shall)。

評価者は、TSF による格納された鍵の暗号操作を要求するアプリケーションを書くか、ま たは、開発者がそのようなアプリケーションへのアクセスを提供しなければならない

(shall)。 評価者は、操作から得られた結果が API文書に従って期待される結果と一致する

ことを検証しなければならない (shall)。評価者は、FCS_STG_EXT.1中の保証アクティビ ティに従ってセキュアな鍵ストレージの機能をテストするため、これらの API を利用しな ければならない (shall)。

D.2.4 TLS クライアントプロトコル (FCS_TLSC)

D.2.4.1 EAP-TLSクライアントプロトコル

FCS_TLSC_EXT.1 拡張：EAP-TLSプロトコル

FCS_TLSC_EXT.1.6 TSFは、Client Hello中のsignature_algorithms拡張に以下のハッシ ュアルゴリズムを含む supported_signature_algorithms 値を提示しなければならない (shall)： [選択：SHA256、SHA384、SHA512] 及びその他のハッシュアルゴリズムなし。

適用上の注釈：本要件は、クライアントによるデジタル署名検証の目的でサポートされる ハッシュアルゴリズムを制限すると共に、サーバによるデジタル署名生成の目的でサポー トされるハッシュにサーバを制限する。signature_algorithm拡張は、TLS 1.2のみによって サポートされる。

signature_algorithms 拡張のサポートは、2015 年の第 3四半期以降に評価に入る製品につ

いて必須となる。

保証アクティビティ：

評価者は、signature_algorithm 拡張について、そして要求されるふるまいがデフォルトで 実施されるのか設定され得るのかのどちらであるか、TSS に記述されていることを検証し なければならない (shall)。本要件を満たすためにはsignature_algorithm拡張が設定されな ければならない (must) ことが TSS に示されている場合、評価者は AGD ガイダンスに

signature_algorithm拡張の設定が含まれることを検証しなければならない (shall)。

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

 テスト：評価者は、signature_algorithms拡張のクライアントHashAlgorithm一覧 にしたがってサポートされていないTLS接続において証明書を送信するようサー バを設定しなければならない (例えば、SHA-1 署名を持つ証明書を送信する)

(shall)。 評価者は、サーバの証明書ハンドシェイクメッセージの受信後、TOEが

接続を切ることを検証しなければならない (shall) 。

FCS_TLSC_EXT.1.7 TSFは、RFC 5746に従って「renegotiation_info」TLS拡張を使っ てセキュアな再ネゴシエーションをサポートしなければならない (shall)。

FCS_TLSC_EXT.1.8 TSFは、ClientHelloメッセージで [選択：以下より1つのみ選択：

renegotiation_info 拡張、TLS_EMPTY_RENEGOTIATION_INFO_SCSV 暗号スイート] を 含めなければならない (shall)。

適用上の注釈： RFC 5746は、再ネゴシエーションのハンドシェイクを最初のハンドシェ イクの暗号にバインドするようなTLSへの拡張を定義している。

選択に含まれる暗号スイートは、クライアントがその拡張をサポートしないサーバと互換 性を持つための手段である。 クライアント実装が暗号スイートと拡張の両方をサポートす ることが推奨されている。

保証アクティビティ：