0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

お題は不問！Qiita Tech Festa 2026で記事投稿！
Qiita Tech Festa20262026年7月13日まで開催中！
@amu-kuroneko(kuroneko)Team Tea & Water

その多要素認証、どの攻撃に効いてますか？ ── 脅威で認証を整理し直す【CySec復習ログ#6】

0
Posted at

はじめに

少し前の私は、自分が運用するサービスにログイン機能と多要素認証(MFA)を入れていました。けれど、やっていたことは「とりあえずパスワードに加えて SMS のワンタイムコードも要求しておく」止まりでした。「多要素にしたから安全」と思い込んでいて、その対策が どの攻撃に効いて、どの攻撃には効かないのか を一度も整理したことがなかったのです。

この記事は、CySec(東京電機大学が提供する社会人向けのサイバーセキュリティ教育プログラム「国際化サイバーセキュリティ学特別コース」)で学んだ内容を、自分の言葉で再構成した復習ログです。本シリーズの通し番号では #6 にあたります。想定読者は、少し前の私と同じく「ログインや MFA を実装・運用しているが、『とりあえず多要素にした』止まりで、その対策がどの脅威に効くのかを整理できていないエンジニア」です。

この記事の軸になる見方を、先に1行で書いておきます。

認証は「どの脅威に効いて、どの脅威に効かないか」で整理できる。

結論を先に3点でまとめておきます。本文はこれをほどいていく形です。

  1. パスワード攻撃は「オンライン/オフライン」で分かれ、アカウントロックが効く範囲もそこで分かれる。 オフライン攻撃やリスト型攻撃にはロックが届かない。
  2. 多要素にしても AiTM や MFA 疲労攻撃で破られる。だから必要なのはフィッシング耐性で、SMS ワンタイムコードはそれを満たせない。 つまり「パスワード＋ SMS」止まりは、AAL2 が求めるフィッシング耐性の水準に届いていない。NIST SP 800-63 の AAL が対策の強さの共通のものさしになる。
  3. 暗号の認証利用の核心は「鍵の所有証明=チャレンジレスポンス」。鍵はライフサイクル・2030年問題・耐量子まで面倒をみる。 その鍵が本人のものだと保証するのが PKI。

「パスワードを長く複雑にする」も「多要素にする」も「パスキーにする」も、それぞれ効く脅威と効かない脅威があります。やみくもに対策を積むのではなく、脅威の地図の上に対策を並べ直すと、自分のサービスに足りないものが見えてきます。読み終えたとき、自分のサービスの認証を「これはどの攻撃に効いているんだっけ?」と棚卸ししたくなれば成功です。なお私自身まだ学習中なので、間違いがあれば指摘していただけると助かります。

なお、対称鍵・公開鍵・ハッシュ・デジタル署名といった暗号の 仕組み そのものは、同シリーズの第4回(暗号)で詳しく扱いました。この記事ではそれらを「認証にどう使うか」に絞り、仕組みの再解説はしません。仕組みが気になったら第4回(暗号)を参照してください。

認証の前に「識別」がある ── 識別・認証・認可は別物

認証の話を始める前に、混同されがちな3つの言葉を分けておきます。講義の冒頭でも、ここがいちばん最初に整理されていました。

  • 識別(Identification): 「あなたは誰ですか?」に対して、ユーザ ID のような 識別子 を割り当てる段階です。印鑑証明の世界でいえば、印鑑を登録して登録番号をもらうところにあたります。
  • 認証(Authentication): 与えられた識別子が 本当に正当な持ち主のものか を検証する段階です。「ID が alice だと名乗っている人は、本当に alice 本人か?」を確かめます。
  • 認可(Authorization): 認証が済んだ相手に、何をしてよいか(読む・書くなどの権限)を与える段階です。

この記事で扱うのは、真ん中の 認証 です。認証とは、講義の定義では「対象(人・デバイス・データ)の正当性を検証する作業」でした。

ここで押さえておきたいのは、識別がいい加減だと認証は無意味になる ということです。誰の ID かもあやふやなまま「正当性を検証」しても、何を検証しているのか分かりません。識別・認証・認可は、この順番で積み上がる土台のような関係です。

そして、認証と認可は アクセスコントロール を実現するために存在します。アクセスコントロールとは「誰が(Subject)・何に対して(Object)・どうするのか(Operation)」をコントロールすることです。今回扱う認証は、この「誰が」を確かめる部分にあたります。

もう1つ、講義で強調されていた言葉が 説明責任(Accountability) です。「いつ・誰が・何をしたか」を記録しておくことで、インシデントが起きたときに原因を追えます。認証がしっかりしているからこそ「誰が」を特定でき、説明責任が成立します。認証は、その場のログインを通すためだけのものではなく、あとから事実をたどるための土台でもあるわけです。

