マイナンバーカードを使って、マイナポータルへログインする。e-Taxで申告データに電子署名を付ける。どちらもカードを使いますが、カードの中で働いている仕組みは同じではありません。

カードのICチップには、用途の異なる二つの電子証明書があります。さらに、氏名や住所などを申請フォームへ読み込むための機能も別にあります。

前回の「認証とセッション②」では、指紋・顔・公開鍵を使う認証を見ました。今回は、身近なマイナンバーカードを例に、ログインの本人確認と電子文書への署名、そしてログイン後の状態が続く仕組みをつないでみます。

カードのICチップには、二種類の電子証明書

マイナンバーカードのICチップには、公的個人認証サービス（JPKI）で使う「利用者証明用電子証明書」と「署名用電子証明書」が格納されています。電子証明書には公開鍵などが含まれ、それに対応する秘密鍵はICチップの外へ取り出せないように管理されています。

電子証明書そのものは、秘密鍵ではありません。サービス側へ提示するのは電子証明書や署名などで、カードの中の秘密鍵は、認証や署名の計算に使われます。カードの表面に印刷された個人番号とも、役割が異なります。

カードの中には電子証明書のほかにも、用途別のアプリケーション領域があります。あとで見る「券面事項入力補助AP」もその一つです。マイナンバーカードのICチップ内の構成については、デジタル庁の説明でも確認できます。

ログイン用と、文書に署名するものは別

利用者証明用電子証明書：ログイン時の本人確認

利用者証明用電子証明書は、マイナポータルなどのWebサービスにログインするとき、「このカードに対応する本人が操作している」ことを確かめるために使います。暗証番号は数字4桁です。証明書には、氏名・住所・生年月日・性別の基本4情報は記載されません。

サービスが必要とするのは、通常、カードの利用者が登録済みのアカウント本人であることの確認です。氏名や住所をフォームへ入力する機能とは別です。利用者証明用電子証明書の用途は、公的個人認証サービスの説明にも示されています。

署名用電子証明書：申請データに電子署名

署名用電子証明書は、申請データや契約書などに電子署名を付けるときに使います。署名用電子証明書には基本4情報が記載され、暗証番号は英数字6〜16文字です。氏名や住所などの基本4情報に変更があった場合、署名用電子証明書は失効し、更新が必要になります。

文書に署名するときも、証明書が署名を作るわけではありません。カード内の署名用秘密鍵で署名を作り、電子証明書に含まれる公開鍵で、その署名を検証できるようにします。電子証明書に記載される情報や二つの証明書の違いは、JPKI利用者ソフトの証明書表示案内でも確認できます。

e-Taxでは、申告データに電子署名を付ける

e-Taxで確定申告データを作成したら、マイナンバーカードを読み取り、署名用電子証明書の暗証番号を入力して電子署名を付けます。署名されたデータを送信すると、受信側は電子署名と証明書を検証し、データが改ざんされていないことや、署名に使われた鍵と証明書の対応を確認します。

これは、紙に手書きした署名の画像を貼り付ける操作ではありません。申告データに対して暗号技術を使った署名を作り、受け取った側が検証できる形にする操作です。

ここで、e-Taxのログインと申告データへの電子署名を分けておきます。ログインには利用者証明用電子証明書、申告データへの署名には署名用電子証明書が使われます。e-Taxの利用開始時には、券面事項入力補助用パスワードを使って基本4情報を読み込む場面もあります。ひとつのサービスの中で、カードの別々の機能を使うことがあるのです。

e-Taxで使う暗証番号の役割は、国税庁の案内に整理されています。

基本4情報を、申請フォームへ読み込む

氏名・住所・生年月日・性別の基本4情報は、署名用電子証明書にも記載されています。ただし、申請フォームへ自動入力する機能では、署名用電子証明書を読み取るのではありません。ICチップ内の「券面事項入力補助AP」という別の領域から読み出します。

