DARK MATTER

CDI Engineer's Technical Blog

IoTセキュリティでこれだけは押さえておきたい三つのリスク ~ 不都合な真実

はじめに

こんにちは石垣です。

社会的に大きな影響を及しているCOVID-19によって、「ニューノーマル」と呼ばれる、新しい常識や常態への順応・適応が否が応でも求められるようになりました。

社会の仕組みが「ニューノーマル」仕様となるべくIoTが生活に組み込まれて身近になると同時に、IoTのセキュリティ対策はどうなっているのだろうかと思われた方はいるのではないでしょうか?

今回はIoTにおけるセキュリティについて理解するべき三つの基本リスクと対策について理解いただく事を目的として本記事を執筆しました。

本記事の対象者と得られる知見としては

  • IoTサービス/デバイスの利用者であれば、利用しようとしている/利用しているIoTのセキュリティ対策について評価
  • IoTデバイス/サービスに関係する企画者/エンジニア/保守・運用者は現状/今後のセキュリティ対策の妥当性判定や対策方法の原理

となります。

IoTの定義には揺らぎがありますので本記事では「物理的な目的で利用されるセンサー/アクチュエータを備え、ネットワークにつながるデバイス・サービス」とします。

IoT特有のセキュリティリスクとは?

IoTが活用される場所の一例

f:id:tatac1:20200720165423j:plain

  • トンネル/橋
  • 車両
  • 病院
  • etc...

身近なIoT活用の例としてお住まいの自宅に設置されたスマートメータなどはわかりやすい事例と思います。

またバイタルデータ等を取得するものから、薬液注入ポンプなど医療機器がIoTとして活用されている事例があります。

まずはじめにIoTとネットワークサービス(ウェブサービス等)で根本的に異なるのは、IoTデバイスが管理者/製造者の手元から物理的に離れます。結果、物理的に分散するということは、その分物理制約上、セキュリティ対策が分散することとなります。

攻撃者視点で考えると、クラウドサービスをホスティングするサーバへ物理的にアクセスする事はデータセンターへの侵入等乗り越えるハードルが高いですが、上記に列挙した場所に設置されたIoTデバイスであれば鹵獲や物理的ないたずらは難しくないことが想像いただけるかとおもいます。

したがってIoTのセキュリティリスクは「物理的に離れた」ことによってクラウドサービスには存在しない新たなセキュリティリスク(特有のセキュリティリスク)が生まれます。

セキュリティ対策ガイドラインや記事

既に様々なIoTのセキュリティに関するガイドライン/記事等が公開されております。

www.ipa.go.jp

www.iotac.jp

monoist.atmarkit.co.jp

www.intellilink.co.jp

コンプライアンスの観点は上記のガイドラインにお任せし、本記事では上記ガイドラインでは触れられない視点(攻撃者の視点から)からIoT全般に見られるセキュリティリスクについて説明を行いたいと思います。

セキュリティリスク - 範囲外について

製造の過程(いわゆるサプライチェーン)によるチップ、基板等に加えられた攻撃は本記事ではスコープ外としてセキュリティリスクの説明を行います。

一例として

io.cyberdefense.jp

ほかにもサイドチャネル攻撃等様々な攻撃手法が有ります。

なおHardware Trojanは論文、書籍等様々資料が公開されていますので、興味がある方は関連キーワードで調べてみてください。

IoT特有のセキュリティリスク

攻撃者は鹵獲すると物理デバイスに好きなようにアクセスできますので何でもありです。例えば

  • ディスク/メディアを解析
  • ディスク内のソフトウェア改造
  • 通信のタッピング

が可能となります。

弊社社員が執筆した記事が参考となるかとおもいますのでご紹介します。

io.cyberdefense.jp

io.cyberdefense.jp

io.cyberdefense.jp

io.cyberdefense.jp

io.cyberdefense.jp

以降にIoT全般で共通する具体的なセキュリティリスクをご紹介します。

デバイスのユニーク性および真正性に関するリスク

ネットワークを経由で認証を行う場合、認証する側から見ると(データ収集側)誰が接続し認証してきたかを確認することが重要となります。

人間がIDとパスワードを入力する場合とは異なり、IoTの場合自動で認証を行う方式になると考えられますので、この自動認証の仕組みをどのようにするかは悩まれた方も多いかと思います。

攻撃者はなりすましを行う事ために、まず物理デバイスのディスク/メディアを解析し、ハードコーディング、難読化データから認証情報の窃取を試みます。

攻撃者のモチベーションはターゲットのアカウント権限であり、なりすますとその権限であらゆる事が可能となるからです。

コードに隠蔽しても動的解析を行う等で変数やレジスタの値を見てしまえばいくらでも解析は可能です。

またディスクが暗号化されていなければカジュアルにデータを解析が出来たりします。

脅威の例としては、自宅にあるスマートメーター固有番号が他のメータになりすまされると請求を行う際に大変困ることが想像できるかとおもいます。

医療機器であれば、A患者に利用されているものが、実はB患者のものになりすまされると事故につながるかと考えられます。

実行ソフトウェア/生成データの完全性に関するリスク

IoTデバイスが想定したとおりのソフトウェアが実行されていることをデータ収集側としては期待します。すなわち改ざんされた状態ではない事をデータ収集側は把握する必要があります。またIoTデバイス生成データが改ざんされていないことをデータ収集側としては期待します。

攻撃者は改ざんを行う事ために、まず物理デバイスのディスク/メディアを解析し、ソフトウェア/生成データの改ざん、通信ケーブルのタッピング等を行い通信の改ざんを試みます。

攻撃者のモチベーションは望み通りの動作をIoTデバイスに行わせることです。

OSからは見つけることができないレイヤー(UEFI, firmware, bootloader等)にマルウェアを仕込まれると、OS側からは何もするすべがないです。

またディスクが暗号化されていなければカジュアルに解析/改造が行えたりもします。

脅威の例としては、自宅のスマートメーターが正しく計量している「ふり」や改ざんされた計量データを送信をされると大変困ることが想像できるかとおもいます。

医療機器であれば、A患者で計測されているバイタルデータが正しく計量している「ふり」や改ざんされた場合事故につながるかと考えられます。

データの機密性に関するリスク

IoTデバイスがデバイス内にデータを保存した場合や、データを送信した場合に機微な情報は暗号化されているべきだと利用者は期待するかもしれません。

