【緊急寄稿】PKI認証は危険か?オンラインバンキング不正送金問題

IT・IT製品TOP > Key Conductors > 亀田 治伸(日本セーフネット株式会社) > 【緊急寄稿】PKI認証は危険か?オンラインバンキング不正送金問題
この記事をtweetする このエントリーをはてなブックマークに追加

IT現場の道先案内人 Key Conductors

【緊急寄稿】PKI認証は危険か?オンラインバンキング不正送金問題

エンドポイントセキュリティ 2014/05/23

 本寄稿は4回連載における2回目となる。第1回目ではオンラインバンキングのおける業界的なOTPとPKIの使い分けについて、それらの認証強度の違い、PKI認証の安全性に疑義が生じている現状をまとめさせていただいた。第2回目となる今回は、OTP認証に比べてPKI認証が強固であるといえる別の技術的側面をまとめさせていただくとともに、証明書を盗む手口などをブラウザ種別ごとにまとめさせていただきたい。

認証乗っ取りとPC乗っ取り(遠隔操作)

 本連載では、PKIおよびOTPを盗むことによる攻撃に主題を置いていたが、第1回に対する皆様のコメントとして、「PCそのものを遠隔操作で乗っ取る場合はPKI認証の強度は弱いのではないか?」というご指摘をいただいた。このため、急遽4回連載とさせていただき、第4回目にPCに対する遠隔操作におけるPKI認証とOTP認証の違いについてまとめさせていただく予定である。あくまで第2回である今回は、「認証識別子を盗むこと」について主眼をおかさせていただく。

昨今のニュース

 第1回目に記載させていただいたのと同様、法人バンキングの不正送金被害において、電子証明書を盗まれることによる被害が発生したとされる明示的なニュースは、依然存在しない。ただし上記の情報を鑑みるに、オンラインバンキングにおけるPKI認証の安全性について疑義が生まれていることは確かのようだ。ここでいうICカードとはどのようなものであるかをまずはまとめさせていただく。ICカードはブラウザの代わりに証明書を格納し、PCに接続して使用するものだ。カード型やUSBトークン型が存在する。カード型はリーダライタが別途必須になるという難点はあるが、いろいろな情報を印刷できるというメリットがある。

 前回の寄稿から2つニュースが飛び込んできているのでまずはそちらを紹介させていただきたい。

1.東京三菱UFJ銀行は、法人向けオンラインバンキングサービスにおいて(筆者注:標準でPKI認証を使用している)、今後新規ユーザーはすべてICカードを配布すると公表している (詳細)。
2. 全国銀行協会(全銀協)から、以下の内容のアナウンスが実施された。
(略)
足下で発生している犯罪手口を踏まえ、会員銀行は、法人向けインターネット・バンキングにおけるウイルス等による不正送金被害を防止するため、各行の法人向けインターネット・バンキングの仕様等に応じ、今後、次のような対策を1つまたは複数組み合わせるなどして、対策を講じていくよう努める。
(1)電子証明書のセキュリティ強化策
A. 電子証明書をICカード等、取引に利用しているパソコンとは別の媒体・機器へ格納する方式の採用(略):詳細

 第1回目に記載させていただいだのと同様、法人バンキングの不正送金被害において、電子証明書を盗まれることによる被害が発生したとされる明示的なニュースは、依然存在しない。ただし上記の情報を鑑みるに、オンラインバンキングにおけるPKI認証の安全性について疑義が生まれていることは確かのようだ。
 では、ここでいうICカードとはどのようなものであるか。ICカードはブラウザの代わりに証明書を格納し、PCに接続して使用するものだ。カード型やUSBトークン型が存在する。カード型はリーダライタが別途必須になるという難点はあるが、いろいろな情報を印刷できるというメリットがある。

※会員登録いただくと図をご覧いただけます。
会員登録はこちら(無料)

※会員登録いただくと図をご覧いただけます。
会員登録はこちら(無料)

ICカードの技術検討時に考慮すべき主な項目

証明書を書き込む/内部生成する機能はあるが、Exportする機能がない

証明書を盗むことが不可能(耐タンパ性)