認証の3要素と、認証連携でパスワードを減らす

認証で使う「材料」は、大きく3種類に分けられます。これを 認証の3要素 と呼びます。

要素 英語 中身 例
知識認証 Something You Know 本人しか知りえない情報 パスワード、暗証番号
所有物認証 Something You Have 本人だけが持っているモノ IC カード、USB トークン、スマートフォン
生体認証 Something You Are 本人の身体的な特徴 指紋、静脈、虹彩、顔、声

後で出てくる「多要素認証」は、この3要素のうち 2つ以上 を組み合わせたものです。まずはこの3分類を頭に置いてください。

ところで、現実にはサービスごとに ID とパスワードが増えていきます。銀行・ショッピング・SNS・社内システムと、数えきれないほどの ID を持つのが当たり前になりました。ユーザは多くの ID・パスワードを管理したくないし、サービス側も大量の認証情報を抱えたくありません。

この問題への答えが 認証連携(ID 連携) です。認証を行って、その結果を他のサービスに渡す役割を IdP(Identity Provider) や CSP(Credential Service Provider) と呼びます。認証結果を受け取って利用する側のサービスを RP(Relying Party) と呼びます。

ここで効いてくるのが、RP は認証情報(Credential)を持たない という点です。パスワードを保管するのは IdP/CSP だけで、RP は「IdP が認証してくれた」という結果を信じます。Google や Microsoft のアカウントで他サービスにログインできるあの仕組みです。認証情報を1か所に集めることで、漏えいの面を小さくできます。この「認証結果を伝える強度」の話は、後半の NIST のガイドラインでもう一度出てきます。

パスワード攻撃の地図 ── アカウントロックが効く攻撃・効かない攻撃

ここからが、この記事の背骨です。まず、いちばん身近な「知識認証=パスワード」が、どんな攻撃にさらされるのかを地図にします。

講義で挙げられたパスワードへの攻撃は5種類でした。

  • 推測: 誕生日・自分や家族・ペットの名前など、推測できる値を試す。
  • 総当たり攻撃: すべての文字の組み合わせを順に試す。
  • 辞書攻撃: よくある単語や短いパスワードを、辞書を使って試す。
  • レインボーテーブル攻撃: 盗み出したパスワード DB(のハッシュ値)を、事前計算した表で一気に解析する。
  • リスト型攻撃: どこかで漏れた「正しい ID とパスワードの組」を、別のサービスで使い回しを狙って試す。

長く複雑なパスワードは、何に効くのか

「パスワードを長く複雑に」とよく言われますが、それが効くのは主に 推測・総当たり・辞書攻撃 です。総当たりの大変さを、講義の試算で見てみます。

ここで注意が必要なのは、これは 「1GHz の CPU で1秒間に10億通り試せる」と仮定した場合 の数字だという点です。あくまで桁感をつかむための仮定値です。

パスワードの種類 組み合わせの数 総当たりにかかる時間(上記の仮定)
数字4桁 1万通り 瞬殺
英大文字小文字数字記号8桁 約5595兆通り 約2か月
英大文字小文字数字記号10文字 約4839京通り 約1536年

10文字で約1536年と聞くと「総当たりは無理」と思えます。ただし、これはあくまで仮定の計算速度です。実際には GPU や専用ハードウェア(ASIC)を並べればこの何桁も速くなりますし、計算機は年々速くなります。第4回で触れた DES が、アルゴリズムの欠陥ではなく「鍵空間が計算機に追い越されて」破られたのと同じ構図です。「いまの感覚で安全な桁数」は、時間とともに削れていきます。だからこそ、同じ仮定でも文字数を増やせば組み合わせは桁違いに跳ね上がり、総当たりは現実的でなくなります。後述する NIST が単一要素のパスワードに15文字を求める背景も、ここにあります。

核心: オンライン攻撃とオフライン攻撃

ここで、この記事でいちばん持ち帰ってほしい分類が出てきます。先ほどの5つの攻撃は、オンライン攻撃 と オフライン攻撃 に分けられます。

  • オンライン攻撃: 実際のログイン画面に対して試行する攻撃。推測・総当たり・辞書・リスト型がこれにあたります。
  • オフライン攻撃: 盗み出したパスワード DB を、攻撃者の手元で解析する攻撃。レインボーテーブル攻撃がこれにあたります。

この区別が決定的に重要なのは、アカウントロックが効くかどうかが、ここで分かれる からです。

