【緊急寄稿】ネットバンク不正送金問題、さてOTP認証は?

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

IT現場の道先案内人 Key Conductors

【緊急寄稿】ネットバンク不正送金問題、さてOTP認証は?

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

 本寄稿は今回で第3回目となる。第1回目ではオンラインバンキングにおける業界的なOTP(ワンタイムパスワード)とPKIの使い分け。それらの認証強度の違い、PKI認証の安全性に疑義が生じている現状。第2回目は証明書を盗むことに対する技術的可能性の検討およびPKI強化策として全銀協が発表したICカードが備えるべきスペックをまとめさせていただいた。第3回目である今回はOTP認証における“認証乗っ取り”…すなわち不正な人間によるログインをまとめさせていただく予定である。

 また第2回で記載させていただいた通り、本寄稿は3回連載とし認証識別子を不正に入手し、別端末からログインを行うことに関する考察をまとめさせていただく予定であったが、皆様のコメントの中で多くご指摘をいただいた、外部からPCそのものを操作される遠隔操作攻撃、正当なユーザが正しくログインしているのに不正送金被害にあう「マンインザブラウザ」に関するOTP/PKIの認証強度の違いを急遽追加させていただき、4回連載とさせていただきたい。

 というのは、第1回目の記事を寄稿させていただいた後に、日本では被害が確認されていなかったマンインザブラウザ攻撃による実害が確認されたからだ。一部の記事では「OTPのハードウェアトークンが広まったからこその攻撃」と記載されているが、誤解を生みそうで怖い。このあたりは次回解説させていただく予定である。今回はOTPを盗むことによる外部からの不正アクセスによる被害に焦点を当てさせていただきたい。

フィッシング攻撃

 まずOTPを盗み別の端末からログインする際の主な手口は、第2回でも触れたフィッシング攻撃といわれるものだ。 OTPの特性として、一度ログインに成功したパスワードは次回使えなくなる、というものがある。このため、ユーザから生成されたOTPを盗むことができたとしても攻撃は成立せず、ユーザのログインを失敗させなければならない。これがフィッシング攻撃といわれているものである。(PKIでこの攻撃が成立しないのは第2回にまとめさせていただいたのでご参考いただきたい)

 フィッシング攻撃の手口は、まずユーザを不正なそっくりのオンラインバンキングのログイン画面に遷移させることから始まる。そこでユーザはOTPを生成する。ハードウェアトークンの場合、攻撃者は自分でOTPを生成できないからだ。ユーザは生成されたOTPを使用してログインを試みるが、当然、正しいサイトではないためログインはできていない。こうして攻撃者は正しい(なおかつ未使用の)OTPを入手し別のPCからログインすることができるのだ。

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

フィッシング対策協議会にわかりやすい例があるので転載させていただく。

 オンラインバンキングの不正送金被害におけるID/PWDとOTPの割合が統計されている正式なデータは存在していないため不明であるが、OTPによる被害のほとんどはこれだといわれている。ただしほとんどのオンラインバンキングは生成されたOTPには有効期限をつけている(長くても1分)。皆さんの中にはログインしようとしてOTPの有効期限が切れエラーとなりイライラされたご経験をお持ちの方がいるかもしれないが、これは非常に大事な仕組みなので我慢いただきたい。いずれにせよ攻撃者がリアルタイムにOTPを入手できればログインは可能となる。

乱数表によるセキュリティ

 攻撃者が別のPCから上記の方法で入手したOTPを使用してログインした場合、すぐさま不正送金が行えるわけではない。振込カード、乱数表、暗証カード(認証業界では一般的に乱数表といわれるため、以下乱数表で統一させていただく)といわれるあらかじめユーザに配布されるカードに基づき別のパスワードを入力する必要がある。

 これは別の攻撃を組み合わせる必要があるのだが、乱数表というのはOTPと異なり固定である。つまり少し複雑にした固定パスワードである。筆者が使用している三井住友銀行の乱数表は以下となっている。

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