カードを読み取り、券面事項入力補助用の4桁の暗証番号を入力すると、対応したアプリが基本4情報を読み出し、入力欄へ反映します。e-Taxの初回利用時の情報読み取りや、自治体の住民票などのオンライン申請が具体例です。サービスごとに対応状況は異なり、利用者がカードを使う操作を行って情報の提供に同意します。

この暗証番号は「券面事項入力補助用」の番号です。利用者証明用の暗証番号と同じ数字を設定している場合もありますが、機能は別です。国税庁は、券面事項入力補助用パスワードを基本4情報の読み取りに使うと説明しています。また、デジタル庁は券面事項入力補助APを、申請書類作成時の入力支援に使う例を紹介しています。

基本4情報がフォームに入ることと、その文書に電子署名を付けたことは別の処理です。入力補助APは情報の読み出し、署名用電子証明書は文書への署名に使います。

証明書を送るだけでは、本人確認にならない

電子証明書は公開鍵を含む情報です。公開情報なので、証明書を送ることだけでは「今カードを使っている本人が操作した」とは証明できません。証明書をコピーして送るだけなら、別の人も同じ証明書を提示できてしまうからです。

そこでサービスは、ログインのたびに使い捨ての乱数（チャレンジ）を作ってカード側へ送ります。利用者が暗証番号をカード読み取り端末で入力すると、カード内の利用者証明用秘密鍵を使って、そのチャレンジに対する応答を作ります。暗証番号そのものをサービスへ送るのではありません。ブラウザーなどは、利用者証明用電子証明書と応答をサービスへ返します。

サービス側では、証明書の発行者や有効期限、失効情報などを確認します。そのうえで、証明書に含まれる公開鍵、受け取った署名、サービス自身が発行したチャレンジを検証処理に入力し、応答が今回のチャレンジに対して正しく作られたかを判定します。

つまり、サーバーが比較する相手は、サーバー自身が発行した今回のチャレンジです。TLSハンドシェイクのログをそのまま照合する話ではありません。これは文書への署名ではなく、ログイン要求に対するチャレンジ・レスポンス認証です。

カード認証のあと、Webセッションでログインが続く

カードによる本人確認が成功すると、Webサービスはログイン済みの状態を作ります。よくある仕組みでは、サーバーがセッションIDを発行し、HTTPレスポンスのSet-Cookieヘッダーでブラウザーへ渡します。ブラウザーはCookieとして保存し、次のページを開くときにCookieヘッダーでセッションIDを送ります。

サーバーは受け取ったセッションIDを手掛かりに、自分が保持するログイン状態を確認します。そのため、通常のページ移動のたびにカードを読み取る必要はありません。認証が終わった後なら、カードをリーダーから外してもログイン状態が続きます。

ログアウトや一定時間の経過などでセッションが終了すると、同じIDでログイン状態を引き継げなくなります。個人情報の変更や重要な手続きでは、あらためてカード認証や暗証番号の入力を求めるサービスもあります。Cookieの送受信の基本は、Cookieの仕様（RFC 6265）に定められています。

まとめ

マイナンバーカードには、ログイン時に使う利用者証明用電子証明書と、電子文書に署名する署名用電子証明書があります。基本4情報の読み出しには、どちらの証明書とも別の券面事項入力補助APを使います。

ログインでは、サービスが発行したチャレンジにカード内の秘密鍵で応答し、サービスが証明書の公開鍵で検証します。本人確認が終わった後は、セッションIDをCookieでやり取りすることで、カードを外してもログイン状態が続きます。

カード、電子証明書、AP、Cookie。それぞれの役割を分けて見ると、ログインから利用継続までの流れがつながります。

次回

次回は「認証とセッション④ ― ICカードをかざして、タイムカードを作ってみる」です。

カードをリーダーにかざすと、何が読み取られ、どのように出退勤の記録へつながるのでしょうか。ICカードを使った小さな仕組みを、実際に作りながら考えます。