スライド 1

Transcription

1 1 第 15 回情報セキュリティ シンポジウム 2014 年 3 月 5 日 ( 水 ) 講演 2 多要素認証の 1 要素であるパスワードの安全な管理方法 : パスワードリスト攻撃を踏まえて 日本銀行金融研究所 情報技術研究センター 鈴木雅貴 本発表は 産業技術総合研究所の古原和邦氏との共同研究の成果に基づく 本発表に示されている意見は 発表者個人に属し 日本銀行や産業技術総合研究所の公式見解を示すものではない

2 2 発表の概要 国内では 2012 年以降 インターネット バンキングの不正取引 (Man-in-the- Browser 攻撃 ) が増加傾向にあり 取引時に 従来の単なる 2 要素認証ではなく 取引内容を確認する 取引認証 の導入が求められる 他方 昨今 銀行や EC サイト等で使い回しているパスワードの漏洩に起因する不正ログイン ( パスワードリスト攻撃 ) が大規模に発生している [1] 不正ログインによる個人情報 ( 残高 住所等 ) の漏洩等への対策も課題となっている パスワードの使い回しの原因は 複雑なパスワードをサービス毎に設定 記憶する負担にユーザが耐えられないためであると考えられる 1 ログインの 2 要素認証化や 2 シングルサインオンによるユーザのパスワード管理負担の軽減等の対策が知られているが いずれもサービス側のシステム修正等が必要であり 直ぐに利用できるとは限らない 一部のユーザは パスワード管理ツールを利用しているが こうしたツールに求められる安全性に関する議論はあまりない そこで 18 文字程度の短いパスワードを用いた場合の情報漏洩リスク ( オフライン攻撃 ) や 2 パスワード管理を代行するサーバからの情報漏洩リスク ( 不正な管理者等 ) を取り上げ これらに対して安全なパスワード管理方法を議論する [1] 日経新聞電子版 不正ログイン被害 68 万件使い回しパスワード標的 2014 年 2 月 24 日

3 3 パスワード管理に関するユーザの実態 アンケート結果 1 ユーザが利用する Web サイトのうち パスワード認証 を行うサイトの数 ID とパスワードのみを利用する本人確認の方法 自分が記憶できるパスワードの数 トレンドマイクロ [2] シマンテック [3] 平均 14 1~4 個 :26% 5~9 個 :29% 10 個 ~:33% 把握せず :11% 0 個 : 6% 1~3 個 :64% 3 個以下のパスワードの使い回し 7 割 6 割 銀行 EC サイト ゲーム等において パスワードを使い回していたユーザを対象とした不正ログインが 2013 年に約 68 万件発生 [1] 利用者へ パスワードの使い回し防止 を呼び掛けても パスワードの使い回しは無くならないのが実情 呼び掛けから一歩踏み込んだ対応が必要ではないか [1] 日経新聞電子版 不正ログイン被害 68 万件使い回しパスワード標的 2014 年 2 月 24 日 [2] トレンドマイクロ Web サイトのパスワード利用実態調査 2012 年 [3] シマンテック 個人 企業のパスワード管理 に関する意識調査結果のご報告 2013 年

4 4 パスワード漏洩の原因 攻撃者 PW A に関する情報例 :Hash(PW A ) 不正アクセス等 サービス A 全数探索辞書攻撃等 PW A 使用 1 ユーザから漏洩 ユーザ PW A ウイルス フィッシング PW A の使い回し 2 他のサービスから漏洩 PW B 使用 なりすまし ( パスワードリスト攻撃 ) PW B サービス B パスワードは サービス提供者の管理範囲外で漏洩するリスクがある 1ユーザから ( ウイルス フィッシング ) 2 他のサービスから ( パスワードの使い回し ) パスワード漏洩を前提とすると パスワード以外の認証要素 ( 所持物 生体情報 ) を併用する 2 要素認証 ( 多要素認証 ) が根本的な対策

