このシリーズでは、マイナンバーカードを WebAuthn 認証器にして、実在のネット証券にログインするところまで作ってきました。仕組みの核心は「カードの署名を種（seed）にして、サイトごとのパスキー鍵を導出する」ことです。ここにずっと一つ、宿題が残っていました。
電子証明書を更新したら、この鍵はどうなるのか？ 理屈上は「壊れる」はずですが、実際に試したわけではありませんでした。今回、ちょうど自分の利用者証明用電子証明書の更新のタイミングが来たので、更新の前後で実測してみました。結論から言うと——登録済みのパスキーは、全部死にました。
なぜ壊れる「はず」なのか
この認証器の鍵は、次のように作られます。
- カードの利用者証明用鍵で、ある固定入力に署名させる
- その署名を
SHA-256して seed を作る - seed ＋ (rpId, userId) から、サイトごとの Ed25519 / P-256 鍵を導出
つまり鍵の大元はカードの署名です。電子証明書の更新で、カードの中の鍵ペアが新しくなれば、同じ入力でも署名が変わり → seed が変わり → 導出される鍵が全部変わる。結果、これまで各サイトに登録した公開鍵と一致しなくなる＝ログインできなくなる。理屈はこうです。あとは、更新で本当に鍵ペアが変わるのか（＝壊れるのか）を、データで確かめるだけでした。
実測：更新の前後で導出鍵を採る
USB のICカードリーダーにカードを置き、固定した5つの (rpId, userId) について導出鍵（Ed25519 と P-256）を記録しました。これを更新前（before）に採り、更新後にまったく同じ入力（after）で採り直して突き合わせます。
結果：5/5 すべて別の鍵に変わった
| 入力 (rpId / userId) | before (Ed25519 先頭) | after (Ed25519 先頭) |
|---|---|---|
| webauthn.io / test-user-01 | 04D43A2A… | 54916B39… |
| （ある証券） / test-user-01 | 4FF89FCB… | 550D8A2F… |
| google.com / test-user-01 | 2DB65AAF… | 32E80F59… |
| example.com / user-A | 9F905644… | CB824E0E… |
| webauthn.io / user-B | 16C037DE… | B4F45365… |
Ed25519 も P-256 も、全入力で完全に別の鍵になりました。予想どおり、電子証明書の更新でカードの署名鍵が変わり、そこから導出される鍵はすべて変わった。更新した瞬間に、これまで各サイトに登録したマイナ由来パスキーは、例外なく無効になったということです。
「同じカードなのに」が、いちばんの罠
ここが今回いちばん面白かった点です。電子証明書の更新では、物理的なカードは変わりません（新しいカードが発行されるわけではない）。手元にあるのは、見た目も番号もまったく同じマイナンバーカードです。
でも、中の鍵はサイレントに更新されている。だから「同じカードなんだから、今までのログインもそのまま使えるだろう」という直感は間違いで、実際にはカード由来のクレデンシャルが全滅します。カードの見た目は不変、中身（鍵）は可変——このズレが、カードを認証器に使うときの落とし穴です。
おまけで分かったこと
- 更新直後でも、ローカルの導出は即動いた。 after のスナップショットは更新のすぐ後に採れました。つまり新しい鍵はその場でカードに書き込まれている。窓口で「数日は使えない」と言われることがありますが、それは（私の理解では）オンライン側の反映待ちであって、カード内のローカル署名とは別の話のようです。
- マイナは接触リーダーでも読める。 マイナンバーカードは接触・非接触の両対応（券面に端子のあるコンビ型）なので、差し込み型の接触リーダーでも読めました。
設計にどう効くか
カード由来の鍵で作るマイナ認証器は、電子証明書の更新（有効期限による更新は数年ごと）や再発行のたびに、必ず壊れるということです。これはバグではなく仕様——鍵がカードに強く束縛されているからこそセキュアで、その裏返しとして、カードの鍵が変われば導出鍵も変わる。だから運用として、更新・再発行のあとは各サイトでパスキーを登録し直す（再バインドする）ことが前提になります。
実務的な備えも一つ。更新する前に、別のパスキーを足しておくとロックアウトを防げます。今回、私はある証券口座に更新前に別のパスキー（プラットフォーム側のもの）を追加してから証明書を更新しました。おかげで、マイナ由来パスキーが死んだ後もそのアカウントには入れています。前回の設計判断の記事で書いた「マイナは所持ファクターの一つ」という位置づけとも整合します——唯一の鍵にしないのが安全です。
「マイナンバーカードを認証器にする」と聞くと万能に思えますが、鍵はカードの証明書と運命を共にする。この鍵ローテーションを設計に織り込んでおくこと——具体的には「更新後は再バインド」「別手段を必ず併存」——が、実用にするうえでの現実解だと、今回の実測で腹落ちしました。
※ 本記事は自分のカード・自分の口座での検証記録であり、PIN 等の秘密情報や第三者の情報は扱っていません。電子証明書の有効期間や更新後の反映タイミング等の制度面は、公的個人認証サービスの公式情報をご確認ください。
コメントを残す