本文へスキップ
株式会社オープンナレッジ
株式会社オープンナレッジ Open Knowledge Inc.
1. 基本と全体像

この記事の要点と4つの章のご案内

この記事の3つの要点(まずここだけ読めば安心です)に関するイメージ写真
この記事の3つの要点(まずここだけ読めば安心です)
「指紋や顔のデータがネットに送られるの?」という誤解と、パスキーの本当の仕組みに関するイメージ写真
「指紋や顔のデータがネットに送られるの?」という誤解と、パスキーの本当の仕組み
パスワードを覚える時代は終わりへフィッシング耐性を備えた「パスキー」の仕組みと設定手順 の各章におけるテーマと要点一覧表
章構成 主なテーマ 要点と確認ポイント
1. 基本と全体像 この記事の3つの要点(まずここだけ読めば安心です) 「パスワードの定期変更」はもう不要であり、むしろ危険です: 総務省や米国NISTの基準でも、定期変更は「推測しやすい連番パスワード」や「使い回し」を招くため不要と明記されています。それよりも偽サイト対策が最優先です。
2. 現場での進め方と対策 「指紋や顔のデータがネットに送られるの?」という誤解と、パスキーの本当の仕組み SMSの6桁コードは「リアルタイム中継型フィッシング(AiTM)」で突破されます: 本物そっくりの偽サイトに6桁コードを入力してしまうと、攻撃者が裏で本物の銀行や証券サイトへ即座に中継してログインを乗っ取ってしまいます。
3. 関連する制度とルール スマホ・PCでの3分設定手順と紛失時の備え まずは本ページの図解と3項目チェックリストでご自身でできる範囲からお試しください。もし設定や判断に迷われたときは、過度な営業のないご相談窓口(お助け隊・お問い合わせ窓口)へいつでもご相談いただけます。
4. 詳しい技術仕様としくみ 認証・フィッシング対策の実践図解について、専門知識がなくても今日から対策を始められますか? ——なぜSMSの6桁コードは突破されるのか?ご家庭のネット銀行・通販から職場のクラウドまで今日から3分で守る手順
第1章〜第4章では、実務チェックリスト・公的制度基準・詳しい技術仕様を確認できます。
認証・フィッシング対策の実践図解 監修・執筆:登録情報処理安全確保支援士(第007617号)・上級医療情報技師 加藤 明生

パスワードを覚える時代は終わりへフィッシング耐性を備えた「パスキー」の仕組みと設定手順

——なぜSMSの6桁コードは突破されるのか?ご家庭のネット銀行・通販から職場のクラウドまで今日から3分で守る手順

この記事の3つの要点(まずここだけ読めば安心です)

  • 01. 「パスワードの定期変更」はもう不要であり、むしろ危険です: 総務省や米国NISTの基準でも、定期変更は「推測しやすい連番パスワード」や「使い回し」を招くため不要と明記されています。それよりも偽サイト対策が最優先です。
  • 02. SMSの6桁コードは「リアルタイム中継型フィッシング(AiTM)」で突破されます: 本物そっくりの偽サイトに6桁コードを入力してしまうと、攻撃者が裏で本物の銀行や証券サイトへ即座に中継してログインを乗っ取ってしまいます。
  • 03. パスキー(FIDO2)なら「偽サイトではそもそも反応しない」: スマートフォンやパソコンの指紋・顔認証を使う「パスキー」は、接続先のドメイン(URL)を暗号学的に確認するため、人間が偽サイトに騙されても鍵が原則として開きません。
第1章:背景と仕組みの図解

1. 「指紋や顔のデータがネットに送られるの?」という誤解と、パスキーの本当の仕組み

パスキー(Passkeys)をおすすめすると、「自分の指紋や顔の写真がインターネット上のサーバーに保存されるのは怖い」と心配される方がいらっしゃいます。結論から言うと、指紋や顔のデータはあなたのスマートフォンやパソコンの外には1ミリも出ません。その安心の仕組みを図解します。

図1:事象の発生構造と3段階の対策フロー

従来:パスワード + SMS 6桁コード ・人間が画面を見て文字・数字を入力する ・精巧な偽サイト(AiTM)を見分けられない → 入力した瞬間に裏で本物サイトへ中継・突破 ※主な発生要因の整理 パスキー:端末内の金庫と指紋・顔認証 ・顔や指紋は「スマホ内の金庫を開ける鍵」 ・ネットには「数学的なデジタル署名」だけ送信 → 生体情報は外部サーバーへ一切送信されない ※初期設定と運用手順 防御の要:URL(ドメイン)の自動照合 ・ブラウザが接続先URLを暗号レベルで確認 ・1文字でも違う偽サイトには署名を拒否 → 人間が騙されても物理的にログイン乗っ取り不能 ※システム層での保護機構
安心の理由 01:生体情報は端末の中だけ