5 5 2 要素認証を行えば PW は使い回してよいか? インターネット バンキング ログイン ケース 1 ケース 2 ID, PW ( パスワード認証 ) ID, PW, OTP/ 乱数表 (2 要素認証 ) 取引 OTP/ 乱数表 OTP/ 乱数表 パスワード使い回しの影響 不正ログインされ 残高や住所等の個人情報が漏洩するリスク 不正ログインは防止可能 ただし 安全性は 2 要素認証から 1 要素認証に低下 OTP:One-Time Password 外部サービス ( 電子メール等 ) との連携ログインや入金 / 支払の際に 電子メールで通知するサービス等がある 不正検知や利便性向上の観点から有用であるが 外部サービスの中には パスワード認証のものが多く存在 インターネット バンキングで 2 要素認証を導入していたとしても パスワード管理に関する議論は引き続き必要 論点 1: パスワードの漏洩リスクを抑える対策論点 2: パスワードの漏洩による影響の局所化

6 6 論点 1: パスワードの漏洩リスクを抑える対策 攻撃者 PW A に関する情報例 :Hash(PW A ) 全数探索辞書攻撃等 登録時に脆弱なパスワードを排除 ハッシュ時に Salt やストレッチングの利用例 :Hash n (Salt, PW A ) PW A 不正アクセス対策 不正アクセス等 サービス A PW A 使用 ウイルス フィッシング ユーザ 脅威 : ウイルス ウイルス対策ソフト OS 等のセキュリティパッチ 脅威 : フィッシング フィッシング対策ツール (URL のチェック ) パスワード管理ツールによるパスワード自動入力 上記対策の実施には ユーザの協力が不可欠

7 7 論点 2: パスワードの漏洩による影響の局所化 パスワードの使い回し防止 ( 影響の局所化 ) トレードオフ パスワード管理コスト ( 記憶するパスワードの数 ) の増加 非技術的な解消方法 パスワードを紙に書き出し この紙を安全に保管 不正ログインによる影響の大きいサービスでのみ 個別パスワードを使用 [4] 技術的な解消方法 シングルサインオン (Single Sign-On) パスワード管理ツール 利点 ユーザのパスワード管理負荷の軽減 各サービスは ユーザの認証情報を管理しなくて良い 記憶するのは マスターパスワード 1 つのみ サービス側の対応不要 サービス側の対応に関係なく利用できる パスワード管理技術 を取り上げる 安全性に関する議論は あまり見かけないことから 安全性 に焦点を当てる [4] 西本逸郎 賢い 情報管理で安全と便利を両立 日経新聞電子版 2013 年 3 月 4 日 欠点 / リスク SSO への不正ログイン サービス側の対応が必要 ユーザが利用したい全てのサービスが 1 つの SSO で利用できない場合 複数のパスワード管理が必要 ツールの安全性 ツールが乗っ取られるリスク

8 8 想定するパスワード管理方式と脅威

9 9 典型的なパスワード管理方式の形態 ID PW URL ID 1 PW 1 URL 1 ID i PW i URL i DB: 各サービス用パスワードを記録した DB edb: 何らかの方法で暗号化された DB ID M, PW M : パスワード管理用のマスター ID とマスターパスワード ID i, PW i : サービス i の ID とパスワード DB の暗号化 (edb): マスターパスワード PW M を鍵として利用 ローカル管理型 (edb をユーザの端末で保管 ) 端末 サーバ管理型 (edbをサーバで保管) edb 例 : パスワードを記録した Text ファイル (DB) をマスターパスワード PW M で保護する方法 [5] 等 ローカル管理型の一部製品が DB を暗号化していないとの指摘 [6] edb ID M, PW M でログイン マルチデバイス対応 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 10 edb 典型的なパスワード管理方式のリスク edb の復号 PW M 復号 DB 判定 ( フォーマット等の検査 ) DB 復号成功 / 失敗 [5] NTT, 公開鍵暗号の安全性の根拠である 素因数分解問題 で世界記録を更新 2010 年 正しい PW M の場合のみ DB を復号可能 攻撃者がeDBを入手した場合 マスターパスワードの全ての候補を試せば 理論的にはDBを復号可能 ( オフライン攻撃 ) 英数字 (62 種 ) の1 文字の情報量 = 約 6 bit ( ランダムに選択する場合 ) 英数字 8 文字パスワードの情報量 = 約 48 bit 学会では 60bitの全数探索可能であることが実証済み [5] 8 文字程度の 短いパスワード は オフライン攻撃が現実的な脅威 短いパスワード を想定した場合のリスク edb の漏洩 ( サーバ or 端末から情報漏洩 ) PW M の漏洩 ( フィッシング or PW 使い回し ) ローカル管理型 サーバ管理型 オフライン攻撃による DB 漏洩のリスク への不正ログイン (DB 漏洩 )