毎回振込の度に、ランダムに指定された2ヵ所を入力する。1回分の振込の入力項目をマルウェアで不正に取得されても、不正送金被害にあう可能性は少ないが、長期間汚染されたブラウザで送金処理を続けると、攻撃者の手元ではおおよその乱数表が完成する。この時点でOTPが上記のとおり盗まれると不正送金に被害にあうこととなってしまう。法人のオンランバンキングは振込作業者と承認者を別の人にすることでこの攻撃にあう可能性を低くすることができるため、法人オンラインバンキング担当者は必ず、それぞれ別端末から振込処理と承認処理を行っていただきたい。

 ただし個人の場合は承認者を別にすることは成り立たないため、振込作業時には最初にログインしたユーザとは別の流れを作る必要が生じる。
筆者同様、ご自身の銀行振り込みの承認者が妻になると困る人は大勢いるはずである。

フィッシング攻撃のまとめ

 まとめさせていただくとフィッシング攻撃は以下の手順で成立する。

1.ブラウザをマルウェアに汚染させ、ユーザが振込の際に入力する乱数表のデータを複数回収集し、手元に乱数表を完成させる(完全に完成する必要はない。不正振込み処理時に、入力を求められる2ヵ所のデータがマッチすれば可能だ)

2.ユーザを不正なログインサイトにアクセスさせ、ログインのためのOTPを生成させ、入力させる(ユーザのログイン処理は失敗させる)。

これらの攻撃を防ぐ手法はいくつか存在する。大きく分けると以下の3つとなる.

フィッシング詐欺を防ぐ手口

1.

マルウェア汚染を防ぐ

2.

振込処理の際に、再度認証を行う

3.

ユーザが普段操作しているPCと異なるPCからの振込処理の場合、処理に制限をかける

1.マルウェア汚染を防ぐ

 複数のオンラインバンキングがマルウェア対策ツールをユーザに無償配布している。
主なベンダを以下に挙げると…

・Netmove社 nProtect
 
・Trusteer社Rapport
 
・セキュアブレイン社Phishwall
 
等は採用事例が多いようである。ただしマルウェア対策ツールはアンチウイルス同様万能ではない。ゼロデイ攻撃といわれるのだが、マルウェア対策ツールはそれをマルウェアであると認識しない限り当然だがブロックはできない。新種の攻撃手法については、設定ファイル(パターンファイル)の更新がない限りは判断がつかないケースが常にグレーゾーンとして存在しておりベンダーが別途「それはブラックである」という指令を出さない限り判断を行えないためだ。

 セキュリティには一般的にホワイトソリューションとブラックソリューションという2種類があるのだが、その間には常にグレーゾーンが存在する。ホワイトソリューションは、認証等正しいものを正しいと判断する方式、ブラック方式は、アンチウイルス等有害なものを止める方式である。これらを組み合わせなければ、グレーゾーンを排除することは難しく、今回のようにホワイトソリューションの認証が信用できない前提に立つと、マルウェア対策を強化するだけでは攻撃を完全に防ぐことは難しく、もう1つのホワイトソリューションである認証が必要となる。

2.振込処理の際に、再度認証を行う

 ではどうするか?といえば振込時に別の承認プロセスを作る必要がある。ここからは少し複雑で説明が難しいがなるべく専門用語には配慮したいのでご容赦いただきたい。Webというものは基本的に「一度ログインしたユーザは、ログアウトするまで同じユーザである。途中で誰か別のユーザに変わることはない」という大原則で成り立っている。
 簡単にいうと、一度Gmailやfacebookにログインすると、別のアカウントでログインするためには一度ログアウトしなければならない。(余談だが、GoogleAppsとChromeはこのあたりを独自に拡張しようとしており、非常にSier泣かせである。筆者もGoogleApps向け認証ソリューションの販売時には毎回動作検証時に混乱する。)

 このログイン管理には大きく2種類ある。ブラウザに長期保存されるクッキーといわれるものと、ブラウザを閉じると役に立たなくなるセッションクッキーといわれるものだ。前者は前例の通りGmailやfacebookに使用されている。一度ログインすれば、ブラウザを閉じその後ブラウザを再度起動してアクセスしてもログイン後の画面に自動ではいる。これはブラウザがクッキーといわれている情報を保持しているからだ。

 オンラインバンキングはより高いセキュリティが要求されるため、後者のセッションクッキーを使用する。これはブラウザにはごく一部の情報のみが保存されておりサーバ側に情報が保存されている。このため、ある一定時間ブラウザからのデータ送信がないとサーバ側で自動消去される仕組みとなっている。

 不正にOTPを入手し別PCからログインしたユーザを、銀行側のシステムは「正しいユーザ」とみなす。そしてそのブラウザがログアウトするまで(長期間操作をしなければ有効期間を迎え、自動でログアウトされる)は「正しいユーザ」と認識する。このため上記のとおり長期間の不正なデータ収集による乱数表のデータがあれば不正送金が成立してしまう。

