IERAE NIGHT 2024: Crypto「2024年、どんな認証を採用する？～認証の世界観と認証技術のあれこれ～」

自己紹介 ■基本属性 姓名 名古屋 謙彦 （なごや よしひこ） 所属 サイバーセキュリティ事業本部 高度解析部 高度解析課 ■その他の属性 Twitter（X） BlueSky Discord 属性タグ あよくら @ayokura @ayokura.net @ayokura CISSP/CC/クリスチャン エンジニアではない人でも簡単・安全にインターネットを利用できるように、 デジタルアイデンティティや認証連携などの技術の適切な利用を広めていきたいです。 デジタルアイデンティティの技術は、インターネット上で（実世界でも）、 僕が僕であることを、あなたがあなたであることを証明できる大切なパーツであり、 学生自体から今に至るまで大好きな領域です。

今日のテーマ デジタルの世界での「個」を どのようにして表現し どのようにして証明するか

目次 • Digital Identity とはなにか • 認証とはなにか • 近年の動向

Digital Identity とは

Digital Identityとは • Digital Identityって何だとおもいますか？ なぜこの発表者は「ユーザー」や「利用者」ではなく Digital Identityという概念を使うのでしょうか？ 「ユーザー」や「利用者」はDigital Identityだけでなく、Physicalな （物理的な・精神的な）存在も含まれる考えられるものだからです。

Digital Identityとは アメリカのNISTでは、SP800-63 Digital Identity Guidelines の最新の草稿であるSP800-63-4 2nd Public Draftにおいて、 digital identityを以下のように説明しています。 An attribute or set of attributes that uniquely describes a subject within a given context. 「あるコンテキストにおいて、ある主体をユニークに説明することができるようになる属性の集合、 または単一の属性」 また、国際標準であるISO/IEC 24760-1:2019は以下のようにidentityを説明 します。 set of attributes (3.1.3) related to an entity (3.1.1) Note 1 to entry: An entity can have more than one identity. Note 2 to entry: Several entities can have the same identity. 「ある存在に紐づく属性の集合。一つの存在は複数のidentityを持つことができる。いくつかの 存在が同一のidentityを持つこともできる。」

Digital Identityとは • 僕の言葉で説明すると… • コンピューターシステム上で私たちを表す コンピューターシステムの中では属性の集合です。 • Webアプリを書いたことがある人たちは Userをテーブルとリレーションであらわすことができることを知っているかもしれません。 • これらはその人自身と確かに紐づくもので、それがDigital Identityです。 • 属性集合の全体はもちろんですし、その属性集合の部分でもそうかもしれません。 • また、ユニークにどのユーザーかを表すことのできる識別子となれる属性は単一に Digital Identityかもしれません。 • ただ……僕たちは一度記録された属性集合のままでいるわけではな い（ことも多い）ですよね……？

更新されつづける属性集合 • 一度、コンピューターシステムとの接続を切ってしまうと、 その更新のためには、再度紐づけなおす作業が必要になります。 • 一度Digital Identityに再度つなぐために用いられるのが認証技術です。 • もっと僕の中での表現にすると、 • このインターネットという電子の海で、僕が僕であることを、 君が君であることを証明する。 そのための必要不可欠な技術が認証技術であり、 それが実現していることが更新が可能なDigital Identityだと思っています。

Digital Identityサービスの類型 • Digital Identity を用いるサービスの類型（講演者の視点） • 両方を併せ持つものがほとんどですが、メインがどっちかという観点で • 登録時の属性を利用してDigital Identityを確立するもの • 通販だったり、ネットバンキングだったり、チケット購入サービスだったり • その属性をメインとしてにサービスを提供する • 登録時は最低限の属性のみで その後のActivityがDigital Identityを確立するもの • Twitter / Instagram / YouTube など • 積み重ねていく発言や記録・フォローが 各アカウントのDigital Identityを形作っていく

認証の基礎

認証（Authentication）に期待されること • 対象を識別できること • Aさんだよってことがわかること • 識別された対象以外が利用できないこと • BさんがAさんの振りをしても、Aさんとして認証できないこと • 識別された対象が利用できること • Aさんが使いたいときに、拒否されないこと システムに認証を実装するとき、これらのバランスをどのようにするかは そのシステムの持つ性質によって異なってきます

認証を構成する要素 • 正しいユーザであることを確認するために、そのユーザしか作れない 情報を利用(Credential / Secretなどといわれたりする) • 知識による認証 (What you know) ：パスワード等 • その人しか知りえない知識を使う • 所有による認証 (What you have) ：ICカード・秘密鍵・電話番号など • その人しか持たない何かを使う • 生体による認証 (What you are) ：指紋・顔・虹彩等のバイオメトリクス • その人であることを確率的に判断できるような測定結果を使う • バイオメトリクス認証は確率的であり、秘密の情報を使うわけではないので注意 • 個人的には個人のバイオメトリクス情報自体はCredentialではないと考えるところ

