本講演では 以下の 3 点の説明を う 1. FIDO の仕組みの解説 2. FIDO をインターネット バンキングに活 した場合の安全性評価 3. FIDO をインターネット バンキングに活 する際の留意点 ( 注 ) 本講演では FIDO の UAF(Universal Authenticati

Transcription

1 講演 1 本銀 融研究所情報技術研究センター企画役補佐井澤秀益 本講演は ヤフー株式会社 Yahoo! JAPAN 研究所上席研究員五味秀仁様と共同で実施した研究に基づく講演である また 本発表に されている意 は 発表者個 に属し 本銀 やヤフー株式会社の公式 解を すものではない 本銀 融研究所第 17 回情報セキュリティ シンポジウム 2016 年 3 2 本銀 本店 本講演では 次世代認証技術の つである FIDO(Fast IDentity Online) を取り上げる (FIDO に関しては後述 ) 利便性 網羅性 次世代認証技術の つである FIDO の特徴 体認証を利 することができるため ユーザが 然な動作で 体特徴を提 できる ( パスワードを覚える必要無し ) 様々なデバイスやサービス 認証 式を想定 安全性 ( セキュリティ ) 本講演の内容 1

2 本講演では 以下の 3 点の説明を う 1. FIDO の仕組みの解説 2. FIDO をインターネット バンキングに活 した場合の安全性評価 3. FIDO をインターネット バンキングに活 する際の留意点 ( 注 ) 本講演では FIDO の UAF(Universal Authentication Framework) のことを FIDO と便宜的に呼び説明を います FIDO の U2F(Universal Second Factor) については解説しません 詳細は下記論 を参照 ( 井澤秀益 五味秀仁 次世代認証技術を 融機関が導 する際の留意点 FIDO を中 に IMES Discussion Paper Series 2016 年 2 2 3

3 FIDO とは ネットワークを介した認証に 体認証等を利 するための認証 順 ( 認証プロトコル ) を定めた仕様 従来の ID/ パスワード認証 FIDO における認証 ID/ パスワードを 体情報を提 デバイス ID/ パスワード 検証結果 融機関 FIDO の主な実 化動向 時 出来事 2014 年 12 FIDO の仕様が公表 (FIDO UAF/U2F ver1.0 specification)[1] 2015 年 5 NTT ドコモ社の 部のスマートフォンで同社のサービスがFIDOを使って利 可能 [2] 2015 年 9 Bank of Americaのインターネット バンキングのモバイルアプリが FIDOを使って利 可能 [3] [1] [2] [3] releases/consumer banking/bank america introduces fingerprint and touch id sign its mobile ban 4 1. プライバシー配慮 体情報等の認証に必要な秘匿すべき情報をサーバに送信 登録しない検証結果認証 2. 多様な認証要素 体認証に限らず所有物認証等 多様な認証要素の利 を想定している 認証 指紋虹彩 USB ドングル 3. 標準化 様々な端末やサービスが存在する状況においても 統 的なプロトコル (FIDO) で認証を える EC サイト FIDO 銀 SNS 4. 取引認証 取引内容がユーザの意思に基づくものであることをサーバで確認する仕組み (Transaction Confirmation) 詳細は後述 5

4 Authenticator: ユーザ認証や鍵 成 署名 成等を うモジュール Challenge: サーバで 成される乱数 Attestation 秘密鍵 :Authenticator に格納される秘密鍵 (FIDO 認定取得 Authenticator に格納される ) 端末毎 サービス毎に初回にユーザが実施 ユーザの Authenticator をサーバが登録 レガシー認証情報と FIDO におけるユーザ情報 (AAID,KeyID) とを紐付けることが可能 レガシー認証情報 :FIDO に移 する前の段階で使 していた個 認証のための情報 ( 例 :ID, Password) ユーザ Authenticator クライアントサーバ (1) 開始要求 (2) レガシー認証要求 (1) (3) は FIDO 仕様外 実装の 例 (6) 体情報要求 (3) レガシー認証情報 (5) Challenge 等 (4) Challenge 等 (3) ユーザ認証 (6) 体情報応答 KRD(Key Registration Data) : AAID(Authenticator のモデル ) fc(challenge 等のハッシュ値 ) KeyID( ユーザ秘密鍵等から 成 ) RegCounter ユーザ公開鍵 (6) ユーザを検証 (7) ユーザの秘密鍵 公開鍵ペアを 成 ユーザの公開鍵等の情報 (KRD) を 成し Attestation 秘密鍵で署名 (8) KRD, Sign(KRD) (9) KRD, Sign(KRD) (9) KRDの整合性検証 KRDの署名検証 ユーザ公開鍵登録 FIDOにおけるユーザ情報 (AAID, KeyID) を登録 6 Transaction: 取引内容 ( 振込先 振込 額等 ) サービス利 ごとにユーザが実施 サーバがユーザ認証や取引認証を う ユーザ Authenticator クライアントサーバ (1) 開始要求 ( 振込指図 ) transaction (4) 体情報要求 transaction 等を表 (3) Challenge, transaction (2) Challenge, transaction 斜体はオプションの項 (4) 体情報応答 SD(Signed Data): AAID(Authenticator のモデル ) ユーザ検証結果 fc(challenge 等のハッシュ値 ) transaction のハッシュ値 KeyID( ユーザ秘密鍵等から 成 ) SignCounter 振込指図 振込実 ボタン (4) ユーザを検証 (5) transactionやユーザ検証結果等からなる情報 (SD) にユーザ秘密鍵で署名 (1) (4) (4) 振込先振込 額 A さん 1 万円 (6) SD, Sign(SD) (7) SD, Sign(SD) 次の振り込み内容でよろしいですか? よろしければ 体を提 してください Transaction: A さんに 1 万円振込 次の振り込み内容でよろしいですか? よろしければ 体を提 してください Transaction: A さんに 1 万円振込 (5) (7) SD の整合性検証 SD の署名検証 Authenticator ユーザを検証 署名 Transaction: Aさんに1 万円振込 (6) サーバへ 7

5 ユーザの視点 transaction( 取引内容 ) を 視確認する 定められた認証 順 ( 例 : 指紋認証 ) を踏むことにより 取引継続の意思を す Authenticator の視点 定められた認証 順 ( 例 : 指紋認証 ) でユーザを検証出来れば transaction( 取引内容 ) に対して電 署名を付す 電 署名が付された後は マルウエアによる transaction( 取引内容 ) の改ざんをサーバ側で検出可能 Authenticator およびユーザの秘密鍵は 通常領域とは隔離されたセキュアな領域 (TEE 等 ) に存在する前提 Transaction Confirmation は 以下の条件を満たせば不正送 に対して耐性があると考えられる ユーザが 視確認した内容と Authenticator が署名する内容が同 であること (WYSIWYS:What you see is What you sign) ユーザが取引継続の意思を持ったときのみ署名が われること 8 ( 注 )FIDO そのものの安全性評価ではなく FIDO の実装をインターネット バンキングに適 した場合を考えたときの安全性評価 9

6 ( 注 )FIDO そのものの安全性評価ではなく FIDO の実装をインターネット バンキングに適 した場合を考えたときの安全性評価 攻撃側の前提 攻撃者の 標 : 不正送 の実 1: フィッシング 2: マルウエア 3: 体認証でのなりすまし 攻撃者の ( 攻撃者にとって有利な前提を想定 ) ケース A: 物理アクセス e.g. 攻撃者がターゲットのスマートフォンを盗取 ケース B: ネットワークアクセス e.g. 攻撃者がターゲットに NW 越しに攻撃 攻撃者のデバイスへのアクセス能 防御側の前提 Androidスマートフォンを使 融機関の提供するスマホアプリを使 スマホ内にはTEE(Trusted Execution Environment) 等のセキュア領域が存在しAuthenticatorを保護 Transaction Confirmationにより取引内容を確認 ユーザインターネット 融機関サーバ 攻撃は不可と仮定 TEEについてはこの後の 講演 3 を参照 10 登録フェーズにおける評価 万が レガシー認証情報を攻撃者に盗取されてしまえば 攻撃者 のデバイスで登録フェーズが実 可能 ( 不正送 が成 ) 後述 認証フェーズにおける評価 ケース A: 物理アクセス ケース B: ネットワークアクセス 1: フィッシング 攻撃不成 2: マルウエア ( root 権限 < 偽アプリ >) 攻撃不成 (root 権限 ) 不正送 を起こす 法が 存在する ( 注 1) 3: 体認証なりすまし 不正送 を起こす 法が存在する ( 注 2) ( 注 1) 攻撃例 :Display Overlay 攻撃 ( 後述 ) ( 注 2) 攻撃例 : 攻撃者がデバイスを盗取し 体認証でのなりすましで への送 を実施 ( 後述 ) 具体的な評価の 法については 下記論 を参照 井澤秀益 五味秀仁 次世代認証技術を 融機関が導 する際の留意点 FIDO を中 に IMES Discussion Paper Series 2016 年 11

7 12 留意点 : 登録フェーズにおいて レガシー認証情報 が盗取されるリスクに注意すること 攻撃経路 : レガシー認証情報 (ID,Pass) を攻撃者が盗取 ( : マルウエアやフィッシング ) FIDO の問題ではなく FIDO に移 する前に レガシー認証情報 を使 していることに起因する問題 融機関における具体的な対応例 顧客に対して レガシー認証情報を正規の 融機関サイト以外で しない 旨注意喚起 ( フィッシング対策 ) 顧客に対して デバイスのマルウエア対策 を注意喚起 アプリストアに偽バンキングアプリが出現していないかどうか監視 普段使っていないデバイスからの登録フェーズの制限 レガシー認証情報を使 しない登録フェーズの検討 融機関の窓 における登録フェーズの実施等 盗取したレガシー認証情報を いて 攻撃者は らのデバイスにて登録フェーズを実施 登録済デバイスで認証フェーズを実施し 不正送 13

8 留意点 :Transaction Confirmation の仕組みが存在するものの マルウエア感染により 取引内容確認が無効化されるリスクがあることに注意すること マルウエア (root 権限 ) により取引内容が改ざんされた上に 取引内容確認画 も上書き (Display Overlay 攻撃 ) されれば MitB 攻撃の要領で不正送 が成 して しまう ユーザ バンキングアプリ / Authenticator 融機関サーバ A さんに 1 万円送 X さんに 100 万円送 Authenticator が表 しているメッセージ 背 にあるためユーザから えない X さんに 100 万円送 で OK? とのメッセージ A さんに 1 万円送 で OK? とのメッセージ X さんに 100 万円送 で OK? マルウエアが表 しているメッセージ 最前 に表 本来の画 Display Overlay 攻撃 ( 緑 部分 ) 14 融機関における具体的な対応例 Trusted User Interface[1] の今後の動向に留意する Trusted User Interface を備えたスマートフォンであれば Display Overlay に対して耐性があるとされている [2] FIDO では Metadata サービスを通じて Authenticator 毎に Trusted User Interface を利 可能か をサーバ側で確認することが出来る仕組みがある ( 前提とは異なるものの ) 別のデバイスにて取引内容を確認する 同様のアイデアの例 : 電 ペーパによる取引内容確認 [3]( 注 :FIDO 準拠ではない ) [1] GlobalPlatform, GlobalPlatform Device Technology Trusted User Interface API Version1.0, GlobalPlatform Device Specifications, 2013 [2] Rob Coombs, Securing the Future of Authentication with ARM TrustZone based Trusted Execution Environment and Fast Identity Online (FIDO), ARM White Paper, 2015 [3] 浩光 インターネットバンキング不正送 被害の根本的対策と監督当局の関わり 融庁 曜ランチョン 2014 年 takagi handout.pdf 15

9 留意点 : 認証フェーズにおいて 体認証でのなりすまし に注意すること 攻撃経路 : 取得したデバイスのロックを攻撃者が解除 ( : 体認証でのなりすまし ) 取得デバイスで 攻撃者が らの 座への振込指 を実施 認証フェーズにて 体情報提 を求められた時に 強制的に取引を続 ( : 体認証でのなりすまし ) クライアント側における 体認証でのなりすましの検知精度の問題 FIDO Alliance による Authenticator の認定はセキュリティ評価指標 (FAR APCER 等 ) の評価認定ではないことに留意すること 融機関における具体的な対応例 Authenticatorのセキュリティ評価指標 (FAR, APCER 等 ) がコモンクライテリア認証等 第三者によって評価されたものか調査しておくこと この後の 講演 2 も参照 ユーザの意図せざる取引も想定し 振込先情報 振込時刻等を利 した振込操作の 異常検知技術 と併 すること この後の 講演 4 も参照 リスク値の算出に利 出来る情報の例 (FIDO Metadataサービスを使って 可能な情報 ) 1 Authenticator 毎のセキュリティ評価指標 (FAR 等 ) ただしベンダの 評価値 2 デバイスで Trusted User Interface が使 可か否か 3 デバイスで TEE や Secure Element が使 可か否か 16 FIDO を活 する動きが今後 融機関や FinTech 企業において活発化する可能性がある FIDO を利 したインターネット バンキング ( 認証フェーズ ) では フィッシングやマルウエア ( root 権限 ) による不正送 に対して 定の耐性を有している ただし 以下の脅威にかかるリスクは存在する 登録フェーズでの脅威 : フィッシング マルウエアによるレガシー認証情報盗取 認証フェーズでの脅威 : マルウエア (root 権限 ) 体認証なりすまし 正しい使い をしていれば デバイス ( スマートフォン ) がマルウエア (root 権限 ) に感染する可能性は低いと考えられる 当該リスクへの対応は インターネット バンキングのサービス内容に応じて検討する必要がある ユーザが リスクサービス ( 例 : 新規振込先への送 ) を利 する場合には 振込限度額を設定することも 案 インターネット バンキングの不正送 は 々進化している FIDO も ver2.0 策定の動きがある このような状況の変化をフォローしつつ インターネット バンキングの将来像を検討することが重要 17