顔や指紋は外へ送信されない

指紋や顔認証は、お手元のスマートフォン内の安全チップ(Secure Enclave / TPM)を起動するためだけに使われ、サーバーには公開鍵の署名データしか届きません。

安心の理由 02:偽サイトを自動で見破る

人間がURLを見間違えても安全

どんなに本物そっくりの偽サイトでも、ドメイン名が異なる限りブラウザがパスキーの作動を自動的に止めるため、フィッシング被害がゼロになります。

安心の理由 03:覚える・打つストレスゼロ

メモ帳も複雑な記号も不要に

大文字・小文字・記号を混ぜた長い文字列を覚えたり打ち間違えたりする苦労がなくなり、ご高齢のご家族でも普段のスマホロック解除と同じ感覚で使えます。

場面別の実務確認ポイント

ご家庭・シニア・初めて学ぶ方へ 難しい専門用語を覚える必要はありません。上の図解の「真ん中の箱(手順 02)」と、実践チェックリストの3項目を1つずつ確認するだけで十分に安全を高められます。
経営者・総務・医療や現場の責任者の方へ 比較表と実践手順をそのまま社内の点検シートとしてお使いいただけます。高額な機器契約の前に確認すべき判断基準も明記しています。
ろう者・難聴者・発達障害のある方へ 音声や動画のみに頼らず、すべて視覚的な図解と文字で完結しています。画面右上の「文字拡大」「シンプル表示」や、A4印刷にも対応しています。
情報システム担当・エンジニア・研究者の方へ 第3章にて、RFC・CVE・NIST SP 800シリーズ等の一次仕様に基づく数理モデルと、Rust Edition 2024(unsafe禁止)による検証コードを公開しています。
第2章:実践手順とセルフチェック

2. スマホ・PCでの3分設定手順と紛失時の備え

専門的な知識がなくても、ご家庭や職場で今日から順番に確認・実践できる具体的な比較表とチェックリストをまとめました。

認証方式偽サイト(AiTM)への耐性日々の使いやすさスマホ機種変更・紛失時の復旧方法
パスワードのみ 無力(入力した瞬間に盗まれる) 記憶・管理が大変、使い回しリスク大 メール等でのパスワード再設定
SMS 6桁コード / 認証アプリ 低い(偽サイトへ6桁を入力すると突破される) 毎回スマホを開いて6桁を転記する手間 電話番号の引き継ぎ、またはバックアップコード
同期型パスキー(iCloud / Google) 極めて高い(偽ドメインでは厳格作動しない) 指紋・顔・PINだけで1秒ログイン 新しいスマホでApple/Googleアカウントに復元
物理セキュリティキー(YubiKey等) 高水準(物理キー所持+Origin束縛) USBまたはNFCでかざしてタッチ 予備キー(バックアップ用2本目)を金庫に保管

今日から無理なく進めるための4ステップ実践手順

手順 01(所要時間:約15分)

現状の棚卸しと「見えにくいリスク」の把握

新しい機器やソフトを購入する前に、現在使っている機器・アカウント・契約先を紙1枚に書き出します。被害の大半は「昔作ったまま誰も管理していない古い機器や共有アカウント」から始まります。

手順 02(所要時間:約30分)

費用をかけずにできる「3つの基本設定」

01 パスキー(FIDO2)または二要素認証の有効化、02 ルーター・VPN・OSの自動更新設定、03 バックアップ用外付けHDDの常時接続解除(切り離し保管)の3点を実施します。

手順 03(所要時間:約15分)

異変に気づいたときの「責めない連絡ルール」

不審なリンクを開いたり偽警告が出たりした際、「怒られるかも」と隠すことが被害を広げます。「迷ったら6秒深呼吸して手を止め、すぐ共有してくれた人を褒める」ルールを共有します。

手順 04(3ヶ月に1回・約15分)

定期的な復元テストと第三者の落ち着いた確認

季節の変わり目ごとに「バックアップから実際に1つのファイルを戻せるか」を試すとともに、退職・異動に伴うアカウント整理を行い、迷う点は専門窓口で点検します。

現場で陥りやすい3つの落とし穴と、安全な回避策

落とし穴 01:パスキーを設定したのに「従来のパスワードログイン」をそのまま残してしまう

裏口としてパスワード+SMS認証が残っていると、攻撃者は「パスキーが使えない環境」を装ってパスワード入力画面へ誘導します。主要メンバーがパスキー登録を終えたら、順次パスワード認証を無効化(または長大なランダム文字列へ変更)してください。

