DARK MATTER

CDI Engineer's Technical Blog

光ファイバー盗聴・侵入を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の実装における脆弱性は別問題。

社内PKIを支えるYubiKeyのAttestation

はじめに。

はじめまして。技術部のishizukaです。社内でYubiKeyを使って遊ぶ機会に恵まれ、クライアント証明書の発行のフローと遊んでいる最中に気づいた面白いことをまとめていきます。基本CLIベースな記事なので画像がほとんどないです。

概要

CyberDefense社内では、YubiKeyに入れた証明書を利用した個人認証を行っています。これによりパスワードからの脱却を目指しております(多少誇張)。一方で、ICカード等の物理デバイスの運用は、PINの誤入力によるロック、物理的な紛失といった別のリスクが存在します。

これらのリスクに対して社内では証明書のリモート発行を準備することで、誤ってロックアウトされてしまった際でも出社することなく証明書を再発行する運用ができるように準備を整えました。この証明書発行フローを簡略化して説明していきます。

f:id:m-ishizuka:20200526123123j:plain
yubikey_farm

CDI社内で、YubiKeyにより認証している箇所

社員はWindows/Mac/Linuxのいずれかを利用し以下のリソースをYubiKeyの証明書で利用しています。

  • VPN
  • 802.1X(有線・無線の双方)
  • 一部Webサービス
  • Kerberos
  • メール
  • SSH(実際は証明書ではないですが)
  • 一部OSのログイン(U2Fの場合も)

YubiKeyのAttestation

公式のAttestationに記載の通り、秘密鍵がYubiKey内部で生成された際に、Attestationが生成できます。このAttestationの機能のおかげで、その秘密鍵が、外部で生成され、importされたものではないことが保証できます。これにより、秘密鍵がマルウェア等により作成されているリスクや、ファイルベースでコピーできるリスクなどをほぼ無視できます。リモート証明書発行にはこのAttestationの機能を利用します。

Attestationスロット(F9)にそのYubiKeyの中間CA証明書と秘密鍵が入っており、各種スロット(PIV Authentication, Card Authentication, Key Management, Digital Signature)のAttestationを生成する・・・ようです。(ブラックボックスのため推測)

今回の内容はYubiKey5をベースに記載してますが、openssl1.0を利用するか、本家のPythonスクリプトを利用することでYubiKey4でも確認が可能です。

確認環境

ベースOS

