M 社は，従業員数 200 名の小売業である。コーポレートサイトである Web サイト A（URL は，https://site-a.m-sha.co.jp/）と，自社の特定のブランドを取り扱う EC サイト（以下，ブランドサイトという）を複数運営している。現在運営しているブランドサイトは，Web サイト B から Web サイト F の五つである。Web サイトの開発や運用は自社の開発部で行っている。
Web サイト A は，ブランドサイト全体のポータルサイトでもあり，各ブランドのキャンペーン情報などを掲載している。会員専用の機能は有していない。
Web サイト B（URL は，https://site-b.m-sha.co.jp/）は，ブランド B の商品を扱う EC サイトで，会員数は 10 万名である。Web サイト B では，Cookie を利用したセッション管理を行っている。
会員情報は，各ブランドサイトで個別に管理している。
〔各ブランドサイトから Web サイト A への情報連携〕
今回，各ブランドサイトの売上数を基にした，ブランド別の売れ筋商品情報を，Web サイト A 上で表示するとともに，希望があれば，各ブランドサイトの会員に電子メールでも定期的に配信することにし，そのために売れ筋商品情報及び会員情報を取得する機能（以下，情報連携機能という）を実装することにした。具体的な機能は次のとおりである。
機能 1 Web サイト A が各ブランドサイトの売れ筋商品情報を取得する。
機能 2 希望する会員に電子メールを配信するために，Web サイト A は，当該会員の会員情報を取得する。なお，配信の申込みは，Web サイト A 上で行う。
情報連携機能の実装は，開発部の C さんが中心になって進めることになった。まず初めに Web サイト B から Web サイト A への情報連携を行うために，次の二つの Web API を Web サイト B に実装することにした。
Web サイト B の売れ筋商品情報を取得可能とするための Web API（以下，API-X という）
Web サイト B の会員情報を取得可能とするための Web API（以下，API-Y という）
なお，Web API で受け渡されるデータは，JSON（JavaScript Object Notation）形式にする。C さんは，API-Y からブランドサイトの会員情報を取得する際，配信を希望する会員の同意を得たいと考えた。そこで，会員情報の取得には，会員の Web ブラウザを経由して行う方式を採用することにした。
Web サイト B から Web サイト A への情報連携機能を図1に示す。
図1 Web サイト B から Web サイト A への情報連携機能
〔情報連携機能の実装についての検討〕
スクリプト Z は，a ポリシによって，b，c，d のいずれかが異なるリソースへのアクセスが制限される。そこで，C さんは，この制限をう回するために JSONP（JavaScript Object Notation with Padding）を用いることを開発部の D 課長に提案した。次は，その時の会話である。
C さん：API-Y からの会員情報の取得に JSONP を用いるつもりです。
D 課長：JSONP は，アクセス先を制限する機能をもたないので，その実装では問題がある。例えば，まず，会員情報を窃取するように攻撃者がスクリプト Z を変更して，攻撃者の Web サイトのページに置く。次に，被害者に①特定の操作をさせた上で，そのページにアクセスさせると，攻撃者が被害者の会員情報を窃取できてしまう。
C さん：JSONP の代わりに何の技術を用いればよいでしょうか。
D 課長：CORS（Cross-Origin Resource Sharing）を用いるのがよいだろう。
〔CORS の概要〕
CORS とは，ある Web サイトから他の Web サイトへのアクセスを制御することができる仕組みである。XMLHttpRequest を使って“https://test2.example.com/test”にリクエストを送るスクリプトの例を図2に示す。
図2 XMLHttpRequest を使ったスクリプトの例
Web ブラウザが“https://test1.example.com/”にアクセスし，図2のスクリプトを含むページを読み込んだとする。図2のスクリプトが実行されると，最初に Web ブラウザは“https://test2.example.com/test”にプリフライトリクエストと呼ばれるリクエストを送る。そうすると，実際のリクエスト（以下，メインリクエストという）で許可されるメソッド名やヘッダフィールド名などがレスポンスとして返る。その後，メインリクエストを送り，レスポンスが返る。この一連の動作を図3に，また，図3中の（ⅲ）～（ⅵ）のリクエストとレスポンスの先頭部分の例を図4～図7に示す。
D 課長：今後，他のシステムでも CORS を利用することが考えられるので，コーディング規約も併せてまとめておきたい。Access-Control-Allow-Origin ヘッダフィールドに指定できるオリジンは一つだけなので，複数のオリジンからのアクセスを許可するような仕様であった場合に，No. 4 の内容では不十分である。Web API のプログラム内に，許可するオリジンのリストを用意しておく必要がある。プリフライトリクエスト又はメインリクエストが Web API に送られてきたときに，そのリクエスト中の h を，i と突合し，j した値があればその値を Access-Control-Allow-Origin ヘッダフィールドに設定するという内容もコーディング規約に含めればよいだろう。
C さん：分かりました。
C さんは，CORS の利用に関するコーディング規約をまとめ，表1をこれに合うように修正し，D 課長に再度確認した。修正後の内容で問題ないということだったので，C さんは実装を行った。
その後，セキュリティ専門業者に脆弱性診断を依頼し，脆弱性が検出されないことを確認した上で，情報連携機能をリリースした。その後，同様に残り四つのブランドサイトから Web サイト A への情報連携機能も実装した。
スクリプト Z は，a ポリシによって，b，c，d のいずれかが異なるリソースへのアクセスが制限される。
〔情報連携機能の実装についての検討〕
この制限をう回するために JSONP（JavaScript Object Notation with Padding）を用いることを開発部の D 課長に提案した。
スクリプトを読み込んだページとは異なるオリジンのリソースへのアクセスを，Web ブラウザが制限する仕組みは，Same-Origin ポリシである。本文は，スクリプト Z が Web サイト A のページ上で動き，Web サイト B の API-Y にアクセスする場面なので，このポリシによる制限を受ける。JSONP や CORS は，この制限をう回する，又は緩和する側の技術である。
本文の例では，Web サイト A のオリジン“https://site-a.m-sha.co.jp”と，Web サイト B のオリジン“https://site-b.m-sha.co.jp”とでスキーム（https）とポート番号（https の既定の 443）は同じで，FQDN だけが違う。このように三つのうち一つでも違えば，異なるオリジンとして制限される。
まず，会員情報を窃取するように攻撃者がスクリプト Z を変更して，攻撃者の Web サイトのページに置く。次に，被害者に①特定の操作をさせた上で，そのページにアクセスさせると，攻撃者が被害者の会員情報を窃取できてしまう。
図1 注2)
会員が Web サイト B にログインした状態のときにアクセスする。
図1 注3)
会員情報が得られない場合，エラーを返す。
API-Y は，会員がログインした状態のときにだけ会員情報を返し，ログインしていなければエラーを返す仕様である（図1 の注2，注3）。ログイン状態は Web サイト B の Cookie によるセッション管理で保たれている。JSONP では，攻撃者のページに置いたスクリプトを被害者のブラウザが実行して API-Y を呼び出すと，被害者の Web ブラウザは Web サイト B の Cookie を付けて API-Y にアクセスし，会員情報が返ってしまう。ただし，それは被害者が Web サイト B にログイン済みのときに限られる。したがって，被害者にさせる“特定の操作”は，Web サイト B へのログインである。
攻撃者の側から見ると，被害者を攻撃者のページに誘導するだけでは足りず，その前に被害者が Web サイト B にログインしている必要がある，というのが D 課長の説明の前提である。本文は“被害者に特定の操作をさせた上で，そのページにアクセスさせる”と順序を示している。
Web ブラウザは，g と Access-Control-Allow-Origin ヘッダフィールドの値を照合し，アクセスが許可されていることを確認する。
CORS では，Web ブラウザが，API-Y から返された Access-Control-Allow-Origin ヘッダフィールドの値と，スクリプトを含むページのオリジンを照合する。一致すれば次の処理（メインリクエスト）に進み，確認できなければ送らずに終了する。スクリプト Z を含むページは Web サイト A の売れ筋商品情報配信の申込ページ（No.1・2）なので，g は“売れ筋商品情報配信の申込ページのオリジン”である。
Origin ヘッダフィールドは Web ブラウザが付与するので（図4 注3），スクリプトの作者が書き換えることはできない。照合の相手は，スクリプトを含むページのオリジンである。
U 社は，東京に本社をもつ従業員数 1,000 名の商社である。複数の海外拠点を設置し，海外向けに営業展開している。海外拠点の従業員数は 1 拠点当たり十数名ほどである。
本社の情報システムは，本社の情報システム部が管理しており，各海外拠点の情報システムは，現地の情報システム担当者が管理している。電子メール（以下，メールという）の送受信には，本社ではオンプレミス環境を導入しているが，海外拠点では，P 社が提供するクラウドサービス型 Web メールサービス（以下，メールサービス P という）を利用している。海外拠点では，全ての従業員にスマートフォンとノート PC を貸与している。
〔セキュリティインシデント発生〕
1月10日，送信者が海外拠点 Q の従業員 S さんのメールアドレスである不審なメールを受け取ったという連絡が，S さんとやり取りのあった本社の従業員から情報システム部にあった。情報システム部では，情報処理安全確保支援士（登録セキスペ）である T さんが，調査を担当することになった。T さんが当該メールのヘッダ情報を確認したところ，メールサービス P から送信されたものであった。
海外拠点 Q の情報システム担当者である Y さんによれば，1月10日に S さんのアカウントからの不審なメール送信と考えられる履歴が複数残っているとのことであった。そこで，T さんは，Y さんにメールサービス P の S さんのアカウントを一時的に無効化するよう依頼した。また，会社から貸与された S さんのスマートフォン及びノート PC 並びに S さんのメールボックスには重要情報がなかったことを確認した。T さんが，海外拠点 Q の全従業員のアカウントについて，メールサービス P に残っていた全てのメール送信履歴を Y さんに確認してもらったところ，S さんのアカウント以外に不審なメールの送信履歴はないとのことであった。
〔経緯の調査〕
T さんは，メールサービス P に残っていた海外拠点 Q の全従業員のアカウントのメール送信履歴及び監査ログ，並びに S さんへのヒアリングの結果を Y さんから送付してもらい，調査した。調査結果を図1に示す。
図1 調査結果（抜粋）
T さんが調べたところ，メールサービス P は HTTP over TLS でサービスが提供されている。HTTP でアクセスした場合は HTTP over TLS の URL にリダイレクトされる仕様になっており，HSTS（HTTP Strict Transport Security）は実装されていない。
こうしたことから，T さんは S さんが不正アクセスを受けたと確信し，図2に示す手口（以下，手口 G という）を使って，攻撃者がメールサービス P の S さんの利用者 ID で不正アクセスしたと推測した。
図2 手口 G
T さんは，今回のセキュリティインシデントの調査結果を情報システム部長に報告した。情報システム部長は，会社から貸与されたノート PC を U 社以外の無線 LAN に接続してはならないというルールの全社への周知及びメールサービス P の認証方式の強化を T さんに指示した。
〔認証方式の強化〕
情報システム部長からメールサービス P の認証方式の強化について，次の2点が要求された。
要求 1 U 社以外の無線 LAN に接続したとしても手口 G を防ぐこと
要求 2 手口 G に限らず，偽サイトにアクセスしてしまったときにフィッシングの手口によるメールサービス P への不正アクセスを防ぐこと
T さんが調査したところ，メールサービス P は，単体ではパスワード認証にしか対応していないが，認証連携の機能があることが分かった。認証連携機能を使えば，メールサービス P にアクセスしようとしたときに，他の ID 管理サービスにリダイレクトされ，そこで認証が行われ，認証に成功すると，メールサービス P にアクセスできるようになる。そこで，X 社が提供するクラウドサービス型 ID 管理サービス（以下，IDaaS-X という）が対応している，より強力な認証方式を利用することにした。IDaaS-X では，認証サーバ X を使って利用者を認証する。
攻撃者は，①無線 LAN アクセスポイント，DNS サーバ及び Web サーバを用意した。その DNS サーバには a の FQDN と b の IP アドレスとを関連付ける A レコードが設定されていた。
図2
S さんは，Web ブラウザからメールサービス P にアクセスしたつもりだったが，実際には Web ブラウザは②攻撃者が用意した Web サーバに接続していた。
A レコードは，FQDN と IP アドレスを関連付ける DNS のレコードである。S さんは Web ブラウザにメールサービス P の FQDN を手入力してアクセスしたが，実際には攻撃者が用意した Web サーバに接続している。したがって，攻撃者の DNS サーバには，“メールサービス P の FQDN”と，“攻撃者が用意した Web サーバの IP アドレス”を関連付ける A レコードが設定されていたことになる。a はメールサービス P，b は攻撃者が用意した Web サーバである。
PC-S は DHCP で DNS サーバの情報を自動取得する設定だった（図1）ので，攻撃者のアクセスポイントに接続した結果，攻撃者の DNS サーバが設定された（図2）。この DNS サーバが，メールサービス P の名前を攻撃者の Web サーバに解決する。
図5及び図6中の c ～ f に入れる適切な字句を，解答群の中から選び，記号で答えよ。解答群 ア 公開鍵 A イ 公開鍵 K ウ 秘密鍵 A エ 秘密鍵 K
〔c〕解答例
ウ
〔d〕解答例
ア
〔e〕解答例
エ
〔f〕解答例
イ
解説
本文の根拠
図5 注1)
オーセンティケータには，搭載されたデバイスごとにユニークな公開鍵 A，秘密鍵 A，及び証明書 A が組み込まれている。
図5
c を用いて署名 L を生成
図5
d を用いて署名 L を検証
図6
IDc 及び e を取得
図6
IDc に対する f を選択
ディジタル署名は，秘密鍵で署名し，対応する公開鍵で検証する。図5（登録）の署名 L は，IDc，H（ドメイン），公開鍵 K などに対する署名で，オーセンティケータに組み込まれた秘密鍵 A で生成する（c＝ウ）。認証サーバ X は，直前に検証した証明書 A に含まれる公開鍵 A で署名 L を検証する（d＝ア）。これで，登録しようとする公開鍵 K が，正規のオーセンティケータで生成されたものだと確認できる。
図6（認証）の署名 M は，登録時に生成した IDc ごとの鍵ペアのうち，オーセンティケータが保存している秘密鍵 K で生成し（e＝エ。“IDc 及び秘密鍵 K を取得”），認証サーバ X は，登録済みの IDc に対する公開鍵 K を選択して検証する（f＝イ）。図5 の“IDc，利用者 ID，ドメイン，公開鍵 K，秘密鍵 K の組合せを登録”と，認証サーバ側の“利用者 ID，IDc，公開鍵 K の組合せを登録”とが，この対応の根拠である。
間違えやすいのは公開鍵と秘密鍵の取り違えで，講評も，公開鍵と秘密鍵を取り違えている解答が散見された，としている。署名する側が秘密鍵，検証する側が公開鍵，という原則に戻って考える。また，鍵 A（機器固有）と鍵 K（IDc ごと）を取り違えないよう，署名 L は鍵 A，署名 M は鍵 K と，どの署名にどの鍵ペアが対応するかを図で追う。
パスワードレス認証では，Web ブラウザが，実際にアクセスした Web サイトのオリジン b を認証要求に含めてオーセンティケータに渡し，署名 M は H（オリジン b || 乱数 c′）を対象に生成される。認証サーバ X は，受け取ったオリジン b と自身の Web サイトのオリジン s の一致を確認する。偽サイトにアクセスしている場合，オリジン b は偽サイトのオリジンであり，オリジン s と一致しないので，認証は失敗する。フィッシング（中間者）では，ブラウザが付けるオリジンを偽サイトが本物のものに偽装できないので，認証を中継しても成立しない。
OTP 認証方式（設問2(1)）は，ユーザが入力した OTP を中継されると防げなかったが，パスワードレス認証方式は，署名に“アクセスした Web サイトのオリジン”が含まれ，しかも認証サーバ X がそれを確認する。これが要求 2 を満たせる理由である。
V 社は，IoT 機器を製造・販売している従業員数 3,000 名の会社である。家庭用ゲーム機（以下，ゲーム機 V という）の発売を予定しており，設計を開発部が担当している。設計リーダは，開発部の H さんである。利用者はゲーム機 V とゲームプログラムの利用権を購入し，ゲーム機 V からゲームサーバ上のゲームプログラムを利用する。複数のゲームプログラム開発会社が，それぞれ複数のゲームプログラムを開発し，販売する予定である。開発部が設計したゲーム機 V，認証サーバ及びゲームサーバ（以下，三つを併せてゲームシステム V という）の構成を図1に，構成要素とその概要を表1に示す。
図1 ゲームシステム V の構成（概要）表1 ゲームシステム V の構成要素とその概要
ゲームを行う際は図2の認証フローで利用者の認証が行われる。
図2 利用者がゲームを行う際の認証フロー
認証トークンには，認証サーバの FQDN，利用者 ID 及び MAC（Message Authentication Code）が格納される。①MAC は，認証サーバの FQDN と利用者 ID に対して，ハッシュ関数を共通鍵と組み合わせて使用し，生成する。共通鍵は，ゲームシステム V 全体で一つの鍵が使用され，ゲームサーバ管理者がゲームプログラムに設定する。図2の 5. では，ゲームプログラムによる認証トークンの MAC の検証が成功し，かつ，FQDN が確かに認証サーバのものであることが確認された場合だけ，認証が成功し，図2の 6. でゲームプログラムからゲーム画面が送信される。
〔セキュリティレビューの実施〕
認証トークンが認証サーバ以外で不正に生成されると，購入していないゲームプログラムを利用されたり，クラウド V 上のリソースを不正に利用されたりするおそれがある。そこで仮に認証サーバ以外で認証トークンを生成されたとしてもゲームプログラムでは検証に失敗することが求められる。また，利用者がコントローラの不正な操作情報をゲーム機 V から送信することによって，ゲームを有利に進めるといったことも防ぐ必要がある。
V 社では，システム設計にセキュリティ上の問題がないか，製品の設計工程でセキュリティレビュー（以下，レビューという）を実施することになっており，ゲームシステム V はセキュリティ部の N さんがレビューを担当することになった。次は，N さんがゲームシステム V のレビューを行った時の，H さんとの会話である。
N さん：現状の認証トークンの設計には二つの問題があります。一つ目の問題は，現在の設計では認証トークンに格納される情報が不足しているということです。情報が不足していることによって，ゲームプログラム A 用の認証トークンがゲームプログラム B においても認証に成功してしまうので，攻撃者がゲームプログラムの URL を知ることができれば，購入していないゲームプログラムも利用できてしまいます。②この問題への対策を検討してください。
H さん：分かりました。
N さん：二つ目の問題は，③認証トークンをゲームサーバ管理者が不正に生成できてしまうことです。
H さん：その問題への対策としては，ゲームプログラムごとに別の共通鍵を利用するという設計はどうでしょうか。
N さん：それでは対策として不十分です。④その設計にしたとしても，不正にゲームプログラムが利用できる認証トークンをゲームサーバ管理者が生成できてしまいます。
H さん：MAC ではなく，ディジタル署名を利用すれば対策になりますか。
N さん：はい。そうすればゲームサーバ管理者が認証トークンを不正に生成したとしても，ゲームプログラムで検証が失敗します。
H さん：では，a で公開鍵と秘密鍵の鍵ペアを生成し，b をゲームサーバに配布しておきます。a が c を使って認証トークンに署名を付加し，ゲームプログラムでは b を使って署名の検証を行います。
N さん：それで問題ありません。次に，不正な機器から認証サーバとゲームサーバへのアクセスをどのようにして防ぐのか教えてください。
H さん：クライアント認証を使います。
N さん：ゲーム機 V 内のクライアント証明書とそれに対応する秘密鍵（以下，鍵 C という）が攻撃者の PC から不正に使用できると，その PC から各サーバに接続されてしまいます。さらに，コントローラの操作情報を改ざんして送信することによって，ゲームを有利に進めることも考えられます。クライアント証明書と鍵 C はゲーム機 V のどこに格納しますか。
H さん：鍵 C を含めた全てのデータは，搭載する SSD（Solid State Drive）に格納します。搭載する SSD は，広く流通しているものです。
N さん：それでは問題がありますね。現状の設計では，専用 OS に脆弱性が存在しなかったとしても，⑤攻撃者がゲーム機 V を購入すれば，専用 OS を改ざんせずに，ゲーム機 V 内のクライアント証明書と鍵 C を PC などから不正に使用できます。
H さん：どのように対策したらいいでしょうか。
N さん：TPM（Trusted Platform Module）をゲーム機 V に搭載し，TPM 内に鍵 C を保存するという方法があります。TPM は，⑥内部構造や内部データを解析されにくい性質を備えているので，TPM 内に鍵 C を保存すれば不正に読み取ることは困難になります。
また，ブートローダ又は専用 OS の改ざんはゲーム機 V の不正利用につながります。例えば，コントローラの不正な操作情報を送信されるおそれがあります。そのため，ブートローダ及び専用 OS の改ざん対策についても検討してください。
H さん：分かりました。設計を見直します。
〔ブートローダ及び専用 OS の改ざん対策〕
2回目のレビューでは，ブートローダ及び専用 OS の改ざん対策について確認した。次は，その時の H さんと N さんの会話である。
H さん：ブートローダ及び専用 OS の改ざんに備えた対策として，ブートローダ又は専用 OS が改ざんされていると判定されたときは，ゲーム機 V の起動処理を中止するようにしました。ブートローダ及び専用 OS の改ざん対策の処理の流れを図3に示します。
図3 ブートローダ及び専用 OS の改ざん対策の処理の流れ
N さん：処理の流れは分かりました。ハッシュ値リストが保護されていないと，改ざんされたファイルが実行されるおそれがありますが，どのように対策していますか。
解答群が MAC の方式の名前に偏っているので，“ハッシュ関数を使う”ことと“MAC である”ことの両方を満たす選択肢を選ぶ。MD5 はハッシュ関数だが，鍵を使わないので MAC ではない。
設問2(1)15字以内
本文中の下線②について，対策として認証トークンに追加する必要がある情報を，15 字以内で答えよ。
解答例
ゲームプログラムID
解説
本文の根拠
〔セキュリティレビューの実施〕
情報が不足していることによって，ゲームプログラム A 用の認証トークンがゲームプログラム B においても認証に成功してしまうので，攻撃者がゲームプログラムの URL を知ることができれば，購入していないゲームプログラムも利用できてしまいます。
認証トークンの説明
認証トークンには，認証サーバの FQDN，利用者 ID 及び MAC（Message Authentication Code）が格納される。
認証トークンは，認証サーバの FQDN，利用者 ID，MAC だけで作られており，どのゲームプログラムのためのトークンかを表す情報が入っていない。そのため，ゲームプログラム A 用のトークンが，共通鍵が同じ別のゲームプログラム B でも MAC の検証に通ってしまう。対策は，認証トークンにゲームプログラム ID を追加し，その ID も MAC の計算対象に含め，ゲームプログラム側で自分の ID と一致することを確認することである。
図2 の 3. で利用者が“アクセスするゲームプログラム ID”を認証サーバに伝え，4. で認証サーバがその ID に対応するゲームプログラムの URL と認証トークンを返す。認証サーバは購入情報を基に，アクセス可能なゲームプログラム ID の一覧を返しているので（2.），どのゲームプログラムの利用を許可したかを知っている。それをトークンに入れれば，ゲームプログラム側で検証できる。講評は，本問のような認証連携方式では，利用を許可するリソースの範囲をトークンに含める必要があることがよく理解されていた，としている。
共通鍵は，ゲームシステム V 全体で一つの鍵が使用され，ゲームサーバ管理者がゲームプログラムに設定する。
〔セキュリティレビューの実施〕
二つ目の問題は，③認証トークンをゲームサーバ管理者が不正に生成できてしまうことです。
MAC は，生成する側と検証する側が同じ共通鍵をもつ方式である。本システムでは，認証サーバが MAC を生成し，ゲームプログラムが同じ共通鍵で検証するので，ゲームプログラムを動かしているゲームサーバにも，認証サーバと同じ共通鍵が保存されている。共通鍵を知るゲームサーバ管理者は，自分で認証トークンの MAC を計算でき，認証サーバ以外が，正しい MAC の付いた認証トークンを不正に生成できてしまう。
設問2(2)・(3) で問題になっていたのは，生成と検証に同じ共通鍵を使うことだった。署名なら，生成に必要な秘密鍵は認証サーバだけが保持し，ゲームサーバには検証用の公開鍵だけを置けばよい。これが“そうすればゲームサーバ管理者が認証トークンを不正に生成したとしても，ゲームプログラムで検証が失敗します”という N さんの発言の根拠である。
本文中の下線⑤について，どのようにするとクライアント証明書と鍵 C を PC などから使用可能にしてしまうことができるか。攻撃者が使用前に行う必要があることを，25 字以内で具体的に述べよ。
解答例
SSDを取り出し，PCなどにつなげる。
解説
本文の根拠
表1 ゲーム機 V
PC に接続しても外部ストレージとして認識されず，内部のデータを直接読み出すことはできない。
〔セキュリティレビューの実施〕
鍵 C を含めた全てのデータは，搭載する SSD（Solid State Drive）に格納します。搭載する SSD は，広く流通しているものです。
〔セキュリティレビューの実施〕
攻撃者がゲーム機 V を購入すれば，専用 OS を改ざんせずに，ゲーム機 V 内のクライアント証明書と鍵 C を PC などから不正に使用できます。
ゲーム機 V は PC に接続しても外部ストレージとして認識されないので，ゲーム機 V の専用 OS を経由した読み出しはできない。しかし，鍵 C を含む全てのデータは，広く流通している SSD に格納されている。そこで，攻撃者は，購入したゲーム機 V から SSD を取り出し，PC などに直接つなげば，専用 OS を改ざんせずにクライアント証明書と鍵 C を読み出して，PC から各サーバに接続できる。使用前に行うことは，SSD を取り出し，PC などにつなげることである。
本文は，“専用 OS に脆弱性が存在しなかったとしても”，“専用 OS を改ざんせずに”と述べている。つまり OS 側を攻めるのではなく，ゲーム機の筐体から記憶装置を物理的に取り出す攻撃である。対策として TPM に鍵 C を保存する案が続く。
