パスキー（Passkey）って結局なに？仕組みと安全性、そしてBluetoothの意外な役割

対象読者： パスキーという言葉は聞くけれど、裏で何が起きているのか気になっているエンジニアやIT担当者
目的： パスキーの安全性、公開鍵暗号の仕組み、そしてクロスデバイス認証におけるBluetoothの役割を整理する

最近、Googleアカウントにログインするたびに「パスキーを設定しましょう」と勧められませんか？ 自分もずっと「なんとなく安全そうだけど、何が起きてるんだろう」くらいの理解でスルーしていました。

で、ある日パスキーでログインしてみたら、スマホで顔認証するだけであっさり入れて便利だったんですが、よく見ると裏でBluetoothが動いている。「え、Bluetoothで何を送ってるの？鍵のデータ？それ大丈夫なの？」と気になって調べ始めたのがこの記事のきっかけです。

ワンタイムパスワードの強化版なのかな？等考えておりましたが、調べてみると思った以上によくできた仕組みだったので、自分の整理も兼ねてまとめてみます。

0. そもそも「秘密鍵」と「公開鍵」って何だっけ？

パスキーの話に入る前に、土台となる「公開鍵暗号方式」を簡単におさらいしておきます。

公開鍵暗号では、秘密鍵と公開鍵という2つの鍵がペアで使われます。秘密鍵は自分だけが持つ鍵で、絶対に他人に渡してはいけない。公開鍵は誰に見せても問題ない鍵。この2つには「秘密鍵で署名したものは、対応する公開鍵でしか検証できない」「公開鍵から秘密鍵を逆算することはできない」という数学的な関係があります。

実はこの仕組み、すでに日常的に使われています。ブラウザでHTTPSのサイトにアクセスするとき、裏側ではTLSという仕組みが動いていて、その中で公開鍵暗号が通信経路の暗号化に使われている。「データが途中で盗み見られないようにする」ために、公開鍵暗号はすでに活躍しているわけです。

じゃあパスキーは何が新しいのか。パスキーは、この公開鍵暗号を通信経路の保護ではなく、「認証そのもの」に使うという発想です。従来はTLSで経路を守りつつも、認証には「パスワード」という秘密の文字列をサーバーに送っていました。パスキーはこの構造を変えて、秘密の情報をサーバーに送ること自体をやめる。

この違いが、パスキーの安全性の根本にあります。

1. パスキーは本当に安全なの？

「なんとなく安全そう」で使い始めた自分が言うのもアレですが、調べてみるとパスキーはパスワード認証に比べて構造的に安全でした。「気をつけていれば安全」ではなく、「仕組み自体が攻撃を成立させない」設計になっている。

サーバーから情報が漏洩したらどうなる？

パスワード認証の場合、サーバーにはハッシュ化されたパスワードが保存されています。パスワード自体が弱かったり、ハッシュ方式が古かったりすると、漏洩時に突破されるリスクがある。パスワードを使い回していれば、他のサービスにも芋づる式に被害が広がります。

一方パスキーの場合、サーバーに保存されるのは公開鍵だけ。公開鍵は「誰に見られても問題ないもの」として設計されているので、サーバーがハッキングされても攻撃者はそこから何もできません。

従来のパスワード認証とパスキーで、攻撃がどう成立する（またはしない）かを図にするとこうなります。

【従来のパスワード認証の攻撃リスク】

graph TD
    P1[ユーザー] -->|パスワードを送信| P2[サーバー]
    P2 -->|ハッシュ化パスワードを保存| P3[(データベース)]
    ATK1[攻撃者] -->|盗聴・フィッシングで
パスワードを窃取| P1
    ATK1 -->|DB漏洩時に
ハッシュを解析| P3
    ATK1 -->|窃取したパスワードで
不正ログイン ❌| P2

【パスキー認証の防御構造】

graph TD
    K1[ユーザーのデバイス] -->|署名だけを送信
秘密鍵は出ない| K2[サーバー]
    K2 -->|公開鍵を保存| K3[(データベース)]
    ATK2[攻撃者] -->|通信を傍受しても