正当なユーザーでもExport不可能

FIPS140-2Level3による外部認定 

初回利用時にPINの設定を強制づけることが可能

簡単なPINの設定拒否が可能(1111等)

PINの定期的な変更の強制が可能(1年毎等)

PINが複数回間違えたときに、ロックをかけることが可能。

ユーザーによるロック解除は不可能

(PINというのは技術的にはパスワードと同一のものであるが、OTPやPKIを導入する際に、「パスワードを設定しておいてください」とはいいづらい。このため「PINを設定しておいてください」と言い換えているのである。銀行によってはマニュアルに「証明書パスワード」と記載しているケースもある。)

ICカードの技術検討を進められる際には、これらの機能をすべて備えているものを検討する事が望ましいが、一番大事なのは「耐タンパ性」といわれる部分である。「耐タンパ性」を備えたカードに証明書を格納するメリットは、Windowsやブラウザと証明書の管理を切り離すことだけではない。中に格納された証明書を取り出すことが管理者であっても不可能なのだ。このため、証明書が漏洩しないことを保証してくれる。耐タンパ性は、ICカードベンダーが単独で謳う分には根拠に乏しく、外部の監査機関に疑似攻撃テストなどを行ってもらい、また設計思想などをレビューし、公的な認定を取得することで初めて公に宣言が可能となる。

 日本では大きく米国政府が主導で策定した「FIPS140-2」とヨーロッパなどでより重視される国際共通規格の「CommonCriteria」の2種類が存在しているが、政府系の暗号製品調達では「FIPS140-2」が重視される傾向にある。(同様に筆者はCommonCriteriaの複雑さおよび曖昧さから、概念を一般に流通させるのは難しいと考えている。仕組み自体に脆弱性があると考えている。たとえばICカードは「EAL4」という認定を取っている必要があるといわれるが、実はWindows OSも「EAL4」認定を取得している。さて、「EAL4」認定取得商品から情報漏洩がしないといえるだろうか?)

 耐タンパ性を確保して初めて「証明書が盗まれない」と宣言することが可能となり、耐タンパ性は「FIPS140-2」認定により第三者的な裏付けを得ることが出来、「FIPS140-2」認定を取得することで公的に、また国際的に安全であると認識されることとなる。

FIPS140-2の認定レベル

 「FIPS140-2」は大きく以下の3レベルが存在している。

【レベル
1】
1番低いレベルであり、非常に限定した要件を課する:大まかに、すべてのコンポーネントが製品品質であり、甚だしくセキュリティの欠如がないこと(ソフトウェア製品の取得上限)。

【レベル2】
レベル1に次の要件を加える: 物理的な改竄の痕跡を残すこと、及びオペレータの役割ベースでの認証を行うこと。 

【レベル3】
レベル2に次の要件を加える:物理的な改竄への耐性(モジュール中に含まれる取扱注意情報への攻撃者のアクセスを困難にする)を持つこと、オペレータのIDベースでの認証を行うこと、及び重要なセキュリティパラメータがモジュールに出入力するインタフェースと、その他のインタフェースとを物理的又は論理的に分離すること。
(wikipediaより)

 このうちICカードはレベル3認定を取得していなければ、耐タンパ性の認定を保持しているとはいえない。取得していないICカードは、内部データが漏洩しないという第三者的裏付けがないことに注意する必要がある(すなわち劣っているわけではもちろんない)。実際レベル3を取得しているICカードは未取得ICカードに比べてそれほどコストが増えるわけでもないため、無理をして認定未取得カードを選定される経済的理由も薄いことを合わせて述べさせていただきたい。