■振込時にもう一度認証を

 ではどうすればいいのかというと、ブラウザとは別の領域で銀行側システムとセッションの構築を行う必要がある。ブラウザが汚染されていたら?という命題を解決するためには、ブラウザとウェブサーバでやり取りされるセッション管理自体が信用できなくなってしまうからだ。

 単純にいってしまえばOTP認証をログインに採用しているのであれば、振込時にもう一度ユーザにOTPを生成させ入力させればよい。攻撃者は正当なユーザが生成したOTPを1個入手し攻撃を行っているわけだから、2個目のOTPの入力で失敗する。仮に攻撃者が複数のOTPを同時に入手できたとしても、1分立つと使えなくなるので攻撃が成立する可能性を下げられる。非常に単純ではあるがこれだけでかなり安全になるはずだ。

 逆にいうと、すでにOTP認証基盤があるため、追加投資はかなり抑えられるはずだ。

■追加の強化策:OCRA

 それだけで不安な場合、ワンタイムパスワードにはRFCの6287で拡張プロトコルとして「OATH Challenge-Response Algorithm」(業界では頭文字をとってOCRAと呼ばれている)という振込時の電子署名の機能が備わっている。昨年三井住友銀行がこの方式を採用し業界では話題となった。

OCRA例

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

OCRA例
ただし現時点では、ユーザ利便性のバランスを考慮し、ログインのみに使用しており、振込時の処理には使用していないようだが、近いうちに振込時の処理にも利用され始めるはずだ。
■ワンタイムパスワードの方式

 OCRAについて説明をさせていただくためにまずワンタイムパスワードの規格についてまとめさせていただく。ワンタイムパスワードは日本のオンラインバンキングでは大きく2種類(RSA方式、Oath方式)が流通している。細かい独自方式はもっと存在しているが割愛させていただく。

 RSAはご存知の通り日本のワンタイムパスワード業界のトップベンダであり、1社独自プロトコルとなる。それに対してOathというのは“OpenAuthentication”の略であり、複数社による相互運用を目的としたものである。主なプレイヤーはSymantec(旧VeriSign)、Vasco、Safenet、Gemalto等が商品を提供している。Oath方式の製品は総合運用が可能であり、運用途中でのベンダ変更が容易なため、調達コストが安いという特徴もある。

■OATH:3つの方式

Oath方式は大きく3つ存在している。

時刻方式

イベント方式

チャレンジレスポンス方式

 これらの方式の違いはどうやってサーバとの同期をとっているか?が異なる。OTPは生成される値が毎回異なるのだが、どうやってサーバがその値を正しいかどうか判断できているか不思議に思ったことはないだろうか?

 実は個別のOTP生成トークンは個別の暗号データを持っている。これを“シード”と呼んでいる。サーバ側ではどのユーザIDがどの“シード”を含んだOTP生成トークンを持っているかを管理している。OTPはその“シード”に「何か」を掛け合わせて生成される。このため乱数で生成されているわけではなく、サーバはあらかじめ次回ユーザがどういうOTPを生成するかがわかっているのだ。(詳細は割愛させていただくが、これによりOTPはサーバが攻撃にあうと全ユーザが危険となるが、PKIはサーバが攻撃されても全ユーザが危険とはならない違いをもつ)

 「何か」を掛け合わせる際に、現在時刻を使用するものを(TOTP)、前回ログインしてからユーザがOTPを生成した回数を使用するものと(HOTP)、サーバが生成した乱数を使用するものを(OCRA)と呼ぶ。前述のとおりオンラインバンキングは生成されたOTPに有効期間を持たすことが可能なTOTPを使用している。

■OCRAの仕組み

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

 まずサーバが乱数を生成しそれをブラウザに表示させる。ユーザは電卓のようなトークン