署名は使い回せない ⭕| K1
    ATK2 -->|DB漏洩しても
公開鍵からは何もできない ⭕| K3
    ATK2 -.->|不正ログイン不可 ⭕| K2

フィッシング詐欺にはどう強いの？

パスキーの安全性でもう一つ大きいのが、ドメインとの紐付け。

パスキーは作成されたドメイン（例：codemingle.co.jp）と暗号学的に結びついています。もし悪意のある偽サイト（例：codeming1e.co.jp）に誘導されたとしても、ブラウザが「ドメインが違うからこのサイト用のパスキーは存在しないよ」と判断して、署名プロセス自体が起動しない。

ユーザーが騙されても、ブラウザとプロトコルが騙されない。これはかなり強い。パスワード認証では「偽サイトだと気づかずに入力してしまう」ことが最大のリスクでしたが、パスキーではその心配がありません。

【パスワード：フィッシングが成立する】

graph LR
    U1[ユーザー] -->|偽サイトに
パスワードを入力| FAKE1[偽サイト
codeming1e.co.jp]
    FAKE1 -->|パスワードを横流し| REAL1[本物のサーバー]
    FAKE1 -.->|攻撃成立 ❌| REAL1

【パスキー：フィッシングが成立しない】

graph LR
    U2[ユーザー] -->|偽サイトにアクセス| FAKE2[偽サイト
codeming1e.co.jp]
    FAKE2 -.->|ドメインが違うので
パスキーが起動しない ⭕| U2

2. どういう仕組みで動いているの？

パスキーの技術的な基盤は FIDO2 / WebAuthn という標準規格。ざっくり言うと、パスワードという「秘密の文字列」をサーバーと共有するのをやめて、認証そのものに公開鍵暗号方式を使おう、という仕組みです。

従来のパスワード認証とパスキーで、登録時とログイン時にそれぞれ何がどこを流れるかを見比べてみます。

登録時には何が起きている？

パスワード認証でも、通信経路自体はTLS（HTTPS）で暗号化されているので、パスワードが平文のままネットワークを流れるわけではありません。ただ、TLSの終端であるサーバーにはパスワードが届いて、ハッシュ化されて保存される。サーバー側には「秘密の情報」が存在する構造です。

sequenceDiagram
    participant U as ユーザー
    participant S as サーバー

    Note over U,S: 🔸 従来のパスワード認証（登録時）
    U->>S: パスワードを送信（TLSで経路は暗号化）
    Note right of S: パスワードをハッシュ化して保存
    Note over U,S: ⚠️ 経路は守られるが、サーバーにはパスワードが届く

パスキーの場合は、デバイスの中で秘密鍵と公開鍵のペアが生成されます。秘密鍵はSecure Enclave（Apple）やTPM（Windows）といった極めて安全なハードウェア領域に保存されて、公開鍵だけがサーバーに送られる。サーバーには秘密の情報が一切届きません。

sequenceDiagram
    participant U as ユーザー
    participant D as デバイス
    participant S as サーバー

    Note over U,S: 🔹 パスキー（登録時）
    S->>D: 登録リクエスト
    U->>D: 生体認証（顔・指紋）
    Note over D: 秘密鍵と公開鍵のペアを生成
秘密鍵はハードウェア領域に保存
    D->>S: 公開鍵だけを送信
    Note right of S: 公開鍵を保存
    Note over U,S: ⭕ サーバーに秘密の情報が一切届かない

ログイン時には何が起きている？

パスワード認証では、毎回ユーザーが入力したパスワードがサーバーに送られます。TLSで経路は暗号化されているけど、サーバーには毎回パスワードが届く構造は変わらない。

sequenceDiagram
    participant U as ユーザー
    participant S as サーバー

    Note over U,S: 🔸 従来のパスワード認証（ログイン時）
    U->>S: パスワードを送信（TLSで経路は暗号化）
    Note right of S: ハッシュを比較して検証
    S->>U: ログイン成功
    Note over U,S: ⚠️ 経路は守られるが、毎回サーバーにパスワードが届く