攻撃 種別 アカウントロックは効くか
推測 オンライン 効く(試行回数を止められる)
総当たり攻撃 オンライン 効く
辞書攻撃 オンライン 効く
リスト型攻撃 オンライン 効きにくい(後述)
レインボーテーブル攻撃 オフライン 効かない

アカウントロック(一定回数の失敗でログインを止める)は、ログイン画面で何度も試すオンライン攻撃には有効です。何百万回も試す前にロックされるからです。

ところが、レインボーテーブル攻撃のような オフライン攻撃には効きません。攻撃者はすでにパスワード DB を手元に持っていて、攻撃対象のログイン画面を一切叩かないからです。ロック機能はログイン画面の前に立っている門番なので、門の外で勝手に解析されているかぎり手出しできません。だからこそ、第4回や講義で繰り返された「パスワードは SALT 付きハッシュで保存する」という対策(DB が漏れても解析されにくくする)が、オフライン攻撃への備えとして効いてきます。

もう1つ、リスト型攻撃 が要注意です。これはオンライン攻撃ですが、攻撃者は「正しい ID とパスワードの組」を試すので、ログイン自体は1〜2回で成功してしまいます。失敗を重ねないので、アカウントロックをすり抜けやすい のです。パスワードを長く複雑にしても、使い回していて他サービスから漏れていれば、リスト型攻撃の前では無力です。

こうして地図を描くと、「パスワード単体」では守りきれない範囲がはっきりします。長く複雑にしてもオフライン攻撃やリスト型攻撃には届かない。だから、別の要素を足す 多要素認証 へ進みます。

多要素にしても破られる ── AiTM と MFA 疲労攻撃

多要素認証(MFA) とは、先ほどの3要素(Know / Have / Are)のうち 2つ以上 を要求する認証手法です。講義で挙がっていた身近な例はこうでした。

  • 銀行のキャッシュカード: 暗証番号(Know)とカード(Have)。
  • スマートフォン: スマートフォン本体(Have)と生体認証(Are)。

要素を増やせば、どれか1つが漏れても突破されにくくなります。ただし、それぞれの要素にも固有の弱点があります。

生体認証は「比較」なので完璧ではない

生体認証(Are)は、Know や Have とは性質が違います。Know は「知っているか/知らないか」、Have は「持っているか/持っていないか」で、答えが白黒つきます。一方、生体認証は登録したデータと どれくらい似ているか を比較するので、本質的に曖昧さが残ります。

そのため、2種類の誤りがついて回ります。

  • 本人拒否率(FRR: False Rejection Rate): 本人なのに「別人」と判定してしまう率。
  • 他人受入率(FAR: False Acceptance Rate): 別人なのに「本人」と通してしまう率。

判定のしきい値を厳しくすると FAR は下がりますが FRR が上がり(本人がはじかれてイライラする)、緩くすると逆になります。この2つはトレードオフで、用途に応じてしきい値を調整します。さらに、生体情報は 盗まれても変更できません(指紋を取り替えるわけにはいきません)。だから生体データはネットワークに流さず、手元のデバイス内で照合する「ローカル認証」が基本になります。

多要素でも破られる2つの攻撃

では、要素を増やせば安心かというと、そうではありません。講義の本筋とは別に、講師から補足された(そしていま現場で問題になっている)2つの攻撃があります。これらは講義スライドの外なので、一次情報を確認したうえで書きます。

1つめは AiTM(Adversary-in-the-Middle、中間者)攻撃 です。攻撃者は本物そっくりの偽ログインページを リバースプロキシ として用意し、ユーザと本物のサイトの間に割り込みます。手口は次の流れです。

  1. ユーザが偽ページに入力した ID・パスワードを、攻撃者がリアルタイムで本物に中継する。
  2. その後ユーザが入力したワンタイムコードも、同じく本物に中継する。
  3. 本物が発行した セッションクッキー を、攻撃者が横取りする。
  4. クッキーを奪えば、以降は認証をやり直さずにアクセスし放題になる。

つまり、ワンタイムコードによる二段階認証も中継されて突破されます。Microsoft は、MFA を導入済みのアカウントを狙うこの種の攻撃が大きく増えていると報告しています(参考)。Evilginx のようなツールキットによって、攻撃の敷居も下がっています。

2つめは MFA 疲労攻撃(MFA fatigue / prompt bombing、プッシュ通知爆撃) です。攻撃者は何らかの方法で先にパスワードを入手したうえで、認証アプリの「ログインを承認しますか?」というプッシュ通知を 何度も何度も 送りつけます。ユーザは大量の通知にうんざりして、あるいは「IT 部門の作業だろう」と勘違いして、つい「承認」を押してしまいます。2022年の Uber への侵入が代表例として知られています。

