專利名稱：檢驗數字式免費票據有效性的方法及其設備的制作方法
郵件上應用數字式郵資郵戳已是人們所熟知的方法。
為了讓發(fā)件人易于生成郵資郵戳，用戶可采用諸如德國郵局使用的免費系統(tǒng)在用戶系統(tǒng)中生成郵資郵戳，然后通過任意可用的界面將其輸出到打印機上。
德國臨時申請書DE100 20 402 A1公布了這一普通的做法。
為了防止欺詐性使用這種方法，數字式郵資郵戳包含有密碼信息，例如有關控制生成郵資郵戳的用戶系統(tǒng)的識別符。
本發(fā)明基于建立一種快速、可靠地檢驗郵資郵戳真實性的方法的目標，特別是該方法能適合于大規(guī)模的檢驗程序，主要是用于郵件中心或貨運中心。
根據本發(fā)明，真實性的檢驗是根據數據密鑰是從中央數據庫(ZinScentral)生成并傳輸到本地付費保險系統(tǒng)(ZinS local)這樣的方法完成的，這一目標業(yè)已實現(xiàn)。它是通過使用一個生成的免費密鑰和用到郵件上的郵資郵戳實現(xiàn)的，因此，包含在郵資郵戳中的密碼信息解密后用于檢驗郵資郵戳的真實性。
為了增強該方法的安全性，本地付費保險系統(tǒng)最好是能輸入數據密鑰，并將輸入的結果傳輸到中央數據庫(ZinS中央系統(tǒng))。
在運用該方法的一個特別較好的實施例中，輸入的結果是作為數據記錄傳輸的。
數據記錄最好是含有密鑰。密鑰可能有各種屬性，特別是它可能是對稱的密鑰或非對稱密鑰。根據使用的需要，密鑰可用來解密和/或加密信息。依據密鑰的本性，密鑰還應能夠同樣地傳輸信息。例如，密鑰包含免費密鑰、密鑰生成和/或其結束日期的信息。
為了確保一致的密鑰交換，中央數據庫(ZinS中央系統(tǒng))最好能檢查輸入的結果，并將其傳輸到價值轉移中心(郵資端)。
該方法的實施例還能在價值轉移中心依據輸入的結果開展進一步的過程步驟。
其結果可用多種方法進行檢查，不過，最好的方式還是通過對密鑰解密而檢查結果。
在運用該方法的一個實施例中，其特征在于一旦數據密鑰成功地輸入到幾乎所有的本地付費保險系統(tǒng)(ZinS本地)，該數據密鑰在價值轉移中心(郵資端)作為一個新的免費密鑰釋放，隨后被用來生成新的郵資郵戳。
運用該方法的一個實施例還能依據在付費保險系統(tǒng)中以前所進行的密鑰交換在價值轉移中心進行密鑰交換。這種方法能確保只有當新密鑰已存在于本地付費保險系統(tǒng)時使用新密鑰才能生成郵資郵戳。這樣可保證本地付費保險系統(tǒng)能夠檢驗每個生成的郵資郵戳的真實性。
在運用該方法時，運用本地付費保險系統(tǒng)密鑰交換控制價值轉移中心密鑰交換的實施例的明顯優(yōu)點在于至少結合了本發(fā)明的其它幾個過程步驟。
特別是通過幾種特征的結合，確保了密鑰交換能快速可靠地進行，并能對每次密鑰交換進行檢驗。
在進行密鑰交換時，最好是能將新數據密鑰從價值轉移中心(郵資端)傳輸到中央付費保險系統(tǒng)。
這里，價值轉移中心最好是能將數據密鑰與傳輸密鑰(KT)一道加密。
這里，通常將傳輸密鑰與主傳輸密鑰(KTM)一道加密。
數據密鑰最好是在價值轉移中心生成，這樣具有防止數據密鑰在向價值轉移中心傳輸期間對它的任何欺詐性改變的優(yōu)點。
為了進一步增強數據的安全性，最好能為數據密鑰提供密鑰識別信息。
密鑰識別信息最好能同樣以加密形式傳輸。
為了確保每一加密和/或解密步驟均能使用有效的數據密鑰，最好能為數據密鑰提供一個生成計數器和/或與生成計數器一道傳輸。
為了避免使用無效的密鑰，免費密鑰最好也能提供一個結束日期，使前面的數據密鑰能與該結束日期一道傳輸。
所述數據密鑰可以用來進行部分或多部分檢驗，以及生成郵資郵戳和/或解密郵資郵戳中包含的信息。
在進行一部分檢驗時，最好能包括對郵資郵戳中包含的密碼信息進行解密。
當檢驗過程包括對密碼信息解密時，它能直接確定郵資郵戳的真實性，因此，檢驗是實時進行的。
另外，進行部分檢驗時最好能包括對郵資郵戳生成的日期與當前的日期進行比較，加入郵資郵戳的生成日期，特別是以加密的形式可增強數據的安全性，因為通過對郵資郵戳生成的日期與當前的日期的比較可以避免一種郵資郵戳的多次使用。
為了進一步提高檢驗速度，閱讀單元與檢驗單元最好以同步協(xié)議交換信息。
在運用該方法時，另一個較好的實施例的閱讀單元與檢驗單元是通過非同步協(xié)議進行相互交流的。
這里，閱讀單元向檢驗單元發(fā)出數據電報是非常重要的。而且數據電報最好包含郵資郵戳的內容。
本發(fā)明的其它優(yōu)點、特征和實際改進的本地可從從屬的權利要求和下面參照圖解的較好實施例的表達中可見一斑。


