マイナンバーカードがiPhoneに入るので中身を見てみる

背景

マイナンバーカードがiPhoneに入る

2025年6月からマイナンバーカードをiPhoneに入れることができるようです

上記リンクの手順に従うと数分ほどの操作でウォレットアプリにマイナンバーカードが追加されます

何ができるの？

通常のマイナンバーカードと同じようにカードリーダー等で読み取ることができます
行政のサービスにも対応しており、少なくとも私が住む大田区では「スマートフォンのマイナンバーカード」を使用した住民票交付に対応しているようです

通常のマイナンバーカードと何が違うの？

後に詳しく触れますが、内部に含まれる情報が一部異なります
代表的なものとして利用者証明用と電子署名用のそれぞれについて秘密鍵と証明書の内容が異なります

マイナンバーカードの機能には署名と利用者証明がありますが
今回は利用者証明用の情報に注目して通常のマイナンバーカード（以下、物理カード）とスマートフォンのマイナンバーカード（以下、スマホカード）の違いやその影響について考えていきます

中身を見るために必要なツール

マイナンバーカードの中身をNFCカードリーダーとOpenSCを使って見てみましょう
物理カードもスマホカードも同様にカードリーダーとOpenSCを使って読み取りができます

NFCカードリーダー

一例として、下記型番のNFCカードリーダーとドライバの組み合わせでマイナンバーカードを読み取ることができました
型番：USB-NFC4

ドライバ：I-O DATAが下記リンクで配布しているもの

OpenSC

OpenSCはスマートカード用のツール・ライブラリ群です
マイナンバーカード用のカードドライバを開発してくださった方がいるのでマイナンバーカードに対応しています

下記リンクからOpenSCのインストーラをダウンロードできます

中身を見てみる

他人のマイナンバーカードの中身を見るのはやめましょう
あと本記事の内容でなんらかの損害を被っても私は知りません

pkcs15-tool --dumpでマイナンバーカードに格納されている情報を表示することができます
利用者証明用と電子署名用の用途別にそれぞれPIN 秘密鍵 公開鍵 証明書 CA証明書が格納されていることがわかります

物理カードとスマホカードでどのような違いがあるのでしょうか？

詳しい内容は後述しますが、まとめると下表のように一部項目が異なっています
利用者証明用の項目についてのみ記述しています

項目	同一性
利用者証明用 秘密鍵	✖
利用者証明用 公開鍵	✖
利用者証明用 証明書	✖
利用者証明用 CA証明書	〇

利用者証明用 秘密鍵

物理カードとスマホカードのそれぞれで利用者証明用 秘密鍵を使って特定の文字列に対して署名を行い、署名を比較することで同一性を確認しました
同一文字列に対する署名結果が異なることから秘密鍵が異なることがわかります

署名結果は先頭の一部のみ表示しています

物理カードでの署名

echo "hogehoge" > message.txt
pkcs15-crypt -s -k 1 --pkcs1 -R -i message.txt -o message.signed
(message.signedをバイナリエディタで表示)
Livis4hVhVx0Ggdz8L....

スマホカードでの署名

echo "hogehoge" > message.txt
pkcs15-crypt -s -k 1 --pkcs1 -R -i message.txt -o message.signed
(message.signedをバイナリエディタで表示)
SSPU6S078odK52Ztpe....

利用者証明用 証明書

物理カードとスマホカードのそれぞれについて証明書を読み出します
利用者証明用証明書は利用者証明用PINで保護されているので --verify-pinオプションを使用し、--auth-id 1で利用者証明用PINを指定します

出力結果はマスクしています

証明書の読み出し

PS C:\Users\stodo> pkcs15-tool --read-certificate 1 --verify-pin --auth-id 1
Using reader with a card: Circle USBNFC4 0
Please enter PIN [User Authentication PIN]:
-----BEGIN CERTIFICATE-----
MIIGHzCCBQegAwIBAgIEBxSf...
...........................
...........................
-----END CERTIFICATE-----

出力内容をそれぞれ適当なファイルに保存します
物理カードとスマホカードのそれぞれについて読み出した証明書の内容を表示して比較してみます
物理カードが緑、スマホカードを赤として差分を表示しています

利用者証明用 証明書

PS C:\Users\stodo> openssl x509 -text -noout -in 1.pem

Certificate:
    Data:
        Version: 3 (0x2)