パスキーの場合は、サーバーからランダムな文字列（チャレンジ）が送られてきます。デバイス上で顔認証や指紋認証を通すと、ハードウェア領域内の秘密鍵でそのチャレンジに署名が作られて、署名だけがサーバーに返される。サーバーは持っている公開鍵で署名が正しいかを検証して、一致すればログイン成功。

sequenceDiagram
    participant U as ユーザー
    participant D as デバイス
    participant S as サーバー

    Note over U,S: 🔹 パスキー（ログイン時）
    S->>D: チャレンジ（ランダムな文字列）を送信
    U->>D: 生体認証（顔・指紋）
    Note over D: 秘密鍵でチャレンジに署名
    D->>S: 署名だけを送信
    Note right of S: 公開鍵で署名を検証
    S->>D: ログイン成功
    Note over U,S: ⭕ 秘密鍵はデバイスの外に出ない

ここが一番大事なところで、従来のパスワード認証ではTLSで通信経路を守っていても「サーバーに秘密の情報が届く」という弱点が残っていた。パスキーは認証そのものに公開鍵暗号を使うことで、秘密の情報がサーバーに届くこと自体をなくした。TLSとパスキーは別のレイヤーで安全性を担保していて、ここを理解したとき「Googleがあんなに勧めてくる理由はこれか」と腑に落ちました。

3. Bluetoothも使っているって本当？

ここからが個人的に一番「えっ？」となったところです。

同じデバイス上でのパスキー認証は分かった。でも実際には**「PCでログイン画面を開いて、手元のスマホのパスキーで認証する」**という場面もありますよね。QRコードを読んだりするアレ。

で、このとき自分のスマホのBluetooth設定を見たら、通信が走っていた。「Bluetoothで鍵のデータ送ってるの？それ傍受されたらまずくない？」というのが、冒頭に書いたとおりこの記事を書き始めたきっかけです。

Bluetoothで秘密鍵を送っているの？

結論から言うと、送っていません。認証に関わる通信自体はインターネット経由（エンドツーエンドで暗号化されたトンネル）で行われています。

じゃあ何のためにBluetoothを使っているのかというと、物理的な距離の確認（Proximity Check）。

なぜ物理的な距離の確認が必要なの？

もしBluetoothによる距離確認がなかったら、こんな攻撃が成立してしまう。地球の裏側にいる攻撃者が、あなたのPCのログイン画面を遠隔で操作してQRコードを表示させて、その画像をあなたに送りつけて「これをスマホで読んで認証して！」と騙す。これが「リレー攻撃」です。

パスキーの仕様（FIDO AllianceのHybrid Transportプロトコル）では、この攻撃を防ぐために「PCとスマホがBluetoothの電波が届く距離（数メートル以内）に存在すること」をBLE通信で確認します。

Bluetoothの正体が「データ転送」ではなく「距離の証明」だったと分かったとき、正直かなり感心しました。

クロスデバイス認証はどんな流れで進むの？

具体的には、こんなステップで処理が進みます。

1. PCがQRコードを表示する — QRコードには、BLEでの接続に必要な情報と、暗号化トンネルを確立するための情報が含まれています。
2. スマホでQRコードを読み取る — スマホがQRコードの情報をもとに、PCとのBLE接続を試みます。
3. BLEで近接確認が行われる — PCとスマホがBLEの電波圏内にいることが確認されます。この時点で「目の前にあるPCである」ことが証明される。
4. 暗号化トンネル経由で認証が実行される — 近接確認を通過したあと、インターネット経由の暗号化トンネルを通じて、スマホ上の秘密鍵で署名が作られサーバーに送られます。
5. ログイン完了 — サーバーが署名を検証し、PCのブラウザでログインが完了。

つまりBluetoothの役割は**「今ログインしようとしているPCは、間違いなくユーザーの目の前にある」ことを物理的に証明すること**であり、認証データの転送には使われていません。

BLEの距離確認は万能なの？

ただし、このBLEによる近接確認も万能ではありません。