Mac or Linuxを推奨します。opensslとyubico-piv-tool(https://developers.yubico.com/yubico-piv-tool/Releases/) が手軽に利用できるからです。WSL2でも利用できるかもですが、非推奨というか利用方法がよくわからないです。

またDockerコンテナ内で作業もできますが、USBをコンテナ側から利用できるようにする必要がありますので、これも非推奨というかハードル高いです。 一見ハードルが高そうなVMのLinuxが一番ハードル低いかもです。

今回はUbuntu20.04がリリースされて間もないので、折角なのでVirtualBoxにこれを入れ使います。インストール手順は省略します。

プログラム

  • openssl
    • mac/ubuntu ともに初期で入っているはず。
  • yubico-piv-tool
    • ubuntuなら sudo apt install -y yubico-piv-tool で入ります。
    • macは適当にインストーラを使うなど。

手順

今回は分かりやすいようにリリースされている既存のツールのみを利用し、PIV authenticationのスロット(9a)のみ説明していきます。

なお、実際の会社では以下のようなフローになるかなと思います。

  1. 資産管理チーム
    1. シリアルと、利用者と紐付け、証明書発行チームに連絡
  2. 証明書発行チーム
    1. Attestationの中間CAを保存
    2. CSR生成
    3. Attestation 生成
    4. 証明書発行
    5. YubiKeyに証明書の導入、ユーザにYubiKeyを渡す
  3. ユーザ
    1. 利用

再発行時は、

  1. ユーザ
    1. CSR生成
    2. Attestation 生成
    3. 証明書発行チームにCSRとAttestationを送付・依頼
  2. 証明書発行チーム
    1. Attestationの検証
    2. CSRとAttestationの確認
    3. 証明書発行
    4. ユーザに証明書送付
  3. ユーザ
    1. YubiKeyに証明書の導入
    2. 利用

Attestationの中間CA証明書を保存

社員に証明書を発行する前にYubiKeyからAttestationの中間CA証明書を保存しておきます。これを利用し、そのYubiKeyが会社から支給されたYubiKeyか否かの判断材料になります。

$ yubico-piv-tool -a read-certificate -s f9 -o test-intca.crt
$ openssl x509 -in test-intca.crt -noout -issuer -subject
issuer=CN = Yubico PIV Root CA Serial 263751
subject=CN = Yubico PIV Attestation

このようにIssuerがYubico PIV Root CA Serial 263751の中間CA証明書が出力されます。先に記載したAttestationにRootCAの証明書があるので、検証できるか確認してみます。

$ wget -q https://developers.yubico.com/PIV/Introduction/piv-attestation-ca.pem
$ openssl verify -CAfile piv-attestation-ca.pem test-intca.crt 
test-intca.crt: OK

Verify OKになりました。これでこの中間CA証明書は適切に利用可能であることがわかりました。

CSR生成

この作業は利用者側で実行でも構わない箇所です。というのも在宅勤務でYubiKeyをロックさせてしまう可能性を考慮してです。なお私もこのコロナ禍の初期に一度YubiKeyの証明書を消失させてしまった経験があります。VPNが利用できず辛みしかありませんでした。

ECDSAのほうが秘密鍵作成時間が短いので、意図的にECDSAを利用しています。

PINは初期値の123456を利用しています。

$ yubico-piv-tool -a generate -s 9a -A ECCP256 -o 9a.pub
Successfully generated a new private key.
$ yubico-piv-tool -a verify-pin -a request-certificate -i 9a.pub -s 9a -S "/CN=test/" -o 9a.csr -P 123456
Successfully verified PIN.
Successfully generated a certificate request.

さてCSRが作成できました。合わせてCSRの中身を見てみます。

$ openssl req -in 9a.csr -noout -subject
subject=CN = test 

適切なPEMフォーマットのCSRだとわかります。

Attestation 生成

され、これだけだと誰がどのようにして作成したCSRかわからないため、Attestationを生成します。ついでに、以前に取得した中間CA証明書を利用して、検証できるか確認します。

$ yubico-piv-tool -a attest -s 9a -o 9a.attest.crt
$ openssl verify -CAfile <(cat piv-attestation-ca.pem test-intca.crt ) 9a.attest.crt 
9a.attest.crt: OK

Attestationの検証に成功しました。この9a.attest.crtと9a.csrを証明書発行チームに送ります。

証明書発行チーム

証明書発行チームが見る内容は以下です。

  1. Attestationの検証に通ること
  2. Attestationの中身の公開鍵と、CSRの公開鍵が一致すること
  3. Attestationの証明書内のYubiKeyのシリアルが配布したYubiKeyのシリアルであること

1により、秘密鍵がYubiKey内部で生成されており、複製が計算量的に非常に困難であることが保証できます。 2により、提出されたCSRの公開鍵がAttestationで保証できます。 3により他の人のYubiKeyではないことが確認できます。1

この2つを確認することで、提出されたCSRが会社支給のYubiKeyで生成された秘密鍵を利用して作成されたものであることがリモートから検証できます。

Attestationの検証

$ openssl verify -CAfile <(cat piv-attestation-ca.pem test-intca.crt ) 9a.attest.crt
9a.attest.crt: OK

Attestationの中身の公開鍵とCSRの公開鍵の比較

$ diff <(openssl req -in 9a.csr -noout -pubkey) <(openssl x509 -in 9a.attest.crt -noout -pubkey)

Attestationの証明書内のYubiKeyのシリアルの確認

Attestationの中身 を見る限り、単純なシリアルナンバーのはずだが、頭2バイトに不要な値が。

$ openssl asn1parse -in 9a.attest.crt | grep -A1 "1.3.6.1.4.1.41482.3.7"
  473:d=5  hl=2 l=  10 prim: OBJECT            :1.3.6.1.4.1.41482.3.7
  485:d=5  hl=2 l=   6 prim: OCTET STRING      [HEX DUMP]:020347B06E
$ printf "%d\n" 0x47B06E                                                                                                                                                   
4698222

検証に通ること、diffによる差がないことを持って提出されたCSRがYubiKey内部で生成されたことが保証されました。これをもってCSRに署名をします。ここは省略します。

YubiKeyへの証明書のimport

証明書発行チームから9a.crtというファイルが届いたという前提で後続作業をします。

以下の可能性を考慮し正当性を確認しましょう。

  • 証明書発行チームが悪意を持って違う証明書を送ってきた
  • 証明書発行チームのヒューマンエラーで違う証明書を送ってきた
  • 途中経路で改竄が発生し、異なる証明書になってしまった

証明書発行チームが行っているCSRとAttestationの比較を今度は送付された証明書で行います。自身のYubiKeyに入っているAttestationのPubkeyと送られてきた証明書のpubkeyを比較します。

$ diff <(yubico-piv-tool -a attest -s 9a | openssl x509 -in - -noout -pubkey) <(openssl x509 -in 9a.crt -noout -pubkey)

さて、これで送られてきた証明書が正しいものだと確認できました。証明書をyubikeyに入れ、最後に確認します。

$ yubico-piv-tool -a import-certificate -s 9a -i 9a.crt 
Successfully imported a new certificate.
$ yubico-piv-tool -a status

Attestation周りの確認

  • 外から鍵をimportするとAttestationは生成されない。というよりエラーが帰ってくる。
$ openssl genpkey -paramfile <(openssl ecparam -name prime256v1 ) -out 9a.key
$ yubico-piv-tool -a import-key -i 9a.key -s 9a
Successfully imported a new private key.
$ yubico-piv-tool -a attest -s 9a
Failed to attest data.

持っているYubiKeyの秘密鍵が外からimportされたものではないことを確認する意図なら、証明書が出力されればそれでOKと考えることもできます。

結び

YubiKey5を利用したオンライン証明書発行を支えるAttestationの機能の確認と実際の利用の仕方についてまとめました。次回はYubiKeyを破壊します。


  1. 確認した限り、60本のYubiKeyで同一の中間CA証明書でした。単位については不明(同一ロットでなのか、注文時のまとめ買い数なのか、Firmwareなのか)

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