認証の隣にいる技術 • Identity Proofing (身元確認、 近い意味としてKYC、eKYCとも) • 示されたIdentityを構成する属性が正しいことを検証する • メールアドレス・電話番号： メール・SMSや音声通話のワンタイムコード（リンクのことも） • 氏名： 顔写真付き身分証明書を利用したeKYCや、電子証明書を利用したeKYC • 住所： 氏名同様の方法や、転送を禁止した郵便物（転送不要郵便）を利用 • 登録時やリカバリ時などに利用されている • 認可 (Authorization / AuthZ) • 「処理が許可されている？」を確認 • あらかじめ決めたポリシー （認可ポリシー）に基づいて確認 • アクセス制御、アクセスコントロール

認証の対象いろいろ • ユーザー認証 • ここまで説明してきたユーザーに対する認証 • サーバー認証 • TLS（HTTPSなど）やSSHではサーバーが正しいかを公開鍵証明書で確認 • クライアント認証 • クライアントが正しいクライアントであるかを確認。TLSクライアント認証や Client Secretを用いた認証など。

出来ればシンプルに管理したい • Webサーバの数だけ認証が必要 • ユーザ：多くのID/パスワードを覚えたくない・管理したくない • Webサーバ：できることならID/パスワードを管理したくない • 認証連携・ID連携 • 認証を行い、その結果を他のサービスに渡すサーバ • Identity Provider（IdP）やCredential Service Provider(CSP)と呼ばれる • パスワードなどのCredentialを管理するのが役割 • 認証結果を利用するサーバ (Relying Party: RP) • RPは全面的に、IdP/CSPを信頼する（IdP/CSPにトラストを置く） • RPでは、Credentialを持つ必要がない • IdP/CSPの送ってくる認証結果（属性）を使って処理する

昨今の動向と 今後の技術

ここ10年くらいの動向 • スマートフォンの定着と、ローカル生体認証の定着 • Androidでの各種生体認証や、iOS でのTouch ID / Face ID • 攻撃動向 • パスワードリスト型攻撃 • フィッシング攻撃 • 偽サイト型 • Adversary-in-the-Middle（AiTM）型 • 多要素認証に対する疲労攻撃（MFA Fatigue Attack） • ブラウザ上での認証技術の変化 • 10年前のブラウザ上での認証技術 • パスワードマネージャーの普及 • WebAuthn / FIDO / パスキー の実装

ここ10年くらいの動向 • スマートフォンの定着と、ローカル生体認証の定着 • Androidでの各種生体認証や、iOS でのTouch ID / Face ID • 攻撃動向 • パスワードリスト型攻撃 • フィッシング攻撃 • 偽サイト型 • Adversary-in-the-Middle（AiTM）型 • 多要素認証に対する疲労攻撃（MFA Fatigue Attack） • ブラウザ上での認証技術の変化 • 10年前のブラウザ上での認証技術 • パスワードマネージャーの普及 • WebAuthn / FIDO / パスキー の実装

スマートフォンと、ローカル生体認証の定着 • 生体認証の特性 • 基本的に一生涯変えられない • 指紋はもちろん現在の顔認証は数年後の顔・数十年後の顔であっても認識できるものも多い • 確率的な認証となる • １か０ではなくその間がある • 他人受入率（FAR）と本人拒否率（FRR）というパラメーターで呼ばれる • 中央管理型の生体認証はあまりおすすめできない • それしかない場合やそれが向いてる場合もあるけど • スマートフォンに実装された指紋認証・顔認証・虹彩認証などの バイオメトリクス認証はローカル認証として当たり前に利用されている

ここ10年くらいの動向 • スマートフォンの定着と、ローカル生体認証の定着 • Androidでの各種生体認証や、iOS でのTouch ID / Face ID • 攻撃動向 • パスワードリスト型攻撃 • フィッシング攻撃 • 偽サイト型 • Adversary-in-the-Middle（AiTM）型 • 多要素認証に対する疲労攻撃（MFA Fatigue Attack） • ブラウザ上での認証技術の変化 • 10年前のブラウザ上での認証技術 • パスワードマネージャーの普及 • WebAuthn / FIDO / パスキー の実装

フィッシング攻撃 • 昔から多くあるタイプ（以下、従来型） • 偽サイトを作り、そのフォーム上から属性情報を盗む • メールアドレス・パスワード・氏名・住所・電話番号・（二要素認証用の）乱数 表の中身・クレジットカード情報など • 二段階認証も突破できるAiTM型 • ユーザーからの入力を本来のサイトに転送して認証させることで セッションを奪い取る • ドメイン自体が偽物なことは基本的に変わらないが、単独で動作する偽サイト ではなく本来のサイトを使って動く