11 11 想定するパスワード管理方式 ハイブリッド管理型 DB を復号するための情報を と PM クライアント ( 端末 ) で分散管理 ユーザは短い PW PM のみを記憶 (PW 管理負担の軽減 ) インターネット サービス i は 修正不要 サービス i における本人確認方法 (2 要素認証 パスワード認証等 ) は サービス i に依存 ユーザ ID M, PW M PM クライアント ( ユーザ所有の端末 ) 共有端末は想定しない ID i / PW i インターネットのサービス i 端末内データの破損 または PW M の忘却に対しても DB 復旧可能 ( 復旧機能 ) PM:Password Manage ユーザの端末内で DB を復号 複数台の端末で利用可能 ( マルチデバイス対応 )

12 12 検討対象とするパスワード管理方式の処理 ストレージ 処理 1: DB の暗号化 復号処理 2: と端末の暗号通信 処理 3: 端末の追加 ( マルチデバイス対応 ) ユーザ ストレージ ID ID PW URL M, PW M ID i PW i URL i 端末 1 端末 2 処理 4: 端末内データの破損時の DB 復旧方法 処理 5: マスターパスワード PW M の忘却時の DB 復旧方法

13 13 想定する脅威と安全性要件 脅威 : 不正な管理者等 ( 含 :からの情報漏洩 ( の管理者等 ) に対して DB や PW M を秘匿 脅威 : フィッシング PW 使い回し PW M が漏洩していても DB が漏洩しない 端末 ID M, PW M ID i / PW i ユーザ サービス i 脅威 : 端末の紛失 端末から漏洩した情報から DB や PW M が漏洩しない 脅威 : 復旧機能の悪用 復旧機能の悪用から DB や PW M が漏洩しない 端末のウイルス感染は想定しない ウイルス感染した場合は パスワード管理技術を利用しなくてもパスワード漏洩のリスクがあり 別途対策が必要

14 14 各処理の実現方法の安全性評価

15 15 処理 1:DB の暗号化 復号 登録 ( 暗号化 ) 利用 ( 復号 ) DB の暗号化 (edb): ランダムに生成した暗号鍵 K(128 bit 以上 ) を使用 単純分散方式 ( 暗号文 edbと鍵 Kを分散保管 ) edb 鍵分散方式 ( 鍵 K も暗号化し 分散保管 ) edb, ek S edb edb edb ek S ek S edb 暗号化 K 復号 暗号化 K 端末 K 復号 DB 端末 DB DB 秘密分散 ek C 秘密分散 DB DB ( 上記方式の拡張 ) 上記方式は マスターパスワード PW M を未使用だが 鍵 K の暗号化に PW M を利用可能 ただし 忘却等により PW M が利用不可の場合 正規ユーザであっても DB 復号困難 (1 オフライン攻撃と同等の処理により DB を復号する 2PW M 復旧手段を用意する必要 )

16 16 補足 : 秘密分散 秘密分散 秘密情報 ( 暗号鍵 ) を複数の情報 ( シェア ) に分割する暗号化方法 秘密情報 (K) 10 分割シェア1 ( 暗号化 ) (ek S ) 復号 3 K ek S + ek C 7 シェア 2 (ek C ) 例 : 秘密情報 10 を 2 つ または 3 つのシェアに分割 秘密情報シェア分割 分割 12-2 秘密情報シェア分割 と 8 が漏洩しても 10 は求められない ( 情報理論的に安全 )

17 17 処理 1:DB の暗号化方式の安全性 単純分散方式 edb 1 鍵分散方式 edb, ek S 端末 K 23 ek C 端末 1から情報漏洩 2 端末から情報漏洩 3 端末から漏洩した情報の無効化 新たに生成した鍵 K で DB を暗号化し直す必要 DB を求めることは 計算量的に困難 edb が漏洩しておらず DB は安全 各シェア (ek S, ek C ) の更新により無効化可能 鍵 K は情報理論的に安全のため DB を暗号化し直す必要はない

18 18 処理 2:と端末の暗号通信 暗号通信に必要な処理 : 暗号通信用の鍵の共有 相互認証 PKI(SSL 暗号通信 )+ パスワード認証 OK/NG LR-AKE[7] Leakage-Resilient Authenticated Key Exchange ( 乱数 S C と PW M を用いた 2 要素認証 ) Hash 公開鍵ペア, Hash(PW M ) PW M SSL 鍵共有 PW M 本人確認 S S OK/NG 鍵共有本人認証 端末 端末 OK/NG 登録情報生成 乱数 S C 鍵共有サーハ 認証 登録 利用 PW M PW M [7] S.Shin, K.Kobara, H.Imai, Secure PAKE/LR-AKE Protocols against Key-Compromise Impersonation Attacks, SITA 2008.

19 19 処理 2:と端末の暗号通信の安全性 PKI+ パスワード認証 公開鍵ペア, Hash(PW M ) 端末 OK/NG 1 2 LR-AKE PMサーバ S S 端末 乱数 S C 1から情報漏洩 2 端末から情報漏洩 Hash(PW M ) に対するオフライン攻撃により PW M 漏洩のリスク 計算量的に PW M は安全 S C には PW M の情報は含まれない

20 20 情報漏洩に耐性のあるパスワード管理方式の例 [8] DB の復号手順 : 処理 1( 鍵分散方式 ) と処理 2(LR-AKE) の組合せの場合 LR-AKE 鍵共有本人認証 S S S S, ek S, edb 暗号通信路の確立 ek S 暗号通信路 edb 端末 ユーザ 鍵共有サーハ 認証 S C S C, ek C ek C 秘密分散 K 復号 PW M PW M 鍵分散方式 DB 特徴 端末内で DB を復号 または 端末から情報が漏洩しても DB や PW M が漏洩しない 端末から漏洩した情報 (S C, ek C ) を無効化可能 PW M が漏洩しても DB は安全 [8] S.Shin, K.Kobara, H.Imai, A Secure Public Cloud Storage System, IEEE ITST, 2011.

21 21 処理 3: 端末の追加 ( マルチデバイス対応 ) ハイブリッド管理型における新しい端末 ( 端末 2) の追加 端末 2 の追加前 端末 2 の追加後 S1 S, ek1 S, edb S1 S, ek1 S, edb S2 S, ek2 S 端末 1 端末 1 端末 2 S1 C, ek1 C S1 C, ek1 C S2 C, ek2 C ( 追加手順の方針 ) 端末 1 を信頼の根拠として 端末 2 に関する 用と端末用のデータ S2 S, S2 C, ek2 S, ek2 C を端末 1 が生成 端末 1 から に S2 S, ek2 S を渡す 次に 端末 2 に S2 C, ek2 C を格納する その際 に ek2 C が漏洩すると ek2 S, ek2 C, edb から DB が漏洩する点に注意 ek2 S, ek2 C と edb の関係 端末 1 ek1 S, ek1 C 秘密分散 K ek2 S, ek2 C 秘密分散 K 端末 2 edb 復号 DB

22 22 処理 3: 端末の追加 ( マルチデバイス対応 ) 端末 2 に S2 C, ek2 C を安全に格納する方法 安全なローカル通信路の利用 端末 1 端末 2 S2 C, ek2 C Bluetooth 接続 USB 接続 USB メモリ QR コード / カメラ家庭内 LAN 等 端末 1 経由の通信路の利用 S2 C, ek2 C 暗号化 OTP ユーザ S2 C, ek2 C 復号 端末 2 S2 C, ek2 C S2 C, ek2 C (OTP の入力方法 ) QR コード / カメラ 目視 / 手入力 ( 英数 21 文字あれば OTP の情報量が 128 bit 程度になる )

23 23 処理 4, 5: 端末内データ マスターパスワードの復旧 S S, ek S, edb PW M 秘密分散 PW M ユーザ S2 C, ek2 C 暗号化 端末 S C, ek C 復号 PW 端末, PW 外部メモリ処理 5: マスターパスワードの復旧 PW M の復旧に必要な情報を端末と外部メモリに格納 DBの暗号化に PW M を用いない場合には マスターパスワードの再設定も可能 ただし 再設定の手続きを悪用されるリスクへの対応が必要 公開鍵 PK 端末 PW 端末 秘密分散 外部メモリ 処理 4: 端末内データの復旧 端末内データの復旧に必要な情報を と外部メモリに分散して格納 もっとも 複数台の端末を追加している場合には 1 台でも利用可能であれば DB 復号可能 秘密鍵 SK 端末 PW 外部メモリ

24 24 考察

25 25 考察 : パスワード管理ツールの利用上の留意点等 パスワード管理ツールを利用する際に 留意すべき項目 や端末から漏洩した情報に対するオフライン攻撃による DB 漏洩 不正な管理者等による DB 漏洩 端末内データやマスターパスワードの復旧機能の悪用による DB 漏洩 実装ミス等による DB 漏洩 上記の各項目への耐性が客観的に評価されているか ユーザが正規ツールを入手できる枠組みがあるか ユーザにパスワード管理の意識を持たせるアイデア 攻撃者 ユーザ ID1 不正ログイン試行 ID1, PW0 正規ログイン ID1, PW1 前回ログイン以降の ログイン失敗回数 サービス 失敗 成功 自分のアカウントに不正ログインの試行があったか否かがユーザにはわからない 前回ログイン時刻 ログイン失敗回数 の通知により 自分のアカウントが狙われていることを意識するきっかけになると期待される ( 製品も存在 )

26 26 考察 : アグリゲーション サービスからの情報漏洩対策 アグリゲーション ( アカウント情報集約 ) サービス 1ID M, PW M Agg サーバ 2ID 1, PW 1 ユーザに代わってログイン ユーザ 端末 6 残高等のまとめ情報 3 残高 履歴等 サービス 1 DB(Agg サーバが管理 ) 4ID 2, PW 2 乱数表 2 サーヒ ス 1 ID 1, PW 1 5 残高 履歴等 サーヒ ス 2 ID 2, PW 2, 乱数表 2 サービス 2 Agg サーバに預けた情報で 残高照会だけでなく 取引も可能な場合 Agg サーバからの情報漏洩等により不正取引が発生するリスクがある 例 : サービス 2 において ログインと取引に同じ乱数表 2 を使用する場合 対策 1: サービス側 ( インターネット バンキング等 ) において ログインと取引に用いる認証要素を分ける ( 例 : ログインは ID/PW 取引は 2 要素認証 ログインは ID/PW/ 乱数表 取引は取引認証 ) 対策 2:Agg サーバにおいて DB を預からない形態 ( 本発表のハイブリッド型 ) を採用 対策 3: サービス側と Agg サーバの両者において 代理アクセス技術 (OAuth 等 ) を採用

27 27 おわりに パスワード認証の限界 ( 管理範囲外からの漏洩 ) を踏まえて システムを設計する必要がある 例 : 新しい端末からの初めてのログイン時は 2 要素認証化する アグリゲーションサーバからのパスワード漏洩への対応 パスワード管理については 人によって主張が異なっており もっとオープンに議論し コンセンサスを醸成する必要があるのではないか 例 : パスワードを手帳に書くことの是非 パスワード管理ツールの利用の是非など 少なくとも パスワード使い回しに対して 対策 (2 要素認証等 ) を導入したり 使い回しを回避する方法についてユーザに情報提供していくことが必要であると考えられる