第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