講演資料 - 日本銀行金融研究所

第15回情報セキュリティ・シンポジウム
2014年3月5日(水)
1
講演2
多要素認証の1要素である
パスワードの安全な管理方法:
パスワードリスト攻撃を踏まえて
日本銀行金融研究所
情報技術研究センター
鈴木雅貴


本発表は、産業技術総合研究所の古原和邦氏との共同研究の成果に基づく。
本発表に示されている意見は、発表者個人に属し、日本銀行や産業技術総合研究所の公式見解を示すものではない。
2
発表の概要
国内では、2012年以降、インターネット・バンキングの不正取引(Man-in-theBrowser攻撃)が増加傾向にあり、取引時に、従来の単なる2要素認証では
なく、取引内容を確認する「取引認証」の導入が求められる。
他方、昨今、銀行やECサイト等で使い回しているパスワードの漏洩に起因す
る不正ログイン(パスワードリスト攻撃)が大規模に発生している[1]。不正ログ
インによる個人情報(残高、住所等)の漏洩等への対策も課題となっている。
パスワードの使い回しの原因は、複雑なパスワードをサービス毎に設定・記憶
する負担にユーザが耐えられないためであると考えられる。①ログインの2要
素認証化や、②シングルサインオンによるユーザのパスワード管理負担の軽
減等の対策が知られているが、いずれもサービス側のシステム修正等が必要
であり、直ぐに利用できるとは限らない。
一部のユーザは、パスワード管理ツールを利用しているが、こうしたツールに
求められる安全性に関する議論はあまりない。そこで、①8文字程度の短いパ
スワードを用いた場合の情報漏洩リスク(オフライン攻撃)や、②パスワード管
理を代行するサーバからの情報漏洩リスク(不正な管理者等)を取り上げ、こ
れらに対して安全なパスワード管理方法を議論する。
[1] 日経新聞電子版、「不正ログイン被害68万件 使い回しパスワード標的」、2014年2月24日
3
パスワード管理に関するユーザの実態
■アンケート結果
1ユーザが利用するWebサイトのうち、
パスワード認証※を行うサイトの数
トレンドマイクロ[2]
シマンテック[3]
平均14
1~4個:26%
5~9個:29%
10個~:33%
把握せず:11%
※ IDとパスワードのみを利用する
本人確認の方法
0個: 6%
1~3個:64%
自分が記憶できるパスワードの数
3個以下のパスワードの使い回し
7割
6割
銀行、ECサイト、ゲーム等において、パスワードを使い回していたユーザ
を対象とした不正ログインが、2013年に約68万件発生[1]
利用者へ「パスワードの使い回し防止」を呼び掛けても、
パスワードの使い回しは無くならないのが実情。
呼び掛けから一歩踏み込んだ対応が必要ではないか。
[1] 日経新聞電子版、「不正ログイン被害68万件 使い回しパスワード標的」、2014年2月24日
[2] トレンドマイクロ、「Webサイトのパスワード利用実態調査」、2012年
[3] シマンテック、「個人・企業のパスワード管理」に関する意識調査結果のご報告、2013年
4
パスワード漏洩の原因
PWAに関する情報
例:Hash(PWA)
全数探索
辞書攻撃等
攻撃者
PWA
ウ
イ
ル
ス
、
①ユーザ フ
ィ
から漏洩 ッ
シ
ン
グ
不
正
ア
ク
セ
ス
等
サービスA
PWA使用
PWAの使い回し
なりすまし
(パスワード
リスト攻撃)
PWB使用
ユーザ
PWB
②他のサービス
から漏洩
サービスB
パスワードは、サービス提供者の管理範囲外で漏洩するリスクがある
①ユーザから(ウイルス、フィッシング)
②他のサービスから(パスワードの使い回し)。
パスワード漏洩を前提とすると、パスワード以外の認証要素(所持物、
生体情報)を併用する「2要素認証(多要素認証)」が根本的な対策
5
2要素認証を行えば、PWは使い回してよいか?
OTP:One-Time Password
■インターネット・バンキング
ケース1
ケース2
ログイン
ID, PW
(パスワード認証)
ID, PW, OTP/乱数表
(2要素認証)
取引
OTP/乱数表
OTP/乱数表
パスワード
使い回しの
影響
不正ログインされ、残
高や住所等の個人情
報が漏洩するリスク
不正ログインは防止可能。た
だし、安全性は、2要素認証
から1要素認証に低下。
■外部サービス(電子メール等)との連携
ログインや入金/支払の際に、電子メールで通知するサービス等がある。
不正検知や利便性向上の観点から有用であるが、外部サービスの中には、
パスワード認証のものが多く存在。
インターネット・バンキングで2要素認証を導入していたとしても、
パスワード管理に関する議論は引き続き必要。
論点1:パスワードの漏洩リスクを抑える対策
論点2:パスワードの漏洩による影響の局所化
6
論点1:パスワードの漏洩リスクを抑える対策
攻撃者
全数探索
PWAに関
辞書攻撃等
する情報
例:Hash(PWA)
不
正
ア
ク
セ
ス
対
策
PWA
ウ
イ
ル
ス
、
フ
ィ
ッ
シ
ン
グ
不
正
ア
ク
セ
ス
等
サービスA
 登録時に脆弱なパスワードを排除
 ハッシュ時に、Saltやストレッチングの利用
