認証にまつわる セキュリティの新常識 rev.3 - NIST改定で世の中は変わったか - 2022.01.27 勝原 達也

1. 本資料は”Internet Week 2018” にて利⽤した版に2022 年までの最新動向を追加し更新した第3版です 2. 発⾔は個⼈の⾒解であり、所属組織を代表するものではあ りません 3. 内容の正確性を維持すべく努⼒していますが、 それを保証するものではありません 4. 本資料記載の会社・団体名、ロゴおよび製品・サービス名 は各社・各団体の商標または登録商標です おことわり

勝原 達也/Tatsuya Katsuhara https://www.linkedin.com/in/kthrtty • クラウドに関連する会社 (現在) • クラウドのセキュリティ • NDIAS(NRIとDENSOの合弁会社) • ⾃動⾞のセキュリティ • NRIセキュアテクノロジーズ • Web/プラットフォーム脆弱性診断 • IoT/制御システム・OTのセキュリティ • デバイスのセキュリティ • 野村総合研究所 • デジタル・アイデンティティ • 認証システム/API認可プラットフォームの開発・運⽤ • OAuth/OpenIDに関する開発・コンサル • OpenID Foundation JAPAN設⽴・運営

認証

⽇本語訳、根深い問題

No content

Certificationが上に書いてある

No content

認証局 Certification Authority

No content

(通称) 技適認証 Technical Standards Conformity Certification

No content

認証済みアカウント Verified Account

相互認証 Cross Certification Mutual Authentication

同じ⾔葉に 違う意味を割り当てすぎ

⾝の回りにあふれている ≒単純な概念に思えてくる ≒決めつけがち ≒議論がかみ合わない ≒地味に苦労する

本⽇のテーマ 認証／Authentication

本⽇お伝えしたいこと • 認証およびデジタルアイデンティティを考えるために有⽤な 共通⾔語をNIST SP800-63-3の考え⽅を通じて知る • 認証にフォーカスした63Bを通じてAuthenticator種別を知る • SP800-63-3の改定の過程で巻き起こった議論と、 その背景にあるメッセージを考えてみる • デジタルアイデンティティのセキュリティの⾯⽩さを知る https://www.flickr.com/photos/alexristea/5636821732/

NIST SP800-63-3とは • NIST SP800-63-3は⽶国政府機関 向けに、デジタルアイデンティティ フレームワークについて⾔及したガ イドライン • ⽇本の事業者には何ら役務が発⽣す ることはない • エッセンスと考え⽅はとても有⽤で、 様々な業界から参照されている • Fit&Gapしてリスク分析して流⽤す ることは良いアプローチ(なはず) https://pages.nist.gov/800-63-3/ OIDFJでの活動 兼 趣味で翻訳 https://openid-foundation-japan.github.io/800-63-3-final/ ※違和感のある訳の改善のためプルリクお願いします

デジタル認証の ガイドライン 登録プロセス ⾝元確認 認証と ライフサイクル管理 フェデレーションと アサーション 興味キーワード NIST SP800-63-3全体概要 本⼈確認 ⾝元確認 窓⼝での対⾯確認 写真付き⾝分証明書 映像での遠隔⾝元審査 犯罪収益移転防⽌法 KYC(Known Your Customer) パスワード認証 パスワード定期変更 秘密の質問 多要素認証 SMS認証 バイオメトリクス アカウントリカバリ Federated Identity Single Sign On(SSO) SAML OAuth2.0 OpenID Connect Web API Authorization Identity Platform NIST SP800-63-3とは 本⽇の 対象

NIST SP800-63-3とは IAL 1-3 (Identity Assurance Level) ユーザ認証の 確からしさ 連携⽅法の 確からしさ 本⽇の 対象 例えば銀⾏ 2 ユーザ⾝元確認の 確からしさ 例えばECサイト 2 2 1 2 － AAL 1-3 (Authenticator Assurance Level) FAL 1-3 (Federation Assurance Level)

63Bもくじ ⽬次 内容 4. Authenticator Assurance Levels 5. Authenticator及びVerifierの要件 付録A ̶ 記憶シークレットの強度 • AAL毎の要件と、それに合致するAuthenticatorの話 • Authenticatorの種類や、備えるべき機能の話 6. Authenticatorライフサイクルの要件 • Authenticatorの発⾏、紛失、盗難、破棄などの要件 7. セッション管理 • セッションCookie、AccessToken、再認証など認証後の セッション維持とその保護に関わる話 8. 脅威とセキュリティに関する考慮事項 9. プライバシに関する考慮事項 • AuthenticatorやSessionに関するリスク要因および対策 • プライバシーリスクアセスメント、コントロールなどの話 10. ユーザビリティに関する考慮事項 • Authenticationのユーザビリティとビジネス影響 • Authenticatorライフサイクルを通じたユーザビリティ確保 本⽇の 対象

⽤語 • ユーザは⽂脈で区別される • Applicant→Subscriber→Claimant • Credential Service Provider • Applicant情報を確認・検証・登録 • SubscriberへAuthenticatorを発⾏ • Authentication(認証) • ClaimantがSubscriberであることを、 Authenticatorを⽤いて確認する⾏為 • Verifier • Authenticatorの出⼒を⾒て、 Subscriberかどうかを確認する • Relying Party • Verifierの確認結果に基づいて、 認証済みセッションを開始 アカウント をゲット︕ 登録したい︕ きちんと⾝元を 確認して ID/PW発⾏する︕ サービス使いたい から認証する︕ きちんと認証して 加⼊者だけにサービス する︕ 認証結果や加⼊者情報を 提供してもらったので サービスできる︕

