⽇本銀⾏⾦融研究所 情報技術研究センター 企画役補佐 井澤秀益

【講演１】

※本講演は、ヤフー株式会社Yahoo! JAPAN研究所上席研究員五味秀仁様と共同で実施した研究に基づく講演である。また、本発表に⽰されている意⾒は、発表者個⼈に属し、⽇本銀⾏やヤフー株式会社の公式⾒解を⽰すものではない。

⽇本銀⾏⾦融研究所 第17回情報セキュリティ・シンポジウム 2016年3⽉2⽇ ⽇本銀⾏本店

本講演では、次世代認証技術の⼀つである「FIDO（Fast IDentity Online）」を取り上げる（FIDOに関しては後述）。

1

利便性 ⽣体認証を利⽤することができるため、ユーザが⾃然な動作で⽣体特徴を提⽰できる（パスワードを覚える必要無し）

網羅性 様々なデバイスやサービス、認証⽅式を想定

安全性(セキュリティ)

本講演の内容

次世代認証技術の⼀つであるFIDOの特徴

本講演では、以下の3点の説明を⾏う。

− （注）本講演では、FIDOのUAF(Universal Authentication Framework)のことをFIDOと便宜的に呼び説明を⾏います。FIDOのU2F(Universal Second Factor)については解説しません。

− 詳細は下記論⽂を参照（http://www.imes.boj.or.jp/citecs/papers.html）

井澤秀益・五味秀仁、「次世代認証技術を⾦融機関が導⼊する際の留意点―FIDOを中⼼に―」、IMES Discussion Paper Series、2016年2⽉

1. FIDOの仕組みの解説

2. FIDOをインターネット・バンキングに活⽤した場合の安全性評価

3. FIDOをインターネット・バンキングに活⽤する際の留意点

2

3

FIDOとは、「ネットワークを介した認証に⽣体認証等を利⽤するための認証⼿順（認証プロトコル）を定めた仕様」

− 従来のID/パスワード認証

− FIDOにおける認証

FIDOの主な実⽤化動向

ID/パスワードID/パスワード

を⼊⼒

検証結果

⽇時 出来事2014年12⽉ FIDOの仕様が公表（FIDO UAF/U2F ver1.0 specification）[1]

2015年5⽉ NTTドコモ社の⼀部のスマートフォンで同社のサービスがFIDOを使って利⽤可能[2]

2015年9⽉ Bank of Americaのインターネット・バンキングのモバイルアプリがFIDOを使って利⽤可能 [3]

⽣体情報を提⽰

4

⾦融機関デバイス

[1] https://fidoalliance.org/specifications/download/[2] https://www.nttdocomo.co.jp/info/news_release/2015/05/26_00.html[3] http://newsroom.bankofamerica.com/press‐releases/consumer‐banking/bank‐america‐introduces‐fingerprint‐and‐touch‐id‐sign‐its‐mobile‐ban

1. プライバシー配慮 ⽣体情報等の認証に必要な秘匿すべき情報をサーバに送信・登録しない

検証結果認証

2. 多様な認証要素 ⽣体認証に限らず所有物認証等、多様な認証要素の利⽤を想定している

認証

指紋 虹彩 USBドングル

3. 標準化

銀⾏

ECサイト

SNS

様々な端末やサービスが存在する状況においても、統⼀的なプロトコル（FIDO）で認証を⾏える

FIDO

4. 取引認証 取引内容がユーザの意思に基づくものであることをサーバで確認する仕組み(Transaction Confirmation)。詳細は後述。

5

端末毎・サービス毎に初回にユーザが実施。

ユーザのAuthenticatorをサーバが登録。レガシー認証情報とFIDOにおけるユーザ情報（AAID,KeyID）とを紐付けることが可能。

− レガシー認証情報：FIDOに移⾏する前の段階で使⽤していた個⼈認証のための情報（例：ID, Password）

ユーザ Authenticator クライアント サーバ

(1) 開始要求

(2) レガシー認証要求

(3) レガシー認証情報(3) ユーザ認証

(4) Challenge等(5) Challenge等

(6) ⽣体情報要求

(6) ⽣体情報応答(7) ユーザの秘密鍵・公開鍵ペアを⽣成、ユーザの公開鍵等の情報（KRD）を⽣成しAttestation秘密鍵で署名

(8) KRD, Sign(KRD)(9) KRD, Sign(KRD)

(9) KRDの整合性検証、KRDの署名検証、ユーザ公開鍵登録、FIDOにおけるユーザ情報（AAID, KeyID）を登録

KRD(Key Registration Data) :• AAID(Authenticatorのモデル)• fc(Challenge等のハッシュ値)• KeyID(ユーザ秘密鍵等から⽣成)

• RegCounter• ユーザ公開鍵

(6) ユーザを検証

6

• Authenticator:ユーザ認証や鍵⽣成、署名⽣成等を⾏うモジュール

• Challenge:サーバで⽣成される乱数• Attestation秘密鍵：Authenticatorに格納される秘密鍵（FIDO認定取得Authenticatorに格納される）

