前回①では、ログインの場面で使われるパスワード、確認コード、認証アプリなどを見ました。では、指紋や顔でログインするとき、サイトは何を受け取って本人を確かめているのでしょうか。

今回は、パスキーを中心に、認証器の中で行われる確認と、サイト側で行われる検証を追います。後半では、USBやNFCで使うセキュリティキーと、TLSのクライアント証明書も取り上げます。

これらに共通するのは、公開鍵暗号を使って「秘密鍵を使えること」を確かめる考え方です。ただし、パスキーとクライアント証明書は同じ仕組みではありません。何を確認し、どの通信の中で使うのかを分けて見ていきます。

指紋や顔は、サイトへ送っているのか

スマートフォンの画面に指紋や顔のマークが出ると、その情報をWebサイトに送っているように見えるかもしれません。パスキーでは、指紋や顔は通常、端末や認証器の中で利用者を確認するために使われます。Webサイトへ送るのは、生体情報そのものではありません。

生体確認に成功すると、認証器が管理している秘密鍵を使える状態になります。その秘密鍵で、ログイン要求に結び付いたデータへ署名します。サイトが受け取るのは、その署名を含む認証応答です。FIDO Allianceも、生体情報とその処理は端末内にとどまり、遠隔サーバーへ送られないと説明しています（FIDO Alliance：Passkeys）。

ここで指紋や顔は、サイトが直接照合するパスワードの代わりではありません。認証器に対して「この秘密鍵を使ってよい利用者か」を確認するための手段です。機器や設定によっては、指紋・顔の代わりに端末のPINなどを使うこともあります。

また、パスキーには、特定の機器に結び付くものと、パスキープロバイダーを通じて複数の機器で使えるよう同期されるものがあります。どちらの場合も、ログイン先のWebサイトに秘密鍵を渡して認証するわけではありません（FIDO Alliance：Passkeys）。

パスキーは、登録した公開鍵でログインを確かめる

パスキーの登録では、サイトとブラウザーが認証器に鍵ペアを作るよう依頼します。認証器は、サイトごとに使う秘密鍵と公開鍵を用意します。秘密鍵は認証器の管理下に置かれ、公開鍵がアカウントに対応付けてサイト側へ登録されます。

登録するとき：公開鍵をサイトへ登録する

サイトは登録処理のためのデータを用意し、ブラウザーを通じて認証器へ渡します。認証器は利用者の操作や確認を経て鍵ペアを作り、公開鍵などの登録情報を返します。サイトは、その公開鍵と認証器を識別する情報を、該当するアカウントの認証情報として保存します。

この時点で、サイトが持つのは公開鍵です。秘密鍵をサイトへコピーして保存する手順ではありません。WebAuthnの仕様では、公開鍵資格情報は認証器で作成され、登録したRelying Party（Webサイト）に結び付けられます（W3C Web Authentication Level 3）。

ログインするとき：新しいチャレンジに署名する

ログイン時、サイトは一度限りのランダムな値であるチャレンジを用意します。ブラウザーは、チャレンジや接続先のサイトに関する情報を含む認証要求を認証器へ渡します。利用者の確認が済むと、認証器は秘密鍵で応答に署名します。

この署名は、チャレンジだけを裸のまま署名するという単純な形ではありません。WebAuthnでは、認証器のデータと、チャレンジや接続元などを含むクライアントデータのハッシュが署名対象に結び付けられます。サイト側は、登録済みの公開鍵を使って署名を検証し、チャレンジや接続先などの条件も確認します（W3C Web Authentication Level 3）。

署名の検証は、公開鍵で署名を復号してハッシュ値を取り出す操作とは限りません。検証処理に公開鍵、署名、署名対象のデータを渡し、有効か無効かを得る、と捉えると仕組みを追いやすくなります。チャレンジと接続先の確認も通れば、サイトは登録された公開鍵に対応するアカウントのログインを認めます。

パスキーを使うサービスでも、パスワードやSMSなど別のログイン・回復手段が残っていることがあります。強い認証を導入しても、弱い代替経路がそのまま残っていれば、アカウント全体の守り方はその経路にも左右されます。

USBやNFCのセキュリティキーも使える

パスキーを使う認証器は、スマートフォンやPCだけではありません。USBポートに挿すドングル型のセキュリティキーや、NFC対応のカード型キーもあります。FIDOの認証器は、製品に応じてUSB、NFC、Bluetoothなどでブラウザーや端末と通信します（FIDO Alliance：Specifications）。