どちらの攻撃も、フィッシングが入口になっています。やっかいなのは、フィッシングメールが本物をほぼ丸ごとコピーしていて気づきにくいことです。「URL をよく見る」「証明書を確認する」といった対策はユーザの負担が大きく、長くは続きません。人間の注意力に頼る対策は、いつか必ず破れます。

ここから導かれる答えが、フィッシング耐性(phishing resistance) です。人が偽サイトにだまされても、仕組みのレベルでフィッシングが成立しないようにする。それを実現するのが FIDO/パスキーであり、後半で見る NIST のガイドラインでも、AAL2 では「検証者がフィッシング耐性のある認証の選択肢を必ず用意し、その利用を強く推奨する」、AAL3 では「authenticator としてフィッシング耐性が必須」と要求されています。パスキーがなぜフィッシング耐性を持つのかは、後ろの「暗号は認証にどう使うのか」で仕組みごと説明します。

NIST SP 800-63 ── 認証を「保証レベル」で測る

ここまで「どの攻撃に効くか」を見てきましたが、対策の強さを 共通のものさし で測れると、議論がぐっと楽になります。そのものさしが NIST SP 800-63(Digital Identity Guidelines) です。第5回の中核トピックでした。

これは米国 NIST が出している、もともと連邦政府機関向けのデジタル認証の技術ガイドラインです。ただし内容が体系的で、いまや事実上の世界標準として参照されています。

講義時点では Revision 4 はまだ確定前という前提で説明されていましたが、その後 2025年7月に SP 800-63-4 が正式版として公開 されました(旧 Revision 3 は2025年8月1日に廃止)。本記事はこの最新版にもとづいて書いています(NIST のページ)。

3分冊と、保証レベル

SP 800-63 は3つの分冊に分かれていて、それぞれが「識別・認証・連携」の段階に対応します。冒頭で整理した識別・認証・認可の流れと、きれいに重なります。

分冊 テーマ 保証レベル
SP 800-63A 識別・身元確認(Enrollment and Identity Proofing) IAL(Identity Assurance Level)
SP 800-63B 認証(Authentication and Authenticator Management) AAL(Authentication Assurance Level)
SP 800-63C 連携(Federation and Assertions) FAL(Federation Assurance Level)

それぞれの保証レベルは3段階あり、サービスのリスク(本人確認に失敗したときの損害の大きさなど)に応じて選びます。「全部最高レベルにする」のではなく、リスクに見合ったレベルを選ぶ、というリスクベースの考え方です。

このガイドラインは、認証しようとしている主体(Subject)の状態も時系列で分けています。

状態 意味
Applicant これから身元確認(Identity Proofing)を受ける、申し込んだ人
Subscriber 身元確認が完了した人
Claimant いままさに認証を受けようとしている人

AAL ── 認証の強さの3段階

この記事の主役は、認証の強さを測る AAL です。ざっくり言うと、次の3段階です。

  • AAL1: 単一要素でもよい(パスワードだけ、など)。
  • AAL2: 多要素が必要。検証者はフィッシング耐性のある認証の選択肢を 必ず1つ以上用意し(SHALL offer)、その利用を 強く推奨する(SHOULD encourage)。
  • AAL3: 暗号鍵の 所有を証明 できる多要素で、かつ authenticator としてフィッシング耐性が 必須(SHALL provide)。

注目してほしいのは、AAL ごとに「どの攻撃に耐えること」が求められているか、要件が明記されている点です。まさにこの記事の軸そのものです。

要求事項 AAL1 AAL2 AAL3
認証済み保護チャネル(注1) 必須 必須 必須
リプレイ耐性 不要 必須 必須
フィッシング耐性 不要 選択肢の提供必須(SHALL offer)・利用は強く推奨(SHOULD encourage) authenticator として必須(SHALL provide)
認証の意思確認 不要 推奨 必須
認証処理の侵害への耐性 不要 不要 必須

(出典: SP 800-63B-4 のレベル別要求事項)

※ 表中の「推奨」は原典の SHOULD、「必須」は SHALL に対応します。

注1: ここでいう中間者攻撃(MitM)への耐性は、SP 800-63B が AAL1〜3 すべてに課す「クレイマントと検証者の通信は 認証済み保護チャネル(authenticated protected channel)経由で行う(SHALL)」という要件を指します。原典に「MitM 耐性」という独立した項目名があるわけではなく、この保護チャネル要件として AAL1 から共通に課されています。

先ほど「多要素でも AiTM やフィッシングで破られる」と書きましたが、SP 800-63 はそれを織り込んでいます。AAL2 以上ではリプレイ耐性が必須 で、さらに AAL2 では「検証者がフィッシング耐性のある認証の選択肢を少なくとも1つ必ず用意し(SHALL offer)、その利用を強く推奨する(SHOULD encourage)」 と定めています。authenticator そのものにフィッシング耐性が必須(SHALL provide)になるのは AAL3 です。