(1)〜(3)はFIDO仕様外、実装の⼀例

サービス利⽤ごとにユーザが実施。サーバがユーザ認証や取引認証を⾏う。

ユーザ Authenticator クライアント サーバ

(1) 開始要求（振込指図） transaction

(2) Challenge, transaction(4) ⽣体情報要求

transaction等を表⽰

(4) ⽣体情報応答

(6) SD, Sign(SD) (7) SD, Sign(SD)

SD(Signed Data)：• AAID(Authenticatorのモデル)• ユーザ検証結果• fc(Challenge等のハッシュ値)• transactionのハッシュ値• KeyID(ユーザ秘密鍵等から⽣成)

• SignCounter

(3) Challenge, transaction

(4) ユーザを検証(5) transactionやユーザ検証結果等からなる情報(SD)にユーザ秘密鍵で署名

(7) SDの整合性検証、SDの署名検証、

※斜体はオプションの項⽬

振込指図⼊⼒

振込実⾏ボタン

次の振り込み内容でよろしいですか？よろしければ

⽣体を提⽰してください

Transaction:Ａさんに1万円振込

Ａさん1万円

振込先振込⾦額

次の振り込み内容でよろしいですか？よろしければ

⽣体を提⽰してください

Transaction:Ａさんに1万円振込

(1) (4) (4)

7

• Transaction：取引内容（振込先・振込⾦額等）

ユーザを検証

Transaction:Ａさんに1万円振込

署名

サーバへ

(5)

(6)

Authenticator

8

ユーザの視点

− transaction（取引内容）を⽬視確認する。

− 定められた認証⼿順（例：指紋認証）を踏むことにより、取引継続の意思を⽰す。

Authenticatorの視点

− 定められた認証⼿順（例：指紋認証）でユーザを検証出来れば、transaction（取引内容）に対して電⼦署名を付す。

電⼦署名が付された後は、マルウエアによるtransaction（取引内容）の改ざんをサーバ側で検出可能。

Authenticatorおよびユーザの秘密鍵は、通常領域とは隔離されたセキュアな領域（TEE等）に存在する前提。

Transaction Confirmationは、以下の条件を満たせば不正送⾦に対して耐性があると考えられる。

− ユーザが⽬視確認した内容とAuthenticatorが署名する内容が同⼀であること(WYSIWYS：What you see is What you sign)

− ユーザが取引継続の意思を持ったときのみ署名が⾏われること

9

（注）FIDOそのものの安全性評価ではなく、FIDOの実装をインターネット・バンキングに適⽤した場合を考えたときの安全性評価

攻撃側の前提

− 攻撃者の⽬標：不正送⾦の実⾏

防御側の前提

10

ユーザ ⾦融機関サーバインターネット

• Androidスマートフォンを使⽤• ⾦融機関の提供するスマホアプリを使⽤

• スマホ内にはTEE(Trusted Execution 

Environment)等のセキュア領域が存在しAuthenticatorを保護

• Transaction Confirmationにより取引内容を確認

⼿⼝１：フィッシング

⼿⼝２：マルウエア

⼿⼝３：⽣体認証でのなりすまし

ケースＡ：物理アクセス

ケースＢ：ネットワークアクセス

e.g.攻撃者がターゲットのスマートフォンを盗取

e.g.攻撃者がターゲットにNW越しに攻撃

攻撃者の⼿⼝（攻撃者にとって有利な前提を想定）

攻撃者のデバイスへのアクセス能⼒

• 攻撃は不可と仮定

TEEについてはこの後の「講演3」を参照

（注）FIDOそのものの安全性評価ではなく、FIDOの実装をインターネット・バンキングに適⽤した場合を考えたときの安全性評価

登録フェーズにおける評価

− 万が⼀、レガシー認証情報を攻撃者に盗取されてしまえば、攻撃者⾃⾝のデバイスで登録フェーズが実⾏可能（不正送⾦が成⽴）。→後述

認証フェーズにおける評価

⼿⼝ ケースA：物理アクセス

ケースB：ネットワークアクセス

⼿⼝１：フィッシング ── 攻撃不成⽴⼿⼝２：マルウエア

（⾮root権限＜偽アプリ＞）── 攻撃不成⽴

（root権限） ── 不正送⾦を起こす⽅法が存在する（注１）

⼿⼝３：⽣体認証なりすまし 不正送⾦を起こす⽅法が存在する（注２）

──

11

※具体的な評価の⽅法については、下記論⽂を参照。井澤秀益・五味秀仁、「次世代認証技術を⾦融機関が導⼊する際の留意点―FIDOを中⼼に―」、IMES Discussion Paper Series、2016年http://www.imes.boj.or.jp/citecs/papers.html

（注２）攻撃例：攻撃者がデバイスを盗取し、⽣体認証でのなりすましで⾃⾝への送⾦を実施（後述）。（注１）攻撃例：Display Overlay攻撃（後述）。

12

留意点：登録フェーズにおいて「レガシー認証情報」が盗取されるリスクに注意すること。

− 攻撃経路：

− FIDO⾃⾝の問題ではなく、FIDOに移⾏する前に「レガシー認証情報」を使⽤していることに起因する問題。