認証乗っ取りにおけるPKI認証の現状

 さて本題である。「PKI認証」はもう使いものにならないのだろうか?筆者は“それはない”と強く主張させていただきたいと考えている。また批判を恐れずOTP認証よりPKI認証の方が強固であるとも宣言させていただきたい。いままで攻撃されないといわれていたものが、攻撃されているのかもしれない、となっているのが現状である。

 OTP認証はフィッシング攻撃といわれる攻撃手法によりパスワードが漏洩することは10年以上前にわかっている。にも関わらず第1回でまとめさせていただいた通り、個人向けオンラインバンキングはID/PWD以外ではOTP認証がデファクトとなっている。個人バンキングの不正送金被害はすべて銀行が補填しているのだから、より強い認証方式に切り替えたいという銀行サイドの思いがあるのは間違いないはずだ。

 ではなぜそれがなされないのか…?それは簡単である。「セキュリティとユーザの利便性を両立しつつ」「十分な大規模運用の実績を持つ」認証方式がほかに存在していないのである。無理にユーザ利便性を損なう強固な認証方式に切り替えると、ユーザビリティが格段に低下してします(PKI認証はログイン可能な端末を固定するため、コンシューマ展開には不向きである)。

 ソフトウェア開発に携わったことのある方であればお分かりになると思うが、ユーザ数が数万、数十万と増加するにつれて、予想しなかった問題が発生する。これらがシステムの安定性をそぎ、脆弱性につながる。結局のところOTP認証より具合のよいバランスのとれた認証方式は存在していない(技術的に優れたものは、当然いくつか存在するが、それは本寄稿では割愛させていただく)。

 PKI認証も同様である。PKI認証より具合のよい、大量ユーザの実績を持つ認証方式は存在しない。また銀行は半公的インフラであり、何よりもその安定性と公平性を重視している。PKIは共通プロトコルであり、そのすべての仕様は公開されており、そういう観点からもPKI認証に変わる認証方式は存在しておらず、当面は上記の全銀協からの発表にある通りPKI認証をより強固にする方向に検討が進むのは妥当であると思う。

OTPを盗むには?

 前置きが長くなってしまったため、具体的な攻撃手法に話を移させていただく。まずOTP認証とPKI認証との対比として、上記に述べたフィッシング攻撃について説明をさせていただきたい。フィッシング攻撃というのは、ユーザを一見正しい不正なサイトにログインさせようとして、そこでユーザが入力したパスワードを盗み取る。ユーザがオンラインバンキングのログイン時に入力したOTPを別のサイト、別の人間に送るのだ。その後ユーザはログインに自動的に失敗する(OTPは毎回異なり一度ログインが成功すると、不正に入手したパスワードは使用不可能となってしまう。このため、ユーザはログインに失敗しなければならない。)こちらに対する技術的考察と対策は次回まとめさせていただく。ユーザに正しい銀行のサイトにログインさせ、振込処理時点で動き始めるマンインザブラウザ攻撃も存在しているが、それは第4回で改めさせていただく。

※会員登録いただくと図をご覧いただけます。
会員登録はこちら(無料)

フィッシング対策協議会にわかりやすい例があるので転載させていただく
http://www.antiphishing.jp/consumer/abt_phishing.html

PKI認証の場合は?

 一方PKI認証はこの手の攻撃が通用しない。少しPKIの仕組みの話になってしまうが、お付き合いいただきたい。PKI認証はユーザが電子証明書を持つことにより実現されるが、電子証明書は大きく2つのコンポーネントからなる。公開鍵(証明書)と秘密鍵だ。公開鍵と秘密鍵は切り離せないペアとなっていることが特徴であり、どちらか1つだけでは使用が不可能となる。オンラインバンキングの認証では、公開鍵(証明書)のみをサーバに送るが、公開鍵(証明書)のみでは認証が成立しないようになっている。

 これは電子証明書が持つ特性である以下を利用している。

●「公開鍵で暗号化されたものはペアの秘密鍵のみで解読できる」    
●「秘密鍵で暗号化されたものはペアの公開鍵のみで解読できる」

 認証の流れのなかで、クライアントブラウザはまず乱数を生成する。そしてその乱数を秘密鍵で暗号化を行い、公開鍵(証明書)と一緒にサーバに送るのだ。サーバは、送られてきた暗号データを公開鍵(証明書)で復号化してみる。復号化できたのであれば、ユーザは対応する秘密鍵を持つユーザ、つまり正当なユーザであると認識ができるようになっている。このため、クライアントとサーバの間の通信には公開鍵(証明書)のみが流れるため、通信の傍受やフィッシング攻撃では対応する秘密鍵を盗むことができないのだ。したがって仮にフィッシング攻撃で公開鍵(証明書)を不正に入手できたとしても、なりすましログインが成立しない。OTP認証より乗っ取りに強いといわれる理由がこれである。