ここで効いてくるのが、SMS のワンタイムコードの位置づけです。AAL2 が用意すべき「フィッシング耐性のある選択肢」を、SMS ワンタイムコードは満たせません(AiTM でリアルタイムに中継されてしまうため)。だから「パスワード＋ SMS ワンタイムコードだけ」の多要素では、AAL2 で求められるフィッシング耐性の選択肢を提供できていない、ということになります。これは、かつての私の「とりあえず多要素」を真正面から問い直す基準でした。

記憶された秘密(パスワード)の実務指針

SP 800-63B は、パスワード(ガイドラインでは「記憶された秘密」と呼びます)の扱い方も具体的に示しています。ここがいちばん実務に刺さりました。私が「常識」と思っていたいくつかが、否定されていたからです。

  • 単一要素として使うパスワードは最低15文字、多要素の一部なら最低8文字を要求し、いずれも64文字以上まで受け入れる。スペースも許可する。(SP800-63B-4 §3.1.1.2)
  • 辞書攻撃で破られそうな値はチェックして拒否する(よくある単語、漏えい済みパスワード、aaaaaa のような繰り返し、123456 のような連続、ID と同じ、など)。
  • 定期的な変更を要求しない。漏えいが判明したときだけ変更させる。
  • 入力欄でのペーストを許可する(パスワードマネージャを使いやすくするため)。
  • 入力文字を確認できるようにする(**** でなく一時的に平文表示できる。特にモバイル)。
  • SALT 付きハッシュで保存する(SALT 長は最低32ビット)。これがオフライン攻撃への備えです。
  • SMS は避けるべき(セキュリティを考慮して作られた仕組みではないため。なお Rev.4 では全面禁止ではなく、SIM スワップ等のリスク考慮が必要な restricted authenticator という整理です。SP800-63B-4 §3.1.3.3)。

太字にしたい逆説は2つです。1つは「3か月ごとに変更」のような定期変更を、もう求めない点。定期変更は、かえって覚えやすい弱いパスワードや使い回しを誘発するので、漏えい時のみ変更させる方針に変わりました。もう1つは、私が二要素のつもりで使っていた SMS が「避けるべき」とされている 点です。少し前の私の運用は、最新の指針からはずれていたわけです。さらに Rev.4 では、単一要素として使うパスワードの最低長が8文字から15文字へ引き上げられました。「8文字あれば十分」という感覚もまた、更新されたわけです。

Revision 3 から 4 への変更

旧版(63-3)からの主な変更も、この記事の文脈に直結していました。

  • フィッシング耐性の要件が追加された(5.2.5 節)。AiTM・フィッシングの深刻化を反映したものです。
  • 生体認証のパフォーマンス要件が追加された(5.2.3 節)。
  • パスキー(同期可能なオーセンティケータ)への対応が入った。
  • セキュリティとプライバシーに加え、公平性(Equity)とユーザビリティ の考慮が拡張された。
  • 63-3 にあった「保証レベルを選ぶフローチャート」がなくなり、よりリスクベースの判断に寄った。

フィッシング耐性が後から追加されたという事実そのものが、「人の注意力に頼る対策では足りない」という時代の流れを表しています。

暗号は認証にどう使うのか ── 鍵の所有証明=チャレンジレスポンス

ここまで何度か「暗号鍵の所有を証明する」「フィッシング耐性」という言葉が出てきました。その中身を、ここで仕組みごと開きます。第5回で「暗号を認証に使う」話のいちばんの主戦場です。

前置きとして、対称鍵・公開鍵・ハッシュ・デジタル署名の仕組みは第4回(暗号)で扱ったので、ここでは再解説しません。必要なのは1点だけです。デジタル署名は、ハッシュ値に秘密鍵で署名することで「この署名を作れたのは秘密鍵を持つ本人だけだ」と証明できる ということ。そして検証は、誰でも持てる公開鍵で行えます(仕組みは第4回参照)。

この「秘密鍵を持つ本人だけが署名を作れる」という性質は、そのまま 所有物認証(Something You Have) になります。秘密鍵という「持っているモノ」の所有を、署名できることで証明するわけです。

チャレンジレスポンス

では、秘密鍵をネットワークに流さずに「持っていること」を証明するにはどうするか。答えが チャレンジレスポンス です。講義の「デジタル署名を認証に使う場合」のスライドそのものです。