例:Hashn(Salt, PWA)
PWA使用
【脅威:ウイルス】
 ウイルス対策ソフト
 OS等のセキュリティパッチ
【脅威:フィッシング】
 フィッシング対策ツール(URLのチェック)
 パスワード管理ツールによるパスワード
自動入力
上記対策の実施には、ユーザの協力が不可欠
ユーザ
7
論点2:パスワードの漏洩による影響の局所化
パスワードの使い回し防止
(影響の局所化)
トレードオフ
パスワード管理コスト(記憶する
パスワードの数)の増加
■非技術的な解消方法
 パスワードを紙に書き出し、この紙を安全に保管
 不正ログインによる影響の大きいサービスでのみ、個別パスワードを使用[4]
■技術的な解消方法
シングル
サインオン
(Single
Sign-On)
パスワード
管理ツール
利点
欠点/リスク
 ユーザのパスワード管理負
荷の軽減
 各サービスは、ユーザの認
証情報を管理しなくて良い
 SSOへの不正ログイン
 サービス側の対応が必要
 ユーザが利用したい全てのサービ
スが1つのSSOで利用できない場
合、複数のパスワード管理が必要
 記憶するのは、マスター
パスワード1つのみ
 サービス側の対応不要
 ツールの安全性
 ツールが乗っ取られるリスク
サービス側の対応に関係なく利用できる「パスワード管理技術」を取り上げる。
安全性に関する議論は、あまり見かけないことから、「安全性」に焦点を当てる。
[4] 西本逸郎、「「賢い」情報管理で安全と便利を両立」、日経新聞電子版、 2013年3月4日
8
想定するパスワード管理方式と脅威
9
典型的なパスワード管理方式の形態
ID
PW
URL
ID1
PW1
URL1
…
…
…
IDi
PWi
URLi
DB:各サービス用パスワードを記録したDB
eDB:何らかの方法で暗号化されたDB
IDM, PWM:パスワード管理用の
マスターIDとマスターパスワード
IDi, PWi:サービスiのIDとパスワード
■DBの暗号化(eDB):マスターパスワードPWMを鍵として利用
■ ローカル管理型
(eDBをユーザの端末で保管)
端末
eDB
 例:パスワードを記録したTextファイル(DB)を
マスターパスワードPWMで保護する方法[5]等
 ローカル管理型の一部製品が、DBを暗号化し