落とし穴 02:共有パソコンで個人のパスキーを作ってしまう

職場の共用パソコンでパスキーを作成すると、そのパソコンのWindows Hello等を使える他の人もログインできてしまいます。共用端末では必ず「スマートフォンでQRコードを読み取って認証する方式」または個人の物理キーを使ってください。

落とし穴 03:スマホ紛失時に備えた「2台目の登録」を忘れる

スマートフォン1台だけにパスキーを登録していると、水没や紛失時にログイン復旧に時間がかかります。パソコン本体やタブレット、または予備のセキュリティキーなど「2つ以上の手段」を登録しておくと安心です。

今日からできる3項目セルフチェック(クリックして確認)

達成状況:0 / 3 項目

ご家庭や職場で現在できている項目にチェックを入れてみてください。すべてお使いのブラウザ内でのみ計算され、外部へ送信されることはありません。

上の3項目をクリックすると、現在の達成状況に応じたアドバイスが表示されます。まずは1項目ずつ順番に整えていきましょう。
理解を深める確認クイズ

パスキー(FIDO2)を設定しているとき、精巧な偽の銀行サイト(フィッシングサイト)を開いてしまった場合はどうなるでしょうか?

よくあるご質問と、迷ったときの判断基準

Q1. 社内に専任のシステム担当者がいないのですが、自分たちだけで始められますか?

はい、始められます。まずは費用や特別な契約を伴わない「基本の3項目(パスキー・自動更新・切り離し保管)」から1つずつ進めてみてください。途中で設定画面の見方が分からなくなったときだけ、相談窓口を頼っていただければ十分です。

Q2. 外部の営業担当者から「今すぐ専用機器(UTM等)をリース契約しないと手遅れになる」と言われました。

その場で即決せず、必ず見積書を持ち帰ってセカンドオピニオンを確認してください。公的ガイドラインや2026年SCS評価制度(★3)が求めているのは、特定メーカーの高額機器ではなく「基本的な管理の仕組み」です。

Q3. このページの内容を印刷して、職場や家族に配ってもよいですか?

もちろんです。本サイトの図解やチェックリストは、地域の企業・医院・学校・ご家庭の安全を守るための公開技術資料として掲載しています。ブラウザの印刷機能(A4縦)でそのまま読みやすく印刷できます。

4. 詳しい技術仕様としくみ:技術アーキテクチャ仕様

W3C WebAuthn Level 3 / FIDO2 CTAP2 における RP ID ハッシュ検証と ECDSA P-256 署名検証実装

設計背景・判断基準リファレンス

本節では、パスキーがリアルタイム中間者攻撃(AiTM)を数学的に無効化する根拠である AuthenticatorData バイナリ構造(37バイト以上)、Origin / RP ID Hash 照合、および User Presence (UP) / User Verification (UV) ビットマスク検証の Rust Edition 2024 実装を示します。

STANDARD
W3C WebAuthn L3 / CTAP 2.1
CRYPTOGRAPHY
ECDSA P-256 (ES256) / Ed25519
ORIGIN BINDING
SHA-256(rp_id) Exact Match
ASSURANCE LEVEL
NIST SP 800-63B AAL3 Ready

1. プロトコル内部構造・数理モデルと設計根拠

1. AuthenticatorData の 37バイト構造と Origin 束縛: WebAuthn 認証器が生成する `authenticatorData` の先頭 32バイトは `SHA-256(rpId)`(正規ドメインのハッシュ値)であり、33バイト目の `flags` には Bit 0(UP: User Presence)および Bit 2(UV: User Verification、生体認証またはPIN確認済み)が格納されます。続く 34〜37バイト目はビッグエンディアンの 32ビット署名カウンタ(`signCount`)であり、クローンされた認証器を検知します。

2. AiTM リバースプロキシのプロトコル層での抑止: 攻撃者が `login-bank-jp.example` 上でリバースプロキシを稼働させても、被害者のブラウザが生成する `clientDataJSON.origin` および `rpIdHash` は攻撃者ドメインの SHA-256 値となるため、正規サーバーが要求する SHA-256("bank.co.jp") と決して一致せず、署名の転送攻撃(Replay / Relay)は 100% 失敗します。

2. 技術パラメータ・検証仕様一覧