通信内容から機微な情報が解析/窃取されたり、デバイスの破棄時にデータが第三者に解析/窃取されないように暗号化が必要となります。

攻撃者のモチベーションは、システム内部をつまびらかにして興味がありそうな情報を覗いてふむふむしたい、悪用できる情報の窃取をしたい、悪用の結果を確認するためにデータを覗くなどです。

攻撃者の用意した証明書を信用させるために、通信先の証明書のチェックで必要となる認証局のroot証明書を書き換えてしまえば、いくらでも暗号通信内容を覗くことが可能になります。

脅威の例としては、自宅のスマートメーターの計量データが平文で通信していると在宅の有無等の推測を容易となる、デバイス内に平文保存されていると在宅の傾向が判明するなどのプライバシーの侵害が行えるようになりえる等です。

医療機器であれば、A患者で計測されているバイタルデータ等が平文通信されている場合や、デバイス内に平文で保存されていると医療情報の漏洩事案に該当すると考えられます。

結論: IoT特有のセキュリティリスク対策

結論を拙速に書き下すと、IoT特有のセキュリティリスク対策は

  • 公開鍵基盤を利用した電子証明書の発行/更新/失効の仕組み
  • TPM/Trust Zone/Intel TXT等のハードウェアセキュリティ機能

を利用することが必要となります。

電子証明書は真正性、完全性、機密性を確保する技術として既にインターネットで広く利用されており説明は不要かとおもいます。

電子証明書の利用に加え、電子証明書で利用される公開鍵暗号方式において秘密鍵を窃取などから保護しつつデバイス上からのみセキュアに利用可能とするための対策として耐タンパー性、良質な乱数、暗号処理を備えたハードウェアセキュリティモジュールを利用することが必要となります。

ハードウェアセキュリティモジュールは、利用者は秘密鍵を知ることなく利用することだけが可能となる仕組みを提供し秘密鍵の生データには直接アクセスは出来ない回路となっています。例としては「IC付きクレジットカードを利用する際に暗証番号を入力」が皆さんになじみがある利用ケースです。

現在利用もしくは提供されているIoTにおいて「電子証明書」、「TPM/Trust Zone/Intel TXT等のハードウェアセキュリティ」のテクノロジー/技術がIoTデバイスで利用されていなければ、既に説明した三つの「デバイスのユニーク性および真正性に関するリスク」「実行ソフトウェア/生成データの完全性に関するリスク」「 データの機密性に関するリスク」いずれか、もしくはすべてが攻撃者からみると管理策の弱点=脆弱であると解釈されます。

本記事を読まれた方は既に感づかれているかもしれませんが、IoT特有のセキュリティ対策を行う事は実はとても大変です。

この三つのリスクに正しく対策・実装されたIoTデバイスは一部の製品1でしか筆者は見たことがなく、利用者はどういったテクノロジー/技術を利用してセキュリティ対策が行われているのか知る由もないので不都合な真実であると筆者は考えます。

一方攻撃者はデバイスが鹵獲できればカジュアルに物理攻撃からのサイバー攻撃が可能であり、防御側は分が悪く非常に悩ましい課題です。

もしガイドライン等でセキュリティモジュールを利用しなければいけないと定められた場合、セキュリティを理解でき正しく設計・実装が出来る開発者が限られてしまい、結果製品の選択が狭まる事が考えられます。法令・ガイドライン等は何処でバランスを取るべきか悩ましい選定/基準定義になると考えられます。

民生品の場合、以下リンクで紹介されているカルフォルニア州の「デバイスのデフォルトパスワードを禁ずる」法令で制限する等が現状のベター解決策であるかと筆者は考えます。

jp.techcrunch.com

以降、具体的な対策の一例をご紹介します。

具体的対策の一例

如何に攻撃者のコストを上げるかを考えた場合、前項で記載したセキュリティリスクの対策としてはワンチップ化、Intel TXT、TrustZone、TPM、セキュリティチップ等の利用が前提となります。

もちろんそれらのテクノロジーを利用したとしても完全無欠の対策とはなりませんが、対策のレベル感としてはNSA, DoD(国防省)等でも要件として記載されるものと考えていただくといいかと思います。

以下のNSAのサイトでは、納品にかかる基準概要が記載されています。

apps.nsa.gov

In 2007 the DoD Chief Information Officer issued a policy memorandum, which requires that "all new computer assets (e.g. server, desktop, laptop, and PDA) procured to support the DoD enterprise include a Trusted Platform Module (TPM) version 1.2 or higher where such technology is available."

なおTPM/TrustZone/Intel TXTを利用した場合でも完全ではなく過去に脆弱性が報告されております。

TrustZoneを利用したTEEの脆弱性 speakerdeck.com

TPMの脆弱性 tpm.fail

Intel TXTの脆弱性 www.intel.com

ワンチップ化の実装は対策案の中で特に難易度が高いため、三つのIoT特有のセキュリティリスク対策ではコモンクライテリアやFIPS140の認証が取得されており仕様が公開されているTPMチップ(ディスクリート)もしくはfTPMボード(ファームウェアベース)を利用する方法がまず最初に考えられると思われます。

弊社は、TPM仕様標準化などを行なっており実装事例も多数公開しているTrusted Computing Groupのメンバーであるため、TPMを利用した対策方法について紹介したいとおもいます。

TPM(Trusted Platform Module)について

ざっくり説明するとIC付きクレジットカードと同様の耐タンパー性、暗号/乱数生成機能を持ち、改ざん検証等の固有のユースケースにも対応可能なチップです。

はなしが若干それますが今年4月からIC機能が組み込まれたクレジットカードのみが利用可能と運用が変わりました。理由としては磁気スキミングの事故が後を絶たないためです。経緯等興味がある方はこちらの記事を参照ください

もとい、大抵のTPMチップはCommon Criteria EAL4, FIPS 140-2に対応しています。

Trusted Computing GroupでTPMの仕様が策定されています。

TPMの詳細にについて書籍が無料で公開されていますので、以下からダウンロード可能です。

link.springer.com

TPMを利用したデバイスのユニーク性担保

TPM製造元を信じることを前提として

TPMの内に封入されたEK鍵を利用し、AIK鍵を作ってユニーク性を担保します。

AIK鍵を使って、クライアント認証、署名、暗号化等を行います。

TPM内に秘密鍵を保存することで認証情報の保護を行います。

EK鍵 ~ TPMごとに一意な電子証明書鍵が製造者によって生成されており鍵の変更および削除は不可。