+       Serial Number: 118792... (0x7149...)
-       Serial Number: 158126... (0x96cd...)
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=JP, O=JPKI, OU=JPKI for user authentication, OU=Japan Agency for Local Authority Information Systems
        Validity
+           Not Before: Mar  1 07:21:08 2024 GMT
-           Not Before: Sep  1 06:09:06 2025 GMT
            Not After : May  2 14:59:59 2029 GMT

+       Subject: C=JP, CN=2922A...
-       Subject: C=JP, CN=26CFA...
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
+                  00:9b:57:bf:a0:f8:a3:34:de:bb:7a:37:bb:d3:f6:
+                  19:65:61:...
-                  00:bb:ad:2d:e9:df:f6:2f:f8:7c:91:5e:e4:c5:70:
-                  44:0b:78:...                  
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Key Usage: critical
                Digital Signature
            X509v3 Extended Key Usage:
                TLS Web Client Authentication
            X509v3 Certificate Policies: critical
                Policy: 1.2.392.200149.8.5.1.3.30
                  CPS: http://www.jpki.go.jp/cps.html
            X509v3 Issuer Alternative Name:
                DirName:/C=JP/O=\xE5\x85\xAC\xE7\x9A\x84\xE5\x80\x8B\xE4\xBA\xBA\xE8\xAA\x8D\xE8\xA8\xBC\xE3\x82\xB5\xE3\x83\xBC\xE3\x83\x93\xE3\x82\xB9
            X509v3 CRL Distribution Points:
                Full Name:
+                 DirName:C = JP, O = JPKI, OU = JPKI for user authentication, OU = CRL Distribution Points, OU = Tokyo-to, CN = Minato-ku CRLDP
-                 DirName:C = JP, O = JPKI, OU = JPKI for user authentication, OU = CRL Distribution Points, OU = Tokyo-to, CN = Ota-ku mobileCRLDP
            Authority Information Access:
+               OCSP - URI:http://ocspauthnorm.jpki.go.jp
-               OCSP - URI:http://ocspauthnorm_mobile.jpki.go.jp
            X509v3 Authority Key Identifier:
                keyid:1A:C1:00:F5:96:A3:BC:8C:4B:3D:F1:95:E3:26:99:24:9E:9E:30:8A
                DirName:/C=JP/O=JPKI/OU=JPKI for user authentication/OU=Japan Agency for Local Authority Information Systems
                serial:06:D1:80:06
            X509v3 Subject Key Identifier:
+               F6:53:A0:CF:C3:F7:7D:7F:...
-               59:C1:B2:5A:0F:4D:AD:9C:...
    Signature Algorithm: sha256WithRSAEncryption
    Signature Value:
+       14:95:86:85:c0:00:a1:73:36:cd:21:e2:fb:40:f5:fe:52:1e:
+       19:47:8a:...
-       79:d8:22:61:8e:1a:50:d5:d4:5d:e2:eb:ea:53:f8:dc:12:3f:
-       0c:14:63:...

いくつかの項目を抜粋して内容を見ていきます

Serial Number

認証局ごとに一意なSerial Numberが割り振られます
この値が物理カードとスマホカードで違うものになっていることから、異なる利用者証明用証明書が格納されていることがわかります
なお、証明書に署名をした認証局は同じです
Issuer: C=JP, O=JPKI, OU=JPKI for user authentication, OU=Japan Agency for Local Authority Information Systems Validity

Validity

証明書の有効期限です
期限の開始日について物理カードは転入した日付近でスマホカードは発行した日付近になっています（スマホカードについては9月3日に発行しましたが証明書の開始日は9月1日になっています）
一方で期限の終了日は同じになっています

Validty

+           Not Before: Mar  1 07:21:08 2024 GMT
-           Not Before: Sep  1 06:09:06 2025 GMT
            Not After : May  2 14:59:59 2029 GMT

Subject

CNが異なります

Subject

+       Subject: C=JP, CN=2922A...
-       Subject: C=JP, CN=26CFA...

公開鍵

物理カードとスマホカードで秘密鍵が違うことは確認済みです
秘密鍵と公開鍵は対応関係にあるので公開鍵も別のものになります

公開鍵

            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