Authenticatorのタイプ # 原⽂ 和訳 認証要素 Something you *** 暗号プロトコル(鍵の 所持証明)の性質あり HWとして 認められる※2 1 Memorized Secret 記憶シークレット 知識 No No 2 Look-up Secret ルックアップシークレット 所有 No No 3 Out of Band Device 経路外デバイス 所有 No No 4 SF OTP Device 単⼀要素OTPデバイス 所有 No Yes/No※3 5 MF OTP Device 多要素OTPデバイス 所有+知識/⽣体※1 No Yes/No※3 6 SF Cryptographic Software 単⼀要素暗号ソフトウェア 所有 Yes No 7 SF Cryptographic Device 単⼀要素暗号デバイス 所有 Yes Yes 8 MF Cryptographic Software 多要素暗号ソフトウェア 所有+知識/⽣体※1 Yes No 9 MF Cryptographic Device 多要素暗号デバイス 所有+知識/⽣体※1 Yes Yes ※1) 基本的にはAuthenticatorを活性化(Activation)するためのローカルの認証要素であり、記憶シークレット(NW通信路を通る) との性質の違いに留意すること ※2) HWという単語の実態は「様々な脅威への対策・緩和策の集合体」であり物理的なHWだからAAL3、という安直な解釈はNG ※3)「デバイス」という呼称と、HWとして認められるかは⼀致しないので注意 HWという単語の実態は「様々な脅威への 対策・緩和策の集合体」であり物理的な HWだからAAL3、という安直な解釈はNG

Authenticatorのタイプ # Authenticatorのタイプ 内容 1 Memorized Secret 記憶シークレット ユーザが記憶するもの。 例︓パスワードやPIN ※ローカル／リモートどちらであるか問わない。 2 Look-up Secret ルックアップシークレット Claimant（認証をしたい⼈）とCSP（認証情報を登 録・払い出す側）の間で共有されているシーク レット。 例︓乱数表、Googleアカウントの⼆要素認証のリ カバリコードのようなもの 3 Out of Band 経路外 (RESTRICTED) セカンダリチャネルを介してVerifierと安全に通信 できるようなもの。 例︓SMSによるコード送信、QRコード読み取り、 電話によるコード読み上げ／⼊⼒ ※今回の改定で、EメールやVoIPはセカンダリチャ ネルとして認められないとされた点に注意。

Authenticatorのタイプ # Authenticatorのタイプ 内容 4 SF OTP Device 単⼀要素OTPデバイス ⼆要素⽬の⼊⼒によるアクティベーションを必要 とせず、所持していることで認証を実施できる。 例︓パスフレーズ⼊⼒不要なOTPデバイス（物理 OTPトークンや、Google Authenticatorなどスマホに インストールしたソフト含む） 5 MF OTP Device 多要素OTPデバイス SF OTP Deviceに更に⼆要素⽬の⼊⼒によるアクティ ベーションを追加したもの。 例︓（スマホのロック解除とは別に）Touch IDやマ スタPWでアクティベートするOTPアプリ 6 SF Cryptographic Software 単⼀要素暗号ソフトウェア ディスクあるいはソフト媒体に記録された⼀意な 暗号鍵。鍵はデバイス上で最もセキュアなスト レージに保存されており、アクセスコントロール が施されている。 例︓端末毎のクライアント証明書（PW保護無し） 7 SF Cryptographic Device 単⼀要素暗号デバイス 保護された暗号鍵を⽤いて認証を⾏うハードウェ アデバイス。鍵はデバイスで⼀意であり、エクス ポートできてはいけない。 例︓FIDO U2FのUSBドングル(挿すだけ)

Authenticatorのタイプ # Authenticatorのタイプ 内容 8 MF Cryptographic Software 多要素暗号ソフトウェア 単⼀要素暗号ソフトウェアに対して、更にアク ティベートするための2要素⽬が必要となったもの。 例︓指紋認証を⾏うことで有効化されるクライア ント証明書 9 MF Cryptographic Device 多要素暗号デバイス 単⼀要素暗号デバイスに対して、更にアクティ ベートするための2要素⽬が必要となったもの。 例︓パスワードまたはバイオメトリクスでアク ティベートしなければ利⽤できないようになって いるUSBトークン、指紋認証や顔認証でセキュアエ レメントをアクティベートするようなFIDO対応ス マホ。 注）なるべく具体例を⼊れていますが、NISTの基準においてFIPS140 Approvedかどうかなどが影響するため、厳密には該当しない 場合があります。

