CPU卡發卡程序設計過程中應當注意的問題
文章出處：http://www.jrzgy.com 作者：中國一卡通網 收編 人氣： 發表時間：2011年09月28日
1摘要
構建IC卡應用系統過程中，如何定義卡中的數據信息（相對邏輯加密卡）或卡中的應用類型及其數據信息（相對CPU卡）及將數據信息寫入卡中，以便應用于系統中進行交易是一個重要環節。這一環節在業界通常稱為卡片個人化。卡片個人化既可以在專門的設備機器上進行，以便于對大批量的卡片進行個人化；也可以在PC機上通過連接IC卡讀寫器進行，以便于對小批量的卡片進行個化。不管硬件設備如何，都必須設計一套程序軟件來進行個人化。這個程序軟件通常稱為發卡程序。本文討論CPU卡發卡程序設計過程中將會遇到的關鍵技術問題及其解決方法。
CPU卡發卡大體可分為三個組成部分：（1）卡結構建立；（2）密鑰寫入；（3）個人化數據寫入。當然，為確保正確發卡，程序設計過程中最好是采用一邊建立卡結構，一邊寫入密鑰和個人化數據。
2發卡前的準備工作
一般地，卡片供應商提供卡片時，已經對卡片進行過初始化（主要用于對卡片進行測試），亦即卡片上已經建立了主文件（MF）及主密鑰文件（MF下的Keyfile文件），主密鑰文件中也已寫入了初始卡片主控密鑰。
在對CPU卡建立特定的卡結構及寫入密鑰和數據之前，程序設計中的第一步應該對卡片進行外部認證。外部認證所使用的密鑰正是初始卡片主控密鑰。
當完成外部認證后，接下來最好是擦除卡片上已有的卡片結構，然后再開始重新建立卡片結構。
許多發卡程序在設計過程中，沒有考慮到擦除卡片上已有的卡片結構，而是在完成外部認證后直接改寫原有卡片的主密鑰文件的卡片主控密鑰。常見問題是由于原有主密鑰文件創建時的空間大小不夠，而發卡程序試圖寫入除卡片主控密鑰外還想寫入卡片維護密鑰時，勢必造成寫入空間不夠而導致寫入不成功。
3密鑰文件的建立與密鑰值的寫入
為了獨立地管理一張卡上不同應用之間的安全問題，CPU卡中的每一個應用放在一個單獨的ADF中。各個ADF及其下屬各文件數據的訪問（包括改寫、讀取）只能應用該ADF下的密鑰文件中的密鑰數值。為討論方便，此處假設只有一個ADF。
用戶卡結構中主要存在以下兩個密鑰文件及相應的幾個密鑰：
(1)MF下的密鑰文件(簡稱KMF)，其裝載的密鑰是卡片主控密鑰(簡稱CCK，以下同)；
(2)ADF下的密鑰文件(簡稱KADF)，其裝載的密鑰有應用主控密鑰(簡稱ACK，以下同),應用維護密鑰(簡稱AMK)，及其它應用密鑰；
(3)其它密鑰，如口令密鑰PIN，口令解鎖密鑰，DES運算密鑰等等。
3.1密鑰文件的創建
各密鑰文件在建立時必須慎重考慮以下兩個要素:
(1)文件大小的分配；
(2)有關權限和密鑰使用后的后續狀態值的規定。
密鑰文件的大小分配取決于要裝載的密鑰個數。每個密鑰均為一條可變長的記錄，每條記錄的長度為密鑰數據長度加7。以此可以計算密鑰文件的大小。在發卡程序設計過程中，常常會出現因為密鑰文件的大小分配不夠而造成后面的密鑰無法寫入。
密鑰文件建立過程中的有關權限和密鑰使用后的后續狀態值的規定一方面起到對密鑰文件本身的安全維護作用，另一方面也將決定對卡片操作的流程。顯然這個要素至關重要。
3.2各密鑰值的寫入
關于密鑰值的寫入，關鍵問題是要弄清楚該密鑰要求以何種形式寫入。通常有以下幾種形式：
(1)以明文形式寫入（常見的如口令密鑰PIN的寫入）；
(2)以帶線路保護的形式寫入（要求計算MAC）；
(3)以對密鑰值進行加密后的密文形式寫入（要求計算DES或3DES）；
(4)以對密鑰值進行加密并帶線路保護的形式寫入（要求計算DES＆MAC）。
如果密鑰值的寫入要求加密并帶線路保護，則密鑰值寫入時須對該密鑰值進行DES＆MAC計算后以密文形式寫入（當然卡片操作系統內部會自動將其解釋成明文），帶線路保護的目的是防止密鑰值在寫入的過程中被劫取。如果不要求帶線路保護寫入，可直接以明文方式寫入。
在發卡程序設計過程中，尤其要注意卡片主控密鑰、應用主控密鑰、應用維護密鑰及其它密鑰之間的關系及其寫入要求。
3.2.1卡片主控密鑰與應用主控密鑰
卡片主控密鑰是對整個卡片的訪問起控制作用的密鑰，由卡片生產商寫入，由發卡方替換為發卡方的卡片主控密鑰。發卡程序設計過程中,在對卡片進行任何操作之前,必須使用卡片主控密鑰作外部認證,
應用主控密鑰是應用的控制密鑰，在卡片主控密鑰控制下寫入。一般地，發卡方替換卡片的主控密鑰之后，為驗證替換工作正確，再用新的卡片主控密鑰作一次外部認證。