ていないとの指摘[6]
■ サーバ管理型
(eDBをサーバで保管)
PMサーバ
eDB
IDM, PWMでログイン
マルチ
デバイス対応
PM:Password Manage
[5] IPA、「全てのインターネットサービスで異なるパスワードを!」、2013年
[6] A.Belenko and D.Sklyarov, “Secure Password Managers” and “Military-Grade Encryption” on Smartphones: Oh, Really?”,
Blackhat Europe, 2012.
10
典型的なパスワード管理方式のリスク
[5] NTT, 「公開鍵暗号の安全性の根拠
である「素因数分解問題」で世界記録を
更新」、2010年
■eDBの復号
eDB
PWM’
復号
DB’
判定
(フォーマット等
の検査)
DB復号 成功/失敗
正しいPWMの場合のみ、
DBを復号可能
攻撃者がeDBを入手した場合、マスターパスワードの全ての候補を
試せば、理論的にはDBを復号可能(オフライン攻撃)
英数字(62種)の1文字の情報量 = 約6 bit (ランダムに選択する場合)
英数字8文字パスワードの情報量 = 約48 bit
学会では、60bitの全数探索可能であることが実証済み[5]
⇒8文字程度の「短いパスワード」は、オフライン攻撃が現実的な脅威
■「短いパスワード」を想定した場合のリスク
eDBの漏洩
(サーバ or 端末から情報漏洩)
PWMの漏洩
(フィッシング or PW使い回し)
ローカル管理型
サーバ管理型
オフライン攻撃によるDB漏洩のリスク
PMサーバへの
不正ログイン(DB漏洩)
11
想定するパスワード管理方式
■ ハイブリッド管理型
DBを復号するための情報をPMサーバとPMクライアント(端末)で分散管理
ユーザは短いPWPMのみを記憶
(PW管理負担の軽減)
PMサーバ
インターネット
IDM, PWM
ユーザ
PMクライアント
(ユーザ所有の端末)
※ 共有端末は想定しない
端末内データの破損、または、PWMの忘却
に対しても、DB復旧可能(復旧機能)
PM:Password Manage
サービスiは、修正不要。
サービスiにおける本人確認方法
(2要素認証、パスワード認証等)
は、サービスiに依存。
IDi / PWi
インターネットの
サービスi
 ユーザの端末内でDBを復号
 複数台の端末で利用可能