AAL(Authenticator Assurance Level） • 「Claimant＝Subscriberであること」の確認(認証)の信頼性を3段階に分類したもの • 観点は複数あり、同時に満たした場合に当該レベルに適合、HW要件は複合的&厳しい • 認証要素（Something you ***）は同じ要素を2つ使っても1要素とカウント※ • 利⽤する暗号アルゴリズム要件は63-3記載の「承認済み(Approved)」なものを利⽤ 要求事項 AAL 1 AAL 2 AAL 3 許容される Authenticator タイプ • 9タイプ全部OK（何でも良い） • Authenticator単独で2要素以上 • またはPW(知識)＋2要素⽬(所有,特徴) • 2要素以上 • 暗号鍵の所持証明要素 • ハードウェア（複合的&厳しい要件） • 記憶シークレット • ルックアップシークレット • 経路外 • 単⼀要素OTPデバイス • 多要素OTPデバイス • 単⼀要素暗号ソフトウェア • 単⼀要素暗号デバイス • 多要素暗号ソフトウェア • 多要素暗号デバイス • 多要素OTPデバイス • 多要素暗号ソフトウェア • 多要素暗号デバイス • 記憶シークレット＋以下 • ルックアップシークレット • 経路外 • 単⼀要素OTPデバイス • 単⼀要素暗号ソフトウェア • 単⼀要素暗号デバイス • 多要素暗号デバイス • 単⼀要素暗号デバイス ＋記憶シークレット • 多要素OTPデバイス(SW/HW) ＋単⼀要素暗号デバイス • 多要素OTPデバイス(HW) ＋単⼀要素暗号ソフトウェア • 単⼀要素OTPデバイス(HW) +多要素暗号ソフトウェア • 単⼀要素OTPデバイス(HW) +単⼀暗号ソフトウェア +記憶シークレット ※単⼀要素を複数⽤いた場合の認証強度を否定するものではないが、尺度の基準を統⼀することが難しい。そのため 「多要素」という考え⽅ありき。

要求事項 AAL 1 AAL 2 AAL 3 許容される Authenticatorタイプ • 9タイプ全部OK （何でも良い） • Authenticator単独で2要素以上 • またはPW(知識)＋2要素⽬(所有,⽣体) • 2要素以上 • 暗号鍵の所持証明要素 • ハードウェア（複合的&厳しい要件） FIPS 140適合 Level 1 (政府機関のVerifier) Level 1 (政府機関のAuthenticator及び Verifier) Level 1 総合 (Verifier及び単⼀要素暗号デバイス) Level 2 総合 (多要素Authenticator) Level 3 物理セキュリティ (全てのAuthenticator) 再認証 30 ⽇ 12 時間または30分間活動なしの場合に、 1つの認証要素を利⽤して再認証(任意) 12 時間または15分間活動なしの場合に、 両⽅の 認証要素を利⽤して再認証(必須) セキュリティ統制 [SP 800-53] 低い基準 (または 等価なもの) [SP 800-53] 中度の基準 (または等価なもの) [SP 800-53] ⾼い基準 (または等価なもの) 中間者攻撃耐性 必須 必須 必須 Verifierなりすまし 耐性(Phishing耐性 /MITM耐性) 不要 不要 必須 Verifier危殆化耐性 不要 不要 必須 リプレイ耐性 不要 必須 必須 認証意図 (AuthN Intent) 不要 推奨 必須 レコード保持ポリシ 必須 必須 必須 プライバシ統制 必須 必須 必須 AAL(Authenticator Assurance Level）

読む際のコツ︓要求記法および規則 • SHALL(するものとする)およびSHALL NOT(しないものとする) • 厳密に従うことを要求しており、内容と異なってはならない。 • SHOULD(すべきである)およびSHOULD NOT(すべきではない) • いくつかある選択肢の中で特定の推奨があることを⽰している。 • 他の選択肢については⾔及も除外もしない。 • ⾏動指針を推奨するが、必須であることまでは要求しない。（微妙な表現） • MAY(してもよい)およびNEED NOT(しなくてよい) • ⾏動指針が許容できることを⽰す。 • CAN(できる)およびCANNOT(できない) • 物質的、物理的、偶発的であるかに関わらず 可能性や能⼒があること。

パスワードからパスフレーズへ https://xkcd.com/936/

パスワードからパスフレーズへ • パスフレーズ前提 • 8⽂字以上(ランダム⽣成なら6⽂字以上)(SHALL) • 最低64⽂字(SHOULD) • 空⽩/Unicode(SHOULD) • 他には複雑さ要件を課さない(SHOULD) • リスト突合で弱いPWをはじく(SHALL) • 漏洩PW、辞書、繰り返し/連番、⽂脈で特定 • ペースト機能(SHOULD) • パスワードマネージャ連携/使いまわし改善 • 可視化(SHOULD) • ラスト1⽂字表⽰、トグルで表⽰/⾮表⽰など • パスワード強度メーター(SHOULD) • (強度を正しく伝えられるかの議論あり) パスフレーズを推奨し、 桁数を伸ばす⽅向へ誘導 することで、総合的にセ キュリティ向上を図って いくというメッセージ。

パスワード定期変更を求めない⽅向性 「ユーザに対し定期変更を要求すべきではない」(SHOULD) 「パスワードが危殆化した可能性があれば変更強制」(SHALL) →危殆化をモニタリングできるかという隠れた重めの課題も。 • 定期変更を通じてユーザは「弱いパスワード」を使うようにな るので、結局は突破されがち、という考えに基づく。 https://pages.nist.gov/800-63-FAQ/ • ⽶ノースカロライナ⼤学の研究(過去パスワードが分かれば、 17%のユーザは5回以内の試⾏で現在パスワードが特定できる) https://www.ftc.gov/news-events/blogs/techftc/2016/03/time-rethink-mandatory-password-changes ⼤⽂字/数字 記号 桁数 定期変更#1 定期変更#2 password Passw0rd P@ssw0rd P@ssw0rd! P@ssw0rd!1 P@ssw0rd!2

完全に廃⽌された「秘密の質問」 • SP800-63-2では”Pre-registered Knowledge Token”と呼称。 • Knowledge Based Authentication(KBA)とも⾔われる。 • SP800-63-3では記憶シークレットの⼀部として扱われ、 「やってはいけない」(SHALL)記憶シークレットの例としてわ ざわざ記載されることになった。（例︓ペットの名前） • 「アカウントリカバリ」の難易度が増加。 • ⽣年⽉⽇（ソーシャルエンジニアリングの餌⾷なので問題外） • メールアドレス（経路外Authenticatorとしては禁⽌だが・・・） • SMS（RESTRICTEDだが・・・）

地味に影響しそうな乱数表の制限追加 • 各セルの値の使い回しが禁⽌ (SHALL) • NISTは「⽇本的」な乱数表の利⽤は考慮されていない • ⼆要素認証の有効化時に発⾏されるような「回復コード表」は許容 以前 何回でもセルの値を使ってよい。 ⽇本における乱数表イメージ （例︓キャッシュカード裏⾯） 今後 各セルは1回しか使えない。

バイオメトリクスの位置付け 単独でAuthenticatorとして認めないが、2要素⽬として補助的 には利⽤して良い 理由はいくつか挙げられている。 • False Matching Rate(誤合致率)が低く抑えられようと、 認証⾏為の確実性に繋がるわけではない。 • バイオメトリクスは確率的なもの • 特徴点情報(テンプレート) の保護や無効化の標準不在 • バイオメトリクス特性はシークレットではない • プレゼンテーション攻撃を防ぐPADは今後必須要件になる⾒込み。

経路外認証は使えるが”RESTRICTED” • ドラフト改訂の当初は、公衆交換電話網(PSTN)を使っている 場合、SMSの経路外認証は⾮推奨になり、⼤盛り上がり • 最終的には”RESTRICTED”という経過観察的な処遇。 • 他にも事業者にとって重要な要件がいくつか • VoIP/EメールはNG（特定デバイスの所持証明にならない）(SHALL) • 事前登録済みの電話番号は物理デバイスと結びついていることを確認 • スマホのPush通知インフラはセカンダリチャネルとして有効 • 「アカウントリカバリ」は特別な要件が追加 • 電話番号の変更は新しいAuthenticatorのバインディングとみなされる。

SMSに対する攻撃の例 • SS7(Signaling System #7) • 携帯キャリア(MNO:Mobile Number Operator)および 他の携帯キャリアとの間で発呼・SMSルーティング等に ⽤いられる歴史のあるプロコル • 脆弱なMNOを経由して攻撃対象のMNOのSMSを不正に 受信する • SIM Swapping • ソーシャルエンジニアリング • オペレーターの本⼈確認プロセスにおける⾝元詐称 • 内部不正・結託 https://fedotov.co/wp-content/uploads/2016/07/31c3- ss7-locate-track-manipulate.pdf https://www.vice.com/en/article/y3g8wb/hacker-got-my-texts-16-dollars-sakari-netnumber • SMSを⽤いたマーケティングサービスのブローカー悪⽤(⽶国) • SMSを⽤いたマーケティングサービス(Sakari社)とバックエンドのSMSルーティングサービスの ブローカー(Bandwidth社)に対し、携帯電話事業者・SMSハブが⼀部機能を開放していたと推測 • その機能が悪⽤され、SMS先の電話番号の所有／同意確認の⽢さから、SMSが窃取されたとされる 幸い⽇本では報告されて いない（はず）

よくある追加認証はNISTでは⾔及がない • いわゆる「重要な取引の前に追加の認証を⾏う」こと • ⾔い回しは違えど、様々なガイドラインで⾔及されている • OWASP(Open Web Application Security Project) • FISC安対（⾦融機関等コンピュータシステムの安全対策基準・解説書） • 「同じ認証要素を複数回使っても、1要素とみなす」NISTでは追加認証の 有⽤性を図る尺度は提供していない • 現実のシステム検討時には⼗分な議論と整理が必要 • ログインパスワードと取引パスワードが「真に」独⽴なら、⼀定の効果はありそうだが… • セッションハイジャック対策であれば再認証(NIST⾔及)でも⼗分では… • パスワードだけに依存せず、多要素認証にしたほうが整理しやすいのでは… ログインパスワード 閲覧操作 注⽂＆取引パスワード （追加認証の⼀種） 取引成⽴

バインディング • Authenticatorの登録・追加・交換・廃⽌のプロセス。 • ライフサイクルを通じて、AAL維持を意識したプロセスが必要。 登録時バインディング(IAL x) 登録後バインディング(AAL x<=) バインドされ た状態 未バインド 状態 同時にバインド実施 リモートトランザクション（途切れてしまう場合） • ⼀時シークレット（TEL、Email、住所へ送付）を⽤いて再開 ローカルトランザクション（途切れてしまう場合） • ⼀時シークレット（TEL、Email、住所へ送付）を⽤いて再開（再利⽤禁⽌） • バイオメトリクス利⽤ あるAALに必要な Authenticatorが⼀部ま たは全部利⽤不能 Authenticator追加(AAL1⼿段の複数登録または、AAL2にアップグレード) • 追加するAuthenticatorが利⽤されるAAL以上で認証。 • 通常は、保有しているAuthenticatorのAALで新Authenticatorを登録。 • AALのアップグレード(AAL1→2のみ)実施。 所有する⼀部のAuthenticatorが紛 失、盗難、破損、有効期限切れ、 失効 所有する⼀部のAuthenticatorが紛失、 盗難、破損、有効期限切れ、失効 置き換え（ AAL2/3の場合のAuthentication要素不⾜に対応） • 基本的にはIdentity Proofingを伴う当初のリモート/ローカル トランザクションと同様のバインディング⼿続きを実施 • ⼀時シークレットまたはバイオメトリクス利⽤ 紛失、盗難、破損、有効期限 切れなどで失効、または解約 したAuthenticatorのバイン ディングは削除する必要あり。 (63-A記載のIdentity Proofingを伴う) 63B記載内容から作成した簡易な状態遷移例

AALを意識したアカウントリカバリは難しい • アカウントリカバリは難しく脆弱になりがち≒狙われやすい • パスワードを覚えていれば、2要素でのリカバリには定⽯あり • パスワード(知識)＋アカウントの回復コード(所有) • スマホ紛失でOTPアプリが使えない、などの問題解決 • パスワードを忘れると、2要素でのリカバリは難しい • 別のパスワードを事前登録・・・どうせそれも忘れる＆秘密の質問NG • 指紋を予め登録しておけば・・・ハードル⾼い • IAL2,3の場合は、登録時の⾝元確認をやり直すことでリカバリ可能 （⼿続きは煩雑になるため、現実的には⾦融や⾏政など極めて重要 な領域に限られる）

AAL2におけるパスワード忘れのリカバリ • Physical Authenticatorを2つ使い、確認コード送付/検証(MAY) という⽅法が例⽰されている • “Physical Authenticator”は「所有要素」の全Authenticator • 以下をすべて同時に窃取するのは困難という前提に基づく • 2つのPhysical Authenticator • 事前登録アドレス（例︓住所・メールアドレス）宛に送信された確認コード • 2要素確保は必須ではない • 代表的な事業者では、経路外AuthenticatorをPhysical Authenticator かつ確認コード受け取りを満たす⼿段として解釈 • AAL2の2要素認証のパスワード忘れリカバリ典型例 • OTPアプリ＋メールアドレス宛の確認コード⼊⼒ • スマホアプリPush＋SMS宛の確認コード⼊⼒

受信した 確認コードを⼊⼒ パスワード再設定 2段階認証(認証要素は1つ)で ログイン完了 確認コードを メールアドレスに 送信開始 登録済みの認証要素いずれか (FIDO, OTP, SMS, 回復コード) ※全て「所有」要素

アカウントを識別 設定済みのOTP (所有)を実施 マスク済み情報は 値を⼊⼒させる (試⾏回数に制限) メールアドレス/SMSに 届いた確認コードを⼊⼒ 2段階認証(認証要素は 1つ)でログイン完了 登録済みの認証要素どれか (メール、SMS, 回復コード) ※OTPは使⽤済み判定 ※Windows Helloで⽣体要素 が増えるかも。

Eメールの取り扱いには曖昧さが残る • 代表的な事業者では「Eメール」での確認コード送付も活⽤ • FIDOキー、OTP、SMS、Eメール、回復コードの組み合わせ。 • 「所有」1要素だが、2 Physical Authenticatorsを利⽤。 • リカバリ時の「Eメール」での確認コード送付は根深い問題 • 経路外AuthenticatorとしてのEメールは使えない(SHALL)となってい るものの「現実的には使わざるをえない」というのが、コンシューマ 向けサービスでの落とし所と⾔えそう。

NIST SP800-63-3関連の重要な補⾜⽂書 • NIST SP800-63-3を読み解くうえで有⽤な解釈情報や実際の適⽤ケースなどを 補⾜する⽂書が存在するため、併せて参照するとよい • FAQ • 記憶シークレットはシステムアカウントと⼈間を対象とする︖(⼈間だけ) • TLSを使うことでFAL2でのアサーション暗号化要件を満たす︖（満たさない） • デジタルIDウォレットはIdPにできる︖（IdPとして⾒なされる要件を満たさない） • などなど • 実装時の解釈・補⾜情報集 • NIST SP 800-63-3 Implementation Resources • コンフォーマンス確認のためのクライテリア集（要件抜き出し＆ID付与＆補⾜） • Conformance Criteria for SP 800-63A Enrollment and Identity Proofing • Conformance Criteria for SP 800-63B Authentication and Lifecycle Management • Conformance Criteria for SP 800-63C Federation and Assertions

PCI DSS Payment Card Industry Data Security Standard

Multi-Step vs. Multi-Factor • 多段階認証と多要素認証 • アクセス許可するまえに全ての要素の 認証が成功しなければならない • 全ての要素が提⽰されるまで認証の 成否が分かってはならない • 多段階だと「ユーザー列挙攻撃(User Enumeration)」可能な実装になりがち “Multi-Factor Authentication version 1.0” https://www.pcisecuritystandards.org/pdfs/Multi-Factor- Authentication-Guidance-v1.pdf https://www.flickr.com/photos/31176607@N05/with/34684294971/ ※多段階認証は基本的には「要素が何であるかに依らない」が、定義によっては「同じ要素の認証を2回⾏う」ことを意味するため注意

PCI DSS的にMicrosoftはNGということ? • 2段階認証かつ2要素認証なUX。 • 識別後に1要素⽬の認証。それが成功してから2要素⽬の認証。 まずは識別 1次認証 (Something you know) 1要素⽬で認証済みの状態で 2要素⽬(Something you have)で2次認証

PCI DSS的にGoogleはNGということ? • 2段階認証かつ2要素認証なUX。 • 識別後に1要素⽬の認証。それが成功してから2要素⽬の認証。 まずは識別 1次認証 (Something you know) 1要素⽬で認証済みの状態で 2要素⽬(Something you have)で2次認証

• 2段階認証かつ2要素認証なUX。 • 識別後に1要素⽬の認証。それが成功してから2要素⽬の認証。 PCI DSS的にAWSはNGということ? まずは識別 1次認証 (Something you know) 1要素⽬で認証済みの状態で 2要素⽬(Something you have)で2次認証

結局Multi-Step AuthenticationはOKに • コミュニティでの質問が相次ぎ、条件付きで認め られることに。 • 3つの認証要素のうち最低2つを利⽤すること。 • ある認証メカニズムは、別のものと「独⽴」であること。 • ある認証要素が別の認証要素へのアクセス許可をあたえない。 • ある認証要素の危殆化が、別の認証要素の⼀貫性・機密性に影 響しない。 • 「独⽴でない」例 • ID/PW認証後に発⾏された認証コードの受け取りメール アカウントに、同じID/PWを⽤いている場合。 →ユーザ依存な側⾯が残るが、判断が難しい。 https://blog.pcisecuritystandards.org/faq-is-two-step- authentication-acceptable-for-pci-dss-requirement-8.3

PCI DSSではパスワードの定期変更が残る • 「パスワード定期変更」については現状v3.2.1でも要件が残ったまま • システム運⽤に関わる「⾮コンシューマ」にはある程度効果的とはいえそう • 「⼈間のいい加減さ」を軽減して、期待した効果が得られる可能性はある • 2020年に次期改定があるため、そのタイミングでの取り込み⽅に注⽬

PCI DSS v4.0 最新ロードマップ • 当初は2021年中ごろにPCI DSS v4.0 公開と⾔われていた • COVID-19などの影響で遅延 • 最新スケジュールでは・・・ • 2022年1⽉にステークホルダー向けのド ラフト公開 • 2022年3⽉に⼀般向け正式版公開 • NISTの改定を取り込んだものになる とされている • v3では対策にも⾔及していたが、 v4では⽬的を記載し、対策に柔軟性を持 たせる⽅向へ Updated PCI DSS v4.0 Timeline (pcisecuritystandards.org) https://blog.pcisecuritystandards.org/updated-pci-dss-v4.0-timeline

FIDO – Fast IDentity Online & WebAuthn https://commons.wikimedia.org/wiki/File:The_FIDO_Alliance_Logo.png https://ja.wikipedia.org/wiki/World_Wide_Web_Consortium#/media/%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB:W3C%C2%AE_Icon.svg

速習FIDO&WebAuthn • 公開鍵暗号を⽤いており、フィッシング耐性に優れた認証⽅式 • ネイティブアプリ⽤、Webブラウザ⽤など複数の仕様群 • FIDO2仕様がW3Cに提供され、Web標準化(WebAuthn) NII Open Forum 2020 AXIES認証基盤部会・学認合同企画「新しい認証技術FIDOの最新動向」 https://www.nii.ac.jp/openforum/upload/20200610-NII%20Open%20Forum%20rF%2B.pdf

• ブラウザのJS APIにWebAuthのIFが追加 • ログイン画⾯でセキュリティキーの挿⼊＆操作を求められる ブラウザ利⽤を前提としたWebAuthn

USB Type-C Bluetooth USB Type-A NFC OpenSK セキュリティキーのOSSを 開発ボードに焼いたもの https://github.com/google/OpenSK

https://media.fidoalliance.org/wp-content/uploads/2020/06/Screen-Shot-2020-06-30-at-8.11.50-AM.png

FIDO Certified Authenticator Level • FIDOのAuthenticatorの実装がセキュアである度合い、HW観点で多くの観点を提供 • Android7+/Windows HelloがPlatformとしてL1認定を取得し⾝近に • NISTがFIPS140-*を参照して「ハードウェア/耐タンパ性」としている部分にフォーカス • ハードウェアといっても細かく⾒れば想定脅威と対策・緩和レベルに明らかな優劣がある、 すなわち物理的なハードウェアだからAAL3要件満たすなどと「安直に」は⾔えない、という背景 Certified Authenticator Levels - FIDO Alliance Level HW&SW要件 耐性 実装例 L1 制限なし • フィッシング耐性 • ⼤規模攻撃に対する耐性 • SWとセキュリティべスプラ 考慮 L2,L3のベースとなる機能要件 Android7+, Windows Hello (実装次第で上位レベル可) L2 許可された (Allowed)ROE(Restricted Operating Environment※)を備える • ハードウェアが保護する AROE • SWレベルの遠隔からの攻撃 耐性 • Security Key (BLE/NFC/USB) • Trusted Execution Environment • ARM TrustZone • Intel VT etc… L3 物理的な攻撃に対してもセ キュリティ上の耐タンパ性 を有するAROE • ハードウェアが保護する AROE • SWレベルの遠隔からの攻撃 耐性 • HWに対する直接的・物理的 な攻撃への耐性 • GlobalPlatform(ICカード、 SEの規格団体) certifiedな TEE • Common Criteria(ISO15408) CertifiedなSE 専⽤HW、メモリがTEEとパッケージングされている、チッ プのパッケージが破られ回路にダイレクトアクセスできる 状態でも解析に⻑期間を要する、などなど

HWベースAuthenticatorにおける ユーザビリティとセキュリティ • HWベースのAuthenticatorはHW紛失が悩ましい • HWベースでは鍵を取り出せない＆さない性質を重視 • HWを紛失すると鍵も紛失 • “Passkeys in iCloud Keychain”でデバイス間同期 • FaceID/TouchIDを⽤いたWebAuth(FIDO2)の秘密鍵を iCloud Keychainを介して同期する [1][2] • Keychain⾃体はパスコードとSecure Enclaveで保護 • 持ち運びはiCloudのHSMで保護 • NFC/BLE/USBで接続する外部Security Keyは対象外 • SP800-63-3では、ユースケース⾃体のセキュリティ の尺度は⾔及されていない • 鍵の複製⾏為は推奨しない、という記述あり • HW&SW&プラットフォーム全てに影響⼒を有するプレイ ヤーは、今後も独⾃の⽅法で実装していくと予想 [1] Move beyond passwords - WWDC21 - Videos - Apple Developer [2] Appleの発表したPasskeys in iCloud KeychainはWebAuthnをどう変 えるのか - r-weblife (hatenablog.com) 強い認証⼿段を使ってもらうためには、 Recoverableであることもとても重要であり、 そこを解決するというメッセージ

HW root of Trustに基づく認証は突破されない︖ • 残念ながらHWにも稀に脆弱性が⾒つかることもある。 • 回路解析で独⾃暗号化アルゴリズムの脆弱性特定(例︓Mifare Classic) • Side Channel Attack(例︓InfineonのTPM、Spectre Meltdown) • グリッチング、Voltage Fault Injection、電⼒差分解析 • 半導体の物理現象 (例︓Row Hammer、bit flipping) • etc… • HW Root of Trustを維持・堅牢にしていくためのセキュリティ 活動にも下⽀えされている、ということを頭の⽚隅においてお きたい。

FIDOと関連の強いAndroidセキュリティ補⾜ • Androidは互換性定義⽂書 (CDD: Compatibility Definition Document) で準拠すべき端末仕様に⾔及 • Android 6: 指紋センサ搭載時はHardware-backed KeyStore※1必須 • Android 7: 鍵のRemote Attestation(構成証明)対応※2など • Android 8: IDのRemote Attestation(構成証明)対応※2など • Android 9: Global Platformに準拠したSecure Element搭載 • スマートフォンのSE搭載状況も踏まえマイナンバーカードのスマホ搭載 について検討中 • 「総務省｜マイナンバーカードの機能のスマートフォン搭載等に関する検討会」 https://www.soumu.go.jp/main_sosiki/kenkyu/mynumber_smartphone/index.html • 「スマートフォンにおける公的個⼈認証サービスの 利活⽤環境実現に向けた調査研究結果」 https://www.soumu.go.jp/main_content/000780433.pdf ※1)Androidハードウェア格納型キーストア: https://source.android.com/security/keystore ※2)Android SafetyNet API: リモートアテステーション(構成情報の完全性チェック)を⾏う機能 ※他)Google_Android_Enterprise_Security_Whitepaper_2020.pdf

NIST SP800-63-4?

NIST SP800-63-4へ向けた動き • SP800-63-4の改定ロードマップは公式 には開⽰されていない • 2020年1⽉に現⾏SP800-63-3に対して パブリックコメントを受け付けるアナウ ンス • さらに2021年3-4⽉にrevision 4の更新 作業を⾏うGithubリポジトリでパブ リックコメント受付け https://github.com/usnistgov/800-63-4

FIDO Allianceによるパブコメ • SMS OTPやPush通知による2要素認証でのフィッシング被害の 増加について警鐘 • フィッシング対策に有効なFIDO/WebAuthn Authenticatorが、 フィッシング耐性の弱いAAL2のAuthenticatorと同列に扱われ るべきではない、という提⾔ https://media.fidoalliance.org/wp- content/uploads/2020/09/FIDO-ALLIANCE-Response-to- NIST-800-63-3-call-for-comments.pdf ※FIDO Authenticator Level 1な Android7+,Windows Hello(SW) を含む （準拠HW実装次第でより⾼いAALと解 釈しうるものもあり） AAL2で利⽤するAuthenticator例 フィッシングに弱い共通 シークレットベース AAL3で利⽤するAuthenticator例 PW + フィッシング耐性を有 する⾮対称鍵ベース (SWまたは限定的な耐 タンパ性※) 現⾏のAAL2の中には、ユーザー保護の有効性のレベルが 異なるものが混在するので、区別すべき、という主張 フィッシング耐性を有する ⾮対称鍵ベース (HWによる⾼い耐タンパ性 を有する) Weak Strong

派⽣トピック︓Windows

Microsoftのセキュリティベースラインにも変化 • WindowsにおけるPW有効期限のセキュ リティベースラインが改定された。（デ フォルト42⽇は変化なし） • セキュリティベースラインは“Microsoft Security Compliance Toolkit 1.0”とし て配布されており、パスワードの有効期 限設定が評価されなくなっている※。 • Microsoft 365では既にNISTの新しいベ スプラに変更済み。 （デフォルト無期限） https://blogs.technet.microsoft.com/secguide/2019/05/23/security- baseline-final-for-windows-10-v1903-and-windows-server-v1903/ Windows 10 May 2019 Updateで セキュリティベースライン改定 ※Windows 10の「パスワード期限切れポリシー」は廃⽌なんかされていない︕ https://atmarkit.itmedia.co.jp/ait/articles/1907/24/news008.html

https://docs.microsoft.com/ja-jp/office365/admin/misc/password-policy- recommendations?view=o365-worldwide

https://docs.microsoft.com/ja-jp/office365/admin/misc/password-policy- recommendations?view=o365-worldwide

パスワードレス

「パスワードレス」の動きが加速中 • Windows Helloで顔認識ログイン • ⽣体要素 or 知識要素 • Authenticator活性化のためのローカル認証 • 所有要素（⾮対象鍵暗号を⽤いた鍵所持証明） • Global Platform準拠SE利⽤時はAAL3とみなせる(はず) • WebではWindows Helloに加え、 MS Authenticatorアプリでログイン • Push通知クリック＋⽣体認証 • このUXは多くの他の事業者も採⽤(Google他) 参考）クラウド時代の認証保護 MicrosoftとFIDO、パスワードレスへの流れ https://www.slideshare.net/FIDOAlliance/microsoftfido 参考）Azure Active Directory を使⽤して NIST AAL3 を達成する https://docs.microsoft.com/ja-jp/azure/active-directory/standards/nist-authenticator-assurance-level-3

真のパスレス「パスワード無効化」も始まった • パスワード認証⾃体をできなくする • NIST SP800-63-3的にはパスワードが使えないと 多要素Authenticatorが必要 • Authenticator紛失時のリカバリへの考慮が⼤切 • ⽇本でもパスワード無効化を⾏う事業者登場 • Yahoo! JAPAN ID • リカバリ（パスレスの解除）には、SMSまたはメールの どちらか⼀⽅での確認でOKとしている。（SMS/メール ともに登録値を指定する必要がある） • docomo ID • スマホ紛失時のリカバリには、SIMによる回線認証 or メール・SMS双⽅での確認を必要としている。 Microsoftアカウントのセキュリティ設定画⾯ （パスワード無効化） How to go passwordless with your Microsoft Account https://support.microsoft.com/en-us/account-billing/how-to-go-passwordless-with-your-microsoft- account-674ce301-3574-4387-a93d-916751764c43 Yahoo! JAPAN （パスワード無効化） docomo （パスワード無効化）

認証にまつわる事件

象徴的だった「ドコモ⼝座」事件 • 決済サービスである「ドコモ⼝座」への⼊⾦元であり連携相⼿であ る銀⾏から、不正にドコモ⼝座に預⾦がチャージされ、コンビニな どで換⾦性の⾼い商品の購⼊を経て換⾦されるなどにより⾦銭的被 害が発⽣した事件 • 潜在的に同様の問題を抱えているサービスは多いのかもしれない • 他のサービスでも類似の被害が報告されていた • 同時期に銀⾏との紐付け機能などを閉塞するサービスも複数あった 不正な紐づけ （脆弱な認証） 正当な紐づけ 正当なユーザーの 銀⾏⼝座 不正なユーザー （⾝元を詐称して登録し放題） 正当なユーザー 正当な チャージと利⽤ 不正な チャージと利⽤ 商品を換⾦し 資⾦洗浄 何らかの⼿段で特定した ⼝座番号や4桁の暗証番号 で勝⼿に銀⾏と紐付けてしまえ ⾜がつきにくい⼿段 （出し⼦など）で 換⾦性が⾼い商品購⼊

紐づけパターン別のシナリオと対策⽅針 • ⾃⾝のサービスの状態を分析・整理することで、IAL/AALの強化が⾃分のビ ジネスのどの不正シナリオの対策となりうるか分析することが有⽤ • 追加制約によるリスク低減策もあるが、デメリット・制約を踏まえて要検討 • 取扱い額キャップ、段階的な機能解放、⼀意な携帯紐付け、⽒名・⽣年⽉⽇突合 etc Pay系 サービス ⾦融 機関 不正イメージ (ビジネス構造により異なる) 対策 (Pay系) 対策 (⾦融機関) 正当なユーザーと正当な⼝ 座とを紐づけて利⽤ 正当 正当 なし（正常利⽤） AAL強化 (認証強化し正当なユー ザーをアカハクを防⽌) AAL強化 (認証強化し正当な⼝座の アカハクを防⽌) 正当なユーザーと悪意ある ⼝座とを紐づけて利⽤ 正当 悪意 Pay系サービスの正当なユーザー をアカハクし、悪意のある⼝座と の紐付け＆出⾦ AAL強化 (認証強化し正当なユー ザーをアカハクを防⽌) IAL強化 (⾝元確認を強化し悪意あ る⼝座の作成防⽌) 悪意あるユーザーと正当な ⼝座とを紐づけて利⽤ 悪意 正当 他⼈の⼝座から、Pay系サービス 悪意あるユーザーのフロントサー ビスへの不正チャージ IAL強化 (⾝元確認を強化し悪意あ るアカウントの作成防⽌) AAL強化 (認証強化し正当な⼝座の アカハクを防⽌) 悪意あるユーザーと悪意あ る⼝座とを紐づけて利⽤ 悪意 悪意 Pay系サービスと⼝座との紐づけ キャンペーンでの特別ポイント繰 り返し取得を繰り返し獲得して集 約（何らか出⼝機能を経て換⾦） IAL強化 (⾝元確認を強化し悪意あ るアカウントの作成防⽌) IAL強化 (⾝元確認を強化し悪意あ る⼝座の作成防⽌) 例︓4PINダメ! 例︓携帯番号必須

Authentication(認証)を語り尽くすには Identity Proofing(⾝元確認)の理解が必須 • NISTでもIALとAALは密接な関係 • ⾝元確認レベル(IAL)≧認証レベル(AAL)だとリカバリに都合良し • Authenticator喪失時は、登録時IALプロセス再実施&再登録 • ⽇本政府・⺠間セクタの⾝元確認 • 「⾏政⼿続におけるオンラインによる本⼈確認の⼿法に関するガイドライン」 https://www.kantei.go.jp/jp/singi/it2/cio/kettei/20190225kettei1-1.pdf • 犯収法、携帯法、古物法、出会い系規制法 etc... • NIST IAL ”Supervised Remote”の解釈と国内eKYCの「本⼈容貌確認」 • FATF第4次対⽇相互審査とAML(マネロン対策)の継続的CDD • 欧州eIDAS、改定されたNZ政府EOI Standard... • Identityの「確からしさ」を検証する観点 • 真正性︓証跡が改ざんされないこと • 実在性︓実在すること • 当⼈性︓間違いなく当⼈であること • ⼀意性︓複数登録されていないこと • ⽣存性︓⽣存していること • 継続性︓成り替わりや変容していないこと 「本⼈確認」のニュー・ノーマル – 崎村夏彦 http://www.anisec.jp/yuzawa/wp- content/uploads/2020/10/5b72022af3f96d 45ad9be7e42fa2412a.pdf サービス事業者のための本⼈確認⼿続き （KYC）に関する調査レポート https://www.openid.or.jp/news/2020/01/ky cwg-report.html

Digital Identity Journeyは続く…

このような「過渡期」をどう進むか • ベスプラと法令・業界等の「コンプライアンス順守」は別問題 • 適合基準／認定プロセスの枠組みで、新しいベストプラクティスとの 差異があっても、それはそれ。 • 変化の⽅向性を把握して「次に打つべき⼿」を検討 • SP800-63-3の改定はシステム的な機能追加を要する要件が多い。 • 近い将来業界が求める要件を先読みし、コスト投下ポイントを⾒定め。 • 特定の変更点だけをピックアップして都合よく解釈するのはやめよう。 • パラダイムシフトを起こすのはガイドラインではなく事業者 • 「効果はゼロではない」か「どんぐりの背⽐べ」の議論ではなく「効 果が⾼い施策」にシフトレフト。(例えば多要素認証の導⼊) • ⼤変なのは、⼤変よく分かります。 • ⽭盾も不整合も把握したうえでリスクを踏まえて⼿を打てるのは、 「保護すべきユーザ」に直接相対しているからこそ。

「やっぱり認証とか デジタルアイデンティティって ⾯倒で地味なテーマだな」 とか思っていませんか︖

デジタルアイデンティティは「今だに」アツい • FIDO/WebAuthn/⽣体認証でパスワードレス • 「なるべく」パスワードを使わない世界へ • ⾦融グレードAPI/FAPIを⽀えるOAuth2/OpenID Connect • Financial APIを公開したので使ってください、が普通になるかも • ⾝元確認(eKYC)の重要性の⾼まりとマイナンバーカード • ⾦融機関など⾝元保証レベル(IAL)の⾼い⼿法で実施されたKYC結果を流通 • 公的個⼈認証によって⾼いIALを必要とする⾏政サービスを容易に利⽤開始 • Self-Sovereign Identity/Decentralized Identifier/ Verifiable Credential • ⾃分のアイデンティティは⾃分で管理（ユーザセントリック） • あらゆるサービスに通⽤する⾃分⾃⾝の永続的な識別⼦

まとめ • デジタルアイデンティティフレームワークとして再編された NIST SP800-63-3、特に63Bの考え⽅を通じて共通⾔語を得た • 63A︓登録プロセスと⾝元確認 • 63B︓認証とライフサイクル管理（★本⽇フォーカス） • 63C︓フェデレーションとアサーション • 「パスワード認証」で⼀⼤転換 • パスワードからパスフレーズへ • パスワード定期変更は「事業者(CSP/Verifier)が採る対策として(禁⽌はしないが)⾮推奨」 • 秘密の質問の廃⽌で、アカウントリカバリは複雑さを増していく • SMS認証は要観察 • ⽣体認証は「今」は補助的なもの • 過渡期の⽭盾や解釈の曖昧さに翻弄されず、⽅向性を⾒極めよう • 細部を⾒ると課題はあるが、進むべき⽅向性は⽰されている • デジタルアイデンティティはセキュリティ/UX/ビジネスに関係し、アツい期間が継続中 https://www.flickr.com/photos/alexristea/5636821732/

ありがとうございました 感想はお気軽にご連絡ください 誤りなどご指摘いただけると⼤変助かります [email protected]; @kthrtty https://www.flickr.com/photos/alexristea/5636821732/

(Blank) https://www.flickr.com/photos/alexristea/5636821732/