從2025年6月開始,個人編號卡將能夠存放於iPhone中。
按照上述鏈接的步驟,只需幾分鐘的操作,個人編號卡即可新增至錢包應用程式中。
與普通的個人編號卡一樣,能夠通過讀卡器等設備進行讀取。
該卡還支援行政服務,至少在我居住的大田區,似乎已經支持使用「智能手機的個人編號卡」進行戶籍謄本的發放。
稍後將詳細介紹,但內部包含的信息有部分不同。
例如,對於用戶證明和電子簽名,秘密金鑰和證書的內容皆不同。
個人編號卡的功能包含簽名和用戶證明,但這次我們將專注於用戶證明的信息,探討普通的個人編號卡(以下稱為物理卡
)和智能手機的個人編號卡(以下稱為手機卡
)之間的差異及其影響。
讓我們使用NFC卡讀取器和OpenSC來查看個人編號卡的內容。
物理卡
和手機卡
皆可利用卡讀取器和OpenSC進行讀取。
以下型號的NFC卡讀取器和驅動程序組合可以成功讀取個人編號卡:
型號:USB-NFC4
驅動程序:I-O DATA在以下鏈接中提供的版本。
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
使用讀取器中的卡片:Circle USBNFC4 0
請輸入 PIN [用戶驗證 PIN]:
-----BEGIN CERTIFICATE-----
MIIGHzCCBQegAwIBAgIEBxSf...
...........................
...........................
-----END CERTIFICATE-----
將輸出內容分別保存到適當的文件中。
接下來,將顯示並比較物理卡
和手機卡
的證書內容。
將物理卡
標示為綠色
,手機卡
標示為紅色
,顯示其差異。
用戶證明用 證書
PS C:\Users\stodo> openssl x509 -text -noout -in 1.pem
證書:
數據:
版本:3 (0x2)
+ 序列號: 118792... (0x7149...)
- 序列號: 158126... (0x96cd...)
簽名算法:sha256WithRSAEncryption
發行者:C=JP, O=JPKI, OU=供用戶驗證的JPKI, OU=日本地方政府信息系統局
有效性
+ 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
+ 主體: C=JP, CN=2922A...
- 主體: C=JP, CN=26CFA...
主體公鑰信息:
公開金鑰算法:rsaEncryption
公開金鑰:(2048位)
模數:
+ 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:...
指數:65537 (0x10001)
X509v3 擴展:
X509v3 鍵用途:關鍵
數位簽名
X509v3 擴展鍵用途:
TLS 網頁客戶端驗證
X509v3 證書政策:關鍵
政策: 1.2.392.200149.8.5.1.3.30
CPS: http://www.jpki.go.jp/cps.html
X509v3 發行者替代名稱:
DirName:/C=JP/O=公共個人認證服務
X509v3 CRL 發佈點:
完整名稱:
+ DirName:C = JP, O = JPKI, OU = 供用戶驗證的JPKI, OU = CRL 發佈點, OU = 東京, CN = 港區 CRLDP
- DirName:C = JP, O = JPKI, OU = 供用戶驗證的JPKI, OU = CRL 發佈點, OU = 東京, CN = 大田區 mobileCRLDP
驗證信息訪問:
+ OCSP - URI:http://ocspauthnorm.jpki.go.jp
- OCSP - URI:http://ocspauthnorm_mobile.jpki.go.jp
X509v3 發行者金鑰識別碼:
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/OU=日本地方政府信息系統局
序列:06:D1:80:06
X509v3 主體金鑰識別碼:
+ F6:53:A0:CF:C3:F7:7D:7F:...
- 59:C1:B2:5A:0F:4D:AD:9C:...
簽名算法:sha256WithRSAEncryption
簽名值:
+ 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:...
提取幾個項目來查看其內容。
每個認證機構(CA)會指派一個唯一的序列號
。
由於該值在物理卡
和手機卡
中不同,因此可知存儲的用戶證明用證書
不同。
值得注意的是,簽署該證書的認證機構是相同的。
Issuer: C=JP, O=JPKI, OU=供用戶驗證的JPKI, OU=日本地方政府信息系統局
證書的有效期。
關於有效期的開始日期,物理卡
接近入住的日期,而手機卡
則接近發行的日期(手機卡
的發行日期為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
CN
是不同的。
Subject
+ Subject: C=JP, CN=2922A...
- Subject: C=JP, CN=26CFA...
已確認物理卡
和手機卡
中的秘密金鑰不同。
由於秘密金鑰和公開金鑰是對應的,因此公開金鑰也是不同的。
公開金鑰
公開金鑰算法:rsaEncryption
公開金鑰:(2048位)
模數:
+ 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響應者的URL不同,因此,從此信息來看,物理卡
與手機卡
的撤銷似乎是分開管理的。
CRL·OCSP
X509v3 CRL 發布點:
完整名稱:
+ DirName:C = JP, O = JPKI, OU = 供用戶驗證的JPKI, OU = CRL 發佈點, OU = 東京, CN = 港區 CRLDP
- DirName:C = JP, O = JPKI, OU = 供用戶驗證的JPKI, OU = CRL 發佈點, OU = 東京, CN = 大田區 mobileCRLDP
驗證信息訪問:
+ OCSP - URI:http://ocspauthnorm.jpki.go.jp
- OCSP - URI:http://ocspauthnorm_mobile.jpki.go.jp
從公開金鑰生成的,用於識別證書的標識符。
我們確認了物理卡
與手機卡
的秘密金鑰
、公開金鑰
和證書
均不同。
當最初確認此點時,我產生了如下樸素的疑問:
結論是,可以正常運作。
讓我們通過用戶證明用 電子證書
的利用者認證流程來思考這個問題。
以下根據總務省的資料第六頁,製作了圖示和解釋。
服務提供者向用戶發送隨機數。
服務提供者向用戶發送隨機數。
用戶使用秘密金鑰簽名。
用戶對隨機數進行哈希化後,使用個人編號卡的秘密金鑰對哈希值進行簽名。
用戶將簽名證書發送給服務提供者。
用戶將簽名和證書發送給服務提供者。
證書中包含了公開金鑰,用於服務提供者檢查簽名。
服務提供者使用公開金鑰進行驗證。
服務提供者使用公開金鑰進行驗證。
這一過程可以確認用戶擁有與公開金鑰對應的秘密金鑰。
因為只有秘密金鑰的擁有者才實際上能生成「可用公開金鑰驗證的簽名」。
服務提供者檢查證書的簽名以確認證書未被篡改。
壞心眼的人可能會發送篡改的證書。
由於證書是由認證機構簽署的,因此可以使用認證機構的公開金鑰檢查簽名,以確認證書內容未被篡改。
服務提供者向認證機構確認證書有效性。
雖然在說明圖中未出現認證機構,但需要向認證機構確認證書是否已被撤銷。
經過上述步驟,服務提供者可以確認:
用戶 = 擁有證書中公開金鑰所對應的秘密金鑰的人
這確保了用戶證明的有效性。
用戶發送到服務提供者的信息是用戶證明用 證書
,因此證書被用來將公開金鑰和用戶信息關聯起來。
用戶證明用 證書
中包含了公開金鑰及CN
或公開金鑰識別碼
等信息,這些信息集體由認證機構簽名。
這表示,CN和公開金鑰識別碼與公開金鑰之間的關係無法被偽造。
如果將CN或公開金鑰識別碼作為登錄ID,那麼可以得出結論:
擁有證書中公開金鑰所對應的秘密金鑰的人 = 證書中的登錄ID的持有者
這個關係成立。
簡而言之,
「我擁有秘密金鑰,因此這份證書中記載的登錄ID就是我的」
這種邏輯是正確的。
實際上,服務提供者不會直接將證書中的信息用作登錄ID,而是預設保持證書中的信息與登錄ID之間的對應關係。
儘管物理卡
和手機卡
在秘密金鑰和證書上存在差異,只要適當管理證書的信息與登錄ID的對應關係,用戶證明仍然可以正常運作。
物理卡
和手機卡
的秘密金鑰不同手機卡
也能夠如同物理卡
般進行身份驗證。