一つ目のリスクはBLE信号そのもののリレー。2022年にNCC Groupが発表した研究では、BLEの近接確認をリレー攻撃で突破する手法がTeslaの車のキーレスエントリーに対して実証されました。BLEの電波を中継デバイスで転送することで、実際には離れた場所にいるのに「近くにいる」と誤認させることが技術的には可能。FIDO2のHybrid Transportでは単純なBLE信号の中継だけでなく暗号化されたやり取りが絡むので車のキーレスエントリーよりは難易度が高くなりますが、BLEの近接確認自体が絶対的な保証ではないという点は認識しておく必要があります。

二つ目のリスクは攻撃者のデバイスを物理的にBLE圏内に置くという手法。BLEの距離をごまかすのではなく、攻撃者のデバイスが正当に近接確認を通過してしまう。この手法を使った具体的な攻撃シナリオは、次のセクションで詳しく触れます。

4. パスキーなら何をされても安全なの？

ここまで調べてきて「パスキーすごい」という気持ちになっていたんですが、じゃあ万能かというとそうでもない。パスキーが守れるのはあくまで「サーバー側の漏洩」「ネットワーク上の盗聴」「フィッシング」「遠隔からのリレー攻撃」といった領域です。

これらを潰された攻撃者は次にどこを狙うのか。自然と**「ユーザーのデバイスとアカウント周辺」**に目が向くことになる。

Chromeの同期やiCloudが乗っ取られたらどうなる？

これは調べていて「あっ」と思ったところです。同期型パスキーを利用している場合、秘密鍵はクラウド経由でデバイス間を移動する。つまり、クラウドアカウントそのものが乗っ取られれば、同期されたパスキーが攻撃者の新しいデバイスに復元される可能性があります。

特に意識しておきたいのが、ブラウザの同期機能。Chromeに保存したパスキーはGoogleパスワードマネージャーを通じてGoogleアカウントに同期される。SafariのパスキーはiCloud Keychain経由でApple IDに、WindowsのパスキーはMicrosoftアカウントに紐づく。

パスキーへの攻撃は、パスキーそのものではなく、同期先のクラウドアカウントの認証を突破することで成立する。攻撃者の立場で考えれば、サーバーを攻撃するよりもGoogleアカウントやApple IDのパスワードを狙うほうが効率的ということになります。Googleがパスキーを勧めてくるのに、そのGoogleアカウント自体のセキュリティが甘かったら元も子もない、という皮肉な構造です。

攻撃者がすぐ近くにいたらどうなる？

セクション3で触れたBLEの近接確認は、遠隔からのリレー攻撃を防ぐための仕組み。しかし、攻撃者が物理的にBLE圏内にいる場合、この防御は意味をなしません。

2025年にinovex社が発表した研究では、この弱点を突いた具体的な攻撃シナリオが実証されています。攻撃者はまず自分のデバイスを標的のBLE圏内（数メートル以内）に設置する。次に標的にスピアフィッシングメールを送り、偽サイトに誘導。標的が偽サイトで「パスキーでログイン」を選ぶと、攻撃者のデバイスが本物のサイトとの認証を開始してQRコードを生成し、そのQRコードが偽サイト上に表示される。標的がそのQRコードをスマホで読み取ると、スマホは攻撃者のデバイスとBLE接続を行い、近接確認は正当に通過。結果として攻撃者のデバイス上で認証が完了し、セッショントークンが攻撃者の手に渡ります。

sequenceDiagram
    participant V as 標的のスマホ
（認証器）
    participant A as 攻撃者のデバイス
（BLE圏内に設置）
    participant F as 偽サイト
    participant R as 本物のサーバー

    Note over V,R: 攻撃者のデバイスは標的のBLE圏内に設置済み
    F->>A: 標的がログインを試みた
    A->>R: 本物のサーバーに認証を開始
    R->>A: チャレンジを返す
    A->>F: QRコードを生成して偽サイトに表示
    F->>V: 標的がQRコードを読み取る
    V->>A: BLE接続（近接確認を正当に通過）
    V->>A: 署名を送信
    A->>R: 署名を転送
    R->>A: セッショントークンを発行
    Note over A: 攻撃者がセッションを取得 ❌