+                  00:9b:57:bf:a0:f8:a3:34:de:bb:7a:37:bb:d3:f6:
+                  19:65:61:...
-                  00:bb:ad:2d:e9:df:f6:2f:f8:7c:91:5e:e4:c5:70:
-                  44:0b:78:...  

CRL・OCSP

失効した証明書の問い合わせをするための情報です
CRL配布ポイントもOCSPレスポンダのURLも異なるので物理カードの失効とスマホカードの失効は少なくともこの情報からは別で管理しているように見えます

CRL・OCSP

            X509v3 CRL Distribution Points:
                Full Name:
+                 DirName:C = JP, O = JPKI, OU = JPKI for user authentication, OU = CRL Distribution Points, OU = Tokyo-to, CN = Minato-ku CRLDP
-                 DirName:C = JP, O = JPKI, OU = JPKI for user authentication, OU = CRL Distribution Points, OU = Tokyo-to, CN = Ota-ku mobileCRLDP
            Authority Information Access:
+               OCSP - URI:http://ocspauthnorm.jpki.go.jp
-               OCSP - URI:http://ocspauthnorm_mobile.jpki.go.jp

Subject Key Identifier

公開鍵から生成されるもので、証明書を識別するための識別子みたいです

利用者証明用証明書による利用者証明

物理カードとスマホカードで利用者証明用の秘密鍵 公開鍵 証明書が異なっていることを確認しました
このことを確認した当初は次のような素朴な疑問がわいてきました

物理カードとスマホカードで秘密鍵が変わってしまって利用者証明として機能するのか？

結論、問題なく機能させることができます

利用者証明用 電子証明書による利用者認証の流れを見ながら考えていきましょう
下記の総務省の資料 P.6を参考に図と説明を作成しています

1. サービス提供者から利用者に乱数を送信

サービス提供者が利用者に乱数を送信します

2. 利用者が秘密鍵で署名

利用者は乱数をhash化した後マイナンバーカードの秘密鍵を使ってhash値に署名します

3. 利用者からサービス提供者に署名・証明書を送信

利用者から署名と証明書をサービス提供者に送信します
証明書には公開鍵が含まれており、これはサービス提供者が署名を検証するために使われます

4. サービス提供者が公開鍵で検証する

サービス提供者は公開鍵によって検証を行います。
検証によって利用者が公開鍵に対応する秘密鍵を所有していることが確認できます
「公開鍵で検証することができる署名」は秘密鍵の所有者にしか実質作れないからです

5. サービス提供者が証明書の署名から証明書が改ざんされていないことを確認する

悪意のある人間が改ざんした証明書を送信してくるかもしれません
証明書は認証局によって署名されているので、認証局の公開鍵を使って署名を検証することによって証明書の内容が改ざんされていないことを確認します

6. サービス提供者が認証局に証明書が有効であることを確認する

説明の図には認証局が登場しませんが、証明書の期限が切れていないかどうかを認証局に確認します

結局どうやって利用者証明するの？

ここまでの手順によってサービス提供者は
利用者 = 証明書に入っている公開鍵に対応する秘密鍵を所有している人
であることを確認できます

利用者からサービス提供者に送信される情報は利用者証明用 証明書ですので、公開鍵と利用者情報を紐づけるために証明書が使用されます

利用者証明用 証明書には公開鍵と一緒にCNや公開鍵識別子が含まれていて、これらの情報がまとめて認証局によって署名されています

このことは、CNや公開鍵識別子と公開鍵の関係を偽造できないことを意味しています
もしCNや公開鍵識別子をログインIDとするなら

証明書に入っている公開鍵に対応する秘密鍵を所有している人 = 証明書内のログインIDの人
となります

平たく言うと、
「俺は秘密鍵を持っているから、この証明書に記載されているログインIDは俺のことです」
という関係が成り立ちます

実際には証明書内の情報をそのままログインIDとして使用するのではなく、証明書内の情報とログインIDの対応関係をサービス提供者が保持していると想定されます

物理カードとスマホカードでは秘密鍵と証明書が異なりますが、証明書の情報とログインIDの対応関係さえ適切に管理されていれば利用者証明は機能します

Conclusion

• iPhoneにマイナンバーカードが入る
• 物理カードとスマホカードで秘密鍵が異なる
• それに伴って証明書も新規に発行されている
• サービス提供者側で証明書の情報とログインIDの対応関係が用意されていればスマホカードでも物理カードと同様に本人確認ができそう