⾦融機関における具体的な対応例

− 顧客に対して「レガシー認証情報を正規の⾦融機関サイト以外で⼊⼒しない」旨注意喚起（フィッシング対策）

− 顧客に対して「デバイスのマルウエア対策」を注意喚起

− アプリストアに偽バンキングアプリが出現していないかどうか監視

− 普段使っていないデバイスからの登録フェーズの制限

− レガシー認証情報を使⽤しない登録フェーズの検討

⾦融機関の窓⼝における登録フェーズの実施等13

レガシー認証情報（ID,Pass）を攻撃者が盗取（⼿⼝：マルウエアやフィッシング）

盗取したレガシー認証情報を⽤いて、攻撃者は、⾃らのデバイスにて登録フェー

ズを実施

登録済デバイスで認証フェーズを実施し、不正送⾦

留意点：Transaction Confirmationの仕組みが存在するものの、マルウエア感染により、取引内容確認が無効化されるリスクがあることに注意すること。

− マルウエア（root権限）により取引内容が改ざんされた上に、取引内容確認画⾯も上書き（Display Overlay 攻撃）されれば、MitB攻撃の要領で不正送⾦が成⽴してしまう。

バンキングアプリ/

Authenticator

⾦融機関サーバユーザ

Aさんに1万円送⾦Xさんに100万円送⾦

Xさんに100万円送⾦でOK？Xさんに100万円送⾦でOK？

とのメッセージ

14本来の画⾯

Aさんに1万円送⾦でOK？とのメッセージ

マルウエアが表⽰しているメッセージ※最前⾯に表⽰

Authenticatorが表⽰しているメッセージ※背⾯にあるためユーザから⾒えない

Display Overlay攻撃（緑⾊部分）

⾦融機関における具体的な対応例

− Trusted User Interface[1]の今後の動向に留意する。

Trusted User Interfaceを備えたスマートフォンであれば、Display Overlayに対して耐性があるとされている[2]。

FIDOでは、Metadataサービスを通じて、「Authenticator毎にTrusted User Interfaceを利⽤可能か」をサーバ側で確認することが出来る仕組みがある。

− （前提とは異なるものの）別のデバイスにて取引内容を確認する。

同様のアイデアの例：電⼦ペーパによる取引内容確認 [3]（注：FIDO準拠ではない）

15

[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年9⽉19⽇https://staff.aist.go.jp/takagi.hiromitsu/paper/fsa‐20140919‐takagi‐handout.pdf

留意点：認証フェーズにおいて「⽣体認証でのなりすまし」に注意すること。

− 攻撃経路：

− クライアント側における⽣体認証でのなりすましの検知精度の問題

− FIDO AllianceによるAuthenticatorの認定はセキュリティ評価指標（FAR、APCER等）の評価認定ではないことに留意すること。

⾦融機関における具体的な対応例

− Authenticatorのセキュリティ評価指標（FAR, APCER等）がコモンクライテリア認証等、第三者によって評価されたものか調査しておくこと。

− ユーザの意図せざる取引も想定し、振込先情報・振込時刻等を利⽤した振込操作の「異常検知技術」と併⽤すること。

リスク値の算出に利⽤出来る情報の例（FIDO Metadataサービスを使って⼊⼿可能な情報）

① Authenticator毎のセキュリティ評価指標（FAR等）…ただしベンダの⾃⼰評価値

②デバイスでTrusted User Interfaceが使⽤可か否か

③デバイスでTEEやSecure Elementが使⽤可か否か

16

この後の「講演2」も参照

この後の「講演4」も参照

取得したデバイスのロックを攻撃者が解除

（⼿⼝：⽣体認証でのなりすまし）

取得デバイスで、攻撃者が、⾃らの⼝座への振込指⽰を

実施

認証フェーズにて⽣体情報提⽰を求められた時に、強制的に取引を続⾏

（⼿⼝：⽣体認証でのなりすまし）

FIDOを活⽤する動きが今後、⾦融機関やFinTech企業において活発化する可能性がある。

FIDOを利⽤したインターネット・バンキング（認証フェーズ）では、フィッシングやマルウエア（⾮root権限）による不正送⾦に対して⼀定の耐性を有している。

ただし、以下の脅威にかかるリスクは存在する。− 登録フェーズでの脅威：フィッシング、マルウエアによるレガシー認証情報盗取

− 認証フェーズでの脅威：マルウエア（root権限）、⽣体認証なりすまし

正しい使い⽅をしていれば、デバイス（スマートフォン）がマルウエア（root権限）に感染する可能性は低いと考えられる。

当該リスクへの対応は、インターネット・バンキングのサービス内容に応じて検討する必要がある。 ユーザが⾼リスクサービス（例：新規振込先への送⾦）を利⽤する場合には、振込限度額を設定することも⼀案。

インターネット・バンキングの不正送⾦⼿⼝は⽇々進化している。FIDOもver2.0策定の動きがある。このような状況の変化をフォローしつつ、インターネット・バンキングの将来像を検討することが重要。

17