フィッシング攻撃 • 人間のみを信頼する場合の限界が明らかになった。 • リモート認証ではクライアント側のコンピュータやスマートフォンについても 信頼するような動きが増えた • 従来型への対策 • 記憶シークレットを窃取された場合の攻撃に備えた対策が進んだ • パスワードリスト型攻撃と同様の対策 • 対策が進んだIdPの認証連携を利用し、自分では作りこまない など • AitM型への対策 • WebAuthn・FIDO・パスキーといった、フィッシング耐性のある認証手段

多要素認証に対する疲労攻撃 • どんな攻撃？ • プッシュ通知を用いたサービスに対し連続して多要素認証要求を送ることで 利用者が誤って承認することを狙う攻撃 • 英語ではMFA Fatigue Attack • どんな影響があった？ • Microsoft Authenticatorなどで、単純に「はい」を押すだけではなく ログイン画面上に表示された数字・記号等の選択や入力が必要になった • プロトコルに疲労攻撃対策として利用できる機能が定義されるようになった。 • （ちなみにＦＩＤＯでは、Authenticatorとの間で近接することを必ず求めている）

ここ10年くらいの動向 • スマートフォンの定着と、ローカル生体認証の定着 • Androidでの各種生体認証や、iOS でのTouch ID / Face ID • 攻撃動向 • パスワードリスト型攻撃 • フィッシング攻撃 • 偽サイト型 • Adversary-in-the-Middle（AiTM）型 • 多要素認証に対する疲労攻撃（MFA Fatigue Attack） • ブラウザ上での認証技術の変化 • パスワードマネージャーの普及 • WebAuthn / FIDO / パスキー の実装

FIDO（Fast IDentity Online） • 電子署名を使い、秘密鍵を持っているならば本人だよね、という認証 • 主要ブラウザ・主要OSが対応している • ブラウザ側のAPIはWebAuthnとして2019年3月に標準化され、以後も改良されている • フィッシング攻撃・リプレイ攻撃などに対する耐性がある • 詳細はFIDOセキュリティリファレンスを参照 FIDO認証モデル User Authenticator ローカル認証 client RP リモート認証（署名） リモート認証モデルにおける認証の機能(識別と検証)が分離されて 検証機能がユーザーの保有するデバイス側に存在 FIDOセキュリティリファレンス: https://fidoalliance.org/specs/common-specs/fido-security-ref-v2.1-ps-20220523.html

• https://fidoalliance.org/specs/common-specs/fido-security-ref-v2.1-ps-20220523.html

パスキー（passkeys) • 「パスワード」を置き換えるものとして「パスキー」としてブランディング • 実体はFIDO Credential（Authenticatorが保管するCredential） • 3種のFIDO Credential（≒パスキー） • 同期パスキー： デバイスを超えて、同期可能になったパスキー • デバイス固定パスキー： デバイスの中でとどまるパスキー • FIDOセキュリティキー： 持ち運べるFIDOセキュリティキー • FIDOアライアンスではパスキーは名詞として以下のように説明されている • FIDO標準に基づき、パスキーはパスワードに代わるもので、ユーザーのデバイスに またがるウェブサイトやアプリへのサインインをより迅速、簡単、かつ安全に行うことが できる。 パスワードとは異なり、パスキーは常に強固でフィッシングに強い。 • パスキーは、アプリやウェブサイトのアカウント登録を簡素化し、使いやすく、ユーザー のほとんどのデバイスで機能し、物理的に近くにある他のデバイスでも機能する。 https://fidoalliance.org/passkeys/?lang=ja

• https://fidoalliance.org/passkeys/?lang=ja

まとめ

まとめ • Digital Identityは、僕やあなたを表す属性の集合 • 認証は、誰かを識別して、その誰かであるかを検証している • 認証に対する攻撃への対抗を容易にするため、 対抗するためにパスキーなどの技術が進化してきた。 • 時間の都合で紹介できなかった技術たち： OpenID Connect / クロスデバ イスでの(FIDO以外の)認証 / フィッシング耐性 / Wallet model / Credential exchange / NIST SP 800-63-4 / FedCM / Private Access Token • いま、君は何に信頼を置いて、どんな優先順位で認証を設計する？

おすすめ資料 • Sign-up / Sign-inのフォームに関するベストプラクティス（可能なら 英語で読むのがおすすめ） • https://web.dev/articles/sign-up-form-best-practices • https://web.dev/articles/sign-in-form-best-practices • この半年の動向について崎村さんがまとめた記事 • https://www.sakimura.org/2024/08/6233/ • 個人的に気になってるDraft類 • https://datatracker.ietf.org/doc/draft-ietf-oauth-crossdevice-security/

• https://web.dev/articles/sign-up-form-best-practices
• https://web.dev/articles/sign-in-form-best-practices
• https://www.sakimura.org/2024/08/6233/
• https://datatracker.ietf.org/doc/draft-ietf-oauth-cross-device-security/