第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要素認証 等）を導入したり、使い回しを回避する方法についてユーザに 情報提供していくことが必要であると考えられる。
© Copyright 2024 ExpyDoc
