この記事の要点と4つの章のご案内
| 章構成 | 主なテーマ | 要点と確認ポイント |
|---|---|---|
| 1. 基本と全体像 | この記事の3つの要点(まずここだけ読めば安心です) | 「パスワードの定期変更」はもう不要であり、むしろ危険です: 総務省や米国NISTの基準でも、定期変更は「推測しやすい連番パスワード」や「使い回し」を招くため不要と明記されています。それよりも偽サイト対策が最優先です。 |
| 2. 現場での進め方と対策 | 「指紋や顔のデータがネットに送られるの?」という誤解と、パスキーの本当の仕組み | SMSの6桁コードは「リアルタイム中継型フィッシング(AiTM)」で突破されます: 本物そっくりの偽サイトに6桁コードを入力してしまうと、攻撃者が裏で本物の銀行や証券サイトへ即座に中継してログインを乗っ取ってしまいます。 |
| 3. 関連する制度とルール | スマホ・PCでの3分設定手順と紛失時の備え | まずは本ページの図解と3項目チェックリストでご自身でできる範囲からお試しください。もし設定や判断に迷われたときは、過度な営業のないご相談窓口(お助け隊・お問い合わせ窓口)へいつでもご相談いただけます。 |
| 4. 詳しい技術仕様としくみ | 認証・フィッシング対策の実践図解について、専門知識がなくても今日から対策を始められますか? | ——なぜSMSの6桁コードは突破されるのか?ご家庭のネット銀行・通販から職場のクラウドまで今日から3分で守る手順 |
パスワードを覚える時代は終わりへ
フィッシング耐性を備えた「パスキー」の仕組みと設定手順
——なぜSMSの6桁コードは突破されるのか?ご家庭のネット銀行・通販から職場のクラウドまで今日から3分で守る手順
この記事の3つの要点(まずここだけ読めば安心です)
- 01. 「パスワードの定期変更」はもう不要であり、むしろ危険です: 総務省や米国NISTの基準でも、定期変更は「推測しやすい連番パスワード」や「使い回し」を招くため不要と明記されています。それよりも偽サイト対策が最優先です。
- 02. SMSの6桁コードは「リアルタイム中継型フィッシング(AiTM)」で突破されます: 本物そっくりの偽サイトに6桁コードを入力してしまうと、攻撃者が裏で本物の銀行や証券サイトへ即座に中継してログインを乗っ取ってしまいます。
- 03. パスキー(FIDO2)なら「偽サイトではそもそも反応しない」: スマートフォンやパソコンの指紋・顔認証を使う「パスキー」は、接続先のドメイン(URL)を暗号学的に確認するため、人間が偽サイトに騙されても鍵が原則として開きません。
1. 「指紋や顔のデータがネットに送られるの?」という誤解と、パスキーの本当の仕組み
パスキー(Passkeys)をおすすめすると、「自分の指紋や顔の写真がインターネット上のサーバーに保存されるのは怖い」と心配される方がいらっしゃいます。結論から言うと、指紋や顔のデータはあなたのスマートフォンやパソコンの外には1ミリも出ません。その安心の仕組みを図解します。
図1:事象の発生構造と3段階の対策フロー
顔や指紋は外へ送信されない
指紋や顔認証は、お手元のスマートフォン内の安全チップ(Secure Enclave / TPM)を起動するためだけに使われ、サーバーには公開鍵の署名データしか届きません。
人間がURLを見間違えても安全
どんなに本物そっくりの偽サイトでも、ドメイン名が異なる限りブラウザがパスキーの作動を自動的に止めるため、フィッシング被害がゼロになります。
メモ帳も複雑な記号も不要に
大文字・小文字・記号を混ぜた長い文字列を覚えたり打ち間違えたりする苦労がなくなり、ご高齢のご家族でも普段のスマホロック解除と同じ感覚で使えます。
場面別の実務確認ポイント
2. スマホ・PCでの3分設定手順と紛失時の備え
専門的な知識がなくても、ご家庭や職場で今日から順番に確認・実践できる具体的な比較表とチェックリストをまとめました。
| 認証方式 | 偽サイト(AiTM)への耐性 | 日々の使いやすさ | スマホ機種変更・紛失時の復旧方法 |
|---|---|---|---|
| パスワードのみ | 無力(入力した瞬間に盗まれる) | 記憶・管理が大変、使い回しリスク大 | メール等でのパスワード再設定 |
| SMS 6桁コード / 認証アプリ | 低い(偽サイトへ6桁を入力すると突破される) | 毎回スマホを開いて6桁を転記する手間 | 電話番号の引き継ぎ、またはバックアップコード |
| 同期型パスキー(iCloud / Google) | 極めて高い(偽ドメインでは厳格作動しない) | 指紋・顔・PINだけで1秒ログイン | 新しいスマホでApple/Googleアカウントに復元 |
| 物理セキュリティキー(YubiKey等) | 高水準(物理キー所持+Origin束縛) | USBまたはNFCでかざしてタッチ | 予備キー(バックアップ用2本目)を金庫に保管 |
今日から無理なく進めるための4ステップ実践手順
現状の棚卸しと「見えにくいリスク」の把握
新しい機器やソフトを購入する前に、現在使っている機器・アカウント・契約先を紙1枚に書き出します。被害の大半は「昔作ったまま誰も管理していない古い機器や共有アカウント」から始まります。
費用をかけずにできる「3つの基本設定」
01 パスキー(FIDO2)または二要素認証の有効化、02 ルーター・VPN・OSの自動更新設定、03 バックアップ用外付けHDDの常時接続解除(切り離し保管)の3点を実施します。
異変に気づいたときの「責めない連絡ルール」
不審なリンクを開いたり偽警告が出たりした際、「怒られるかも」と隠すことが被害を広げます。「迷ったら6秒深呼吸して手を止め、すぐ共有してくれた人を褒める」ルールを共有します。
定期的な復元テストと第三者の落ち着いた確認
季節の変わり目ごとに「バックアップから実際に1つのファイルを戻せるか」を試すとともに、退職・異動に伴うアカウント整理を行い、迷う点は専門窓口で点検します。
現場で陥りやすい3つの落とし穴と、安全な回避策
落とし穴 01:パスキーを設定したのに「従来のパスワードログイン」をそのまま残してしまう
裏口としてパスワード+SMS認証が残っていると、攻撃者は「パスキーが使えない環境」を装ってパスワード入力画面へ誘導します。主要メンバーがパスキー登録を終えたら、順次パスワード認証を無効化(または長大なランダム文字列へ変更)してください。
落とし穴 02:共有パソコンで個人のパスキーを作ってしまう
職場の共用パソコンでパスキーを作成すると、そのパソコンのWindows Hello等を使える他の人もログインできてしまいます。共用端末では必ず「スマートフォンでQRコードを読み取って認証する方式」または個人の物理キーを使ってください。
落とし穴 03:スマホ紛失時に備えた「2台目の登録」を忘れる
スマートフォン1台だけにパスキーを登録していると、水没や紛失時にログイン復旧に時間がかかります。パソコン本体やタブレット、または予備のセキュリティキーなど「2つ以上の手段」を登録しておくと安心です。
今日からできる3項目セルフチェック(クリックして確認)
達成状況:0 / 3 項目ご家庭や職場で現在できている項目にチェックを入れてみてください。すべてお使いのブラウザ内でのみ計算され、外部へ送信されることはありません。
パスキー(FIDO2)を設定しているとき、精巧な偽の銀行サイト(フィッシングサイト)を開いてしまった場合はどうなるでしょうか?
よくあるご質問と、迷ったときの判断基準
Q1. 社内に専任のシステム担当者がいないのですが、自分たちだけで始められますか?
はい、始められます。まずは費用や特別な契約を伴わない「基本の3項目(パスキー・自動更新・切り離し保管)」から1つずつ進めてみてください。途中で設定画面の見方が分からなくなったときだけ、相談窓口を頼っていただければ十分です。
Q2. 外部の営業担当者から「今すぐ専用機器(UTM等)をリース契約しないと手遅れになる」と言われました。
その場で即決せず、必ず見積書を持ち帰ってセカンドオピニオンを確認してください。公的ガイドラインや2026年SCS評価制度(★3)が求めているのは、特定メーカーの高額機器ではなく「基本的な管理の仕組み」です。
Q3. このページの内容を印刷して、職場や家族に配ってもよいですか?
もちろんです。本サイトの図解やチェックリストは、地域の企業・医院・学校・ご家庭の安全を守るための公開技術資料として掲載しています。ブラウザの印刷機能(A4縦)でそのまま読みやすく印刷できます。
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 実装を示します。
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 がセッション乱数と一致すること |
#![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)
);
}
}
FIDO2 / WebAuthn Level 3 と CTAP2 公開鍵暗号によるフィッシング無効化プロトコル実装
プロトコル仕様・数理モデル・Rust 2024 実装コードの詳細は、専門技術モノグラフにて公開しています。
あわせて読みたい関連ガイド
まずは本ページの図解とチェックリストでご自身でできる対策からお試しください。関連する手順や、自分たちだけでは判断に迷われたときの相談窓口も以下からご覧いただけます。