この攻撃が成立するには「標的のBLE圏内にデバイスを設置できること」「標的をスピアフィッシングで偽サイトに誘導できること」「標的がQRコードを読んで認証してしまうこと」という複数の条件が必要で、難易度は高い。ただ、カフェや電車の中、共有オフィスなど不特定多数が近くにいる環境では、特定の人物を狙った標的型攻撃として現実的なリスクになりえます。

パスキーの仕様上、サービス側（Relying Party）がQRコードによるクロスデバイス認証を禁止する設定を送ることはできますが、この研究では攻撃者がその制限を途中で除去できることも示されています。現時点のWebAuthn仕様では、認証に使われたトランスポート方式が暗号学的に保護されていないため、サーバー側で「クロスデバイス認証が使われた」ことを検知して拒否することが困難です。

デバイスが乗っ取られたら？

スマホにマルウェアがインストールされてデバイスごと遠隔操作されているような状況では、パスキーも安全ではありません。秘密鍵はハードウェア領域に保存されていますが、デバイス上の操作自体が攻撃者に支配されていれば、生体認証を含むログインプロセス全体が悪用される可能性がある。これはパスキー固有の問題ではなく、デバイスセキュリティの問題です。

スマホを盗まれて生体認証を突破されたら？

デバイスを物理的に手に入れた攻撃者が、顔認証や指紋認証を何らかの方法で突破できた場合、そのデバイスに保存されたパスキーを使えてしまいます。可能性としては低いものの、デバイスの紛失時にはリモートワイプなどの対策が重要。

パスキーにアクセスできなくなったら？

デバイスを紛失してクラウド同期もしていない場合、パスキーにアクセスできなくなります。このときサービス側が用意するリカバリー手段（メールやSMSによるリセットなど）がパスキーより弱い認証に頼っていると、そこが攻撃の入り口になりえる。パスキーそのものは強固でも、リカバリーフローの設計が甘ければ全体のセキュリティはそこに引っ張られます。

結局、何を守ればいいの？

パスキーは従来のパスワード認証と比べて守備範囲が格段に広い。でも「パスキーを導入すればすべてが安全」ではなくて、パスキーが潰した攻撃経路の外側にあるデバイスとアカウント周辺を固めることが重要です。

具体的には、Google・Apple・Microsoftなど同期先のクラウドアカウント自体にパスキーや二要素認証を設定することが最優先。ここが突破されると同期された全パスキーが危険にさらされます。加えて、デバイスのOSやブラウザを最新に保つこと、不審なアプリをインストールしないこと、デバイス紛失時にリモートワイプできる設定を有効にしておくこと。このあたりが、パスキーの安全性を支える土台になります。また、公共の場でQRコードを使ったクロスデバイス認証を求められた際には、それが本当に自分のデバイスが生成したQRコードかどうかを意識する習慣も大切です。

まとめ

「なんとなく安全そう」から始まった自分のパスキー調査でしたが、調べてみると複数のレイヤーで攻撃を防ぐ緻密な設計がなされていました。

安全性については、サーバーに保存されるのは公開鍵だけなので漏洩しても問題がなく、ドメインとの紐付けによりフィッシング詐欺も構造的に成立しない。仕組みとしては、TLSが通信経路を守るのとは別のレイヤーで、認証そのものに公開鍵暗号方式を使い、秘密鍵がサーバーに届くこと自体をなくしている。そしてBluetoothの役割は認証データの転送ではなく、リレー攻撃を防ぐための物理的な近接確認。

一方で、デバイスの乗っ取りやクラウドアカウントの侵害、BLE圏内でのスピアフィッシング、リカバリーフローの弱さといった、パスキーの守備範囲外のリスクも存在する。パスキーの強みと限界の両方を理解した上で、周辺のセキュリティもあわせて固めていくのが大事だなと感じています。

Googleがしつこく勧めてくる理由、ようやく分かった気がします。