では、PKI認証を乗っ取るにはどうすればいいのか?

 理屈は単純であり、秘密鍵を盗むのだ。そしてPKI認証の強化にはどうすればいいのか?秘密鍵を盗まれないようにすればよいのだ。それがICカードである。秘密鍵の盗み方についてまとめさせていただく。

■Firefoxの場合

 秘密鍵の盗み方はブラウザ毎に異なる。まずは1番簡単なFirefoxを例に挙げる。残念ながらFirefoxの証明書格納状態は非常に脆弱であるといえる。Firefoxにインストールされた秘密鍵はkey3.dbというファイルに保存される。攻撃者はこのファイルを盗めばよい。このファイルはWindowsのファイルシステム上に普通に存在しているため、盗むのは難しくない。盗んだ攻撃者はそのファイルを自分のFirefoxに組み込めばいいのだ。多くのPKI認証をベースとした法人バンキングがIEのみをサポートしているのは、このあたりの背景が大きい。

 また、key3.dbには最低限のセキュリティ機能としてPINといわれるパスワードを設定できる。ユーザが証明書を利用するたびに、ダイアログが出力されPINの入力が求められる。
PINに関してはオンラインバンキングの設定マニュアル上、設定が必須となっているが、PINの設定を強制することができない。少し詳しいユーザがPINなしで利便性のみを追求し証明書を設定しているケースも少なくない。またサーバ側では、ユーザがPINを設定しているかどうかの判別がつかない。    

■IEの場合

 ではIEはどうか?IEの証明書機能はWindowsと統合されており、Firefoxに比べるとセキュリティがかなり高い(余談ではあるが、過去起きたWindows+IEの独占禁止法訴訟に思いを巡らせると、IEとWindowsの完全分離が実現されていれば、オンラインバンキングによるPKI認証自体は死んでいた可能性が高いと筆者は思っている) 。

“第1段階目”のセキュリティ

 そのセキュリティは2段階ある。まずインストールされた証明書および秘密鍵はそれぞれファイルとしてWindows上のファイルシステムに存在する。その際にファイルはSIDといわれるWindowsが設定する個別プロファイルをベースとしてDPAPIにより保護されているため、ファイル単独を盗んでも秘密鍵の復元はできない。SIDをWindowsから盗むことは可能であるが、別のWindowsに復元する手法が存在しておらず、端末もしくはWindows環境そのものを盗む必要がある。

 このため、Windows全体が単独ファイルとして存在するシンクライアント環境にオンラインバンキング用証明書を格納するのは銀行としては推奨していないし、筆者も強く推奨しない。今後全面的に法人バンキングにおける不正送金被害が補填対象になるとしても、仮想化環境は補填対象とならないことも考えられる。これはオンラインバンキング側がクラウドに遅れているのではない。ただ単純に盗まれやすいのだ。

 ではどのように証明書を盗むかといえば、Windowsのコマンドラインラインツールを外部から実行させ証明書をExportすることが可能となっている。このあたりが攻撃に利用されている可能性は限りなく高い。(一瞬、コマンドプロンプトなどが画面に出力される)先日のIEの脆弱性問題では、この攻撃が可能な状態であった。

 ただし証明書にPINを設定している場合は以下のダイアログが出力される。身に覚えのないときにこのダイアログが出た場合は必ず、PCをオフインにしてほしい。また、PINについてVista以降は設定を強制化させることが可能となっている。PINは複数回入力を間違えるとPINがロックし、証明書が利用不可能になる。(11回など)ただし、Windowsを再起動するとまた使える状態にもどる。

※会員登録いただくと図をご覧いただけます。
会員登録はこちら(無料)

“第2段階目”のセキュリティ

 第2段階目のセキュリティとして、Windowsのツールを利用した証明書+秘密鍵のExportを不可能にすることが、証明書発行時に可能である。この場合、Export処理の途中でエラーとなり処理が終了する。この場合遠隔操作による証明書を盗む攻撃は成立しない(しなかった…)。しかしながら、PCの入れ替え時に証明書の入れ替えが行えないという問題が発生するため、採用していないオンラインバンキングもある。