AIK鍵 ~ CSRをEK鍵で署名し、認証局でEKの署名検証後、認証局署名を行った電子証明書鍵、クライアント認証、署名、暗号化等で利用

IEEE. 802.1ARでDevIDとして規格が策定されており参考になるかと思います。

1.ieee802.org

TPMを利用した実行ソフトウェア/生成データの完全性担保

TPMのPCRを利用してブート状態を確認することが可能です。AIK鍵を利用しPCR値に署名を行い、認証側等で署名済みのPCRデータを検証することで、IoTデバイスの状態を検証可能です。

参考となるOpenSource Projectがあるので紹介します。

github.com

さらに生成した何らかのデータ(例:数量、読み取った商品コード、センサーの値、画像等)に署名を行って情報収集側に送信を行う事でデータの完全性担保が可能となります。

通信先の証明書の署名認証局はNVRAM(Non Volatile RAM)に書き込み、変更不可とすることでroot証明書の改ざん対策を行うことが可能となります。

TPMを利用したデータの機密性担保

Windowsではデータの暗号化をBitLockerで行っています。

詳しくは以下に記載があります

docs.microsoft.com

Macでは以下のペーパーが公開されています。

https://www.apple.com/ca/mac/docs/Apple_T2_Security_Chip_Overview.pdf

※両方secure bootに対応してます。

Linuxではどうなるかというと……と記事を書こうと思ったら産総研から以下の資料が公開(若干古いですが)されていたので参考になるかとおもいます。

https://trustedcomputinggroup.org/wp-content/uploads/JRF-WSDec2014_4.-AIST.pdf

  • 改ざん対応 = PCR機能/P27
  • 鍵の隠蔽 = TPM non-volatile storage/P28
  • ディスク暗号化 = 鍵の隠蔽の応用

Stackexchange にも参考となる投稿もあるので、ご紹介します。

security.stackexchange.com

続編: 不都合な真実の詳細と、IoT特有のセキュリティリスク対策やってみた。

不都合な真実をもう少し解説しつつ、実際にIoT特有のセキュリティリスク対策を行ったシステムを作ってみましたので次回ご紹介します。

[次回記事リンク貼り付け予定]

io.cyberdefense.jp

余談: Raspberry Piで対策ってどうすればいい?

評価検証フェーズでよく利用されるRaspberry Piですが、商用でそのままソフトウェアを利用したといったニーズがあるかとおもいますので過去に調べた結果をご紹介します。

結果: 現状としては、残念ながらRaspberry Piでは三つのセキュリティリスク対策をすべて行うことは不可能です。

認証情報秘匿やディスク暗号化だけは以下のデバイスを利用することで実現は可能です。

筆者も実際に購入し利用したことがある二つのデバイスを紹介します。

LetsTrust TPM for Raspberry Pibuyzero.de

www.zymbit.com

しかしながらRaspberry Piではroot of trust = シリコンレベルで真のsecure bootは行えません。

www.raspberrypi.org

blog.nviso.eu

上記のTPMやセキュリティモジュールを利用したデバイスが有ったとしても筆者が攻撃者の立場で考えると、SDカードを取り出しddダンプを行う、暗号化されていないbootプロセスの改ざんを行う、認証情報秘匿やディスク暗号化等に必要な情報を窃取するなど、あとは好きなようにTPM、Securityモジュールに保存されたデータを利用したり内部データを覗くなどを考えます。

その点BitlockerやFileVault2よく出来た仕組みです。

強いです。

LinuxはSecure boot+Full Disk Encryption等の対策を行っていないとsingle user modeでrootがとれます

具体的な方法としては以下が参考になると思います。

www.raspberrypi.org

IoTデバイス、サービスにRaspberry Piが使われてる場合は上記三つのセキュリティリスクをベースに利用ケースに応じた具体的な脅威の例が想像できるかとおもいます。

  • 本サイトに掲載されている商品またはサービスなどの名称は、各社の商標または登録商標です。
  • 本サイトはリスク把握・対策を目的としており、著作権侵害や不正アクセス行為等の教唆、幇助を目的としたものではありません。

  1. 弊社では業務で様々なデバイスを診断していますがNDAがあるため開示不可となっています。また筆者個人として利用する製品は購入し三つのリスク/観点で判断し利用の可否をしています。

光ファイバー盗聴・侵入を5秒でできるか実験してみました

f:id:yasuikj:20200525090330p:plain
光ファイバーの盗聴について考えたことはあるでしょうか?「光ファイバーって盗聴できるの?」「そんなの知ってるよ」など答えは様々かも知れません。ただ実際に試したことがある方は少ないのではないでしょうか?本稿では、光ファイバーの盗聴を実験した顛末を紹介します。実験は成功したのでしょうか?

本記事は、光ファイバー(光ケーブル)が盗聴されるリスクがある事を知っていただく事を目的としています。光ファイバーについて場合によっては必ずしも安全というわけではないことを知った上でセキュリティ対策を考えていただきたいと思います。
ご自身の環境以外では試さないようお願いします。

なぜ光ファイバーからの侵入?

技術部の安井です。長年制御システムを開発してきた経験から制御システムセキュリティ向上に取り組んでいます。以前LANケーブル(有線LAN)からの侵入・盗聴の実験を紹介したところ多くの方に参照いただけました。
io.cyberdefense.jp
LANケーブルの実験をして改めて光ファイバー(光ケーブル)はどうなの?という疑問が膨らみました。室内に敷設されているLANケーブルより、野外を這っている光ファイバーの方が危険ではないのか?という疑問です。LANケーブルの時は「ぐっとすプラグ」という道具を使うと切断から5秒で盗聴できましたが、光ファイバーだとどうなのでしょうか?

光ファイバーってセキュリティ上安全?

普段生活していて、光ファイバーを目にすることはあるでしょうか?一般の方が家庭や職場でむき出しの光ファイバーを目にすることは少ないと思います。しかし、各家庭に光回線が引かれている事からも分かるように身近に光ファイバーは張り巡らされており、海底ケーブルを通して世界中が光ファイバー網でつながっています。
f:id:yasuikj:20200703130553p:plain:w180f:id:yasuikj:20200703130728p:plain:w350
f:id:yasuikj:20200703130812p:plain:w220f:id:yasuikj:20200522155007j:plain:w310
では、光ファイバー盗聴は難しいのでしょうか?光ファイバーの盗聴は、セキュリティ業界では古典的なテーマ*1であり、一般の方も、海底ケーブルを通った情報の盗聴という話題を見聞きしたことがあるかも知れません。海底ケーブルも中身は光ファイバーです。

