D 社は，全国でマンションの開発・メンテナンスを手掛ける中堅の不動産デベロッパである。D 社は各地域を担当する四つの子会社をもち，各子会社はそれぞれ複数の事業部門をもつ。D 社及び子会社（以下，D 社グループという）は，積極的に人材交流を行い，人材育成及び人材活用を推進している。D 社グループの構成を表 1 に示す。
表 1 D 社グループの構成
D 社グループの従業員（以下，グループ従業員という）には，D 社グループ内で一意となる番号（以下，グループ従業員番号という）が付与されている。また，オフィスや現場事務所の入室及び退室時に必要となる専用の IC カード（以下，入退室カードという）が貸与されている。D 社グループ各社にはそれぞれ IT 部門がある。D 社グループの全ての入退室カードは，D 社の IT 部門が管理している。各社の IT 部門は，自社従業員が利用する PC 及びネットワークを管理しており，D 社の IT 部門は，それらに加えて人事，経理などのバックオフィス系のシステムを管理している。
各事業部門は，それぞれ専用の Web システム（以下，事業用システムという）を多数運用している。D 社の子会社が実施するプロジェクトに参加する D 社グループ及び取引先のプロジェクトメンバには，必要に応じて事業用システムのアカウントが付与される。事業用システムは，今後も新しいシステムの導入や既存システムの更新が見込まれている。
〔IT 部門の統合〕
D 社では，IT による業務効率向上，コスト削減及び情報セキュリティ強化を目的に，D 社グループ各社の IT 部門を統合し，D 社内にシステム部を創設することにした。
システム部長に任命された M さんは，体制の整備とともに，D 社グループ各社のシステムに関する調査を進めた。事業用システムの多くは，利用者 ID とパスワードで利用者を認証していた。調査の結果，各事業用システムは，類似した利用者認証機能を備えており，利用者認証の統合又は共通化によって業務の効率向上が可能であることが分かった。また，事業用システムの多くは TLS を利用していた。このうち，社内向け事業用システムでは，D 社グループ各社が個別にプライベート認証局を準備し，サーバ証明書を発行していた。事業用システムの利用者認証には，次の問題点があることが分かった。
問題点 1 現場事務所において，現場担当者が自身の利用者 ID とパスワードを紙に書いて PC に貼り付けているケースが散見された。また，利用者 ID とパスワードを，他人に教えたケースも複数あった。
M 部長は，部下の N さんに対して，D 社の情報セキュリティ室の R 主任の支援を受けつつ，方式設計を進めるように指示した。
次は，認証カードの方式設計についての，N さんと R 主任との会話である。
N さん：パスワードを用いる利用者認証では，ログインする人の a を確認していました。認証カードを利用する利用者認証では，認証カードの b を確認することになりますね。
R 主任：そうだね。加えて，認証カードの利用時に PIN を入力させることで，2 種類の方法を組み合わせた c 認証にすることができる。ただし，①認証対象者が不適切な行為をすると，その効果は望めない。
N さん：認証カードを導入すると，利用者 ID とパスワードを使わなくなるので，問題点 1 と問題点 2 は解決しますね。IC カードに PKI を組み合わせるのはなぜですか。
R 主任：IC カードを利用者認証に用いる二つの方法を比べてみよう。一つ目は，PKI を用いない方法で，IC カードに利用者認証情報を記録し，利用者認証時にこれを読み出してその値を比較することによって認証する方法だ。この方法では，IC カードに記録された利用者認証情報を読み出して処理するため，それが何らかの理由で漏えいした場合に，簡単に悪用されるおそれがある。二つ目は，PKI を用いて，IC カードに公開鍵暗号方式の秘密鍵とそれに対応する利用者証明書を格納する方法だ。
N さん：後者の方法では，どのように認証するのですか。
R 主任：公開鍵暗号技術を用いてエンティティ認証を行うプロトコルを，図 2 に示す。これは片方向認証の場合で，検証者 B が要求者 A を認証している。J システムでは，検証者 B は d に相当し，要求者 A は e に相当する。
図 2 公開鍵暗号技術を用いたエンティティ認証のプロトコル
N さん：図 2 のプロトコルを使う上での注意点はありますか。
R 主任：2 点ある。1 点目は，認証が成立するためには，鍵が k していないことが必要であることだ。事業用システムは，利用者証明書の失効情報を確認しなければならない。認証カードの紛失時などの場合，認証局は速やかに当該利用者証明書についての失効情報を提供する。失効情報は，CRL の配布により，又は l を使って提供されることが多い。
システム部は，既存の PC 管理の仕組み及び PC のメンテナンスの機会を利用し，⑤グループ従業員が利用する PC に D 社ルート CA の公開鍵証明書を登録する。取引先の従業者がアクセスするサーバで J システムのサーバ証明書を利用する場合には，当該サーバを利用する全ての取引先に対して，D 社ルート CA の公開鍵証明書を配布する。この際，D 社の認証局が万が一何らかの原因で不正操作される可能性を想定し，⑥取引先においては，D 社ルート CA の公開鍵証明書を，当該サーバだけにアクセスする専用の PC にインストールするよう要請する。
これらの設計案は M 部長に報告され，承認された。J システムは実装され，試験フェーズ 1 が開始された。一部の事業用システムは，J システムの利用者証明書を用いて認証を行うように改修された。また，一部のサーバでは，CA-3 が発行したサーバ証明書の利用が開始された。
〔取引先の従業者への認証カードの貸与〕
試験フェーズ 1 の開始から 3 か月後に，試験フェーズ 2 の準備が開始された。
N さんは，取引先に認証カードを貸与する方式を設計し，表 3 の二つの案にまとめた。取引先へ認証カードを導入するに当たっての機能要件は，従業者を個人ごとに識別・認証できること，及び事業用システムの操作履歴を記録し，プロジェクトごとに表示できることである。N さんは，方式 A 及び方式 B はともに機能要件を満たしていると判断した。また，方式の選択に際して優先される非機能要件は，第 1 に事業部門での管理工数が少ないこと，第 2 にシステム部での管理工数が少ないことである。
表 3 取引先の従業者への認証カード貸与方式案（抜粋）
N さんが取引先について過去数年分のプロジェクトへの参加状況を調査したところ，取引先の従業者は最多で五つのプロジェクトに同時に参加していた。また，専門技術をもつ工事関係取引先の従業者は，各プロジェクトへの参加期間は短いが，1 か月以内に次のプロジェクトに参加することが多いことが分かった。取引先の従業者の 3 割程度が，このような工事関係取引先の従業者であった。
検討の結果，N さんは，方式 B が非機能要件の面で優位と考え，M 部長に提案した。M 部長は提案された方式を承認し，実装が開始された。その後，試験フェーズ 2 が開始され，取引先の従業者への認証カードの貸与が始まった。
パスワードを用いる利用者認証では，ログインする人の a を確認していました。認証カードを利用する利用者認証では，認証カードの b を確認することになりますね。
〔認証カードの方式設計〕 R主任
認証カードの利用時に PIN を入力させることで，2 種類の方法を組み合わせた c 認証にすることができる。
〔認証カードの方式設計〕 R主任
認証が成立するためには，鍵が k していないことが必要であることだ。事業用システムは，利用者証明書の失効情報を確認しなければならない。
〔認証カードの方式設計〕 R主任
失効情報は，CRL の配布により，又は l を使って提供されることが多い。
利用者認証の要素は，本人だけが知っているもの（記憶），本人だけが持っているもの（所持），本人の身体の特徴（生体情報）に分けられる。パスワードは本人の記憶を確かめるので a は“記憶”（ウ），認証カードは持っていることを確かめるので b は“所持”（オ）である。認証カードに PIN（記憶）を組み合わせると種類の違う 2 要素になるので，c は“複数要素”（ス）が入る。
k は，鍵（秘密鍵）が漏えいなどで安全でなくなった状態を指す“危たい化”（エ）である。危たい化した鍵の利用者証明書は失効させ，検証する側は失効情報を確かめる。失効情報の提供方法には，失効した証明書の一覧である CRL を配布する方法と，証明書ごとに状態を問い合わせる OCSP（Online Certificate Status Protocol，RFC 6960）がある。よって l は“OCSP”（イ）である。
解答群の“単要素”は 1 種類だけの認証，“生体情報”は第三の要素なので c には当たらない。“HMAC”は共通鍵を使うメッセージ認証コードで，失効情報の提供には使わない。c は“2 種類の方法を組み合わせた”とあるので，“多機能”ではなく“複数要素”を選ぶ。
要求者 A は鍵ペア（Kp，Ks）とともに f を用意し，手順 6 で f を検証者 B に送る。B は f から A の公開鍵 Kp を取り出して署名を検証するので，f は公開鍵を収めた公開鍵証明書，すなわち利用者証明書（ク）である。図 1 のとおり，認証カードには利用者証明書と秘密鍵が格納されている。注記にあるとおり，B は受け取った証明書の正当性（発行した認証局の署名や失効の有無）も確かめる。
“認証局”は証明書を発行する側で，このプロトコルのメッセージ交換には加わらない。“サーバ証明書”はサーバを認証するときの証明書なので，利用者を認証する f には当たらない。f は秘密鍵ではない。秘密鍵は認証カードから出さず，手順 5 の署名に使うだけである。
Web ブラウザは，サーバ証明書の署名を上位の認証局へとたどり，信頼する認証局（トラストアンカー）の証明書に行き着いたときにだけ証明書を正当と判断する。CA-3 は D 社ルート CA の下位にあり，D 社ルート CA はプライベート認証局なので，PC にその公開鍵証明書を登録しなければ証明書の検証を完了できない。解答例は“サーバ証明書の正当性を確認できず警告が表示される。”である。
これまでは各社が個別のプライベート認証局でサーバ証明書を発行しており，認証局を新しい D 社ルート CA に一本化するので，全 PC に新しいルート CA の証明書を配る必要がある。システム部は既存の PC 管理の仕組みとメンテナンスの機会を使ってこれを行う。
この際，D 社の認証局が万が一何らかの原因で不正操作される可能性を想定し，⑥取引先においては，D 社ルート CA の公開鍵証明書を，当該サーバだけにアクセスする専用の PC にインストールするよう要請する。
ルート CA の公開鍵証明書を PC に入れると，その PC の Web ブラウザは，そのルート CA の配下で発行された全てのサーバ証明書を信頼する。D 社の認証局が不正操作されれば，攻撃者は任意のサーバ名のサーバ証明書を発行でき，それを使った偽のサーバにも取引先の PC は警告なしに接続してしまう。解答例は“PCのWebブラウザが不正なサーバ証明書を信頼し，不正なサーバにアクセスするリスク”である。
専用の PC に限れば，D 社ルート CA を信頼するのはその PC だけになり，取引先が普段インターネットや自社の業務に使う PC には影響が及ばない。取引先にとって D 社は外部の組織なので，D 社の認証局の不正まで自社の全 PC に持ち込まないための措置である。
社内サーバセグメントと各 PC セグメント上の機器からは，プロキシサーバを経由したインターネット上の Web サイトへのアクセスが許可されており，アップデート用サーバと PC にはプロキシサーバを経由するような設定がされている。一方，社内サーバセグメントと各 PC セグメント上の機器からのプロキシサーバを経由しないインターネットへのアクセスは，FW によって禁止されている。アップデート用サーバからのアクセス先は，特定のベンダのサイトに限定されている。
脆弱性対策基準の運用を開始して間もなく，ある Web アプリケーションのソフトウェアパッケージ（以下，ソフトウェア M という）のバージョン Z に SQL インジェクションの脆弱性（以下，X 脆弱性という）があり，パッチが提供されているという情報が公表された。CVSS 基本値は 6.5 であった。Q 主任は，A 社の機器にソフトウェア M が導入されているかどうかが分からなかった。そこで，V チーム員に次の対応を指示した。
固定資産管理台帳に記載がある機器について，ソフトウェア M を導入しているかどうかを調査すること
導入している機器について，X 脆弱性に対する脆弱性対策適用の緊急度を判断すること
V チーム員は，ソフトウェア M を導入しているかどうかの確認に手間取り，1 週間後に Q 主任に調査結果を報告した。ソフトウェア M を導入した機器はないとの調査結果だったので，Q 主任は，X 脆弱性への対応を終了し，P 部長に報告した。ところがその 2 週間後，α 製品本部の V チーム員から，①社外の取引先と重要情報を共有するための公開 Web サーバにソフトウェア M のバージョン Z が導入されていることが分かり，対応したとの報告が入った。
当初の調査に見落としがあったことを問題視し，Q 主任は，α 製品本部の V チーム員に見落としの原因を調べさせた。原因は，当該機器が先月導入されたばかりで，固定資産管理台帳に記載がなかったことにあった。Q 主任は，V チーム員に対して，固定資産の棚卸以降に導入された機器がないかの確認を指示した。他に見落とした機器はなかったことが分かり，Q 主任は P 部長に報告した。
報告を受けた P 部長は，当初の調査のような見落としの再発防止策を検討するよう Q 主任に指示した。Q 主任は，まず，固定資産管理台帳を基に，機器の新たな管理台帳（以下，新台帳という）を V チームで作成することにした。②新台帳にはバージョンを含むソフトウェアの情報も記載することにした。また，機器の新規導入や構成変更の際には，新台帳を速やかに修正する手順にした。Q 主任は，これらの改善策について P 部長に報告し，承認を得て実施した。
Web サーバにおいても，③ある条件を満たす場合には，この Y 脆弱性を悪用される。図 7 は，CGI を利用した，ある Web アプリケーションプログラム（以下，Web アプリ B という）が呼び出される際のフローである。
図 7 Web アプリ B に対するアクセスのフロー
典型的な Web サーバでは，Web サーバ（httpd）が a ヘッダの④フィールド値を環境変数として設定してから Web アプリ B を起動するので，攻撃者は，Y 脆弱性を悪用して Web サーバで任意のコードを実行することができる。例えば，図 6 の例と同様の場合であれば，cat コマンドが実行され，このとき，cat コマンドの実行時の権限によっては，攻撃者にどのようなファイルでも参照されてしまう。
Q 主任は，直ちに Y 脆弱性への対応を開始した。新台帳を基に，Y 脆弱性が影響する機器があるかを V チーム員が確認したところ，公開 Web サーバのうち，重要度レベル高のサーバ 8 台と重要度レベル低のサーバ 5 台が該当していることが分かった。Y 脆弱性が悪用されると公開 Web サーバが改ざんされるおそれもあり，事態を重く受け止めた Q 主任は，重要度レベル高のサーバだけでなく，該当する重要度レベル低のサーバ 5 台に対しても直ちに脆弱性対策を適用するよう V チーム員に指示した。
〔WAF による脆弱性対策〕
Y 脆弱性への対応指示に対して，β 製品本部の V チーム員からは，β 製品本部機器は，パッチの適用作業に 1 か月が必要なので，代替策を検討する必要があるとの報告を受けた。V チームでは，シグネチャによる b という手法で攻撃を検知できる Web アプリケーションファイアウォール（WAF）が代替策になるかどうか，セキュリティベンダの G 氏に相談することにした。
G 氏によれば，WAF による対応は，サーバへのパッチ適用に比べて，⑤対策を実施するまでの期間が短いといわれており，Y 脆弱性への対応も既に可能になっているとのことであった。そこで，Q 主任は，WAF の導入について，導入形態が異なる表 1 のような 2 案を作成した。
表 1 WAF の導入案
β 製品本部の Y 脆弱性がある公開 Web サーバには，新製品の発表時などに，購入希望者からのアクセスが通常時の 100 倍程度まで一時的に増大するものがあり，かつ，次の新製品発表が 3 週間後に予定されている。このため，Q 主任は，案 2 を選び，⑥クラウド型の WAF を 1 週間後に導入し，β 製品本部での Y 脆弱性に対する代替策とする案を P 部長に提案した。P 部長は，この提案を承認し，センタ部に作業を指示した。
〔Y 脆弱性への追加対応〕
WAF 導入後，β 製品本部でのサーバへのパッチ適用前のある日，Y 脆弱性について，社外から直接はアクセスできない機器も社外から攻撃を受ける可能性があるという追加情報（以下，Y 追加情報という）が公表された。A 社の情報システムの構成では，FW によって社外から社内 Web サーバへのアクセスを防いでいる。しかし，Y 追加情報によれば，図 8 に示すような，社外から社内 Web サーバに対する Y 脆弱性を悪用した攻撃が考えられるという。
図 8 社内 Web サーバに対する Y 脆弱性を悪用した攻撃
次の条件 1〜3 が全て成立すると，この攻撃は，成功する可能性がある。
条件 1 攻撃者が f を知ることができ，その情報を図 8 の(2)の攻撃コードに組み込むことができること
条件 2 社内 Web サーバにおいて，CGI を利用した Web アプリケーションプログラムが，bash を呼び出すこと
条件 3 図 8 の(4)の HTTP レスポンスにヘッダとして g が付加されていること
A 社内の Web ブラウザが攻撃者のサイトにアクセスしてしまうと，e を使った攻撃コードがダウンロードされ，実行される。攻撃コードが実行されたとしても，条件 3 が成立していない場合，現在 A 社で利用を許可している Web ブラウザでは，h ポリシによって，攻撃コードが社内 Web サーバからの HTTP レスポンスを読み取ることはできない。しかし，条件 3 が成立している場合，攻撃コードが社内 Web サーバからの HTTP レスポンスを読み取ることができ，その内容を攻撃者のサイトへ送信することで，社内 Web サーバに対する攻撃が成功する。
A 社では，社内 Web サーバは，クロスオリジンリクエストに対する図 8 中の(4)の HTTP レスポンスに，ヘッダとして g を付加していないことが調査の結果分かった。このため，Q 主任は，社内 Web サーバ上のデータが操作される可能性はあるものの，Web ブラウザ経由で情報が攻撃者のサイトに送信される可能性は低いと判断した。
Q 主任は，Y 追加情報による対策の変更は必要ないことを P 部長に報告した。P 部長は，念のため社外のセキュリティ専門業者の F 氏にレビューを依頼するよう Q 主任に指示した。
Q 主任から説明を受け，F 氏は，攻撃者が A 社のプロキシサーバを利用するために必要な情報を知ることができた場合には，図 8 中の(4)，(5)とは別の手法を用いることで，社内 Web サーバの情報が攻撃者のサイトに送信されるおそれがあると指摘した。そして，F 氏は，⑦どのような機能をもつ OS コマンドが社内 Web サーバで利用できる場合に，それが可能かを説明した。Q 主任は，直ちに対策する必要があると P 部長に報告した。P 部長は，対策を追加するとともに，Y 脆弱性への対応を振り返ると，脆弱性レベル高の脆弱性については，重要度レベル低の機器であっても，直ちに脆弱性対策を実施すべき場合があるとして，Q 主任に脆弱性対策基準の見直しを指示した。
本文中の下線③について，必要な条件を解答群の中から選び，記号で答えよ。 解答群 ア HTTP の通信が TLS で暗号化されていないこと イ HTTP の通信が TLS で暗号化されていること ウ Web サーバに Y 脆弱性がある bash が導入されていること エ Web ブラウザが Cookie を受け入れないように設定されていること オ Web ブラウザが Cookie を受け入れるように設定されていること
解答例
ウ
解説
本文の根拠
〔新たな脆弱性の公表と対応〕
Web サーバにおいても，③ある条件を満たす場合には，この Y 脆弱性を悪用される。
図7
(2) Web アプリ B が起動され，bash が呼び出される（Web サーバ（httpd）の中の処理）。
Y 脆弱性は bash の脆弱性なので，Web サーバで悪用されるには，そのサーバに Y 脆弱性のある bash が導入されていることが前提になる（図 7 では Web アプリ B の起動時に bash が呼び出される）。解答例は“ウ”である。
TLS で暗号化するかどうかは通信路の盗聴を防ぐかどうかの違いで，暗号化しても Web サーバ（httpd）は復号したリクエストをそのまま受け取るので，悪用の可否は変わらない（ア・イ）。Cookie を受け入れるかどうかは利用者の Web ブラウザの設定で，攻撃者が自分で送るリクエストには関係しない（エ・オ）。
図 7 では，Web サーバ（httpd）が Web アプリ B を起動し，Web アプリ B が bash を呼び出す。bash は Web アプリ B から起動された子のプロセスとして Web アプリ B と同じ権限で動き，Y 脆弱性によってその bash が実行する cat コマンドも同じ権限で動く。解答例は“ウ”（Web アプリ B の実行時の権限）である。
bash や cat コマンドのプログラムファイルの所有者（多くは管理者）の権限で動くわけではない（ア・イ）。Web ブラウザは攻撃者の手元で動くもので，サーバ上のコマンドの権限とは関係しない（エ）。本文の“cat コマンドの実行時の権限によっては”は，Web アプリ B が強い権限で動いていれば被害が広がるという意味で，Web アプリ B を必要最小限の権限で動かすことが被害を抑える対策になる。
ファイルの所有者と，プロセスが動く権限とを混同しないことが要点である。
設問2(3)解答欄1つ
本文中の a に入れる適切な字句を，10 字以内で答えよ。
〔a〕解答例
HTTPリクエスト
解説
本文の根拠
〔新たな脆弱性の公表と対応〕
典型的な Web サーバでは，Web サーバ（httpd）が a ヘッダの④フィールド値を環境変数として設定してから Web アプリ B を起動するので
〔新たな脆弱性の公表と対応〕
Y 脆弱性が存在する bash では，環境変数の値が“() {”という文字列で始まる場合，関数として解釈され，実行することができる。
CGI の仕様（RFC 3875）の 4.1.18 は，“HTTP_”で始まるメタ変数にはクライアントのリクエストヘッダフィールドから読んだ値が入ると定めている。ヘッダフィールド名は大文字にし，“-”を“_”に置き換え，“HTTP_”を前に付けて変数名にする。つまり Web サーバ（httpd）は，HTTP リクエストのヘッダの値を環境変数として Web アプリ B に渡す。解答例は“HTTPリクエスト”である。
ヘッダの値は攻撃者が自由に決められるので，値を“() {”で始めれば，Y 脆弱性のある bash は環境変数を引き継ぐときにその後ろのコマンドを実行してしまう。ここが Web サーバで Y 脆弱性が遠隔から悪用できる理由である。
攻撃者が A 社のプロキシサーバを利用するために必要な情報を知ることができた場合には，図 8 中の(4)，(5)とは別の手法を用いることで，社内 Web サーバの情報が攻撃者のサイトに送信されるおそれがあると指摘した。
〔A社の情報システムの構成〕
社内サーバセグメントと各 PC セグメント上の機器からは，プロキシサーバを経由したインターネット上の Web サイトへのアクセスが許可されており
〔A社の情報システムの構成〕
社内サーバセグメントと各 PC セグメント上の機器からのプロキシサーバを経由しないインターネットへのアクセスは，FW によって禁止されている。
Y 脆弱性を使えば，図 8 の(3)のリクエストで社内 Web サーバに任意のコマンドを実行させられる。応答をブラウザ経由で持ち出す(4)(5)は同一生成元ポリシで防がれても，社内 Web サーバ自身に攻撃者のサイトへ情報を送らせれば持ち出せる。社内サーバセグメントからは，プロキシサーバを経由すればインターネットの Web サイトにアクセスできる（経由しないアクセスは FW が禁止）。攻撃者がプロキシサーバの情報を知っていれば，プロキシサーバを通じて攻撃者のサイトへ通信する OS コマンドを実行させればよい。解答例は“プロキシサーバを通じて攻撃者のサイトと通信する機能”である。
この攻撃では社内 Web サーバが社外へ通信する主体になるので，ブラウザの同一生成元ポリシは関係しない。Q 主任が“直ちに対策する必要がある”と報告を改めたのはこのためである。
V チームが機器ごとにリスクを評価し，その結果，j というリスク又は k というリスクが高いと判断された場合は，リスクレベル 3 とする。
〔新たな脆弱性の公表と対応〕
Y 脆弱性が悪用されると公開 Web サーバが改ざんされるおそれもあり
〔Y脆弱性への追加対応〕
社内 Web サーバの情報が攻撃者のサイトに送信されるおそれがあると指摘した。
評価が要るのは重要度レベル中の機器で，二つの種類がある。社外からアクセスできないが重要情報を扱う機器（社内 Web サーバなど）では，Y 追加情報の攻撃のように情報を社外に持ち出されること，つまり重要情報が漏えいするリスクを見る。重要情報を扱わないが社外からアクセスできる機器（重要度レベル低の公開 Web サーバなど）では，社外から侵入され，改ざんなどの被害を受けるリスクを見る。解答例は j が“重要情報が漏えいする”，k が“社外から侵入される”（順不同）である。
Y 脆弱性の対応で Q 主任が重要度レベル低の公開 Web サーバにも直ちに対策を求めたのは後者，F 氏が社内 Web サーバの情報の送信を指摘したのは前者に当たる。
![要求者 A と検証者 B の間のメッセージ交換の図。要求者 A 側：[事前準備] 1. 要求者 A の鍵（Kp，Ks）及び［ f ］を用意する。2. エンティティ認証の開始を要求する（A から B へ）。検証者 B 側：3. Rb を求める。Rb = rand()。4. Rb を送信する（B から A へ）。要求者 A 側：5. Ra と X を求める。Ra = rand()，X = sign(［ g ］, ［ h ］)。6. ［ f ］，Ra，X を送信する（A から B へ）。検証者 B 側：7. 次の関数が“True”を返すことを確認する。verify(［ i ］, ［ j ］, Ra||Rb||Sn)。凡例：Kp：要求者 A の公開鍵である。Ks：要求者 A の秘密鍵である。rand()：擬似乱数生成関数。ランダムな値を生成して返す。sign(x, y)：ディジタル署名生成関数。秘密鍵 x と署名対象データ y を受け取り，署名値を返す。verify(s, t, u)：ディジタル署名検証関数。公開鍵 s，署名値 t 及び署名対象データ u を受け取り，t が u に対する正しい署名値であれば“True”，それ以外の場合は“False”を返す。Sn：検証者 B の名称。公知の情報である。||：この記号の左右のデータを連結することを示す。注記 公開鍵証明書の正当性の確認についての記述は省略している。](/data/figures/2016h28a-sc-pm2/q1-f2.png)