圖1顯示的是本發(fā)明一個較好實施例的密鑰分發(fā)系統(tǒng)。
圖2是本發(fā)明密鑰分發(fā)系統(tǒng)的應用實例。
圖3是中央付費保險系統(tǒng)(ZinS中央系統(tǒng))與價值轉移中心(郵資端)之間界面的示意圖。
圖4顯示的是向中央付費保險系統(tǒng)(ZinS central)加入數據密鑰的過程步驟。
圖5顯示的是密鑰從中央付費保險系統(tǒng)(ZinS中央系統(tǒng))分發(fā)到包括有關密碼系統(tǒng)的本地付費保險系統(tǒng)的示意圖。
圖6顯示的是DLL界面的連接。
圖7顯示的是封裝元件和處理錯誤報文的過程步驟的示意圖。
下面將結合個人計算機免費系統(tǒng)對本發(fā)明作一介紹。付費保險使用的過程步驟獨立于用來生成郵資郵戳的系統(tǒng)。單個檢驗站，特別是郵件中心中所述的分散檢驗是一種較好的方法。由于同樣的原因，集中檢驗也是可能的。
在運用本發(fā)明一個較好的實施例中，單個檢驗站是本地付費保險系統(tǒng)，它較好地通過數據連接與中央付費保險系統(tǒng)相連。
在所述的特別好的實施例中，中央付費保險系統(tǒng)也與價值轉移中心相連。
在特別好的實施例中，價值轉移中心即為下面的郵資端。具有優(yōu)勢的實施例的中央付費保險系統(tǒng)即為下面的ZinS中央。
價值轉移中心與付費保險系統(tǒng)之間運用的技術界面包括密碼密鑰的交換。
在價值轉移中心與付費保險系統(tǒng)之間待交換的密鑰能確保生成的郵資郵戳不會被偽造，特別是二維條形碼的那一部分的內容，運用所述的密鑰對形成的郵資郵戳加密，從而達到這一目的。既然所選擇的密鑰是一種對稱的密鑰，由于與性能相關的原因，它必須從價值轉移中心向付費保險系統(tǒng)傳輸，從而分發(fā)到各個郵件中心。
運用特殊的密碼卡能確保密鑰的可靠儲存。本發(fā)明擁有幾個應用轉換鍵，它們能運用這種特殊的硬件管理這些密鑰。這些密鑰的整個生命周期，從其產生、輸出、分發(fā)，一直到輸入到分散系統(tǒng)中，都被充分使用，以便優(yōu)化過程的參數。
圖1顯示一個較好實施例使用的密鑰分發(fā)系統(tǒng)。它是用于價值轉移中心與中央付費保險系統(tǒng)之間的分發(fā)系統(tǒng)。
在過程的第一步為生成郵資郵戳而交換免費密鑰時，首先生成一個新的免費密鑰。
這里使用的術語免費密鑰絕不要以特定的含義去理解，因為所述的密鑰可以以不同的方式生成郵資郵戳。
例如，有可能直接用這種免費密鑰生成郵資郵戳。
不過，它也同樣可以，而且對那些防止操縱生成郵資郵戳的高安全度、擁有多種加密數據內容的系統(tǒng)來說，數據內容的生成最好是幾種運算的結果。這樣，運算結果就會在一個或幾個地方包含到具有免費密鑰的郵資郵戳中。例如，德國臨時專利申請書DE 100 20 402 A1中一種密碼串就包含在免費密鑰中。
為了進一步提高防止欺詐生成郵資郵戳的保護能力，出現(xiàn)了事件特異的免費密鑰交換方式。
在發(fā)表的案例中，新的免費密鑰在固定的時間間隔，例如當預先規(guī)定的時間間隔過期后生成。
不過，同樣也可以依據其它參數，例如根據所付的郵資數量和/或免費郵件，重新生成免費密鑰。
就原則而論，新生成的新免費密鑰可在任意的地方執(zhí)行。不過，為了提高數據的安全性，最好是盡量減少對新免費密鑰的傳輸，盡量在價值轉移中心或其區(qū)域內生成該密鑰。
為了確保高水平地保護該方法，防止欺詐，郵資郵戳含有的信息最好能在本地付費保險系統(tǒng)，例如郵件中心或貨運中心依據免費密鑰解密。
為了確保做到這一點，免費密鑰應從價值轉移中心傳輸到中央付費保險系統(tǒng)，而且這種傳輸最好是自動進行的。
這種交換最好是通過付費保險系統(tǒng)(ZinS中央服務器)的服務器實現(xiàn)的，價值轉移中心(郵資端)不需進行配置。由于該服務器不必需要了解價值轉移中心(ZinS本地系統(tǒng))及其有關的密碼系統(tǒng)，ZinS中央服務器對所述服務器而言就至關重要了。
生成較理想的新對稱免費密鑰后，該密鑰可安全地傳輸到中央付費保險系統(tǒng)(圖1中過程的第二步)，并從那兒分發(fā)到位于本地付費保險系統(tǒng)的密碼系統(tǒng)(圖1中過程的第三步)。本地付費保險系統(tǒng)返回輸入操作結果(圖1中過程的第四步)，從而確認密鑰的成功輸入。中央系統(tǒng)對結果進行編譯、驗證并傳輸到價值轉移中心(郵資端)(圖1中過程的第五步)。
一旦密鑰成功地輸入到本地付費保險系統(tǒng)的所有密碼系統(tǒng)，它在價值轉移中心(郵資端)釋放，隨后用來生成新的郵資數額(圖1中過程的第六步)。
該理想的對稱密鑰是運用免費密鑰生成的郵資郵戳防偽的一部分，憑借它們所述的郵資郵戳以二維的條形碼形式呈現(xiàn)。因此，這些密鑰的交換必須確保高度保密。為了做到這一點，堅持下述各點非常重要·內容的機密性傳輸期間不允許第三者能看到傳輸的密鑰。此外，還必須確保密鑰的安全地儲存，第三者不可能看到密鑰，韋伯珊翠(WebSentry)密碼卡可確保實現(xiàn)后者。
·內容的完整性絕不允許第三者偽造部分密鑰。
·認證通信雙方必須清楚地了解發(fā)送者/接收者的身份是正確的。就接收者角度而言，它說明密鑰是由郵資端生成的；而就發(fā)送者角度而言，必須確保只有有效的ZinS本地密碼系統(tǒng)才能接收該密鑰。
在陳述的對稱方法中，通信雙方具有相同的密鑰KT。價值轉移中心(郵資端)應用該密鑰KT對待傳輸的數據密鑰KD加密，然后向付費保險系統(tǒng)(ZinS中央系統(tǒng))服務器傳輸所述的數據密鑰KD。
該密鑰從中央付費保險系統(tǒng)進一步分發(fā)到本地付費保險系統(tǒng)的ZinS本地密碼系統(tǒng)。這些系統(tǒng)同樣可以訪問密鑰KT，而且可以再一次解密密鑰KD。由于密鑰KT是用來在傳輸期間安全保護密鑰KD的，下面也將其稱做傳輸密鑰。
由于所有的本地付費保險系統(tǒng)均接收到相同的數據，因此不必在每個本地密碼服務器與價值轉移中心(郵資端)之間再另行定義一個傳輸密鑰KT。不過出于安全原因，這個密鑰KT應像數據密鑰KD一樣在固定的時間間隔更新一次。然而，由于沒有那么多的正文如同密鑰KD那樣被這一密鑰加密，可以選擇較長的交換時間間隔，這里一到二年的交換時間間隔比較合適。
這種方法的一個重要部分是傳輸密鑰KT的密鑰交換。出于安全的原因，傳輸密鑰KT的密鑰交換不能像數據密鑰KD的交換那樣通過相同的渠道進行。這種交換不能手工進行。由于這一程序必須在固定的時間間隔為幾個本地付費保險系統(tǒng)進行，這里還必須提供另一種方法，通過它傳輸密鑰的交換同樣可以自動進行。
為了這一目的，ANSI X9.17標準(根據對稱方法金融服務的密鑰管理)定義被稱做主傳輸密鑰(下面均稱做KTM)的另一種密鑰等級。這種密鑰必須在特殊的安全預防措施下安裝到密碼卡上，因此只需在較長的時間間隔交換。在此，同樣的KTM安裝在所有的系統(tǒng)上，它對傳輸密鑰KT加密，使這些傳輸密鑰KT通過相同的渠道以自動的方式分發(fā)和輸入。它們的分發(fā)如同數據密鑰的分發(fā)完全一樣，各個系統(tǒng)或密碼卡的初始化在以下的章節(jié)有詳細的說明。
為了確保報文的完整性以及對發(fā)送者(等于郵資端)的認證，為每個密鑰報文建立了矩陣碼(MAC)。為了生成MAC，需要有簽名密鑰KS。如同KTM一樣，簽名密鑰KS是在密碼卡初始化期間輸入生成的，以后就用這種KS對數據密鑰報文進行簽名。這樣，報文在德國郵政股份有限公司的內聯(lián)網上傳輸期間信息的機密性便通過使用這種高等級的密碼方法得到保證。一種特別理想的加密和解密方法是Triple DES(密鑰長度168比特)，SHA-1算法對計算散列值特別有效。
分發(fā)和儲存數據密鑰時必須考慮付費保險系統(tǒng)郵資端和密碼系統(tǒng)不同時期的有效性。在任意確定的時間點，在郵資端最多只有二個密鑰KD可用，即一個當前有效的密鑰和另一個對新生成的郵資數額進行加密的密鑰(KDNEW)。
現(xiàn)有密鑰與密鑰(KDNEW)運行“交換”狀態(tài)時，新密鑰傳輸到付費保險系統(tǒng)的密碼系統(tǒng)。一旦這一密鑰被本地付費保險系統(tǒng)的所有密碼系統(tǒng)成功地輸入時，便生成一份ZinS中央系統(tǒng)的釋放報文，此時KDNEW便在郵資端被用來對新郵資數額進行加密。到這時，舊的KD應從郵資端刪除，再也不會用來生成新的郵資數額。
本地付費保險系統(tǒng)的密碼系統(tǒng)的情況則不同由于下載的郵資數額可用做預先設定的時間，例如三個月，為了生成郵資郵戳，必須要有幾種可用的密鑰KD對郵資郵戳進行檢驗。
此外，當涉及密鑰的分發(fā)時，還必須考慮到那些不能輸入到某些密碼系統(tǒng)，因此在郵資端不能激活的密鑰的現(xiàn)狀如何，有可能這些密鑰被輸入到其它的密碼系統(tǒng)。就原則而論，在未來的檢驗過程中應考慮這種情況。
在此，為了取得一致的現(xiàn)狀，以便明確密鑰的現(xiàn)狀和便于簡便可能的系統(tǒng)維護，密鑰分發(fā)方法的下述執(zhí)行方式極為有用(1)數據密鑰以加密的形式與無歧義密鑰ID(密鑰相位指示符)、歧義生成計數器和有效的、先前數據密鑰的結束日期一起傳輸。生成計數器用來區(qū)分錯誤的多次加載企圖與所需的對對稱數據密鑰的更新(確保作業(yè)安全，見(7))。
(2)中央付費保險系統(tǒng)應通過確認報文對價值轉移中心(郵資端)傳輸的每份數據密鑰進行回復。
(3)如果回復是肯定的，說明數據密鑰已成功地安裝到所有的本地付費保險系統(tǒng)，可以通過免費的個人計算機發(fā)送到用戶。
此時，生成計數器為后繼的數據密鑰增加“1”。
(4)如果回復是否定的，說明數據密鑰沒有成功地安裝到所有的本地付費保險系統(tǒng)上，價值轉移中心不應該將其發(fā)送到用戶系統(tǒng)用來生成郵資郵戳，否則就會出現(xiàn)大量無效郵件的風險。
此時，生成計數器不會為后繼的數據密鑰增加“1”，也就是說，它仍保留在前一次傳輸的數值。
(5)如果沒有回復，此時價值轉移中心(郵資端)不能向中央付費保險系統(tǒng)(ZinS中央)進一步傳輸密鑰(當然，這種傳輸試圖會遭到付費保險系統(tǒng)的忽視，而且在價值轉移中心也會受到阻截)。
(6)如果在較長一段時間(超過超時時間)收不到付費保險系統(tǒng)的回復，此時價值轉移中心(郵資端)可以通過其直接的或間接的用戶界面發(fā)出報警。
(7)一旦密碼卡接收到數據密鑰，它將刪除具有與最近傳輸相同的生成計數器值的所有數據密鑰。這可保證因錯誤而多次傳輸時，那些僅在前面加載到部分密碼卡上的密鑰將會被刪除，它確保作業(yè)能安全地傳輸密鑰。
(8)在本地付費保險系統(tǒng)的密碼卡上，一個程序將重復調用，最好是定期地，特別是每天地調用，刪除那些不再需要的數據密鑰。當儲存在CKA_END_DATE屬性中的后繼數據密鑰的結束日期小于當前系統(tǒng)日期時，數據密鑰被刪除(除了(7)之外的一個較好的實施例)。
(9)涉及前一個密鑰的結束日期，由于生成的帶有過時郵資數額的郵資郵戳在當地付費保險系統(tǒng)檢查時仍然承認其在有效期接束后兩天還有效，必須為其結束日期制定一個寬限期。另外，生成一個與新數據密鑰生成與釋放之間的時差也必須予以考慮。
圖2是所述密鑰管理應用領域及其在付費保險系統(tǒng)中的應用的總體情況。此外，對較好的一些應用領域也進行了介紹。
以下對應用轉換鍵作進一步的詳細說明，并對有關所述的密鑰管理方法也將做詳細介紹。所述的應用將以密碼卡為例進行說明。
首先介紹密碼卡在價值轉移中心初始化的方式·安裝與配置密碼卡，上載固件，因為生產廠商沒有進行這些工作。通過嵌入碼(專有軟件程序)使固件功能得到擴充。為了安全原因，PKCS#11-特異的(公共密鑰密碼標準)密鑰程序(生成，刪除，等)對用戶封鎖，從而確保密碼卡的密鑰高安全性。
·定義群集(用于集中密碼卡)。
·生成和儲存本地主密鑰(LMK)。LMK應至少在三個組分中分發(fā)，其中兩個組分應特別有利于重新產生或使密碼服務器卡重新初始化。最好是每個組分用PIN保護寫到智能卡(SmartCards)上，這樣安全管理員可得到一張智能卡。此外，還必須生產一些備用智能卡，這樣LMK便可用作上述的主傳輸密鑰KTM。
·用戶管理刪除默認安全管理員和定義包括必要的認證規(guī)則的安全管理員(基于智能卡)。
·生成初始簽名密鑰KS，用KTM加密(包裝)，儲存為文件，以后可將該文件拷貝到軟盤上(只有安全管理員可以訪問該文件/軟盤)。
·生成第一個傳輸密鑰KT，建立有關的密鑰報文，并將該報文儲存到文件中以及日后可將該文件拷貝到軟盤上(只有安全管理員可以訪問該文件/軟盤)。
生成主傳輸密鑰新的主傳輸密鑰(KTM)最好以下述方式生成。有關確認卡的本地主密鑰(LMK)可用作KTM。為安全起見，該LMK至少應細分為3個組分，其中至少2個組分需要重新輸入。
每個組分儲存在智能卡上，因此每個安全管理員接收一個智能卡，并用單個的PIN將其固定。對PIN保密和將智能卡儲存在安全本地可以防止未授權人員對它們的訪問。
為了執(zhí)行主傳輸密鑰，最好應有2種LMK組分一對應于2種不同授權卡，以便可以進行雙重控制原則的自動執(zhí)行。
KTM必須是Triple DES密鑰，其ID屬性由一個類型標識和一個無歧義的數字組成。
類型標識KT無歧義數字01到99。
長度固定的4比特，存檔為CK_CHAR[]。
作為原則，各項安全機制均應確保只有授權人員方能進行密鑰交換。下面所述使用簽名密鑰的實施例具有很大的優(yōu)越性，因為它證明對防止操作具有極高的安全性。
簽名密鑰能保證密鑰報文的完整性，而且它還可在輸入密鑰前用來確定密鑰報文的發(fā)送者是否是郵資端。只有通過智能卡注冊的安全管理員可以生成簽名密鑰，它必須是TDES密鑰，具有“敏感”設置為“TRUE”、“抽取”設置為“FALSE”的安全屬性，以便防止在卡以外的地方看到密鑰的明文。該密鑰的ID屬性由一個類型標識和一個無歧義的數字組成。
類型標識KS無歧義數字01到99。
長度固定的4比特，存檔為CK_CHAR[]。
為了讓該密鑰輸出，它必須與KTM包裝在一起，然后作為文件儲存在軟盤中。軟盤必須存放在安全的地方，可用來使密碼服務器卡初始化。一種用來包裝該密鑰的程序可確保密鑰文件的完整性，該程序最好也應儲存在卡上。
傳輸密鑰KS的較好屬性編輯在下表中
LABEL屬性中的隨機號可用來確定是否成功地輸入到密碼服務器卡，以及與該隨機號相關的散列值(例如通過SHA-1方式)形成，它可用來確認成功輸入和釋放傳輸密鑰。
CKA_ID和CKA_LABEL屬性將填寫為CK_CHAR。所有其它屬性均定義在pkcs11.h文件的類型之中。
簽名密鑰用KTM(＝LMK，CKM_KEY_WRAP_WEBSENTRY機制)加密，如同LMK一樣上載到現(xiàn)場的硬件上。
下面介紹傳輸密鑰的生成。
本應用轉換鍵生成了包括有關密鑰報文的傳輸密鑰，該密鑰的生成模塊最好配置成只有安全管理員能夠啟動傳輸密鑰和/或有關密鑰的報文的生成，交換時間間隔應為一年或二年。
傳輸密鑰應依次為TDES密鑰，具有下述屬性
LABEL屬性中的隨機號可用來確定是否成功地輸入到密碼服務器卡，以及與該隨機號相關的散列值(例如通過SHA-1方式)形成，它可用來確認成功輸入和釋放傳輸密鑰。
CKA_ID和CKA_LABEL屬性將填寫成CK_CHAR[]形式。所有其它屬性均定義在pkcs11.h文件的類型之中。
傳輸密鑰用KTM(＝LMK，CKM_KEY_WRAP_WEBSENTRY機制)加密，具有下述結構的報文形成后從價值轉移中心向中央付費保險系統(tǒng)傳輸
進一步分發(fā)后，該傳輸密鑰報文轉移到ZinS中央服務器。界面便成為一個Session Bean，該服務可通過命名服務(Java命名目錄界面)查出，傳輸方法則有賴于上述的數據塊。
另外，報文以文件的形式儲存在郵資端，安全管理員可以日后將其儲存到放置在安全地方的一張或二張軟盤上，以后軟盤便可用來使新的密碼服務器卡初始化。
下面介紹一種較好實施例釋放傳輸密鑰的方法。
價值轉移中心通過配置可以釋放傳輸密鑰KT。一旦傳輸密鑰KT成功地分發(fā)并成功地輸入到所有本地付費保險系統(tǒng)(ZinS密碼系統(tǒng))，為了釋放傳輸密鑰KT，中央價值轉移中心可通過一個界面釋放該傳輸密鑰。只有通過這樣的釋放，有關的傳輸密鑰才能日后用來加密數據密鑰(KD)。
這時，界面便成為一個塞型餅(Session Bean)，該服務可通過命名服務查出。
釋放程序的數據結構最好具有下述參數
通過參數2可對PP密鑰管理系統(tǒng)的對方，即付費保險系統(tǒng)(ZinS密鑰管理系統(tǒng))的密鑰分配系統(tǒng)進行驗證。這是從傳輸密鑰的LABLE屬性應用SHA-1法建立的一種散列值，在生成傳輸密鑰時用一個隨機號填寫LABLE屬性，由于傳輸密鑰和其所有屬性在傳輸期間是加密的，因此只有ZinS密碼服務器能計算正確的散列值。
如果傳輸的散列值等于為LABLE屬性計算出的KT值，則所述的散列值位于郵資端的韋伯珊翠(WebSentry)模塊，如果傳輸的加工狀態(tài)為“true”，傳輸密鑰被激活。這表明隨后數據密鑰報文將被該傳輸密鑰加密。
當加工存在錯誤(傳輸狀態(tài)＝false)時，該應用轉換鍵也出現(xiàn)變異。在本案例中，該密鑰的生成和分發(fā)的狀態(tài)是有協(xié)議規(guī)定的，因此有關的傳輸密鑰也同樣被刪除。
以下介紹一個較好的實施例生成新數據密鑰的方法。
該應用轉換鍵生成了包括有關密鑰報文的數據密鑰。密鑰分配系統(tǒng)最好配置成該行為只有安全管理員能夠啟動，該項工作應每三個月進行一次。如果數據密鑰KD仍在流通之中，中央付費保險系統(tǒng)(ZinS中央系統(tǒng))迄今仍未收到反饋(釋放或錯誤)，直到收到反饋之前，生成新KD的工作將會被凍結。
數據密鑰KD可用來對某些矩陣碼的內容加密，同時還能確保當未向郵政服務提供商付費時不會生成有效的郵資郵戳。這種數據密鑰可在ZinS密碼服務器上檢驗數字式郵資郵戳。數據密鑰同樣也是使用PKCA#11功能C-發(fā)生密鑰(C_GenerateKey)生成的TDES密鑰，具有如下屬性
該系統(tǒng)介紹了CKA_ID屬性和生成計數器的值。CKA_ID總是以大一個數的方式計數，而生成計數器只有當密鑰成功釋放時才會增加。CKA_ID和CKA_LABEL屬性填寫成CK_CHAR[]形式。所有其它屬性均定義在pkcs11.h文件的類型之中。
LABEL屬性中的隨機號可用來確定是否成功地輸入到密碼服務器卡，以及與該隨機號相關的散列值(例如通過SHA-1方式)形成，它可用來確認成功輸入和釋放傳輸密鑰。
生成數據密鑰交換的報文相對比較復雜，包含下列程序1.數據密鑰經KTM(＝LMK，CKM_KEY_WRAP_WEBSENTRY機制)加密，它具有這樣的好處密鑰的所有屬性(除了其它之外，CKA_EXTRACTABLE＝false)都伴隨加密，且在解密時又重新設置正確。運用這種加密的比特順序，一份具有下述結構的臨時報文形成了
2.臨時報文也同樣用使用CKM_DES3_CBC_PAD機制的有效傳輸密鑰KT加密(初始向量IV填寫0)。
3.供分發(fā)的報文形成，它具有如下結構
4.然后，數據密鑰報文轉移供進一步分發(fā)到ZinS中央服務器。此外，安全管理員還將進一步將其儲存到一張或二張軟盤上，保存到安全的地方，今后可用來初始化新的ZinS密碼服務器卡。
對報文內容兩次加密的優(yōu)點是可使在內聯(lián)網上向KTM傳輸的加密正文減少，從而造成對該密鑰的密碼分析更加困難。
為了釋放數據密鑰KD，必須提供一個界面和協(xié)議機制，以便使數據密鑰的釋放按協(xié)議進行。中央付費保險系統(tǒng)最好能這樣配置只有當數據密鑰成功地釋放和成功地輸入到本地付費保險系統(tǒng)的密碼系統(tǒng)時，數據密鑰才能釋放。只有通過這樣的釋放，有關的數據密鑰才能隨后用來對將包含在郵資郵戳中的密碼串加密。隨后，有關的密鑰識別信息KeyID也才能在郵資數額的識別信息(PostageID)中編碼。
界面通過中央付費保險系統(tǒng)(ZinS中央)與本地付費保險系統(tǒng)(ZinS本地)間的CWMS(計算機化工作管理系統(tǒng))釋放，價值轉移中心(郵資端)PP通過適當的bean接收信息。釋放程序的數據結構具有下述內容
通過參數2可對價值轉移中心PP的密鑰分配系統(tǒng)的對方，即付費保險系統(tǒng)的密鑰分配系統(tǒng)進行驗證。最好是從數據密鑰的LABLE屬性應用SHA-1法建立一種散列值，在生成數據密鑰時用一個隨機號填寫LABLE屬性，由于數據密鑰和其所有屬性在傳輸期間是加密的，因此只有收費保險系統(tǒng)的密碼服務器能計算正確的散列值。
如果傳輸的散列值等于為LABLE屬性計算出的KD散列值，且位于郵資端的WebSentry模塊，如果傳輸的加工狀態(tài)為“true”，數據密鑰被激活。這表明郵資郵戳/郵資數額的密碼串隨后也由該數據密鑰加密。當數據密鑰激活時，簽名密鑰的生成計數器也增加一個數。
當加工存在錯誤(傳輸狀態(tài)＝false)時，該應用轉換鍵也出現(xiàn)變異。在本案例中，該密鑰的生成和分發(fā)的狀態(tài)是有協(xié)議規(guī)定的，因此有關的數據密鑰也同樣從卡上刪除。在這種情況下，生成計數器不會增加一個數。
密鑰分配系統(tǒng)最好能含有一個狀態(tài)存儲器用來儲存所執(zhí)行的密鑰生成。只要從中央付費保險系統(tǒng)(ZinS中央系統(tǒng))沒有收到有關已執(zhí)行的密鑰分發(fā)反饋，顯示狀態(tài)則為開放(open)。成功反饋和分發(fā)后，密鑰標識為已激活。在發(fā)生錯誤的情況下，系統(tǒng)顯示傳輸狀態(tài)信息。
出現(xiàn)錯誤或較長時間收不到釋放信息時，錯誤調查程序被調用。
將密鑰存檔是極為有利的。下面介紹一種在價值轉移中心所進行的一種較好的密鑰存檔方法。為了確保密鑰安全，安全管理員可以執(zhí)行一個存檔功能，用KTM(CKM_KEY_WREP_WEBSENTRY機制)對所有密鑰(KTM除外)進行加密和解密。這些密鑰應當安全地存放在數據庫或安全的文件系統(tǒng)中。
成功地存檔后，所有已超過起始有效期6個月不再有效的密鑰被刪除。
密鑰儲存時，特別是儲存在價值轉移中心PP的密鑰，應將存檔的密鑰數據再次解密(拆包)后儲存在卡上，使用的機制仍舊是CKM_KEY_WRAP_WEB_SENTRY。
當密鑰解密后，具有相同的密鑰識別信息KeyID、且業(yè)已存在于卡上的密鑰被刪除。
通過Websentry卡的特殊安全措施和通過向幾張智能卡的分發(fā)，主傳輸密鑰KTM便可靠地保存下來，不會失密。如果仍要交換主傳輸密鑰KTM，應模擬包括密碼卡(PP)初始化工作的應用轉換鍵，生成一個新的KTM和新簽名密鑰、傳輸密鑰和數據密鑰。
原先的KTM仍保留在卡上作為所謂的“待用LMK”，安全管理員刪除它時必須十分注意。
下面介紹較好應用轉換鍵的密鑰分配系統(tǒng)。這種提供也同樣適用于付費保險系統(tǒng)所有地區(qū)的申請，如果某一組分在本地付費保險系統(tǒng)或在中央付費保險系統(tǒng)執(zhí)行較好時，這種做法特別有利。不過，這種做法在其它每個付費保險系統(tǒng)也可能同樣可以使用。
第一個申請案例是付費保險系統(tǒng)地區(qū)的密碼卡的初始化。
為了使密碼卡初始化，必須建立下述基本配置，從而使多數功能可通過管理工具(WebSentryManager)管理。
·如果生產廠商沒有配置的話，安裝配置卡，上載卡固件。該固件包括嵌入代碼(專有軟件程序)(后者的功能集成到WebSentryManager中)。
·定義群集(與幾個密碼卡)(WebSentryManager)。
·輸入主傳輸密鑰(KTM)，見分離的應用轉換鍵(功能由WebSentryManager提供)。
·用戶管理刪除默認安全管理員和定義包括了必需的認證規(guī)則(基于智能卡)的安全管理員。生成二個可通過預定義PIN自行授權的“正?！庇脩?一個進行密鑰驗證，一個進行密鑰輸入)。同樣，用戶管理的功能由WebSentryManager提供。
·輸入簽名密鑰(KS)見分離的應用轉換鍵。
·輸入傳輸密鑰(KT)見分離的應用轉換鍵。
·可選地輸入數據密鑰(KD)(同樣見其自己的應用轉換鍵)只要它們業(yè)已生成。
這里，密鑰必須按以上規(guī)定的順序輸入，卡可在中心地區(qū)初始化。因此完整的密碼系統(tǒng)計算機必須初始化，隨后發(fā)送出去，這是因為一旦WebSentry卡拔出PCI槽口它會立即刪除內存。
主傳輸密鑰最好是只由至少2個安全管理員輸入，這2個安全管理員在本地上可謂是智能卡讀者和相關智能卡的密碼系統(tǒng)的對手。由于密鑰KTM的重要性，該密鑰只能是應用雙重控制原則輸入到卡上。也就是說，至少需要在應用轉換鍵“主傳輸密鑰”中生成的二個PIN保護的智能卡加入輸入。
由于主傳輸密鑰KTM只能使用二張智能卡加載到卡上，又由于密鑰使用是PIN保護的，這就可以確保使用雙重控制原則時該密鑰才能安裝到卡上，這可提供一個極高的保護水平避免密鑰遭到破壞。
這一功能是通過管理工具WebSentryManager提供的。這一管理工具可以通過智能卡加載一個所謂的本地主密鑰(LMK，對應于這一概念的KTM)，并將它們儲存在卡的安全存儲區(qū)域。
將LMK分發(fā)到3張智能卡上非常有利。這樣，所有的3部分都可用來將LMK輸入到密碼硬件上。在這種情況下，需要有3個安全管理員來輸入主傳輸密鑰KTM。
簽名密鑰可確保密鑰報文的完整性。在輸入該密鑰前它也可用來確定密鑰報文的發(fā)送者是否是價值轉移中心(郵資端)。簽名密鑰可以以不同的方式生成，因此這里提供的實例是十分有用的。有關的密鑰報文由管理員保存到軟盤上，通過本應用轉換鍵，輸入到將初始化的付費保險系統(tǒng)的密碼卡上。
為了輸入該密鑰，存儲在軟盤上的密鑰報文用主傳輸密鑰KTM(PKCS#11功能C_Unwrap，CKM_KEY_WRAP_WEBSENTRY機制)解密，密鑰報文的完整性由該程序自動檢查。如果具有這種KeyID的密鑰已經存在，它便隨后被刪除。
為了進一步傳輸傳輸密鑰報文，中央付費保險系統(tǒng)的服務器提供一個界面，通過該界面可啟動分發(fā)和隨后向各個本地付費保險系統(tǒng)的密碼系統(tǒng)輸入該密鑰報文。
該界面可實現(xiàn)RMI服務，該服務可通過命名服務(JNDI)查到，通過用來分發(fā)P/N目錄的CWMS(計算機化工作管理系統(tǒng))進行分發(fā)。
如果生成了一項新的分發(fā)作業(yè)，密鑰報文便發(fā)送到所有當前注冊的密碼系統(tǒng)，并為每個案例撰寫協(xié)議入口，通過付費保險系統(tǒng)的應用轉換鍵對密碼系統(tǒng)進行管理。
每個密碼系統(tǒng)在固定時間間隔(根據分發(fā)機制變化)都要用輸入控制(ImportController)檢查新密鑰報文收據，當收到一份新報文時，應用轉換鍵“輸入傳輸密鑰”自動開啟，并對該動作的返回值進行檢查。如果收到一個負反饋，輸入工作可重復高達三次。
假如重復三次后仍舊不能輸入，此時向ZinS中央系統(tǒng)發(fā)送有關失敗的協(xié)議報文(也是根據傳輸機制而變化)。如果輸入成功，發(fā)出肯定的協(xié)議報文。
協(xié)議報文通過應用轉換鍵“協(xié)議密鑰加工”集中加工，根據加工結果觸發(fā)釋放傳輸密鑰。
輸入傳輸密鑰要么由在現(xiàn)場初始化密碼系統(tǒng)的安全管理員進行，要么當ImportController接收到一份新傳輸密鑰報文時由密鑰分發(fā)的ImportController自動觸發(fā)輸入。密鑰輸入最好能按照下述過程步驟1.進行卡上注冊，使ID和PIN屬于KeyImport用戶。
2.應用SHA-1法建立傳輸密鑰報文字段1到5的散列值。
3.確定簽名密鑰，應含有字段4標明的KeyID。
4.用該密鑰加密在Point2(CKM_DES3_CBC_PAD機制，初始化向量IV填0)生成的散列值，并與字段6比較。假若這兩個值匹配，完整性可得到保證，而且可確保報文是由PC的免費系統(tǒng)建立的。
5.用KTM對報文字段5的內容解密(C-UnwrapKey法，CKM_KEY_WRAP_WEBSENTRY機制)。從而自動生成一個合適的傳輸密鑰對象，儲存在卡上。此外，該機制還再一次無保留地對密鑰的完整性和正確的發(fā)送者進行檢查。
6.如果一個具有相同KeyID的密鑰業(yè)已存在于卡上，刪除該密鑰。
7.應用SHA-1法建立新輸入密鑰LABLE屬性的散列值，該散列值與KeyID和肯定報文一起返回作為返回值。
8.用戶會話結束。
9.從返回值生成協(xié)議報文，發(fā)送到ZinS中央系統(tǒng)。
10.在KeyID儲存的任何失敗的工作(見下面所述的變異)被重新設置。
該應用轉換鍵的變異即指任何程序或MAC檢查的失敗。在這種情況下，進一步的加工會流產，返回的返回值包括KeyID、錯誤代碼和出錯信息。對于KeyID而言，儲存的失敗次數增加1。一旦該號碼達到3，最新轉移的返回值產生一分協(xié)議報文，發(fā)送到中央付費保險系統(tǒng)。
在手工初始化的情況下，輸入結果還會呈現(xiàn)在安全管理員的監(jiān)視器上。
步驟2到步驟7最好是直接在卡軟件(嵌入代碼)上進行，這樣不僅可以提高性能，而且還可以增強安全，防止破壞。
為了進一步傳輸數據密鑰報文，中央付費保險系統(tǒng)的服務器還提供另一個界面，通過該界面可以進行分發(fā)以及隨后將數據密鑰輸入到本地付費保險系統(tǒng)的每個密碼系統(tǒng)中。
該界面已實現(xiàn)session bean的功能，該項服務可從命名服務(Java命名目錄界面， JNDI)查到。通過用來分發(fā)P/N目錄的CWMS(計算機化工作管理系統(tǒng))進行分發(fā)。
如果生成了一項新的分發(fā)作業(yè)，密鑰報文便發(fā)送到所有當前注冊的密碼系統(tǒng)，并為每個案例撰寫協(xié)議入口，通過分配系統(tǒng)對密碼系統(tǒng)進行管理。如果數據密鑰的分發(fā)作業(yè)已在流通中，且價值轉移中心PP還未收到它的反饋，直到收到反饋之前，任何進一步接收數據密鑰的分發(fā)作業(yè)都將被拒絕。
ImportController都要在固定時間間隔(根據分發(fā)機制而變化)為每個密碼系統(tǒng)檢查新密鑰報文的收據。當收到新報文時，應用轉換鍵“輸入傳輸密鑰”自動開啟，并對該動作的返回值進行檢查。如果收到負反饋，輸入工作將重復高達3次。
如果重復3次后仍不可能輸入，一份關于失敗的協(xié)議報文發(fā)送到ZinS中央系統(tǒng)(同樣根據傳輸機制而變化)。如果輸入成功，則發(fā)出肯定的協(xié)議報文。
協(xié)議報文通過應用轉換鍵“協(xié)議密鑰加工”而集中加工，傳輸密鑰的釋放也由該應用轉換鍵觸發(fā)。
輸入傳輸密鑰要么由在現(xiàn)場初始化密碼系統(tǒng)的安全管理員進行，要么當ImportController接收到一份新數據密鑰報文時由密鑰分發(fā)的ImportController自動觸發(fā)輸入。
該密鑰的輸入類似于傳輸密鑰的輸入，但應考慮數據密鑰報文的特點1.進行卡上注冊，使ID和PIN屬于KeyImport用戶。
2.應用SHA-1法建立數據密鑰報文字段1到7的散列值。
3.確定簽名密鑰，應含有字段5標明的KeyID。
4.用該密鑰加密在Point 2(CKM_DES3_CBC_PAD機制，初始化向量IV填0)生成的散列值，并與字段8比較。假若這兩個值匹配，完整性可得到保證，而且可確保報文是由PC的免費系統(tǒng)建立的。
5.確定傳輸密鑰，應含有字段6標明的KeyID。
6.用在Point 5(C_Decrypt法，CKM_DES3_CBC_PAD機制，初始化向量IV填0)確定的密鑰對報文字段7的內容解密。解密結果是一份臨時報文。
7.用KTM對臨時報文字段1的內容解密(C-UnwrapKey法，CKM_KEY_WRAP_WEBSENTRY機制)。從而自動生成一個合適的數據密鑰對象，儲存在卡上。此外，該機制還再一次無保留地對密鑰的完整性和正確的發(fā)送者進行檢查。
8.如果一個具有相同KeyID的密鑰業(yè)已存在在卡上，刪除該密鑰。
9.閱讀和檢查密碼卡上的所有數據密鑰，了解LABLE屬性，即比特1中的生成計數器的值是否等于新輸入的密鑰。如果等于，這些密鑰應從卡上清除，因為它們是由于輸入到另一個本地付費保險系統(tǒng)的密碼系統(tǒng)時出錯而在價值轉移中心PP沒有釋放的密鑰。
10.應用SHA-1法建立新輸入密鑰LABLE屬性2-65字節(jié)的散列值.該散列值與KeyID和肯定報文一起返回作為返回值。
11.用戶使用密碼卡的會話結束。
12.從返回值生成協(xié)議報文，發(fā)送到ZinS中央系統(tǒng)。
13.在KeyID儲存的任何失敗的工作(見下面所述的變異)被重新設置。
該應用轉換鍵的變異即指任何程序或MAC檢查的失敗。在這種情況下，進一步的加工會流產，返回的返回值包括KeyID、錯誤代碼和出錯信息。對于KeyID而言，儲存的失敗次數增加1。一旦該號碼達到3，最新轉移的返回值產生一分協(xié)議報文，發(fā)送到中央付費保險系統(tǒng)(ZinS中央系統(tǒng))。
在手工初始化的情況下，輸入結果還會呈現(xiàn)在安全管理員的監(jiān)視器上。
步驟2到步驟10最好是直接在卡軟件(嵌入代碼)上進行，這樣不僅可以提高性能，而且還可以增強安全，防止破壞(特別是對初始化向量和KTM)。
數據密鑰應能從盡量多的付費保險系統(tǒng)密碼系統(tǒng)上重復清除，最好是從所有密碼系統(tǒng)上定期清除，以便清除再也不需要的數據密鑰。
清除數據密鑰的程序1.確定位于卡上的所有數據密鑰，按照它們ID(CKA_ID屬性)的升序整理。
2.按下述程序對該清單中的每個密鑰進行檢查(1)確定一個密鑰的繼任者(下一個較大的ID)。
(2)如果存在，檢驗以下內容a.標明前任者有效性結束的繼任者的CKA_END_DATE屬性是否小于當前系統(tǒng)的日期。如果確實如此，輸出該清單中當前加工的密鑰。
b.繼任者的生成計數器(CKA_LABLE屬性的第一位比特)是否等于當前加工密鑰的生成計數器。如果確實如此，輸出該清單中當前加工的密鑰。
中央付費保險系統(tǒng)(ZinS中央系統(tǒng))的服務器上的密鑰加工最好是按協(xié)議規(guī)定進行，經本應用轉換鍵協(xié)議規(guī)定的密鑰是傳輸密鑰和數據密鑰。
對于每個分發(fā)作業(yè)，協(xié)議規(guī)定了密鑰報文應發(fā)向那一個有效的密碼系統(tǒng)。對于每個系統(tǒng)和每個分發(fā)作業(yè)而言，都在“發(fā)送”狀態(tài)時經首先設置而生成有一個獨立的入口。
每次成功或失敗的加工后，每個密碼系統(tǒng)生成一份協(xié)議報文并發(fā)送給中央付費保險系統(tǒng)(ZinS中央系統(tǒng))。這種分發(fā)工作不是通過JMS隊列就是通過數據庫復制進行。
在中央付費保險系統(tǒng)地區(qū)，收到報文之后，報文用來更新上述的協(xié)議入口。為了這一目的，“加工成功”/“不成功”的狀態(tài)以及可能是錯誤的代碼被儲存下來。
伴隨協(xié)議報文的加工，系統(tǒng)還檢查是否有成功地進入到所有密碼系統(tǒng)的分發(fā)作業(yè)。如果存在有分發(fā)作業(yè)，釋放每個相關密鑰的工作，特別是在價值轉移中心啟動。一旦系統(tǒng)報告出錯，價值轉移中心地區(qū)就會生成一份負狀態(tài)的相關報文。
調用密鑰釋放這一事實被通知給分發(fā)作業(yè)，因此，對于一個作業(yè)而言不再有額外的釋放進行。然而，只要未輸入該通知，新的嘗試就會在固定的時間間隔與釋放服務系統(tǒng)取得聯(lián)系。
當經歷一段設定的時間后，最好是幾天，例如3天，也會出現(xiàn)特殊的情況，從所有的密碼系統(tǒng)接收不到反饋。過了這段時間后，一份否定的釋放報文發(fā)送到價值轉移中心。
密鑰分配系統(tǒng)最好應有一個界面，可讓管理員檢查密鑰分發(fā)作業(yè)的狀態(tài)。此時，每個分發(fā)作業(yè)將顯示以下數據·接收分發(fā)報文的系統(tǒng)的號碼·報告成功進行加工的系統(tǒng)的號碼·未報告加工結果的系統(tǒng)的號碼·報告加工失敗的系統(tǒng)的號碼此外，還可編制一份詳細的清單，可以顯示每個系統(tǒng)的當前狀態(tài)。作為一種替代方法，也可顯示存儲在有關卡上的本地密鑰。
最好是能將生成分發(fā)作業(yè)所用的所有密鑰在中央付費保險系統(tǒng)地區(qū)存檔，而不要在本地系統(tǒng)存檔。在本地系統(tǒng)，密鑰存儲在卡的非易失性存儲器上，只有那些也被釋放的密鑰報文才存檔。
為了一個特定的密碼系統(tǒng)，傳輸密鑰和數據密鑰的密鑰恢復可集中進行。在這種情況下，存檔中的當前密鑰被確定，并發(fā)送給特定的密碼系統(tǒng)。為了這一目的，同樣要生成協(xié)議報文。使用這種密鑰分發(fā)方法，只是不需要釋放報文。
如果主傳輸密鑰KTM遺失，要么由相關的密碼系統(tǒng)通知安全管理員要求重新初始化，要么安全管理員不得不對現(xiàn)場的每個系統(tǒng)初始化。
主傳輸密鑰KTM可通過WebSeenry卡的特殊安全措施和通過分發(fā)到幾個智能卡以及通過多級密鑰系統(tǒng)能做到安全可靠地儲存，防止失密。
然而，如果要交換主傳輸密鑰，則必須生成一個新的主傳輸密鑰KTM以及新的簽名密鑰、傳輸密鑰和數據密鑰。
然后這些密鑰又不得不輸入到本地付費保險系統(tǒng)的所有密碼系統(tǒng)中，這需要大量的精力，因為不是所有的密碼系統(tǒng)都要向中央管理地區(qū)進行一個來回的傳輸，就是安全管理員不得不到本地付費保險系統(tǒng)的所有地區(qū)去走一趟。因此，使用本發(fā)明關于主傳輸密鑰KTM的安全機制則特別有利。
早先保留在卡上的主傳輸密鑰KTM稱做所謂的“待用LMK”，應由安全管理員恰當地刪除。
密鑰處理和解密應作為嵌入代碼反映在密碼卡上。采用這種方式，不僅可以獲得更高的安全度，而且有可能提高密碼系統(tǒng)的性能。
密碼卡最好能伴隨所述的擴充包含下列標準的PKCS#11功能·C_CloseSession·C_GetSlotList
·C_Init·C_Login·C_Logout·C_OpenSession此外，永久存儲的功能則不應該包含第三方的進一步擴充，且這里所需的擴充應作為付費保險系統(tǒng)密碼卡功能全部包括進來。
為了標志PKCS#11DLL嵌入密鑰處理方法，這些方法都賦予一個前綴。該前綴定義為CE。在這種情況下，CE代表密碼擴充。
每種嵌入法提供一個CK_RV類型的返回值，定義為pkcs11.h include文件的固定組分。這樣做十分有利，在執(zhí)行嵌入法期間，另外的錯誤返回值可以定義，并提供加入到C++的頭文件中。這種方法的好處在于通過調用嵌入法可以調用各種pkcs11方法，使它們嵌套在硬件上，另一個優(yōu)點就是在密碼卡軟件中建立了完整的、全新的密鑰處理部分。
下面是顯示該方法語法的實例CK_RV＝CE_MethodName(parameter list)在參數表中，必須用結果填寫的參數通過引用調用而轉移，通過有意義的字組合提供方法的明確含義，從而形成方法的名稱。
通過字的選擇使其組合后賦予有意義的內容，例如使用英語中的技術術語。
介紹兩種枚舉類別可用來檢驗不同嵌入法的功能。密鑰類型和密鑰屬性的枚舉類別存在著差異。
CK_EnumKey＝{CE_KT，CE_DT，CE_SE，CE_KA}CE_KA承擔特殊的位置，它不是一個密鑰而是所有密鑰的集合。
如果顯示EnumElement，這些方法將執(zhí)行與卡上含有所有密鑰有關的功能。
CE_EnumKeyAttribute＝{CE_ID，CE_LABLE，CE_STARTDATE，CE_ENDDATE}pkcs11.h文件應引入必要的定義。定義的擴充可在包含在pkcs11.h文件中的獨立頭文件中找到，許多機制均可執(zhí)行這些嵌入法。
在密碼環(huán)境下，定義了一種方法，它可利用可資利用的pkcs11方法自主執(zhí)行所有相關的檢驗。
CK_RV CE_Decrypt(CK_SESSION_HANDLE session，CK_BYTE[]message，CK_BYTE*postagedID CK_BBOOL bok)功能介紹嵌入密碼法接收一個位于參數報文中57比特長的日期，這一日期對應于郵資郵戳上的矩陣碼。在下述工作步驟計數中從1開始第一步建立初始化向量IV。作為初始化向量，前兩個比特填0，然后比特f6-f10以及f14附加到矩陣碼。
第二步確定將使用的KD。密鑰相位指示符包含在比特f14中，它表示那一個密鑰將被使用。密鑰相位指示符儲存在CKA ID密鑰屬性，因此可以無歧義地發(fā)現(xiàn)該密鑰。下面將進一步介紹的密鑰處理應允許足夠的密鑰發(fā)現(xiàn)時間。
第三步解密所含的加密報文。CK_MECHANISM使用的機制是CKM_DES3_CBC。比特f15-f38加密，它們長24比特。解密結果的前12比特用參數postageID輸出，一旦成功地解密，該過程繼續(xù)第四步，否則第五步。
第四步生成和清除散列值。一個特殊構造的77比特長的數據塊用作生成日期散列值的基礎。
比特1到53對應于矩陣碼的前53個比特。
比特54到65對應于當前未加密報文部分(PostageID)的前12個比特。
比特66到77對應于當前未加密報文部分的后12個比特。
應用SHA-1建立散列值，然后，前4個比特必須匹配比特f54-f57。如果不匹配，則生成的日期無效。如果在執(zhí)行散列期間出錯或散列值存有差異，執(zhí)行第五步中的過程。
第五步成功指示符的返回。如果所有的作業(yè)步驟均成功，用“true”填寫參數bOk。如果清除散列值發(fā)現(xiàn)差異或一個pkcs#11法引起出錯，用“false”填寫參數bOk。返回值也應該同樣用錯誤報文填寫，如果沒有出現(xiàn)錯誤，則用CKR_OK填寫。
CK_RV DE_VerifyMsg(CK_SESSION_HANDLE session，CK_BYTE[]message，int length，CK_BBOOL bok)用作檢驗程序的普通數據塊報文如下
未用的字段均填0，該方法的作業(yè)模式通過參數MsgType確定。
生成的數據塊在MesType KT和KD報文中轉移，數據塊填寫每個收到的報文。
MesType KT的功能分配CE_VerifyMsg KT接收MESSAGE屬性中完整的傳輸密鑰報文和LENGTH屬性中的長度，這種嵌入報文可確保傳輸密鑰報文在接收端的完整性。為了啟動檢驗，必須履行下述步驟第一步建立初始化向量IV。初始化向量填0。
第二步解密收到的加密報文。CK_MECHANISM使用的機制是CKM_DES3_CBC_PAD?？勺兊腗AC字段的字節(jié)解密。如果在解碼過程中出錯，程序進入第四步。
第三步清除散列值。為了建立日期的散列值，從傳輸密鑰報文的1+2+5+6+8字段建立散列，并與第二步的散列進行比較。用SHA-1建立散列值。如果這些散列值不相等，則日期無效。如果在執(zhí)行散列期間出錯或散列值存有差異，執(zhí)行第四步中的過程。
第四步成功指示符的返回。如果所有的作業(yè)步驟均成功，用“true”填寫參數b0k。如果清除散列值發(fā)現(xiàn)差異或一個pkcs#11法引起出錯，用“false”填寫參數b0k。返回值也應該同樣用錯誤報文填寫，如果沒有出現(xiàn)錯誤，則用CKR_OK填寫。
MesType KD的功能分配CE_VerifyMsg后，完整的數據密鑰報文轉移到MESSAGE屬性和LENGTH屬性的長度中，這可確保傳輸密鑰報文在接收端的完整性。為了啟動檢驗，必須履行下述步驟第一步建立初始化向量IV。初始化向量填0。
第二步解密收到的加密報文。CK_MECHANISM使用的機制是CKM_DES3_CBC_PAD。解密可變的MAC字段的字節(jié)。如果在解碼過程中出錯，程序進入第四步。
第三步清除散列值。為了建立日期的散列值，從數據密鑰報文的字段1+2+4+3+6+7+8建立散列，并與第二步的散列進行比較，用SHA-1建立散列值。如果這些散列值不相等，則日期無效。如果在執(zhí)行散列期間出錯或散列值存有差異，執(zhí)行第四步中的過程。
第四步成功指示符的返回。如果所有的作業(yè)步驟均成功，用“true”填寫參數b0k。如果清除散列值發(fā)現(xiàn)差異或一個pkcs#11法引起出錯，用“false”填寫參數b0k。返回值也應該同樣用錯誤報文填寫，如果沒有出現(xiàn)錯誤，則用CKR_OK填寫。
這些嵌入的密鑰處理方法應該包括包裝密鑰和有效密鑰管理的密鑰輸入。KS、KD和KT類型的密鑰都應輸入。
CK_RV_CE_ImportKey(CK_SESSION_HANDLE session，CK_BYTE_PTR data，CK_ULONG length，CK_BYTE*HashValue，CE_EnumKey KeyType，CK_CHAR[]KeyKTID)功能分配CE_ImportKey最好能按下述方法進行
應用CKM_KEY_WRAP_WEBSENTRY機制進行包裝。當然，拆包時也要使用同樣的機制。得到的密鑰通過拆包輸入到密碼硬件。因此，第二次輸入的密鑰，也就是說具有相同密鑰相位的密鑰覆蓋舊的密鑰。
包裝的密鑰轉移到DATA參數，其長度等于LENGTH參數的設定。密鑰的長度取決于密鑰屬性的填寫，密鑰類型由KeyType參數檢驗且根據檢驗結果處理。
然后，密鑰送到高速緩存作業(yè)的密鑰管理。適合的話，將重復的前任者刪除。
DT由KeyKTID參數發(fā)現(xiàn)的KT解密。對于所有其它類型的密鑰，該參數都不予考慮，均填寫0。
CKA_END_DATE參數的依賴性十份重要，它表示密鑰的前任者的結束日期。
輸入密鑰的密鑰參數包括隨機號，通過該隨機號可用SHA-1建立散列值。該散列值返回到嵌入法的HashValue參數?；貜兔荑€報文需要使用散列值。
如果在拆包機制或形成散列期間出錯，返回值會輸出適當的錯誤代碼，否則就是CKR_OK。
CK_RV CE_GetKeyCount(CK_SESSION_HANDLE session，CE_EnumKey KeyType，Int*counter)功能分配CE_GetKeyCount表示在高速緩存作業(yè)的密鑰管理中每種密鑰有多少密鑰在卡上注冊。運用這種方式，密鑰參數可與下面介紹的方法一起讀出。
該方法定義如下CK_RV CE_GetAttribute(CK_SESSION_HANDLE session，CE_EnumKey KeyType，CE_EnumKeyAttribute KeyAttribute，Int pos，CK_BYTE[]*attribute，Int*length)密鑰類型通過KeyType參數確定，因此，也就是根據密鑰類型在不同清單中記錄密碼硬件上不同類型密鑰的表來確定的。
密鑰屬性(KeyAttribute)參數規(guī)定讀出的屬性，ITEM參數指示其在表中的開始點。它必須首先用CE_GetKeyCount法為所有的密鑰或一種密鑰獲取最大值，當CKA_END_DATE屬性輸出時，必須注意最后一個當前的密鑰在理論上是無限期有效的(直至一個相同密鑰的新密鑰輸入)，而且在其CKA_END_DATE屬性中含有相同種類密鑰前任密鑰的結束日期。因此，這種表達的密鑰的CKA_END_DATE也同時輸出。
日期屬性具有8個字節(jié)的固定長度，而CSK_ID和CKA_LABLE屬性具有128個字節(jié)的固定長度。假若這兩個參數的密鑰屬性短于128個字節(jié)，在128個字節(jié)長度的不足部分用0填寫。因此，用戶可始終為解決該問題的方法提供足夠的存儲空間。當用戶提供一個相當小的緩沖區(qū)時，將信息進行調整，所得報文通過CK_RV傳遞。
CK_RV CE_DeleteExpiredKeys(CK_SESSIOV_HANDLE session，CE_EnumKey KeyType，Int*counter)
功能分配CE_DeleteExpiredKeys在卡上搜索過期的密鑰，并將它們從卡上刪除。過期密鑰可通過下述方法發(fā)現(xiàn)系統(tǒng)日期比繼任密鑰的CKA_END_DATE更前，見2.5.8項。這也同樣適用于KT和KS。通過EnumType可進行選擇性刪除，運用CE_KA可將整張卡刪除(僅留下LMK)。必須注意，當進行密鑰輸入時，絕對不可使用該方法。這最好是在嵌入碼中進行控制，并用適當的返回值予以指示，采用這種措施可避免任何對內部密鑰管理不確定的負面影響。
付費保險系統(tǒng)與價值轉移中心之間的界面最好是越窄越好，以便排除通過非正規(guī)渠道進行操作的可能性。
圖3顯示的是付費保險系統(tǒng)與價值轉移中心(郵資端)之間的界面結構。
中央付費保險系統(tǒng)提供一個分發(fā)密鑰的界面，價值轉移中心(郵資端)的KeyManagement組份生成的密鑰可通過該界面分發(fā)到付費保險系統(tǒng)的密碼系統(tǒng)。
價值轉移中心向付費保險系統(tǒng)提供一個密鑰釋放界面，當所述密鑰成功地釋放和加工后，付費保險系統(tǒng)可通過該界面釋放該密鑰。
由于這兩者主要都使用Java，建議使用Session Bean實現(xiàn)應用界面。為了使這兩個系統(tǒng)不要耦合，該服務應使用JNDI從命名服務中查出。
Session Bean提供向ZinS中央系統(tǒng)輸入密鑰數據的必要功能，圖4顯示的是其整個通信過程。圖4顯示了將數據密鑰加入到中央付費保險系統(tǒng)(ZinS中央)的過程步驟。
過程程序ImpotKey將數據密鑰集轉移到ZinS中央。
依據使用ASN.1報文，該過程程序準備接收報文，并使該報文儲存在數據庫中。然后，過程程序ImpotKey通過CWMS啟動密鑰數據分發(fā)到ZinS中央系統(tǒng)。
將數據輸入到數據庫以及隨后分發(fā)報文時應嚴格遵守次序，這樣可確保在加工結束前或加工期間接收到的數據的安全。這種方法的優(yōu)點是錯誤領域的事件可以較好地重建，在數據丟失時，如果需要可以訪問數據庫。
由于此時還不甚清楚是否支持ASN.1格式，插入密鑰數據(InsertKeyData)法的參數還未指定。然而，該方法必須擁有兩個參數，以便也能向郵資端發(fā)送詳細的報文。
在ZinS中央系統(tǒng)，密鑰分配系統(tǒng)的分發(fā)方法負責下述工作1.將密鑰報文存檔在ZinS中央的服務器上。
2.通過Vibris提供的CWMS界面從郵資端向各個郵件中心分發(fā)密鑰報文，CWMS服務的結構以及使用可查閱該界面的手冊。
3.一旦分發(fā)和向各個郵件中心輸入完成之后，生成一份有關的返回報文。
數據以ASN.1格式從價值轉移中心(郵資端)傳遞，期待的有關返回回復也以ASN.1格式出現(xiàn)。不過，代替這種格式的其它格式當然也可使用，一些特殊的格式通過語法程序分析后經過改寫也可使用。
下面是較好的ASN.1數據格式傳輸密鑰的分發(fā)報文
TransportKeyMessage＝SEQUENCE{MsgType OCTET STRING，(fix‘KT’)Version OCTET STRING，(0x01)KeyID OCTET STRING，(CKA_ID)SigKeyID OCTET STRING，(CKA_ID of SignatureKey used for MAC)TransKeyEncrypt OCTET STRING，(TransportKey wrapped with LMK)MAC OCTET STRING(MAC oVer aIl preVious elements)}數據密鑰的分發(fā)報文PostageKeyMessage＝SEQUENCE{MsgType OCTET STRING，(fix‘KD’)Version OCTET STRING，(0x01)KeyID OCTET STRING，(CKA_ID)KeyGeneration OCTET STRING，(0x01 ascending)SigKeyID OCTET STRING，(CKA_ID of SignatureKey used for MAC)TransKeyID OCTET STRING，(CKA_ID of TransportKey)DateKeyEncrypted OCTET STRING，(PostageKey wrapped with LMKAndEncrypted with TransportKey)MAC OCTET STRING(MAC over all preVious elements)}參見2.4.6節(jié)。
釋放報文
KeyExchangeReceipt＝SEQUENCE{KeyID OCTET STRING，(CKA_ID of received keyKeyLableHash OCTET STRING，(SHA-1 hash of CKA LABLE ofreceived key)State BOOLEAN，(TRUE/FALSE to enable/dismiss key)Message OCTET STRING(Description of success/failure)}數據結構可以有不同的設定。不過，這里實施例提供的設定特別有利，因為它允許傳輸所有考慮到的信息且其開銷僅占數據傳輸開銷的一小部分，特別是數據可通過CWMS傳遞到位于郵件服務提供商的郵件中心的本地付費保險系統(tǒng)。
當使用ASN.1格式時，數據必須首先進行語法分析形成內部密鑰報文。這樣，如果該文件定義的報文被直接使用時，就可省卻對它的使用。
通過CWMS接收到的數據包對應于該文件以前定義的密鑰報文。這些報文在首先適合標題“數據密鑰KD屬性”上方的數據表后，然后經受嵌入碼VerifyMsg法的檢驗。檢驗后，要么通過嵌入碼開始輸入該密鑰，要么生成一個適當的錯誤報文。在使用CE_ImportKey嵌入碼法時，比較密鑰報文和第12頁至14頁輸入數據的結構。此時上述嵌入碼法會自動地刪除和更新舊的密鑰。
CE_DeleteExpiredKeys法會每天調用，只要需要，它每日隨時都可用來從密碼硬件上清除過時的密鑰。在輸入期間，CA_ImportKey法確保重復生成的密鑰將被刪除，新生的密鑰將取代它們。
嵌入碼法通過Java級密碼適配器(CryptoAdapters)是與應用捆綁在一起的。CryptoAdapters可提供嵌入碼和其他PKCS#11法提供的所有功能(命名也類似)。
DLL(CryptoAdapter.DLL)通過JNI可以使用，它靜態(tài)地將Zaxus提供的DLL連接起來。這樣，通過靜態(tài)連接使安全風險進一步減小。
JNI界面執(zhí)行C++也可提供每次所需會話的錯誤處理。關于這一點，見PCFM設計文件第三階段“多線程操作”一欄。操作者的觀念受到支持，在多線程操作模式時密碼硬件已經啟動，登錄后每個操作者可得到他自己的會話(GetSession，C_GetSession)，結果該操作者在DLL注冊，并專門為該操作者建立了錯誤處理。登錄就會尋求DLL主流，并擁有其自己的用來執(zhí)行PKCS#11法和嵌入法的錯誤處理。
圖6顯示的是執(zhí)行總圖，最好能將嵌入法提供的密鑰清單和代碼清除，否則，選定的結構設定就會完全一樣。
DLL的連接圖7顯示了一個實例中較好的封裝結構和有利的錯誤處理。
如果密碼硬件嵌入碼中存有完整的密鑰清單，可以不要執(zhí)行密鑰清單。GetAttribute法減少到只需一次調用嵌入的CE_GetAttribute法。而且輸入及其執(zhí)行的調用也得到減少，因為必需數據轉移后嵌入碼能自動地進行這一工作。
在嵌入碼中還可提供一個擴充的誤差常數清單。
郵資端的密鑰報文存儲在ZinS中央的數據庫中，以便供有問題的本地付費保險系統(tǒng)日后取代使用。首先，這樣的報文是必須收入數據庫的；其次，管理信息也應收到。
因此，下面的數據庫表是非常重要的。
密鑰數據按照郵資端接收密鑰數據的方式存儲密鑰報文。如果本地付費保險系統(tǒng)失敗，存檔的密鑰報文就可通過輸入存檔的密鑰來協(xié)調失敗的本地付費保險系統(tǒng)與其它剩下的本地付費保險系統(tǒng)。在儲存前，報文必需用ASN.1語法分析，以便向本地系統(tǒng)傳遞。最好是用相同的數據記錄格式作為儲存的形式，它對應于用來介紹CE_VerifyMessage嵌入法使用的數據塊的表。
這條數據記錄具有中心地位的作用。首先，它用來評價從郵件中心的本地付費保險系統(tǒng)收到的反饋。所有的郵件中心最好都能集成到郵件服務提供商的郵件系統(tǒng)，能進行錯誤分析，并在分發(fā)程序過程中一旦時間過期能向系統(tǒng)操作員報警。
而且，這張表還包括管理信息加工，如果合適，這使它能使用SNItemNo入口分配和評價有關的TransportKeyData表單個(83)郵件中心的TransportKeyReplayMessage。
在這張表中，本地付費保險系統(tǒng)的每個密鑰應答報文伴隨輸入程序的變化存檔在郵件服務提供商的郵件中心。
權利要求
1.一種檢驗使用免費密鑰生成并將其用于郵件上的郵資郵戳的真實性的方法，憑借該方法，包含在郵資郵戳中的密碼信息解密，并用來檢驗郵資郵戳的真實性，其特征在于，數據密鑰(KD)生成后從中央付費保險中心傳輸到本地付費保險中心。
2.根據權利要求1所述的方法，其特征在于，所述的本地付費保險中心輸入數據密鑰并向中央付費保險中心(ZinS中央系統(tǒng))傳輸輸入的結果。
3.根據權利要求2所述的方法，其特征在于，所述的輸入結果是以一條數據記錄傳輸。
4.根據權利要求3所述的方法，其特征在于，所述的數據記錄包含有一個密鑰。
5.根據權利要求2到4之一或多條權利要求所述的方法，其特征在于，所述的中央付費保險中心(ZinS中央系統(tǒng))檢查所述的輸入結果并將該結果傳輸給價值轉移中心(郵資端)。
6.根據權利要求5所述的方法，其特征在于，所述的結果用密鑰解密進行檢查。
7.根據權利要求1到6之一或多條要求所述的方法，其特征在于，一旦所述的數據密鑰成功輸入到所有本地付費保險中心(ZinS本地)，所述的數據密鑰在價值轉移中心(郵資端)釋放，并隨后用來生成新的郵資數額。
8.根據權利要求1到7之一或多條要求所述的方法，其特征在于，所述的數據密鑰是一種對稱的密鑰。
9.根據前述權利要求一條或多條所述的方法，其特征在于，所述的新數據密鑰從價值轉移中心(郵資端)向中央付費保險中心傳輸。
10.根據權利要求9所述的方法，其特征在于，所述的價值轉移中心用傳輸密鑰(KT)對該數據加密。
11.根據權利要求10所述的方法，其特征在于，所述的傳輸密鑰用一個主傳輸密鑰(KTM)加密。
12.根據權利要求9到11之一或多條要求所述的方法，其特征在于，所述的數據密鑰在價值轉移中心地區(qū)生成。
13.根據權利要求9到12之一或多條要求所述的方法，其特征在于，所述的數據密鑰提供有密鑰識別信息。
14.根據權利要求13所述的方法，其特征在于，所述的密鑰識別信息以加密形式傳輸。
15.根據權利要求9到14之一或多條要求所述的方法，其特征在于，所述的數據密鑰提供有生成計數器，它和/或與生成計數器一起傳輸。
16.根據權利要求13所述的方法，其特征在于，所述的數據密鑰傳輸到一個密碼單元，特別是一張密碼卡，一旦該密碼單元接收所述的數據密鑰，它將刪除所有與傳輸的數據密鑰具有相同生成計數器值的數據密鑰。
17.根據權利要求9到16之一或多條要求所述的方法，其特征在于，所述的數據密鑰提供有前一個數據密鑰的結束日期，它和/或與該結束日期一起傳輸。
18.根據權利要求17所述的方法，其特征在于，所述的免費密鑰傳輸到一個密碼單元，此時該密碼單元檢查其它數據密鑰是否也有結束日期，檢查繼任的數據密鑰所儲存的結束日期是否比付費保險系統(tǒng)中儲存的日期更舊。
19.根據前述權利要求一條或多條所述的方法，其特征在于，所述的數據密鑰或至少部分該密鑰用來形成生成郵資郵戳的免費密鑰的組分。
全文摘要
本發(fā)明涉及一種檢驗使用免費密鑰生成并將其用于郵件上的郵資郵戳的真實性的方法。憑借該方法，包含在郵資郵戳中的密碼信息解密，并用來檢驗郵資郵戳的真實性。本發(fā)明的方法具有數據密鑰(KD)生成后從中央付費保險中心傳輸到地方付費保險中心的特征。
文檔編號G07B17/00GK1748231SQ200480003858
公開日2006年3月15日 申請日期2004年1月21日 優(yōu)先權日2003年2月12日
發(fā)明者皮特·費里, 朱爾根·黑爾繆斯, 貢特爾·梅爾, 戴爾特·斯特瑪, 卡斯通·瓦瑞爾德 申請人:德國郵政股份公司