光ファイバーの盗聴実験は、海外サイトではいくつか紹介されていますが、実際やってみないことには難しさが実感できません。難しさが分からなければリスクも実感できません。リスク度合いを実感するために、光ファイバーの盗聴実験を行ってみました。

光ファイバーがどの程度安全なのかという話しは、盗聴・侵入を行う攻撃者の技量やモチベーションとの相対的なものであり明確に述べられませんが、 本実験を読んでいただくと具体的なイメージが想像でき、注意するポイントも想像できるようになるのではないかと思います。

盗聴実験

盗聴対象環境の準備

実験では、侵入・盗聴する対象として、図1に示す光ファイバーを2つのメディアコンバータで挟んだ環境を用意しました。
f:id:yasuikj:20200522141211p:plain:w450

f:id:yasuikj:20200525085458p:plain
図1:侵入・盗聴対象ネットワーク

メディアコンバータ はLANケーブルに流れる電気的な信号を光ファイバーに流れる光の信号へ変換する装置です。一般家庭の例だと通信キャリアから貸し出されているONUと呼ばれる装置がLANケーブルと光ファイバーの変換を行っています。光ファイバーに通信データを流すために、メディアコンバータの両端にノートPCとスイッチングハブをLANケーブルで接続し、ノートPCからスイッチングハブにPing通信するようにしました。Ping通信は1秒周期でノートPCからパケットを送信し受信したスイッチングハブがノートPCに応答パケットを返す状態としました。

光ファイバーを切断する方法での盗聴実験

まず、光ファイバーを切断してコネクタを自作する方法で試してみました。

盗聴するための装置の準備

盗聴するための装置として図2に示すメディアコンバータで挟んだリピータハブと盗聴用PCを準備しました。
f:id:yasuikj:20200522142412p:plain:w350

f:id:yasuikj:20200525090032p:plain
図2:メディアコンバータで挟んだリピータハブと盗聴用PC

盗聴用PCはWindowsPCにパケットキャプチャソフトのWiresharkをインストールしたPCです。リピータハブを使ったパケットキャプチャのイメージを図3に示します。リピータハブはLANケーブルにつなげた場合、通信パケットを全てのポートに送り出す装置であり通信パケットを解析する際に使用される装置です。

f:id:yasuikj:20200330185921p:plain
図3:リピータハブを使ったLANケーブルからのパケットキャプチャのイメージ
今回の実験は、LANケーブルの盗聴ではなく光ファイバーの盗聴ですが、図3の構成のリピータハブには光ファイバを直接つなげることができません。このため図4の左側のように、リピータハブに2つのメディアコンバータにつなげ、図4の右側のように光ファイバをメディアコンバータ で LANケーブルに変換してリピータハブにつなげる構成としました。
f:id:yasuikj:20200525134547p:plain
図4:リピータハブを使った光ファイバからのパケットキャプチャのイメージ

この後に実施する実験の前に、ネットワークへの侵入と盗聴の概要を説明します。ネットワークへの侵入は、図1のノートPCとスイッチングハブ間の光ファイバーをニッパーで切断し、切断した光ファイバーの間に図2のメディアコンバータで挟んだリピータハブを設置します。このようにすると、図4の右側に示した構成となり、ノートPCとスイッチングハブ間に流れる通信パケットはリピータハブを経由して盗聴用PCにも流れ込むためWiresharkで盗聴が行えます。この実験では、ケーブルを切断してからどの程度の時間でWiresharkでPing通信の盗聴が行えるかを測定します。

作業工具

今回作業に使用した工具は以下のとおりです*2

f:id:yasuikj:20200703134227p:plain
工具

黄色いシースはがし

ここから盗聴のための作業が始まります。まずシーススリッターで光ファイバーケーブルを挟み引っ張ります。
f:id:yasuikj:20200525100856p:plain:w280f:id:yasuikj:20200525100917p:plain:w280
するとケーブルに沿って縦に切れ目が入り黄色いシースが剥けます。
黄色いシースの中に細い紐の束状の黄色のケブラーがあり、その中に白い心線被覆が出てきます。
f:id:yasuikj:20200525101005p:plain

光ファイバの切断とコネクタ取り付け

ニッパーで白い心線被覆部分を切断します。
f:id:yasuikj:20200525114711p:plain
この時点で通信が切れます。
ジャケットリムーバで白い心線被覆を剥がします。
f:id:yasuikj:20200525101941p:plain:w280f:id:yasuikj:20200525102000p:plain:w280
中から透明な0.25mm素線が出てきます。この後更にもう一段、ジャケットリムーバを使ってコーティングされた樹脂を削りとります。
f:id:yasuikj:20200525102103p:plain:w280f:id:yasuikj:20200525102121p:plain:w280

削くずがとれて、0.125mmの光ファイバーが露出していることがわかります。
削った部分をアルコールで拭き取ります。
f:id:yasuikj:20200525092021p:plain
画面左下の指先から中央のエタノール方向に光ファイバーが伸びているのですが、写真ではほとんど目に見えない細さです。

ここで、今回使用した光ファイバーケーブルの構造を図5で説明します。

f:id:yasuikj:20200525150957p:plain
図5:光ファイバーケーブルの構造
一番外側の黄色部分が2mmのシース。その中に白い0.9mmの心線被覆(図中1mmと記載されているのは0.9mmの誤記)、さらにその中に透明の0.25mm素線があり、その中が0.125mmの光ファイバーとなっています。

ファイバカッターで先端を切り取り光ファイバーの先端を整えます。
f:id:yasuikj:20200525103320p:plain
光ファイバーを留め具付きのコネクタに差し込んだ後、コネクタの留め具を外して光ファイバーとコネクタを固定します。
f:id:yasuikj:20200525103347p:plain:w280f:id:yasuikj:20200525103404p:plain:w280
以上で、コネクタの取り付けが完了です。
もう1つも同じように取り付けます。以下がコネクタを2つ取り付けた図です。
f:id:yasuikj:20200525114932p:plain

コネクタをメディアコンバータに接続

取り付けたコネクタを、図2で準備した盗聴用装置のメディアコンバータ に取り付けます。
f:id:yasuikj:20200525115007p:plain
以上で、盗聴が開始されます。