(マルチデバイス対応)
12
検討対象とするパスワード管理方式の処理
PMサーバ
ストレージ
処理1:
DBの暗号化・復号
処理2:
PMサーバと端末
の暗号通信
×
処理3:端末の追加
(マルチデバイス対応)
ストレージ
ユーザ
IDM, PWM
×
ID
PW
URL
IDi
PWi
URLi
端末1
処理5:
マスターパスワードPWMの忘却時のDB復旧方法
端末2
処理4:
端末内データの破損時
のDB復旧方法
13
想定する脅威と安全性要件
【脅威:不正な管理者等
(含:PMサーバからの情報漏洩】
 PMサーバ(の管理者等)に対して、
DBやPWMを秘匿
【脅威:フィッシング、PW使い回し】
 PWMが漏洩していても、DBが
漏洩しない
IDM, PWM
PMサーバ
端末
IDi / PWi
サービスi
ユーザ
【脅威:端末の紛失】
 端末から漏洩した情報から、DBや
PWMが漏洩しない
【脅威:復旧機能の悪用】
 復旧機能の悪用から、DBやPWM
が漏洩しない
端末のウイルス感染は想定しない。
ウイルス感染した場合は、パスワード
管理技術を利用しなくてもパスワード漏
洩のリスクがあり、別途対策が必要。
14
各処理の実現方法の安全性評価
15
登録(暗号化)
処理1:DBの暗号化・復号
利用(復号)
DBの暗号化(eDB):ランダムに生成した暗号鍵K(128 bit以上)を使用
■ 単純分散方式
(暗号文eDBと鍵Kを分散保管)
■ 鍵分散方式
(鍵Kも暗号化し、分散保管)
PMサーバ
PMサーバ
eDB
eDB
eDB, eKS
eDB
eDB
eKS
eKS
eDB
端末
暗号化
DB
K
端末
復号
DB
暗号化
K
DB 秘密分散
eKC
K
復号
秘密分散
DB
DB
(上記方式の拡張)
 上記方式は、マスターパスワードPWMを未使用だが、鍵Kの暗号化にPWMを利用可能。
 ただし、忘却等によりPWMが利用不可の場合、正規ユーザであってもDB復号困難(①
オフライン攻撃と同等の処理によりDBを復号する、②PWM復旧手段を用意する必要)
16
補足:秘密分散
秘密分散
「秘密情報(暗号鍵)」を複数の情報(「シェア」)に分割する暗号化方法
分割
(暗号化)
3
秘密情報
(K) 10
7
K ← eKS + eKC
シェア1
(eKS)
復号
シェア2
(eKC)
例:秘密情報「10」を2つ、または、3つのシェアに分割
秘密情報
分割
10
10
分割
シェア
3
秘密情報
分割
10
シェア
3
7
8
12
-1
-2
※ 「3」と「8」が漏洩しても、「10」は求められない。
(情報理論的に安全)
17
処理1:DBの暗号化方式の安全性
単純分散方式
鍵分散方式
PMサーバ
PMサーバ
eDB
①
端末
端末
K
①PMサーバ
から情報漏洩
②端末から
情報漏洩
③端末から
漏洩した情報
の無効化
eDB, eKS
②③
eKC
DBを求めることは、計算量的に困難
eDBが漏洩しておらず、DBは安全
各シェア(eKS, eKC)の更新により無効化
新たに生成した鍵K’で
可能。鍵Kは情報理論的に安全のため、
DBを暗号化し直す必要。
DBを暗号化し直す必要はない。
18
処理2:PMサーバと端末の暗号通信
暗号通信に必要な処理:「暗号通信用の鍵の共有」、「相互認証」
■ PKI(SSL暗号通信)+パスワード認証 ■ LR-AKE[7]
PMサーバ
Hash
PWM
公開鍵ペア,
Hash(PWM)
SSL鍵共有
Leakage-Resilient Authenticated Key Exchange
OK/NG
本人
確認
PWM
(乱数SCとPWMを用いた2要素認証)
PMサーバ
OK/NG
鍵共有
本人認証
SS
端末
端末
登録情報
生成
乱数SC
OK/NG
鍵共有
サーバ認証
登録
利用
PWM
PWM
[7] S.Shin, K.Kobara, H.Imai, “Secure PAKE/LR-AKE Protocols against Key-Compromise Impersonation Attacks”, SITA 2008.
19
処理2:PMサーバと端末の暗号通信の安全性
LR-AKE
PKI+パスワード認証
PMサーバ
PMサーバ
公開鍵ペア,
Hash(PWM)
端末
OK/NG
①PMサーバ
から情報漏洩
②端末
から情報漏洩
Hash(PWM)に対するオフライン
攻撃によりPWM漏洩のリスク
①
②
SS
端末
乱数SC
計算量的にPWMは安全
SCにはPWMの情報は含
まれない
20
情報漏洩に耐性のあるパスワード管理方式の例[8]
DBの復号手順:処理1(鍵分散方式)と処理2(LR-AKE)の組合せの場合
PMサーバ
鍵共有
本人認証
LR-AKE
SS
SS, eKS, eDB
暗号
通信路
暗号通信路の確立
eKS
鍵共有
サーバ認証
ユーザ
PWM
特徴 



SC
eKC
SC, eKC
秘密分散
PWM
eDB
K
端末
復号
鍵分散
方式 DB
端末内でDBを復号
PMサーバ、または、端末から情報が漏洩しても、DBやPWMが漏洩しない。
端末から漏洩した情報(SC, eKC)を無効化可能。
PWMが漏洩しても、DBは安全。
[8] S.Shin, K.Kobara, H.Imai, “A Secure Public Cloud Storage System”, IEEE ITST, 2011.
21
処理3:端末の追加(マルチデバイス対応)
■ハイブリッド管理型における新しい端末(端末2)の追加
■ 端末2の追加前
■ 端末2の追加後
PMサーバ
PMサーバ
S1S, eK1S, eDB
S1S, eK1S, eDB
S2S, eK2S
端末1
端末1
S1C, eK1C
端末2
S2C, eK2C
S1C, eK1C
(追加手順の方針)
eK2S, eK2CとeDBの関係
 端末1を信頼の根拠として、端末2に関する
端末1
PMサーバ用と端末用のデータ「S2S, S2C,
eK2S, eK2C」を端末1が生成。
K
秘密分散
 端末1からPMサーバに「S2S, eK2S」を渡す。 eK1S, eK1C
 次に、端末2に「S2C, eK2C」を格納する。その
秘密分散
際、PMサーバにeK2Cが漏洩すると、「eK2S, eK2S, eK2C
K
eK2C, eDB」からDBが漏洩する点に注意。
端末2
eDB
復号
DB
22
処理3:端末の追加(マルチデバイス対応)
端末2に「S2C, eK2C」を安全に格納する方法
■ 安全なローカル通信路の利用
端末1
■ PMサーバ経由の通信路の利用
端末2
PMサーバ
S2C, eK2C
Bluetooth接続
USB接続
USBメモリ
QRコード/カメラ
家庭内LAN等
S2C, eK2C
S2C, eK2C
ユーザ
端末1
暗号化
S2C, eK2C
OTP
端末2
復号
S2C, eK2C
(OTPの入力方法)
 QRコード/カメラ
 目視/手入力(英数21文字あれば、OTPの情報量が128 bit
程度になる)
23
処理4, 5:端末内データ、マスターパスワードの復旧
PWM
PMサーバ
ユーザ
秘密分散
SS, eKS, eDB
PWM
PW端末, PW外部メモリ
S2C, eK2C
処理5:マスターパスワードの復旧
 PWMの復旧に必要な情報を端末と
外部メモリに格納。DBの暗号化に
PWMを用いない場合には、マスター
パスワードの再設定も可能。ただし、
再設定の手続きを悪用されるリスク
への対応が必要
暗号化
端末
SC, eKC
復号
公開鍵PK端末
PW端末
秘密分散
処理4:端末内データの復旧
 端末内データの復旧に必要な情報をPMサーバと外部メモリ
に分散して格納。もっとも、複数台の端末を追加している場
合には、1台でも利用可能であればDB復号可能。
外部メモリ
秘密鍵SK端末
PW外部メモリ
24
考察
25
考察:パスワード管理ツールの利用上の留意点等
■パスワード管理ツールを利用する際に、留意すべき項目
 PMサーバや端末から漏洩した情報に対するオフライン攻撃によるDB漏洩
 不正な管理者等によるDB漏洩
 端末内データやマスターパスワードの復旧機能の悪用によるDB漏洩
 実装ミス等によるDB漏洩
 上記の各項目への耐性が客観的に評価されているか。
 ユーザが正規ツールを入手できる枠組みがあるか。
■ユーザにパスワード管理の意識を持たせるアイデア
不正ログイン試行
ID1, PW0
攻撃者
正規ログイン
ID1, PW1
ユーザ
ID1
前回ログイン以降の
「ログイン失敗回数」
自分のアカウントに不正ログインの試行が
サービス あったか否かがユーザにはわからない。
× 失敗
前回ログイン時刻
○ 成功
「ログイン失敗回数」の通知により、自分の
アカウントが狙われていることを意識する
きっかけになると期待される(製品も存在)。
26
考察:アグリゲーション・サービスからの情報漏洩対策
アグリゲーション(アカウント情報集約)サービス
①IDM, PWM
ユーザ 端末
Aggサーバ
⑥残高等のまとめ情報
DB(Aggサーバが管理)
サービス1
ID1, PW1
サービス2
ID2, PW2, 乱数表2
②ID1, PW1
ユーザに代わって
ログイン
③残高、履歴等
サービス1
④ID2, PW2、乱数表2
⑤残高、履歴等
サービス2
Aggサーバに預けた情報で、残高照会だけでなく、取引も可能な場合、Agg
サーバからの情報漏洩等により不正取引が発生するリスクがある。
例:サービス2において、ログインと取引に同じ乱数表2を使用する場合
 対策1:サービス側(インターネット・バンキング等)において、ログインと取引に用いる認
証要素を分ける(例:ログインはID/PW、取引は2要素認証。ログインはID/PW/乱数表、
取引は取引認証)。
 対策2:Aggサーバにおいて、DBを預からない形態(本発表のハイブリッド型)を採用。
 対策3:サービス側とAggサーバの両者において、代理アクセス技術(OAuth等)を採用。
27
おわりに
パスワード認証の限界(管理範囲外からの漏洩)を踏まえて、
システムを設計する必要がある。
例:
新しい端末からの初めてのログイン時は、2要素認証化する
アグリゲーションサーバからのパスワード漏洩への対応
パスワード管理については、人によって主張が異なっており、
もっとオープンに議論し、コンセンサスを醸成する必要がある
のではないか。
例:
パスワードを手帳に書くことの是非
パスワード管理ツールの利用の是非など
少なくとも、パスワード使い回しに対して、対策(2要素認証
等)を導入したり、使い回しを回避する方法についてユーザに
情報提供していくことが必要であると考えられる。