使う流れは、端末がログイン要求を受け取り、対応するセキュリティキーへ認証要求を渡すところから始まります。キーは内部の秘密鍵を使って応答を署名し、端末を通じてサイトへ返します。利用者は機器に触れる、PINを入力するなど、製品や設定に応じた操作を行います。

カードの形をしていても、交通系ICカードをそのまま認証器として使うという意味ではありません。図のカードは、FIDOに対応した秘密鍵を持つセキュリティキーと、読み取りに使うNFCカードリーダーを表しています。かざすカードと読み取り機器の両方が、対応する認証方式に対応している必要があります。

クライアント証明書は、TLS接続の中で証明する

公開鍵暗号を使って利用者側を確かめる方法には、TLSのクライアント証明書認証もあります。ただし、これはパスキーによるWebサイトのログインと同じ手順ではありません。クライアント証明書認証では、TLS接続を確立するハンドシェイクの中で、クライアントが証明書と秘密鍵の所持を示します。

CertificateVerifyは、秘密鍵でハンドシェイクを証明する

TLS 1.3でサーバーがクライアント証明書を要求すると、クライアントはCertificateメッセージでクライアント証明書を送り、その直後にCertificateVerifyメッセージを送ります。Certificateには証明書が入り、CertificateVerifyには署名が入ります。別々のハンドシェイクメッセージです。

CertificateVerifyの署名対象には、Certificateまでのハンドシェイク記録から計算したトランスクリプトハッシュと、TLS 1.3用の文脈情報などが使われます。クライアントは証明書に対応する秘密鍵で署名を作ります。サーバーは自分が記録したハンドシェイクから同じ署名対象を計算し、証明書内の公開鍵、受け取った署名、署名対象を検証処理へ渡します。ここでも、署名を公開鍵で単純に復号してハッシュを取り出すのではなく、検証結果として有効か無効かを確認します（RFC 9846：TLS 1.3）。

証明書そのものについての確認も別に必要です。サーバーは、信頼する認証局につながる証明書か、有効期間内か、失効していないかなどを確認します。署名が正しくても、信頼できない証明書や失効した証明書を受け入れてよいわけではありません。

Finishedは、署名ではなくハンドシェイク鍵で確認する

CertificateVerifyの後にはFinishedメッセージが続きます。Finishedは秘密鍵で作るデジタル署名ではありません。ハンドシェイクで導出したFinished鍵を使い、そこまでのハンドシェイク記録に対するHMAC値を作って送ります。サーバーも自分の記録から期待する値を計算し、受信したFinishedと照合します。

TLS 1.3では、Certificate、CertificateVerify、Finishedが連続する認証メッセージです。CertificateVerifyは証明書に対応する秘密鍵を使えることを示し、Finishedはハンドシェイクと導出した鍵を確認します。Finishedまで確認して、TLSハンドシェイクが完了します（RFC 9846：TLS 1.3）。

サーバーやアプリケーションは、証明書の識別情報をアカウントへ対応付けます。証明書のSubjectやSAN（subjectAltName）など、どの情報を使うかは証明書の設計やサーバー側の設定によります。証明書の名前を見ただけで自動的に特定のWebアカウントが決まるのではなく、サービス側の対応付けが必要です。

公開鍵を使う点は共通でも、入口は違う

パスキーもクライアント証明書も、秘密鍵を送らず、公開鍵で署名を検証する点は共通しています。しかし、誰が何を確かめるか、どの通信の一部として使うかは異なります。

項目	パスキー（WebAuthn）	クライアント証明書（TLS 1.3）
主に使う場面	Webサイトのアカウントへのログイン	TLS接続中にクライアントを認証
サーバー側で使う情報	登録済み公開鍵、チャレンジ、接続先情報など	クライアント証明書、CertificateVerify、Finished、証明書の信頼情報
秘密鍵の役割	認証器がサイト向けの応答に署名	証明書に対応する秘密鍵でハンドシェイクに署名
最後に行うこと	認証情報をアカウントへ対応付ける	証明書の識別情報をアカウントや接続権限へ対応付ける

同じ公開鍵暗号の考え方でも、パスキーはWebAuthnの認証要求、クライアント証明書はTLSのハンドシェイクを使います。証明書と署名を別々に送り、Finishedを別の鍵で確認するTLSの流れは、図④のように分けて見ると追いやすくなります。

次回

次回は「認証とセッション③ ― マイナンバーカードの電子証明書は、何をしているのか」です。

カードの中にある電子証明書と秘密鍵は、どんな場面で使われ、相手側は何を検証しているのでしょうか。パスキーやTLSのクライアント証明書と比べながら、電子証明書の役割を見ていきます。