盗聴結果の確認

盗聴用PCのWIresharkでPing通信が観察されていることを確認しました。
光ファイバーをニッパーで切断してから、ここまで、約5分でした。以前行ったLANケーブルの盗聴実験と比較すると、道具も手順も複雑であり手間もかかりましたが、逆に言うと慣れてしまうとできなくはないものだということが分かりました。この手順は、あまりに原始的で時間がかかる方法であり犯行を発見しやすい手順なので、次にもう少し高度な手順や発見が困難な手順を様々な公開情報から調査してみました。

クリップオンカップラ*3での盗聴実験

海外のサイトで、盗聴リスクを紹介するサイトの多くで使われている*4のが、クリップオンカップラを用いた盗聴実験です。ここでは、クリップオンカップラを用いた盗聴について説明します。この実験のためにクリップオンカップラを探したのですが、高価かつ希少なものであり、なんとか入手できたのは正常動作しない故障品だけでした。このため残念ですが動作原理のみ説明します。

盗聴するための装置の準備

盗聴するための装置として図6に示す、クリップオンカップラと、光コンバータに接続した盗聴用PCを準備しました。盗聴用PCはWindowsPCにパケットキャプチャソフトのWiresharkをインストールしたPCです。

f:id:yasuikj:20200525161929p:plain
図6:クリップオンカップラ

クリップオンカップラで盗聴する原理を説明します。図7のように被覆を剥がした光ファイバーを適度な角度に曲げると光ファイバーから光が漏れます。もれた光をクリップオンカップラで取り出します。

f:id:yasuikj:20200525162503p:plain
図7:クリップオンカップラに光ファイバをセットする様子

取り出した光を、図8で示すようにメディアコンバータ を経由して盗聴用ノートPCに送ります。盗聴が成功すれば、盗聴用ノートPC上のWiresharkでPing通信の内容が確認できます。
f:id:yasuikj:20200525164327p:plain

f:id:yasuikj:20200525162605p:plain
図8:クリップオンカップラを用いた盗聴のイメージ

この手順から分かる通り、光ファイバーは切断していません。この手順では、通信の物理層のリンク状態も正常状態のままリンク断は発生しません。したがって、通信の回線状態から盗聴されていることを発見する事は非常に困難です。発見するための手段としては、光が漏れることでの減衰が発生するので受信する光出力の強度を監視しておくという方法があります。

クリップオンカップラは、光ファイバーを切断せずに盗聴が行え被覆が剥がれた光ファイバーであれば簡単に盗聴ができそうです。ただし今回使用したケーブルの場合だと被覆がついているので光ファイバーを折らずに被覆を剥がす必要があります。黄色のシースはシーススリッターで簡単に剥がせますが、白い心線被覆は0.9mmと細いためケーブルの途中で剥がすのは今回用意した工具では難しく、それなりの工具が必要そうです。

以上、クリップオンカップラを用いた盗聴の説明でした。正常動作するクリップオンカップラを入手して実際に試したかったのですが、今回は諦めました。なお、クリップオンカップラと同じ仕組みの製品を購入しようとしても、なかなか国内では一般市場には出回っていないため入手も困難と思われます。

光ファイバカプラでの盗聴実験

最後に、短時間で盗聴されてしまう可能性がある光ファイバカプラでの盗聴実験を紹介します。前半の写真で集合住宅の共用部の写真(コネクタがたくさん収納されたBOXの写真)があったのを覚えていますでしょうか。コネクタ部分に接近できるのであれば、光ファイバカプラを使って盗聴するのがもっとも容易です(ただし、暗号化されてなければという条件つきです・・)*5

盗聴するための装置の準備

盗聴するための装置として図9に示す、光ファイバカプラと、メディアコンバータに接続した盗聴用PCを準備しました。盗聴用PCはWindowsPCにパケットキャプチャソフトのWiresharkをインストールしたPCです。

f:id:yasuikj:20200616142219p:plain
図9:光ファイバカプラと盗聴用PC

光ファイバカプラは、光信号を分岐するためのものです。ここでは2分岐の光ファイバカプラを用い、図10に示すように、ノートPCからスイッチングハブに流れるパケットを分岐させて盗聴用PCで盗聴するようにします。

f:id:yasuikj:20200616155951p:plain
図10:光ファイバカプラでの盗聴イメージ

光ファイバカプラの接続直前

図11は、盗聴対象に、光ファイバカプラをつなげる直前の図です。

f:id:yasuikj:20200616142436p:plain
図11:光ファイバカプラとりつけ直前
この実験は、コネクタを繋ぎかえるだけなので非常に簡単です。それでは、実験を開始します。
スイッチングハブ側のメディアコンバータ に接続している光ファイバーのコネクタを外して、外したコネクタとメディアコンバータの間に、光ファイバカプラを繋ぎこみます。
では、外します。3・2・1・・・カチャ カチャ グッ 

光ファイバカプラの接続

図12は、光ファイバカプラをつないだ後の図です。

f:id:yasuikj:20200616142738p:plain
図12:光ファイバカプラをつないで盗聴中
光ファイバを外してから、光ファイバカプラをつなぐまで5秒かかりました。
つなぎなおしたタイミングで盗聴が開始されています。動画をつけたのでそちらもご覧ください。前半がファイバーケーブルを切断しての盗聴実験で、後半4:35から30秒ほどが光ファイバカプラでの盗聴実験です。
youtu.be

盗聴結果の確認

盗聴用PCのWiresharkの画面でノートPCとスイッチングハブのPingパケットがキャプチャできていることを確認しました。
この環境ではコネクタを外してから5秒で盗聴が行えました*6

光ファイバー盗聴は現実的なのか?

今回、光ファイバー盗聴実験を行い、前回、LANケーブル盗聴実験をおこないました。結果的にわかったことは、現実的には光ファイバーの方が盗聴が難しいであろうということです。冒頭に記載のとおり、技術的には光ファイバーの盗聴は可能ですので絶対安全というわけではありませんが、本ブログは無用に不安をあおることを意図しているわけではなく、事実を知っていただきセキュリティ対策に役立てていただくことですので、ここではLANケーブルよりは盗聴が難しいと考えた理由を記載します。

  • 機材が数万円はかかり、扱いがLANケーブルより難しい。

LANケーブルは、一般人でも自作などの扱いに慣れている人が多いが、それに比較すると光ファイバーを自作する人は少ない。

  • 通信方式が多用であり、盗聴対象の通信方式を理解しておく必要がある。