流れはシンプルです。

  1. サーバが、毎回違う使い捨ての値 nonce をユーザに送ります。
  2. ユーザは、その nonce に 自分の秘密鍵で署名 します。
  3. ユーザは署名(レスポンス)をサーバに返します。
  4. サーバは、ユーザの 公開鍵で署名を検証 します。署名が正しければ「秘密鍵を持つ本人だ」と分かります。
  5. 検証が通れば、サーバは認証成功を返します。

この方式の良さは2つです。

  • リプレイ耐性: nonce が毎回変わるので、署名(レスポンス)を盗み見て使い回しても、次は別の nonce が来て通りません。AAL2 以上で必須だった「リプレイ耐性」が、ここで満たされます。
  • 秘密がネットワークを流れない: 流れるのは nonce と署名だけで、秘密鍵そのものは一切出ていきません。だから途中で盗聴されても秘密鍵は漏れません。パスワードのように「入力した秘密を盗聴される」事故が起きないわけです。

これが、AAL3 で要求された「暗号鍵の所有証明」の中身であり、FIDO/パスキー の動作の中核でもあります。

なぜパスキーはフィッシング耐性を持つのか

前半で「フィッシング耐性が答えだ」と書いた理由が、ここでようやくつながります。FIDO/パスキー(WebAuthn)は、このチャレンジレスポンスに加えて オリジンバインディング という仕掛けを持っています。秘密鍵が「どのサイト(オリジン)向けか」に縛りつけられていて、署名するときにブラウザが「いま接続しているサイトのオリジン」を一緒に固めます(参考)。

まず、登録された秘密鍵は本物のオリジン向けにしか署名しないので、ユーザが偽サイトに誘導されても、オーセンティケータは オリジンが違うので署名を作りません。だから、見た目がそっくりな偽ドメインでも拒否されます。たとえば本物の your-bank.example.com に対し、bank の a を見た目がそっくりな キリル文字の「а」(U+0430) に置き換えた your-bаnk.example.com は、人の目には区別がつきませんが、オリジン(ドメイン)としては別物なので署名されません。そして秘密鍵がデバイスから出ない以上、AiTM が間に割り込んでも中継すべき秘密が流れません。

人がだまされても、仕組みのレベルで偽サイト向けの署名を拒否する。これが、前半で「人の注意力に頼らないフィッシング耐性」と書いたものの正体です。

「とりあえず SMS で多要素」と「パスキー」は、同じ多要素でも、フィッシング耐性という点でまったく別物だったわけです。

鍵は「作って終わり」ではない ── 鍵管理ライフサイクルと2030年問題

認証を暗号鍵で支えるなら、その鍵を管理する責任がついてきます。講義の後半は、この 鍵管理 の話でした。鍵は作って配って終わり、ではありません。一生(ライフサイクル)があります。

  • 生成・保管: どんな鍵を、どのくらいの頻度で作るか。どこに保管するか。盗まれたら気づけるか。
  • 使用(Activation): 使うときの認証方法。使用中に盗まれたり盗聴されたりしないか。
  • 廃棄(鍵の無害化): 不要になった鍵を、復元できないように消す。
  • アルゴリズムの寿命: そのアルゴリズム自体が、いつまで安全とみなせるか。

どのくらいの頻度で鍵を更新するか

NIST SP 800-57 Part1 が、鍵の用途ごとに更新の目安を示しています。

鍵の種類 利用期間の目安
署名用の秘密鍵(Private Signature Key) 1〜3年
署名検証用の公開鍵(Public Signature-verification Key) 数年(鍵サイズに依存)
対称認証鍵(Symmetric Authentication Key) 2年以下

どこに保管するか

保管場所には、コストと安全性のトレードオフがあります。

保管場所 メリット デメリット
ディスク コストが安い、バックアップが容易 盗難・無断複製が容易
TPM・IC カード 盗難・無断複製が困難 バックアップが困難
HSM(Hardware Security Module) 盗難・無断複製が困難 コストが高い

TPM や HSM は、鍵を取り出せない耐タンパー(改ざん耐性)のあるハードウェアで、内部で暗号処理を行います。HSM の堅牢さの指標には FIPS 140 があり、耐タンパー性はレベル3以上で実装されます。

バックアップの要否は、鍵の用途で変わるのが面白いところです。機密性のための鍵(暗号化用)は、暗号化したデータがある限りバックアップが必要です。一方、署名用の秘密鍵はバックアップ不要 です。なくしても、新しい鍵ペアを作り直して証明書を再発行すればよいからです(むしろバックアップを増やすほど漏えいの面が増えます)。検証用の公開鍵は、過去の署名を検証する間は必要です。

2030年問題

ここで時間軸の話が出てきます。2030年問題 です。いま広く使われている RSA-2048 は、安全性の強度が「112ビット相当」とされます。NIST は、この112ビット強度の古典的なデジタル署名・鍵確立を、2030年末(2030年12月31日)で「非推奨(deprecated)」に格下げする 方向で整理を進めています。