でそのパスワードを入力すると(チャレンジ)、電卓型トークンに新しい別のパスワードが表示される。このパスワードをブラウザで入力する(レスポンス)のだ。こうやってブラウザとサーバが管理しているセッションとは別に、「ものを持っている」という物理的なセッションを構築することが出来るため、ブラウザ汚染からは保護されることが可能となる。

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

 この方式はひとつ大きな落とし穴がある。ブラウザが汚染されていたとしても、チャレンジのパスワードを盗まれても問題はない。攻撃者はOTP生成トークンを持っていないため、レスポンスを生成できないからだ。ただし、ユーザが入力するレスポンスが汚染されたブラウザから盗まれた場合、攻撃は成功してしまう。結局サーバ側にとっては正しいパスワードが戻ってきているからだ。当然サーバ側はパスワードを入力した人間の善悪は判断がつかない。

■OCRAトランザクション署名

 実は、OCRAにはもう1つ特殊な仕組みがある。先ほどの図におけるサーバが生成する乱数を、サーバが指定する任意の値に置き換えることが可能なのだ。

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

 この場合、ユーザが事前に入力した振込先情報などを元にチャレンジを生成すれば、レスポンスを盗まれたとしても【ユーザが指定した振込先】以外の振込が行えない。OTP認証が失敗するからだ。

 なぜなら、ユーザからレスポンスを受け取ったサーバ側は、振込処理を行う前に、再度同じアルゴリズムを元にレスポンスを再計算し、ユーザが入力したものと付け合せる。途中で不正なプログラムが勝手に振込先を書き換えた場合、計算結果が合わないからだ。

 これがOCRAの仕組みである。この方式は第4回でまとめさせていただく予定である「マンインザブラウザ攻撃(振込時に振込先を書き換え、別の口座に振り込みを行う)」にも同時に対応可能となるため、今後のOTP認証強化策としてはかなり中心に位置づけられると考えられる。

3.普段操作しているPCとは異なるPCからの振込処理の場合、処理に制限をかける

 こちらの方式は現在有望なものは見つかっていない。端末の固定を行うPKI認証を組み合わる例もあるが、OTPとPKIを同時に実装するオンランバンキングはユーザには利便性が悪すぎるように思われる。

 また、PCのプロファイル情報をプログラムで集めてサーバに送っておくことで、普段と異なる端末からの振込操作を禁止するなり、金額制限をかけるなりの手法も存在するが、PCのプロファイルを集める手法はマルウェアと酷似するため、それらのツールとの相性が悪い。

■2経路認証

 このようにどれも決め手に欠けるのだが、上記のOCRAと同様にPCそのもので処理を完結させること自体がもう限界にきているという観点に立つべきであると筆者は考える。

 海外のクレジット決済では一部事例がみられるのだが、振込処理をすると携帯にメールが送られてくる。メールの中には振込先、金額、OKボタンが記載されており、OKボタンを押した時点で振込が完了する。これを“2経路認証”というが、今後こういうPC以外を組み合わせた手法も出てくるはずである。

 今回は前回よりさらに長くなってしまった。本当はもっといっぱい記載すべきこともあり、題材の重たさに対して4回連載は少なかったと後悔している。いずれにせよ、あと1回でありおつきあいいただければ幸いである。

最後に

少しでもオンラインバンキングを安全に利用するために以下を徹底いただければ幸いだ。

(法人であれば)、専用端末をご準備いだきたい。

ICカードが配布された場合は、必ず使用しないときは抜いておいてほしい。

ブラウザに証明書を格納するときは、複雑な証明書パスワード/PINの設定をお願いしたい。

仮想環境は避けてほしい。

ワンタイムパスワード生成トークンを財布に入れずに、別に持ち歩いていただきたい。

 日本のオンラインバンキングはとてもユーザに真摯であり優しい。しかしながら筆者は上記が実施されていないユーザが不正送金被害にあった場合、ユーザも悪い、といわれる日が来るかもしれないことも合わせて申し上げさせていただきたい。

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

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

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

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


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


30007289


IT・IT製品TOP > Key Conductors > 亀田 治伸(日本セーフネット株式会社) > 【緊急寄稿】ネットバンク不正送金問題、さてOTP認証は?

このページの先頭へ

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

ページトップへ