チャレンジ・レスポンス認証

サーバが送った乱数（チャレンジ）に認証器が秘密鍵で署名し、サーバが登録済みの公開鍵でその署名（レスポンス）を検証する

1. 認証器：サーバにアクセスを要求

2. サーバ：乱数によるチャレンジコードを送信

3. 認証器：チャレンジに秘密鍵で署名してレスポンスを返送

4. サーバ：登録済みの公開鍵で署名検証して，検証可能であればアクセス承認

つまり、サーバは、秘密鍵そのものではなく「その秘密鍵を持っていなければ作れない署名」が返ってきたことを確認する。

code:mermaid

sequenceDiagram

participant A as 認証器

participant S as サーバ

A->>S: アクセス要求

S->>A: チャレンジ c（一回限りの乱数）

A->>A: σ = Sign(sk, c)

A->>S: レスポンス σ

S->>S: Verify(pk, c, σ)

alt 検証成功

S-->>A: アクセス承認

else 検証失敗

S-->>A: アクセス拒否

end

SignとVerifyの関係

秘密鍵と公開鍵は、署名 と 検証 がうまくできるペアとして生成されている。

検証(公開鍵, チャレンジ, 署名(秘密鍵, チャレンジ)) = 成功

つまり、秘密鍵で作られた署名は、その秘密鍵に対応する公開鍵で検証できる。

一方、別の秘密鍵で作られた署名は、通常その公開鍵での検証に失敗する。

検証(公開鍵, チャレンジ, 著名(秘密鍵2, チャレンジ)) = 失敗

この性質により、秘密鍵に対応する公開鍵を預けられたサーバは、秘密鍵そのものを調べなくても、ユーザーが秘密鍵の持ち主かどうか判別可能になる。