ここで注意したいのは、「非推奨」は「即使用禁止」ではない、という点です。原典の状態表では2030年末まで「Acceptable(許可)」、それ以降は「Deprecated(非推奨)」とされていて、RSA-2048 が2031年からいきなり使えなくなるわけではありません。さらに NIST は、非対称鍵については 128ビットへの移行を強制せず、112→128→耐量子の二段構えを避けて 一段で耐量子暗号(PQC)へ移す 方針を示しています(SP 800-131A Rev.3 ドラフト)。だから RSA-2048 の行き先は、「いったん RSA-3072 へ」ではなく「PQC へ」というのが NIST の描く道筋です。

なお、この「2030年末で非推奨・行き先は PQC」という整理は、現行の SP 800-131A Rev.2(2019年) 本文ではなく、2024年10月に公開された Rev.3 のドラフト(初版公開草案) で示されたものです。Rev.3 ドラフトは「128ビットへの移行を要求するのではなく(rather than requiring a transition to the 128-bit security strength)」と明記し、二段移行ではなく一段で耐量子アルゴリズムへ移す方針を提案しています。RSA-2048 が112ビット相当であること自体は SP 800-57 Part 1 の強度対応表にもとづきます。

耐量子暗号(PQC)

さらにその先には、量子コンピュータによる危殆化 が控えています。ショアのアルゴリズム を十分大きな量子コンピュータで動かせると、素因数分解と離散対数が高速に解けてしまい、RSA・ECDH・ECDSA がまとめて危殆化します。鍵を長くする2030年問題への対処だけでは足りないわけです。

そこで 耐量子暗号(PQC: Post-Quantum Cryptography) が標準化されています。NIST の PQC プロジェクト(2016年開始)は、約8年の選定を経て 2024年8月13日に3つの FIPS を公開 しました。

規格 内容 もとになった方式
FIPS 203 ML-KEM(格子ベースの鍵カプセル化) CRYSTALS-Kyber
FIPS 204 ML-DSA(格子ベースのデジタル署名) CRYSTALS-Dilithium
FIPS 205 SLH-DSA(ハッシュベースのデジタル署名) SPHINCS+

(出典: NIST のアナウンス)

講義スライドでは耐量子計算機暗号の略語を「PQA(Post Quantum Cryptography)」と表記していましたが、英語表記 Post-Quantum Cryptography の略は PQC が正しいので、一次情報をもとに訂正しました。

ここで講義の結びが効いてきます。導入時に安全でも、後で危殆化する。だから鍵管理は、一度設定して終わりではなく「時間軸の運用」なのです。「いま安全なら大丈夫」ではなく、「いつまで安全か、危殆化したらどう乗り換えるか」までを面倒みる。これが鍵を持つ責任です。

PKI ──「その鍵は本当に本人のものか」を保証する仕組み

チャレンジレスポンスで「秘密鍵の所有」を証明できる、と書きました。けれど、ここに最後の穴があります。検証に使う 公開鍵が、本当に本人のものか をどう保証するのか、という問題です。

講義の言葉を借りると、鍵を作るだけなら誰でもできます。攻撃者が「これが私 alice の公開鍵です」と偽の鍵を配ってしまえば、なりすましが成立します。だから、公開鍵が確かに本人のものだと証明する仕組みが要ります。

それが デジタル証明書 です。証明書は「この公開鍵は確かにこの人のものだ」という証明書で、形式は RFC 5280 の X.509 で標準化されています。証明書には、その正しさを保証する CA(Certificate Authority、認証局)のデジタル署名 が付きます。CA 以外はこの署名を作れないので、証明書が改ざんされていないこと、確かにその CA が発行したことが分かります。

講義では、印鑑証明のアナロジーで説明されていました。

現実の印鑑証明 デジタル証明書の世界
実印(本人だけが持つ) 秘密鍵
印鑑証明書(役所が発行) デジタル証明書(CA が発行)
押印という行為 デジタル署名
役所(信頼できる第三者) CA

証明書には用途を縛る項目もあります。たとえば拡張領域の KeyUsage は、その鍵が署名用なのか、鍵の暗号用なのか、といった使用目的を指定します。鍵を「作って終わり」ではなく「用途を明確にする」ための仕掛けです。