Export不可属性を強制に解除するツール

 ただしここにあるようなツールを使用すると証明書のExportが不可と設定されていたとしても、Export不可属性がサイレントで変更されてしまう。その後Exportツールを使用すれば証明書がExportされてしまう。このツールは決して悪意のあるものではないが、Windowsのアーキテクチャに問題があることを示してくれている。とはいえWindows側の対策を待っている余裕は業界としてはない。

 現時点では、証明書のExport不可フラグをサイレントで解除し、Exportコマンドを実行するマルウェアはどのアンチウイルスベンダからも発表はされていない(それぞれ個別のマルウェア、ツールは存在する)が、時間の問題と思われる。

■Chromeの場合

 Chromeの場合は、IE/Windowsの証明書機能を使用しているため、原則IEと同じである。逆に言えば、IEで取得した証明書はChromeでも使用が可能となる。これは制御不可能だ。

■Safariの場合

 SafariについてはWindowsとMacで大きく異なるが、調べたところSafariに対して証明書を発行しているオンラインバンキングが見つからなかったため、詳細は割愛させていただく。

簡単に申し上げると、WindowsではFirefoxと似た動作となり、MacOSではIEと似た動作となる(ただしExport付加属性の強制は不可能である)。

 つまりPKIのセキュリティ的に頼みの綱であったIE自体が揺らぎ始めているため、上記の全銀協のICカードの配布のアナウンスにつながると思われる。また仮にWindows自体のアーキテクチャが見直されるとしても、IEのシェアを考えるといつまでも、ユーザ利便性の観点から他のブラウザを避けて通るわけにはいかないことも背景としては存在しているだろう。ICカードを利用した場合、すべてのブラウザで高度で同じセキュリティレベルに統一が可能だからだ。簡単にICカードとIE/FireFoxとの対比をまとめさせていただく。

ICカードとIE/FireFoxとの対比

※会員登録いただくと図をご覧いただけます。
会員登録はこちら(無料)

ICカードとIE/FireFoxとの対比

 物理的に盗難しなければならないICカードが、オンラインでの攻撃が可能なIE/Firefoxに比べるとかなり安全であることがお分かりになると思う。

 また第4回でまとめさせていただくが、今後銀行からICカードが付与された場合、使わないときは必ず端末から抜いておいていただきたい。それを怠ると、PCが乗っ取られた際に攻撃にあう可能性が残される。

 かなり長くなってしまったが、わかりにくいPKI認証およびその問題、対策について可能な限りまとめさせていただいたつもりである。次回はOTP認証および問題、対策についてまとめさせていただきたい。

会員限定で「読者からのコメント」が読み書きできます! 「読者からのコメント」は会員限定の機能。会員登録を行い、ログインすると読者からのコメントが読み書きできるようになります。

会員登録(無料)・ログイン

Myリストへ 印刷用ページへ

この記事をtweetする このエントリーをはてなブックマークに追加


この寄稿記事に掲載している情報は、掲載日時点での情報となります。内容は変更となる場合がございますのでご了承下さい。また、「Key Conductors」の寄稿記事及び当該記事に寄せられたコメントについては、執筆者及びコメント投稿者の責任のもと掲載されているものであり、当社が、内容の最新性、真実性、合法性、安全性、適切性、有用性等を保証するものではありません。


30007282


IT・IT製品TOP > Key Conductors > 亀田 治伸(日本セーフネット株式会社) > 【緊急寄稿】PKI認証は危険か?オンラインバンキング不正送金問題

このページの先頭へ

キーマンズネットとは
日本セーフネット CDP事業部 サービスプロバイダ営業部 部長 長年セキュリティ系の事業に従事。特に認証と暗号化を専門としている。 最近は楕円曲線暗号とSAML POSTバインディングを個人的テーマとして研究中。JIPDEC 客員研究員として企業の電子商取引の安全化にも努めている。harunobu.kameda@safenet-inc.com

ページトップへ