LANケーブルにも様々な規格があるが圧倒的にストレートB結線が多く、その前提で試せば盗聴できる可能性が高い。一方で、光ファイバーはマルチモード、シングルモードを始め、盗聴成功するためには知っておかなければいけないことが多く、通信方式の情報を得ておかなければ盗聴は難しい。

  • 通信キャリアなどで通信機器レベルで暗号化されている場合がある。

LANケーブルは、一般には通信機器で暗号化されていることは少ないが、光ファイバーは(全ての光ファイバが暗号化されているわけではないが)通信機器での暗号化の適用がすすんでいる。

以上の理由から、興味をもった素人の人が光ファイバーを盗聴しようとしてもLANケーブルのように簡単には盗聴できないと考えた次第です。

物理対策と監視運用

このような手口もあることを知っておくと、万一セキュリティインシデントが発生した際の侵入口の特定の役に立つかもしれません。いろいろな可能性があることを体験として知っておくと対策を検討する上でも地に足がついた検討が可能になります。

今回、Ping通信の盗聴を行いましたが、もし暗号化されていない独自の光回線を用い重要なデータを平文で通信していた場合など、今回の手口で盗聴されてしまう可能性があります。
本手口に対してはどのような対策が効果があるでしょうか?推奨対策としては暗号化があります。通信機器での暗号化や、論理的な暗号化などいろいろな暗号化が考えられます。とはいえ、制御システムなど昔からの通信を使っており予算的に暗号化できない場合もあるでしょう。光ファイバーに何かおかしなものが物理的に接続されていないか定期点検するというのも1つの案かもしれません。光通信の出力低下を検出できる通信機器で異常検出するというアプローチもあります。物理的な切断に対してはリンク断を検出することが可能です。現状を許容するがインシデント発生時の調査対象に光ファイバーの点検を含めるという考えもあります。答えは1つではないので何が現実的かを考えてみてください。

まとめ

光ファイバーの盗聴・侵入について実験してみました。結論としては、ある特定の条件では5秒で盗聴できたがLANケーブルの盗聴ほど簡単ではないというものでした。
LANケーブルと光ファイバーの両方の盗聴実験をしてみた感想を言うと「平文であれば、LANケーブルの盗聴に比べれば難しいが、できなくは無い。」「各家庭の光ファイバーなど通信キャリア等で適切に暗号化された回線であれば、盗聴困難だろう。」というものです。
本記事は、光ファイバから侵入・盗聴されるリスクがある事を知っていただく事を目的としています。光ファイバーから侵入・盗聴される脅威を正しく把握してセキュリティ対策に役立ててください。
本稿が、セキュリティ対策検討の一助になれば幸いです。

実験を終えて

筆者は、光ファイバーの盗聴実験を行おうと考えた時点で、LANケーブルを盗聴するための知識 はありましたが、光ファイバーを扱った経験はあまりありませんでした。身の回りのどこに光ファイバーが通っているかの調査や、光ファイバーの通信方式の理解から始め、光ファイバーの加工や盗聴について調査を行いました。本実験を行うにあたり、これらの情報を調べたり装置を準備したりとかなりの期間を要しました。装置の使い方を勘違いし初期不良を訴えたり、製品仕様を丁寧に解説いただいたりと、色々ありつつ何とか公開するに至りました。対応いただいた皆様へ感謝します。

今回の実験は、光ファイバー通信方式の中の1つであるシングルモードでの通信を対象としています。文中に光ファイバーの加工手順が出てきましたが、実験のための独自手順であり、正規な手順では無いことをご了承ください。

光ファイバーの暗号化事情についてGE-PONの文献*7を読み通信事業者様の対策をうかがい知ることができましが、一方で、一般企業様で自社回線やダークファイバなどを利用し独自にセキュリティを考慮している場合が気になるところです。

*1:"fiber tapping"で探すと2000年代前半からの資料が容易に見つかります。

*2:今回、勝手がわからなかったため国内大手メーカの光ファイバ加工製品を揃えましたが、光ファイバの加工に精度を求めない盗聴だけの目的であれば、安価な製品でも十分であったと思います。余談ですが、今回の手順は、作業を短時間におこなうためにいろいろ手抜きの手順を試行錯誤した結果の手順ですが、さすがにファイバカッターを使わないとうまくいきませんでした。

*3:クリップオンカップラは今回入手した製品の製品名です。

*4:fiber tapping で検索すればすぐに動画がみつかります。

*5:実際に、この集合住宅が盗聴が容易というわけではありません。個人の設備ではなく検証は行なっていませんが、文献を調べた限りでは盗聴の対策が施されているのだと推測します。世の中の回線のどれだけが物理的に暗号化されているのかの実情は気になるところです。

*6:LANケーブルの実験ブログでは、今回のようなコネクタを外す実験をおこないませんでしたが、LANケーブルでも同じようにコネクタを外して5秒で盗聴可能です。LANケーブルでコネクタをはずす方法は誰でも思いつく方法のため言及していませんでした。

*7:https://www.ntt.co.jp/journal/0511/files/jn200511059.pdf , https://www.ntt.co.jp/journal/0512/files/jn200512051.pdf , https://www.ntt.co.jp/journal/0503/files/jn200503075.pdf

CDIが構築/運用するセキュアなリモートワーク環境 - 折れまくるHWトークンの屍を超えて -

はじめに

技術部の石垣です。

弊社ではCOVID-19の影響を鑑み2月中旬から部署ごとではありますが、リモートワークを開始し2月25日には全社でのリモートワーク対応(BCP対応)となりました。

さてCOVID-19をきっかけとしてお客様から、セキュアなリモートワーク環境について相談を受けることがありましたので、弊社におけるPKIを利用したVPN利用環境およびVPN運用遍歴について少々紹介したと思います。

弊社社員数は50-100名に収まる程度です。

昨今ゼロトラストが話題に上がりVPNいらないんじゃない?となったりしますが、以下の理由でVPNを利用しています。

  • 社内システムをパブリックネットワークに公開した場合、DDoS等の可用性リスクも考慮しなければならない。
  • DDoS攻撃を受けても公開サービス(攻撃者に知られている公開サービス)のみに局所化したい=一般公開していない別系の社内向け公開システム+社内システムは業務継続可能としたい