バイトオフセットフィールド名データ型・サイズ検証不変条件(Invariant)
0..32 (32 bytes) rpIdHash [u8; 32] (SHA-256) 正規サーバーの SHA-256(expected_rp_id) と定数時間比較で一致すること
32 (1 byte) flags u8 Bitmask Bit 0 (UP=0x01) == 1 かつ Bit 2 (UV=0x04) == 1 であること
33..37 (4 bytes) signCount u32 Big-Endian signCount == 0 (Sync Passkey) または signCount > stored_sign_count であること
ClientDataJSON type / challenge / origin UTF-8 JSON type == 'webauthn.get' かつ challenge がセッション乱数と一致すること
3. リファレンス実装コード(crates/ok-auth-fido2/src/webauthn_verifier.rs) Rust Edition 2024 (#![forbid(unsafe_code)])
#![forbid(unsafe_code)]

pub const FLAG_USER_PRESENT: u8 = 0b0000_0001;
pub const FLAG_USER_VERIFIED: u8 = 0b0000_0100;
pub const FLAG_BACKUP_ELIGIBLE: u8 = 0b0000_1000;
pub const FLAG_BACKUP_STATE: u8 = 0b0001_0000;

#[derive(Debug, Clone, PartialEq, Eq)]
pub struct ParsedAuthenticatorData {
    pub rp_id_hash: [u8; 32],
    pub flags: u8,
    pub sign_count: u32,
}

#[derive(Debug, Clone, Copy, PartialEq, Eq)]
pub enum WebAuthnVerifyError {
    BufferTooShort,
    RpIdHashMismatch,
    UserNotPresent,
    UserNotVerified,
    CloneDetected { received: u32, stored: u32 },
}

#[inline]
fn constant_time_eq_32(a: &[u8; 32], b: &[u8; 32]) -> bool {
    let mut diff = 0u8;
    let mut i = 0;
    while i < 32 {
        diff |= a[i] ^ b[i];
        i += 1;
    }
    diff == 0
}

pub fn verify_authenticator_data(
    raw: &[u8],
    expected_rp_id_hash: &[u8; 32],
    stored_sign_count: u32,
    require_uv: bool,
) -> Result<ParsedAuthenticatorData, WebAuthnVerifyError> {
    if raw.len() < 37 {
        return Err(WebAuthnVerifyError::BufferTooShort);
    }

    let mut rp_id_hash = [0u8; 32];
    rp_id_hash.copy_from_slice(&raw[0..32]);

    if !constant_time_eq_32(&rp_id_hash, expected_rp_id_hash) {
        return Err(WebAuthnVerifyError::RpIdHashMismatch);
    }

    let flags = raw[32];
    if (flags & FLAG_USER_PRESENT) == 0 {
        return Err(WebAuthnVerifyError::UserNotPresent);
    }
    if require_uv && (flags & FLAG_USER_VERIFIED) == 0 {
        return Err(WebAuthnVerifyError::UserNotVerified);
    }

    let sign_count = u32::from_be_bytes([raw[33], raw[34], raw[35], raw[36]]);
    if (sign_count != 0 || stored_sign_count != 0) && sign_count <= stored_sign_count {
        return Err(WebAuthnVerifyError::CloneDetected {
            received: sign_count,
            stored: stored_sign_count,
        });
    }

    Ok(ParsedAuthenticatorData {
        rp_id_hash,
        flags,
        sign_count,
    })
}

#[cfg(test)]
mod tests {
    use super::*;

    #[test]
    fn test_aitm_phishing_rp_id_mismatch_is_rejected() {
        let expected_hash = [0xAA; 32];
        let mut raw = [0u8; 37];
        raw[0..32].copy_from_slice(&[0xBB; 32]); — Phishing proxy hash
        raw[32] = FLAG_USER_PRESENT | FLAG_USER_VERIFIED;
        raw[33..37].copy_from_slice(&10u32.to_be_bytes());

        assert_eq!(
            verify_authenticator_data(&raw, &expected_hash, 9, true),
            Err(WebAuthnVerifyError::RpIdHashMismatch)
        );
    }
}
4. 詳しい技術仕様としくみ(システム設計・数理モデル・実装例)

FIDO2 / WebAuthn Level 3 と CTAP2 公開鍵暗号によるフィッシング無効化プロトコル実装

プロトコル仕様・数理モデル・Rust 2024 実装コードの詳細は、専門技術モノグラフにて公開しています。

技術モノグラフを読む →
ご質問・公的制度の活用に関するお問い合わせ窓口

掲載資料に関するご質問・公的制度活用のご案内

本ページの図解や解説内容に関するご質問、経済産業省「SCS評価制度」やIPA「SECURITY ACTION・サイバーセキュリティお助け隊サービス」等の公的制度の確認方法について、落ち着いた参考窓口としてご案内しております。売り込みや営業連絡は一切行いませんので、社内勉強会やご家庭での確認資料としてご自由にご活用ください。

図解・ビジュアルの拡大表示

図表内のテキストもそのまま選択・検索可能です(ベクターSVG描画) 枠外クリックまたは ESC キーで閉じます