この CA を中心とした、鍵と証明書を管理する基盤全体が PKI(Public Key Infrastructure、公開鍵基盤) です。CA は PKI のなかで唯一信頼される起点(トラストアンカー)で、CA が発行した証明書を信じられなくなると、その上の取引すべてが信用できなくなります。だから CA には重い責任が課されます。講義で挙げられた CA の必要要件は次のとおりでした。

  • 本人確認: 証明書を発行する前に申請者を識別する。証明書の信頼性は本人確認の方法に比例する(パスポートと百貨店の会員証では重みが違う)。ここで SP 800-63A の識別が効いてきます。
  • 取消機能: 鍵の危殆化や盗難で、有効期限内でも証明書を取り消せる。取り消した証明書の一覧を CRL(Certificate Revocation List) として発行する。
  • 検証機能: 証明書が有効かどうかを、求めに応じていつでも速やかに答える(可用性が求められる)。
  • 信頼できるタイムスタンプ: 「いつ」発行・取消されたかが正確でないと、取消前の署名か後の署名か判断できない。
  • 監査: CA がポリシー(CP / CPS、RFC 3647 で規定)どおりに運用されているかを第三者が確かめる。

なお、証明書の有効性をリアルタイムに問い合わせる仕組みとして OCSP が長く使われてきましたが、いまは CRL への揺り戻しが起きています。CA/Browser Forum が2023年8月に OCSP を任意・CRL を必須としたのを受け、Let's Encrypt は2025年8月6日に OCSP サービスを終了 し、CRL に移行しました(参考)。「証明書の失効をどう確かめるか」も、固定された答えではなく、運用の最適点が動き続けている領域です。

まとめ

この記事では、CySec 第5回「認証技術」の内容を「認証は『どの脅威に効いて、どの脅威に効かないか』で整理できる」という1本の軸で再構成しました。タイトルの「その多要素認証、どの攻撃に効いてますか?」と、はじめに掲げたこの軸は、同じことを言っています。

この記事の幹は3つです。これだけ持ち帰れば十分です。

  1. パスワード攻撃は「オンライン/オフライン」で分かれ、アカウントロックが効く範囲もそこで分かれる。 推測・総当たり・辞書・リスト型はオンライン、レインボーテーブルはオフライン。ロックはオンライン攻撃には効くが、オフライン攻撃には効かない(だから SALT 付きハッシュ保存が要る)。リスト型はロックをすり抜けやすい。パスワードを長く複雑にしても届かない範囲があるから、多要素へ進む。

  2. 多要素にしても AiTM や MFA 疲労攻撃で破られる。だから必要なのはフィッシング耐性。 「とりあえず SMS で多要素」では足りません。フィッシング耐性を持つのが FIDO/パスキーで、NIST SP 800-63 は AAL2 で「フィッシング耐性のある選択肢を必ず用意し利用を強く推奨」、AAL3 で「authenticator としてフィッシング耐性を必須」としています。SMS ワンタイムコードはこの選択肢を満たせません。SP 800-63 の AAL は、対策の強さを測る共通のものさしになります。

  3. 暗号の認証利用の核心は「鍵の所有証明=チャレンジレスポンス」。鍵はライフサイクル・2030年問題・耐量子まで面倒をみる。 nonce に秘密鍵で署名する仕組みが、リプレイ耐性と「秘密を流さない」を両立させ、これがパスキーと AAL3 の中身です。そしてその鍵が本人のものだと保証するのが PKI(CA とデジタル証明書)です。

最後に、この記事で手を動かしてほしかったことを1つ。自分のサービスの認証を「どの脅威に効くか」で棚卸ししてみてください。 「パスワードのオフライン攻撃対策(SALT 付きハッシュ)は入っているか」「多要素はフィッシング耐性まで満たしているか」「使っている暗号は2030年以降も大丈夫か」。脅威の地図の上に対策を並べ直すと、足りないピースが見えてきます。少し前の私の「とりあえず多要素にした」は、この棚卸しをした瞬間に穴だらけでした。

暗号そのものの仕組み(対称鍵・公開鍵・ハッシュ・デジタル署名がどう成り立っているか)は、第4回で「秘密を小さくしてきた歴史」として整理しています(末尾の「あわせて読みたい」を参照)。あわせて読むと、この記事の「鍵の所有証明」がより立体的に見えるはずです。ここまで読んでいただき、ありがとうございました。

参考

本記事で挙げた規格・年号・攻撃手法は、次の一次情報で確認できます。記事中の内容は学習・執筆時点(2026年6月)のもので、最新は各サイトで確認してください。

※ 講義スライドの「PQA(Post Quantum Cryptography)」は、英語略語として正しい「PQC」に訂正しました(NIST PQC プロジェクトの表記に準拠)。
※ AiTM・MFA 疲労攻撃・パスキーのフィッシング耐性は講義スライド外の講師補足のため、上記の一次情報で裏を取ったうえで記述しています。

あわせて読みたい

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?