なお弊社ではお客様にフォレンジック、診断サービスを行っていることもあり、ハードウェア、ネットワーク機器、OS、middlewareにおける設定上の不備や、運用上の不備、脆弱性等を利用して侵入する過程を見ている+社内メンバーも攻撃能力を持った集団なので、一発即死にならないようにどう対策をすべきかを日々実践しています。

大手ネットワークベンダーや、老舗ソフトェアベンダーであっても安心ではありません。自分が運用者だったら発狂レベルの脆弱性がさらっと公開されています。

最近だと以下があります。

https://jp.tenable.com/blog/cve-2019-11510-proof-of-concept-available-for-arbitrary-file-disclosure-in-pulse-connect-secure

https://unit42.paloaltonetworks.jp/exploits-in-the-wild-for-citrix-adc-and-citrix-gateway-directory-traversal-vulnerability-cve-2019-19781/

https://www.fortinet.com/blog/business-and-technology/fortios-ssl-vulnerability

※診断環境で実際に遭遇するため社内エンジニアがこういった脆弱性を利用し侵入します。

概要と遍歴

さて社内ではフォレンジック・オフェンスのエンジニアだけではなくセールス、バックオフィス等も含め様々なITリテラシーの利用者が、Windows, Linux, Mac等様々な環境からVPNを利用する必要がありなかなかサポートが大変です。

入社当時(7-8年前)は既に社内ではHWトークン1を利用可能なPKIベースのOpenVPNやPacketiX VPN等を利用していました。

またHWトークンは過去にGemalto K30, ePass2003等を利用していました。

なぜHWトークン(スマートカード等)を利用するのかについてですが、様々な侵害レポートでも報告されている通りセキュリティ侵害の主パターンは認証情報の窃取/漏洩/簡単なパスワード/使い回し等であり弊社でもペネトレーションテストでも同様の傾向が見られます。

元CIA CISO Robert Bigman(ロバート・ビッグマン)氏の講演2でも

2つ目は、二要素認証やスマートカードを組み合わせるなどして認証を強化することだ。コストの面で従業員全員に適用するのは難しい場合でも、少なくとも管理者権限を持つユーザーについては、強固な認証を採用すべきだとした。

管理者権限を持つクレデンシャルやチケットを入手するといった一連の作業を素早く行い、これらがサイバーセキュリティリスクの87%を占めている。逆に、こうした動きに対処できれば、かなりの部分を保護できることになる

と述べられています。

またDoD Cyber部隊もスマートカードベースの認証を利用しており以下のURLには利用にかかるドキュメントが公開されています。

https://public.cyber.mil/pki-pke/end-users/getting-started/ f:id:tatac1:20200626144033p:plain

画面右上側のLogin with CACが記載されておりスマートカードベース認証は上記で紹介した組織においても利用されています。

過去の課題

 

Gemalto K30, ePass2003を利用する場合

現在はもしかしたら記載する制約は無いかもしれませんが数年前はGemaltoのHWトークンにおける課題として

  • Linux等でlibidprimepkcs11.0.soが安定して動かない
  • Linux向けは毎回buildが大変

ePassでは

  • 同一のバージョンのソフトウェア+設定であっても、トークン内部のファームバージョン?/chipが異なると動かない

等ハードウェア周りでいろいろと苦労させられることがありました。社内ではほかにSafenet等もトークンあったため選択としてはありましたが、Gemaltoに買収されなかなか製品を見なったため結局利用せずおわってしまいました。

Gemalto K30f:id:tatac1:20200626141353j:plain

利用しているうちに、折れ曲がってしまった無残な姿

ePass 2003 f:id:tatac1:20200626141349j:plain

同じソフトウェア、設定を利用しても、動かない等いろいろ苦しい経験をさせられたePass2003

OpenVPNを利用する場合

  • クライアントソフトウェアのインストールが必要
  • 通信速度が思ったよりも出ない
  • Wi-FiからLTEに切り替わる際接続が切れる

PacketiX VPNを利用する場合

  • スマートカード認証を利用する場合クライアントソフトウェアのインストールが必要
  • Windowsしかスマートカード認証を利用できなく対応プロトコルも限定的

OpenVPN/PacketiXクライアントソフトウェアのインストール・アップデートはなかなか大変です。

またスマートカード認証では基本PKCS11を利用しますが、クライアントソフトウェアのPKCS11対応や、どのプロトコル(L2TP Over IPSecとか)で利用できるかも重要でありPacketiXではWindows限定となるため、弊社CHOが頑張ってクライアント側でTOTP実装をPacketixクライアント側で作り社内のTOTP対応Radiusと連動を試みましたが、接続規定時間or通信上限になると突然途切れる動作(ReKeyで再度TOTP認証が必要)であり運用上の課題となることが予見できたため利用は諦めました。

現在の環境

VPNクライアントはWindows, macOSに組み込まれているVPN(IKEv2)を利用しています。またVPNクライアントで利用するHWトークンは前回のBlog投稿に記載のとおりYubikey 5 NFC/Yubikey 4を利用しており、FIPS-201 PIV3規格(いわゆるスマートカード認証)を利用したクライアント認証のためのデバイス4として利用しています。

Yubikey 4/5 NFCは全体的にメカニカルな部品が露出していないので、耐水性、防塵性、耐久性、費用対効果5が一番高いと社内で評価している製品です。なにより多数のユーザが利用しており様々なフィードバックが製品に反映されていることが最終的に各OS環境において安定した動作につながっているとみられ素晴らしい製品だと思います。

とはいえ利用方法によっては、折れてしまうこともあります。筆者出張先のホテルでYubikey刺しっぱなしのままラップトップを落として破損した経験有ります。社内では筆者含め2名破壊

f:id:tatac1:20200626141346j:plain 根元から完全にUSB端子が折れてしまったので社内HWの達人によって修復されたYubikey。社内Milling Machineでエポキシ樹脂を1/10mm単位削り基板を露出させ配線

f:id:tatac1:20200626141518j:plain 養生テープで補修されていて見た目は悪いですがこれでもYubikey動くんです。

なお弊社ではHSMを利用した社内認証局から証明書発行を行っています。

VPNサーバはIKEv2+RFC5755のAttribute Certificateの仕組みを利用してユーザの所属先ごとに接続可能な通信先が切り替わる仕組みとなっています。またサーバは約2-3年ほど運用しており非常に安定しています。

昨今話題になっているNATテーブル枯渇に関してはIKEv2 Split-Tunnelingを利用し社内向けトラフィックと社外向けトラフィックを分離しているため、VPNが遅い等の問い合わせはありません。なおIKEv2 Windows10 実装は、サーバからのルーティング情報を無視するのでPowershellでVPN設定を行いSplit-Tunneling設定を行っています。

 VPNのパフォーマンスに関してはINTEL AES NIを利用し暗号処理をしているため、現状のVPNクライアント数でCPUは一桁%の負荷であり、回線が先にボトルネックになります。※弊社ではいくつかの出入り口を持っているので必要に応じて接続分散させることで対応は可能

VPN接続後においても社内では同一のYubikeyを利用しシンクライアント、Kerberos、SSH、Web、SMTP等においてもWindows, Mac, Linuxの複数の環境をサポートしつつクライアント認証6を実現しており社内内部,およびネットワーク出入り口で多層防御対策を行っています。

またネットワークレイヤーもVPNによるACL制御(L3)だけではなくL3-L4レイヤーでサービスごとにセグメンテーション分離しACL設定を行っており全体のライン数は数千〜万オーダです。実際にどうやって運用管理をしているかはこちらに記載がありますので興味があればご覧ください。

今後の課題

  • TNC対応 ※リンク先資料に記載されたPEP/PDPのキーワードで気づく方がいるかもしれませんが、筆者はゼロトラストがTNCの概念を取り込んだと思っています。
  • TPM2を利用したいわゆるSecure boot/Trusted Boot + FDE + AIKの対応 ※社内のいくつかのプロジェクトでは既にSecure boot/Trusted Bood, FDE, AIKの動作は検証済みであり技術的な評価はほぼ完了。

まとめ

弊社におけるVPNサービスでのセキュリティ確保およびPKI利用についてご紹介しました。

VPN限らずエンタープライズ環境(内部/外部ネットワーク/アプリケーション)においてオンラインで確かな認証/認可はセキュリティにおける永遠の課題であると思います。

本稿記載内容および参考リンク等を紹介することでセキュリティ対策検討の一助になれば幸いです。

余談 

RFC5755 Attribute Certificateはとっても便利な仕組みです。ある認証局から発行された証明書に対して、何らかの要素を書き加えて署名を行うことができます。

たとえばA CAから発行されたkuma.pem 証明書があったとして、そのkuma.pem証明書にattribute としてgroup: CDI Zero Project とタグみたいなものを付与し、Z Attiribute CAで署名を行って、kuma-zero.pem を生成します。弊社ではYubikeyを利用していますのでkuma.pemに対応する秘密鍵が入ったUSBトークンを利用してVPNサーバに接続するとVPNサーバでZ Attiribute CAおよびA CAをtrustしていれば、kuma.pem -> kuma-zero.pem -> CDI Zero Projectとattributeが見つかります。

サーバとクライアント間はattribute: CDI Zero Projectに定義されたIP Addressのみだけ通信可能なVPN接続できあがる仕組みです。

x509証明書=認証、Attribute Certificate=認可と考えていただくとわかりやすいかと思います。運用面から見ても本人確認を行うプロセス(トークン向け電子証明書)と、利用を許可するプロセス(VPN利用向け電子証明書)が分離でき内部統制や柔軟な運用対応が可能となります。

これを応用するとマイナンバーカードを利用して、認証向け公開鍵(利用者証明書用電子証明書)を取り出して、Z Attiribute CAでattibuteを付与するとVPNでスマートカード認証ができたりもします。

オンラインで公開鍵を受け渡す場合には、署名用電子証明書で利用者証明書用電子証明書に署名を行い、受け取り側で署名検証すると安全な本人確認ができたりします。

ただしマイナンバーカード利用や証明書有効性(CRL,OCSP)確認は以下の申請、回線接続・利用代金が必要です。

https://www.j-lis.go.jp/jpki/minkan/procedure1_2.html

https://www.j-lis.go.jp/jpki/minkan/procedure1_2_2.html

OCSPの提供は無理にしても、CRLぐらいはCDN経由で公開いただくともっと利活用が進む思います。

マイナンバーカードを持ち歩くのは嫌ということを聞きますが、せっかくのリモートワークなので自宅だと家から持ち出す必要なく1000円と安く調達でき、かつ本人確認済み証明書まで発行しているのでセキュアにVPN接続するにはとても便利なデバイスです。自治体だとLGPKI、政府職員だとGPKIで発行されたスマートカードを保有されていると思いますので、入退室等で見せるだけでなくそれらのカードを利用することでセキュアな認証や改ざん対策等の電子署名(SMIME/PDF等)もできます。

なおマイナンバーカード内の利用者証明書用電子証明書データ(プライバシー)を気にされる方は以下の仕様書が参考になるとおもいます。

https://www.j-lis.go.jp/data/open/cnt/3/2187/1/13_profile_genkou.pdf

このRFC5755の応用としてNSAではサプライチェーンリスクでの活用を行う動きがあります。

次回の記事ではIoT環境における攻撃を想定し上記内容を含んだセキュリティ確保対策についてご紹介できればと思います。


  1. パスワードだけに頼らない高セキュリティな認証を行うためデバイス。正規の手続きを行うことで利用は可能ですが、秘密鍵を取り出すことは原理的に不可能となったチップが組み込まれています。規格は異なりますがIC付きクレジットカードなども動作原理は一緒です。

  2. 一にも二にも「防御」を――元CIAのCISOが提言した6つのセキュリティ対策

  3. 米国の国防省ではCAC、連邦政府職員やコントラクターはPIV規格のスマートカードを利用しクライアント認証を行っています。実際にどう利用されているか確認されたい方はこちらこちらへアクセスすることで確認できます。

  4. SP800-63BにおけるAAL3相当です。FIPS Validatedバージョンを利用することでNIST800-1713.5 IDENTIFICATIONAND AUTHENTICATIONに記載されているSP800-63B対応となり連邦政府のコントラクター、防衛産業等で求められるレベルになります。

  5. 4年使ったとすると年間たかだか1200-1300円程度、アンチウイルスソフトの更新料と同等

  6. ウェブブラウジングにおけるクライアント認証はTLS通信であり、クライアント認証できなければ、アプリケーションレイヤーへの攻撃のペイロードも届きません。したがって有効な証明書入りのトークンがなければ、アクセスが不可となります。※TLSの実装における脆弱性は別問題。

株式会社サイバーディフェンス研究所 / Cyber Defense Institute Inc.