CN100585643C - 检验数字式免费票据有效性的方法 - Google Patents

Abstract

本发明涉及一种检验使用免费密钥生成并将其用于邮件上的邮资邮戳的真实性的方法。凭借该方法，包含在邮资邮戳中的密码信息解密，并用来检验邮资邮戳的真实性。本发明的方法具有数据密钥(KD)生成后从中央付费保险中心传输到地方付费保险中心的特征。

Description

检验数字式免费票据有效性的方法

技术领域

本发明涉及检验应用免费密钥生成并用于邮件的邮资邮戳的真实性的方法。凭借该方法，包含在邮资邮戳中的密码信息解密并用来检验邮资邮戳的真实性。

背景技术

邮件上应用数字式邮资邮戳已是人们所熟知的方法。

为了让发件人易于生成邮资邮戳，用户可采用诸如德国邮局使用的免费系统在用户系统中生成邮资邮戳，然后通过任意可用的界面将其输出到打印机上。

德国临时申请书DE100 20 402A1公布了这一普通的做法。

为了防止欺诈性使用这种方法，数字式邮资邮戳包含有密码信息，例如有关控制生成邮资邮戳的用户系统的识别符。

国际专利申请书WO 01/17160A1涉及密钥的分发方法。其中，密钥由中央管理部门产生，通过分发部门以加密形式传输到加密设备，这种加密设备随后又通过分发部门向中央管理部门发报告知是否收到密钥。如果不能成功地收到密钥，将再一次以不加密的形式向有关的加密设备传输。

欧洲专利申请书EP 0 854 444A2公开了一种加密和检查运用免费机器生成邮资邮戳的方法。在这种方法中，还使用了源于免费机器执行的主密钥的附加密钥，用来生成邮资邮戳。附加密钥在邮件中心也同样生成，并用来检查邮资邮戳。

美国专利5,150,408公开了诸如在无线网络通信系统中分发密钥的方法。其中，加密报文经密钥分发部门传输到通信设备，收到该报文后，通信设备向密钥分发部门发出确认的信息。

人们所熟知的传输密码数据的ANSI X9.17标准(见URLhttp://csrc.nist.gov/publications/nistpubs/800-7/node209.html 1994年10月7日)就是基于几种密钥的密钥体系。这里至少存在有一种为短期存在的数据加密的密钥，它以加密的形式在通信伙伴之间进行电子交换，并且作为加密数据密钥的密钥，以手工方式进行交换。此外，在参考文献中还介绍了加密数据使用的Diffie-Hellmann方法，其中，通信伙伴从已知的数字和从秘密的随机数字计算共享的密钥。

欧洲专利申请书EP 0 735 722A2介绍了一种用免费机器生成、分发和管理密钥的密钥管理系统。其中，存在着几个与计算机相连的保密区，可允许这些保密区之间的通信以及它们之间的控制。密钥的生成，以及它们的安装、检验及确认，每一步都是在其中之一的保密区中实现的。每个保密区都与档案相连，因此其状态均记入协议书。

发明内容

本发明基于建立一种快速、可靠地检验邮资邮戳真实性的方法的目标，特别是该方法能适合于大规模的检验程序，主要是用于邮件中心或货运中心。

特别的，真实性的检验是根据数据密钥是从中央数据库(ZinS central)生成并传输到本地付费保险系统(ZinS local)这样的方法完成的，这一目标业已实现。它是通过使用一个生成的免费密钥和用到邮件上的邮资邮戳实现的，因此，包含在邮资邮戳中的密码信息解密后用于检验邮资邮戳的真实性。

为了增强该方法的安全性，本地付费保险系统最好是能输入数据密钥，并将输入的结果传输到中央数据库(ZinS中央系统)。

在运用该方法的一个特别较好的实施例中，输入的结果是作为数据记录传输的。

数据记录最好是含有密钥。密钥可能有各种属性，特别是它可能是对称的密钥或非对称密钥。根据使用的需要，密钥可用来解密和/或加密信息。依据密钥的本性，密钥还应能够同样地传输信息。例如，密钥包含免费密钥、密钥生成和/或其结束日期的信息。

为了确保一致的密钥交换，中央数据库(ZinS中央系统)最好能检查输入的结果，并将其传输到价值转移中心(邮资端)。

该方法的实施例还能在价值转移中心依据输入的结果开展进一步的过程步骤。

其结果可用多种方法进行检查，不过，最好的方式还是通过对密钥解密而检查结果。

在运用该方法的一个实施例中，其特征在于一旦数据密钥成功地输入到几乎所有的本地付费保险系统(ZinS本地)，该数据密钥在价值转移中心(邮资端)作为一个新的免费密钥释放，随后被用来生成新的邮资邮戳。

运用该方法的一个实施例还能依据在付费保险系统中以前所进行的密钥交换在价值转移中心进行密钥交换。这种方法能确保只有当新密钥已存在于本地付费保险系统时使用新密钥才能生成邮资邮戳。这样可保证本地付费保险系统能够检验每个生成的邮资邮戳的真实性。

在运用该方法时，运用本地付费保险系统密钥交换控制价值转移中心密钥交换的实施例的明显优点在于至少结合了本发明的其它几个过程步骤。

特别是通过几种特征的结合，确保了密钥交换能快速可靠地进行，并能对每次密钥交换进行检验。

在进行密钥交换时，最好是能将新数据密钥从价值转移中心(邮资端)传输到中央付费保险系统。

这里，价值转移中心最好是能将数据密钥与传输密钥(KT)一道加密。

这里，通常将传输密钥与主传输密钥(KTM)一道加密。

数据密钥最好是在价值转移中心生成，这样具有防止数据密钥在向价值转移中心传输期间对它的任何欺诈性改变的优点。

为了进一步增强数据的安全性，最好能为数据密钥提供密钥识别信息。

密钥识别信息最好能同样以加密形式传输。

为了确保每一加密和/或解密步骤均能使用有效的数据密钥，最好能为数据密钥提供一个生成计数器和/或与生成计数器一道传输。

为了避免使用无效的密钥，免费密钥最好也能提供一个结束日期，使前面的数据密钥能与该结束日期一道传输。

所述数据密钥可以用来进行部分或多部分检验，以及生成邮资邮戳和/或解密邮资邮戳中包含的信息。

在进行一部分检验时，最好能包括对邮资邮戳中包含的密码信息进行解密。

当检验过程包括对密码信息解密时，它能直接确定邮资邮戳的真实性，因此，检验是实时进行的。

另外，进行部分检验时最好能包括对邮资邮戳生成的日期与当前的日期进行比较，加入邮资邮戳的生成日期，特别是以加密的形式可增强数据的安全性，因为通过对邮资邮戳生成的日期与当前的日期的比较可以避免一种邮资邮戳的多次使用。

为了进一步提高检验速度，阅读单元与检验单元最好以同步协议交换信息。

在运用该方法时，另一个较好的实施例的阅读单元与检验单元是通过非同步协议进行相互交流的。

这里，阅读单元向检验单元发出数据电报是非常重要的。而且数据电报最好包含邮资邮戳的内容。

本发明的其它优点、特征和实际改进的地方可从从属的权利要求和下面参照图解的较好实施例的表达中可见一斑。

附图说明

图1显示的是本发明一个较好实施例的密钥分发系统。

图2是本发明密钥分发系统的应用实例。

图3是中央付费保险系统(ZinS中央系统)与价值转移中心(邮资端)之间界面的示意图。

图4显示的是向中央付费保险系统(ZinS central)加入数据密钥的过程步骤。

图5显示的是密钥从中央付费保险系统(ZinS中央系统)分发到包括有关密码系统的本地付费保险系统的示意图。

图6显示的是DLL界面的连接。

图7显示的是封装元件和处理错误报文的过程步骤的示意图。

具体实施方式

下面将结合个人计算机免费系统对本发明作一介绍。付费保险使用的过程步骤独立于用来生成邮资邮戳的系统。单个检验站，特别是邮件中心中所述的分散检验是一种较好的方法。由于同样的原因，集中检验也是可能的。

在运用本发明一个较好的实施例中，单个检验站是本地付费保险系统，它较好地通过数据连接与中央付费保险系统相连。

在所述的特别好的实施例中，中央付费保险系统也与价值转移中心相连。

在特别好的实施例中，价值转移中心即为下面的邮资端。具有优势的实施例的中央付费保险系统即为下面的ZinS中央。

价值转移中心与付费保险系统之间运用的技术界面包括密码密钥的交换。

在价值转移中心与付费保险系统之间待交换的密钥能确保生成的邮资邮戳不会被伪造，特别是二维条形码的那一部分的内容，运用所述的密钥对形成的邮资邮戳加密，从而达到这一目的。既然所选择的密钥是一种对称的密钥，由于与性能相关的原因，它必须从价值转移中心向付费保险系统传输，从而分发到各个邮件中心。

运用特殊的密码卡能确保密钥的可靠储存。本发明拥有几个应用转换键，它们能运用这种特殊的硬件管理这些密钥。这些密钥的整个生命周期，从其产生、输出、分发，一直到输入到分散系统中，都被充分使用，以便优化过程的参数。

图1显示一个较好实施例使用的密钥分发系统。它是用于价值转移中心与中央付费保险系统之间的分发系统。

在过程的第一步为生成邮资邮戳而交换免费密钥时，首先生成一个新的免费密钥。

这里使用的术语免费密钥绝不要以特定的含义去理解，因为所述的密钥可以以不同的方式生成邮资邮戳。

例如，有可能直接用这种免费密钥生成邮资邮戳。

不过，它也同样可以，而且对那些防止操纵生成邮资邮戳的高安全度、拥有多种加密数据内容的系统来说，数据内容的生成最好是几种运算的结果。这样，运算结果就会在一个或几个地方包含到具有免费密钥的邮资邮戳中。例如，德国临时专利申请书DE 100 20 402A1中一种密码串就包含在免费密钥中。

为了进一步提高防止欺诈生成邮资邮戳的保护能力，出现了事件特异的免费密钥交换方式。

在发表的案例中，新的免费密钥在固定的时间间隔，例如当预先规定的时间间隔过期后生成。

不过，同样也可以依据其它参数，例如根据所付的邮资数量和/或免费邮件，重新生成免费密钥。

就原则而论，新生成的新免费密钥可在任意的地方执行。不过，为了提高数据的安全性，最好是尽量减少对新免费密钥的传输，尽量在价值转移中心或其区域内生成该密钥。

为了确保高水平地保护该方法，防止欺诈，邮资邮戳含有的信息最好能在本地付费保险系统，例如邮件中心或货运中心依据免费密钥解密。

为了确保做到这一点，免费密钥应从价值转移中心传输到中央付费保险系统，而且这种传输最好是自动进行的。

这种交换最好是通过付费保险系统(ZinS中央服务器)的服务器实现的，价值转移中心(邮资端)不需进行配置。由于该服务器不必需要了解价值转移中心(ZinS本地系统)及其有关的密码系统，ZinS中央服务器对所述服务器而言就至关重要了。

生成较理想的新对称免费密钥后，该密钥可安全地传输到中央付费保险系统(图1中过程的第二步)，并从那儿分发到位于本地付费保险系统的密码系统(图1中过程的第三步)。本地付费保险系统返回输入操作结果(图1中过程的第四步)，从而确认密钥的成功输入。中央系统对结果进行编译、验证并传输到价值转移中心(邮资端)(图1中过程的第五步)。

一旦密钥成功地输入到本地付费保险系统的所有密码系统，它在价值转移中心(邮资端)释放，随后用来生成新的邮资数额(图1中过程的第六步)。

该理想的对称密钥是运用免费密钥生成的邮资邮戳防伪的一部分，凭借它们所述的邮资邮戳以二维的条形码形式呈现。因此，这些密钥的交换必须确保高度保密。为了做到这一点，坚持下述各点非常重要：

·内容的机密性：传输期间不允许第三者能看到传输的密钥。此外，还必须确保密钥的安全地储存，第三者不可能看到密钥，韦伯珊翠(WebSentry)密码卡可确保实现后者。

·内容的完整性：绝不允许第三者伪造部分密钥。

·认证：通信双方必须清楚地了解发送者/接收者的身份是正确的。

就接收者角度而言，它说明密钥是由邮资端生成的；而就发送者角度而言，必须确保只有有效的ZinS本地密码系统才能接收该密钥。

在陈述的对称方法中，通信双方具有相同的密钥KT。价值转移中心(邮资端)应用该密钥KT对待传输的数据密钥KD加密，然后向付费保险系统(ZinS中央系统)服务器传输所述的数据密钥KD。

该密钥从中央付费保险系统进一步分发到本地付费保险系统的ZinS本地密码系统。这些系统同样可以访问密钥KT，而且可以再一次解密密钥KD。由于密钥KT是用来在传输期间安全保护密钥KD的，下面也将其称做传输密钥。

由于所有的本地付费保险系统均接收到相同的数据，因此不必在每个本地密码服务器与价值转移中心(邮资端)之间再另行定义一个传输密钥KT。不过出于安全原因，这个密钥KT应像数据密钥KD一样在固定的时间间隔更新一次。然而，由于没有那么多的正文如同密钥KD那样被这一密钥加密，可以选择较长的交换时间间隔，这里一到二年的交换时间间隔比较合适。

这种方法的一个重要部分是传输密钥KT的密钥交换。出于安全的原因，传输密钥KT的密钥交换不能像数据密钥KD的交换那样通过相同的渠道进行。这种交换不能手工进行。由于这一程序必须在固定的时间间隔为几个本地付费保险系统进行，这里还必须提供另一种方法，通过它传输密钥的交换同样可以自动进行。

为了这一目的，ANSI X9.17标准(根据对称方法金融服务的密钥管理)定义被称做主传输密钥(下面均称做KTM)的另一种密钥等级。这种密钥必须在特殊的安全预防措施下安装到密码卡上，因此只需在较长的时间间隔交换。在此，同样的KTM安装在所有的系统上，它对传输密钥KT加密，使这些传输密钥KT通过相同的渠道以自动的方式分发和输入。它们的分发如同数据密钥的分发完全一样，各个系统或密码卡的初始化在以下的章节有详细的说明。

为了确保报文的完整性以及对发送者(等于邮资端)的认证，为每个密钥报文建立了矩阵码(MAC)。为了生成MAC，需要有签名密钥KS。如同KTM一样，签名密钥KS是在密码卡初始化期间输入生成的，以后就用这种KS对数据密钥报文进行签名。这样，报文在德国邮政股份有限公司的内联网上传输期间信息的机密性便通过使用这种高等级的密码方法得到保证。一种特别理想的加密和解密方法是Triple DES(密钥长度168比特)，SHA-1算法对计算散列值特别有效。

分发和储存数据密钥时必须考虑付费保险系统邮资端和密码系统不同时期的有效性。在任意确定的时间点，在邮资端最多只有二个密钥KD可用，即一个当前有效的密钥和另一个对新生成的邮资数额进行加密的密钥(KD_NEW)。

现有密钥与密钥(KD_NEW)运行“交换”状态时，新密钥传输到付费保险系统的密码系统。一旦这一密钥被本地付费保险系统的所有密码系统成功地输入时，便生成一份ZinS中央系统的释放报文，此时KD_NEW便在邮资端被用来对新邮资数额进行加密。到这时，旧的KD应从邮资端删除，再也不会用来生成新的邮资数额。

本地付费保险系统的密码系统的情况则不同：由于下载的邮资数额可用做预先设定的时间，例如三个月，为了生成邮资邮戳，必须要有几种可用的密钥KD对邮资邮戳进行检验。

此外，当涉及密钥的分发时，还必须考虑到那些不能输入到某些密码系统，因此在邮资端不能激活的密钥的现状如何，有可能这些密钥被输入到其它的密码系统。就原则而论，在未来的检验过程中应考虑这种情况。

在此，为了取得一致的现状，以便明确密钥的现状和便于简便可能的系统维护，密钥分发方法的下述执行方式极为有用：

(1)数据密钥以加密的形式与无歧义密钥ID(密钥相位指示符)、歧义生成计数器和有效的、先前数据密钥的结束日期一起传输。

生成计数器用来区分错误的多次加载企图与所需的对对称数据密钥的更新(确保作业安全，见(7))。

(2)中央付费保险系统应通过确认报文对价值转移中心(邮资端)传输的每份数据密钥进行回复。

(3)如果回复是肯定的，说明数据密钥已成功地安装到所有的本地付费保险系统，可以通过免费的个人计算机发送到用户。

此时，生成计数器为后继的数据密钥增加“1”。

(4)如果回复是否定的，说明数据密钥没有成功地安装到所有的本地付费保险系统上，价值转移中心不应该将其发送到用户系统用来生成邮资邮戳，否则就会出现大量无效邮件的风险。

此时，生成计数器不会为后继的数据密钥增加“1”，也就是说，它仍保留在前一次传输的数值。

(5)如果没有回复，此时价值转移中心(邮资端)不能向中央付费保险系统(ZinS中央)进一步传输密钥(当然，这种传输试图会遭到付费保险系统的忽视，而且在价值转移中心也会受到阻截)。

(6)如果在较长一段时间(超过超时时间)收不到付费保险系统的回复，此时价值转移中心(邮资端)可以通过其直接的或间接的用户界面发出报警。

(7)一旦密码卡接收到数据密钥，它将删除具有与最近传输相同的生成计数器值的所有数据密钥。这可保证因错误而多次传输时，那些仅在前面加载到部分密码卡上的密钥将会被删除，它确保作业能安全地传输密钥。

(8)在本地付费保险系统的密码卡上，一个程序将重复调用，最好是定期地，特别是每天地调用，删除那些不再需要的数据密钥。当储存在CKA_END_DATE属性中的后继数据密钥的结束日期小于当前系统日期时，数据密钥被删除(除了(7)之外的一个较好的实施例)。

(9)涉及前一个密钥的结束日期，由于生成的带有过时邮资数额的邮资邮戳在当地付费保险系统检查时仍然承认其在有效期接束后两天还有效，必须为其结束日期制定一个宽限期。另外，生成一个与新数据密钥生成与释放之间的时差也必须予以考虑。

图2是所述密钥管理应用领域及其在付费保险系统中的应用的总体情况。此外，对较好的一些应用领域也进行了介绍。

以下对应用转换键作进一步的详细说明，并对有关所述的密钥管理方法也将做详细介绍。所述的应用将以密码卡为例进行说明。

首先介绍密码卡在价值转移中心初始化的方式：

·安装与配置密码卡，上载固件，因为生产厂商没有进行这些工作。

通过嵌入码(专有软件程序)使固件功能得到扩充。为了安全原因，PKCS#11-特异的(公共密钥密码标准)密钥程序(生成，删除，等)对用户封锁，从而确保密码卡的密钥高安全性。

·定义群集(用于集中密码卡)。

·生成和储存本地主密钥(LMK)。LMK应至少在三个组分中分发，其中两个组分应特别有利于重新产生或使密码服务器卡重新初始化。最好是每个组分用PIN保护写到智能卡(SmartCards)上，这样安全管理员可得到一张智能卡。此外，还必须生产一些备用智能卡，这样LMK便可用作上述的主传输密钥KTM。

·用户管理：删除默认安全管理员和定义包括必要的认证规则的安全管理员(基于智能卡)。

·生成初始签名密钥KS，用KTM加密(包装)，储存为文件，以后可将该文件拷贝到软盘上(只有安全管理员可以访问该文件/软盘)。

·生成第一个传输密钥KT，建立有关的密钥报文，并将该报文储存到文件中以及日后可将该文件拷贝到软盘上(只有安全管理员可以访问该文件/软盘)。

生成主传输密钥

新的主传输密钥(KTM)最好以下述方式生成。有关确认卡的本地主密钥(LMK)可用作KTM。为安全起见，该LMK至少应细分为3个组分，其中至少2个组分需要重新输入。

每个组分储存在智能卡上，因此每个安全管理员接收一个智能卡，并用单个的PIN将其固定。对PIN保密和将智能卡储存在安全地方可以防止未授权人员对它们的访问。

为了执行主传输密钥，最好应有2种LMK组分-对应于2种不同授权卡，以便可以进行双重控制原则的自动执行。

KTM必须是Triple DES密钥，其ID属性由一个类型标识和一个无歧义的数字组成。

类型标识：KT

无歧义数字：01到99。

长度：固定的4比特，存档为CK_CHAR[]。

作为原则，各项安全机制均应确保只有授权人员方能进行密钥交换。下面所述使用签名密钥的实施例具有很大的优越性，因为它证明对防止操作具有极高的安全性。

签名密钥能保证密钥报文的完整性，而且它还可在输入密钥前用来确定密钥报文的发送者是否是邮资端。只有通过智能卡注册的安全管理员可以生成签名密钥，它必须是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一样上载到现场的硬件上。

下面介绍传输密钥的生成。

本应用转换键生成了包括有关密钥报文的传输密钥，该密钥的生成模块最好配置成只有安全管理员能够启动传输密钥和/或有关密钥的报文的生成，交换时间间隔应为一年或二年。

传输密钥应依次为TDES密钥，具有下述属性：

LABEL属性中的随机号可用来确定是否成功地输入到密码服务器卡，以及与该随机号相关的散列值(例如通过SHA-1方式)形成，它可用来确认成功输入和释放传输密钥。

CKA_ID和CKA_LABEL属性将填写成CK_CHAR[]形式。所有其它属性均定义在pkcs11.h文件的类型之中。

传输密钥用KTM(＝LMK，CKM_KEY_WRAP_WEBSENTRY机制)加密，具有下述结构的报文形成后从价值转移中心向中央付费保险系统传输：

项目	长度	比特数	标志	描述
					1	2	f1-f2	MsgType	识别密钥报文，常量‘KT’。
2	1	f3	Version	报文结构版本，1比特，以值‘01’开始。
					3	4	f4-f8	KeyID	传输密钥在明文中的ID。
4	4	f9-f12	SigKeyID	用来签名的密钥的ID。
					5	n-13	f13-f<sub>n1</sub>	TraspKeyEncrypt	传输密钥加密(包装)的结果。
6	24	F<sub>n+1</sub>-f<sub>n+2</sub>4	MAC	用于密钥报文的MAC，它是这样组成的：首先形成报文字段1到5所需的SHA-1散列值，该散列值用签名密钥加密(CKM_DES3_CBC_PAD机制，IV均填0，ID见字段5)。

进一步分发后，该传输密钥报文转移到ZinS中央服务器。界面便成为一个Session Bean，该服务可通过命名服务(Java命名目录界面)查出，传输方法则有赖于上述的数据块。

另外，报文以文件的形式储存在邮资端，安全管理员可以日后将其储存到放置在安全地方的一张或二张软盘上，以后软盘便可用来使新的密码服务器卡初始化。

下面介绍一种较好实施例释放传输密钥的方法。

价值转移中心通过配置可以释放传输密钥KT。一旦传输密钥KT成功地分发并成功地输入到所有本地付费保险系统(ZinS密码系统)，为了释放传输密钥KT，中央价值转移中心可通过一个界面释放该传输密钥。只有通过这样的释放，有关的传输密钥才能日后用来加密数据密钥(KD)。

这时，界面便成为一个塞型饼(Session Bean)，该服务可通过命名服务查出。

释放程序的数据结构最好具有下述参数：

项目	长度	比特数	标志	描述
					1	4	f1-f4	KeyID	传输密钥在明文中的ID。
2	201	f4-f24	RandomHash	转移为传输密钥的LABLE属性的随机号的SHA-1散列值。
					3	1	f25	State	加密结果：true＝需要加工，可以释放；false＝加工不成功
4	128	f26-f153	Message	错误原因的详细报文或详细的成功报文

通过参数2可对PP密钥管理系统的对方，即付费保险系统(ZinS密钥管理系统)的密钥分配系统进行验证。这是从传输密钥的LABLE属性应用SHA-1法建立的一种散列值，在生成传输密钥时用一个随机号填写LABLE属性，由于传输密钥和其所有属性在传输期间是加密的，因此只有ZinS密码服务器能计算正确的散列值。

如果传输的散列值等于为LABLE属性计算出的KT值，则所述的散列值位于邮资端的韦伯珊翠(WebSentry)模块，如果传输的加工状态为“true”，传输密钥被激活。这表明随后数据密钥报文将被该传输密钥加密。

当加工存在错误(传输状态＝false)时，该应用转换键也出现变异。在本案例中，该密钥的生成和分发的状态是有协议规定的，因此有关的传输密钥也同样被删除。

以下介绍一个较好的实施例生成新数据密钥的方法。

该应用转换键生成了包括有关密钥报文的数据密钥。密钥分配系统最好配置成该行为只有安全管理员能够启动，该项工作应每三个月进行一次。如果数据密钥KD仍在流通之中，中央付费保险系统(ZinS中央系统)迄今仍未收到反馈(释放或错误)，直到收到反馈之前，生成新KD的工作将会被冻结。

数据密钥KD可用来对某些矩阵码的内容加密，同时还能确保当未向邮政服务提供商付费时不会生成有效的邮资邮戳。这种数据密钥可在ZinS密码服务器上检验数字式邮资邮戳。数据密钥同样也是使用PKCA#11功能C-发生密钥(C_GenerateKey)生成的TDES密钥，具有如下属性：

该系统介绍了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.供分发的报文形成，它具有如下结构：

4.然后，数据密钥报文转移供进一步分发到ZinS中央服务器。此外，安全管理员还将进一步将其储存到一张或二张软盘上，保存到安全的地方，今后可用来初始化新的ZinS密码服务器卡。

对报文内容两次加密的优点是可使在内联网上向KTM传输的加密正文减少，从而造成对该密钥的密码分析更加困难。

为了释放数据密钥KD，必须提供一个界面和协议机制，以便使数据密钥的释放按协议进行。中央付费保险系统最好能这样配置：只有当数据密钥成功地释放和成功地输入到本地付费保险系统的密码系统时，数据密钥才能释放。只有通过这样的释放，有关的数据密钥才能随后用来对将包含在邮资邮戳中的密码串加密。随后，有关的密钥识别信息KeyID也才能在邮资数额的识别信息(PostageID)中编码。

界面通过中央付费保险系统(ZinS中央)与本地付费保险系统(ZinS本地)间的CWMS(计算机化工作管理系统)释放，价值转移中心(邮资端)PP通过适当的bean接收信息。释放程序的数据结构具有下述内容：

通过参数2可对价值转移中心PP的密钥分配系统的对方，即付费保险系统的密钥分配系统进行验证。最好是从数据密钥的LABLE属性应用SHA-1法建立一种散列值，在生成数据密钥时用一个随机号填写LABLE属性，由于数据密钥和其所有属性在传输期间是加密的，因此只有收费保险系统的密码服务器能计算正确的散列值。

如果传输的散列值等于为LABLE属性计算出的KD散列值，且位于邮资端的WebSentry模块，如果传输的加工状态为“true”，数据密钥被激活。这表明邮资邮戳/邮资数额的密码串随后也由该数据密钥加密。当数据密钥激活时，签名密钥的生成计数器也增加一个数。

当加工存在错误(传输状态＝false)时，该应用转换键也出现变异。在本案例中，该密钥的生成和分发的状态是有协议规定的，因此有关的数据密钥也同样从卡上删除。在这种情况下，生成计数器不会增加一个数。

密钥分配系统最好能含有一个状态存储器用来储存所执行的密钥生成。只要从中央付费保险系统(ZinS中央系统)没有收到有关已执行的密钥分发反馈，显示状态则为开放(open)。成功反馈和分发后，密钥标识为已激活。在发生错误的情况下，系统显示传输状态信息。

出现错误或较长时间收不到释放信息时，错误调查程序被调用。

将密钥存档是极为有利的。下面介绍一种在价值转移中心所进行的一种较好的密钥存档方法。为了确保密钥安全，安全管理员可以执行一个存档功能，用KTM(CKM_KEY_WREP_WEBSENTRY机制)对所有密钥(KTM除外)进行加密和解密。这些密钥应当安全地存放在数据库或安全的文件系统中。

成功地存档后，所有已超过起始有效期6个月不再有效的密钥被删除。

密钥储存时，特别是储存在价值转移中心PP的密钥，应将存档的密钥数据再次解密(拆包)后储存在卡上，使用的机制仍旧是CKM_KEY_WRAP_WEBSENTRY。

当密钥解密后，具有相同的密钥识别信息KeyID、且业已存在于卡上的密钥被删除。

通过Websentry卡的特殊安全措施和通过向几张智能卡的分发，主传输密钥KTM便可靠地保存下来，不会失密。如果仍要交换主传输密钥KTM，应模拟包括密码卡(PP)初始化工作的应用转换键，生成一个新的KTM和新签名密钥、传输密钥和数据密钥。

原先的KTM仍保留在卡上作为所谓的“待用LMK”，安全管理员删除它时必须十分注意。

下面介绍较好应用转换键的密钥分配系统。这种提供也同样适用于付费保险系统所有地区的申请，如果某一组分在本地付费保险系统或在中央付费保险系统执行较好时，这种做法特别有利。不过，这种做法在其它每个付费保险系统也可能同样可以使用。

第一个申请案例是付费保险系统地区的密码卡的初始化。

为了使密码卡初始化，必须建立下述基本配置，从而使多数功能可通过管理工具(WebSentryManager)管理。

·如果生产厂商没有配置的话，安装配置卡，上载卡固件。该固件包括嵌入代码(专有软件程序)(后者的功能集成到WebSentryManager中)。

·定义群集(与几个密码卡)(WebSentryManager)。

·输入主传输密钥(KTM)，见分离的应用转换键(功能由WebSentryManager提供)。

·用户管理：删除默认安全管理员和定义包括了必需的认证规则(基于智能卡)的安全管理员。生成二个可通过预定义PIN自行授权的“正常”用户(一个进行密钥验证，一个进行密钥输入)。同样，用户管理的功能由WebSentryManager提供。

·输入签名密钥(KS)：见分离的应用转换键。

·输入传输密钥(KT)：见分离的应用转换键。

·可选地输入数据密钥(KD)：(同样见其自己的应用转换键)只要它们业已生成。

这里，密钥必须按以上规定的顺序输入，卡可在中心地区初始化。因此完整的密码系统计算机必须初始化，随后发送出去，这是因为一旦WebSentry卡拔出PCI槽口它会立即删除内存。

主传输密钥最好是只由至少2个安全管理员输入，这2个安全管理员在本地上可谓是智能卡读者和相关智能卡的密码系统的对手。由于密钥KTM的重要性，该密钥只能是应用双重控制原则输入到卡上。也就是说，至少需要在应用转换键“主传输密钥”中生成的二个PIN保护的智能卡加入输入。

由于主传输密钥KTM只能使用二张智能卡加载到卡上，又由于密钥使用是PIN保护的，这就可以确保使用双重控制原则时该密钥才能安装到卡上，这可提供一个极高的保护水平避免密钥遭到破坏。

这一功能是通过管理工具WebSentryManager提供的。这一管理工具可以通过智能卡加载一个所谓的本地主密钥(LMK，对应于这一概念的KTM)，并将它们储存在卡的安全存储区域。

将LMK分发到3张智能卡上非常有利。这样，所有的3部分都可用来将LMK输入到密码硬件上。在这种情况下，需要有3个安全管理员来输入主传输密钥KTM。

签名密钥可确保密钥报文的完整性。在输入该密钥前它也可用来确定密钥报文的发送者是否是价值转移中心(邮资端)。签名密钥可以以不同的方式生成，因此这里提供的实例是十分有用的。有关的密钥报文由管理员保存到软盘上，通过本应用转换键，输入到将初始化的付费保险系统的密码卡上。

为了输入该密钥，存储在软盘上的密钥报文用主传输密钥KTM(PKCS#11功能C_Unwrap，CKM_KEY_WRAP_WEBSENTRY机制)解密，密钥报文的完整性由该程序自动检查。如果具有这种KeyID的密钥已经存在，它便随后被删除。

为了进一步传输传输密钥报文，中央付费保险系统的服务器提供一个界面，通过该界面可启动分发和随后向各个本地付费保险系统的密码系统输入该密钥报文。

该界面可实现RMI服务，该服务可通过命名服务(JNDI)查到，通过用来分发P/N目录的CWMS(计算机化工作管理系统)进行分发。

如果生成了一项新的分发作业，密钥报文便发送到所有当前注册的密码系统，并为每个案例撰写协议入口，通过付费保险系统的应用转换键对密码系统进行管理。

每个密码系统在固定时间间隔(根据分发机制变化)都要用输入控制(ImportController)检查新密钥报文收据，当收到一份新报文时，应用转换键“输入传输密钥”自动开启，并对该动作的返回值进行检查。如果收到一个负反馈，输入工作可重复高达三次。

假如重复三次后仍旧不能输入，此时向ZinS中央系统发送有关失败的协议报文(也是根据传输机制而变化)。如果输入成功，发出肯定的协议报文。

协议报文通过应用转换键“协议密钥加工”集中加工，根据加工结果触发释放传输密钥。

输入传输密钥要么由在现场初始化密码系统的安全管理员进行，要么当ImportController接收到一份新传输密钥报文时由密钥分发的ImportController自动触发输入。密钥输入最好能按照下述过程步骤：

1.进行卡上注册，使ID和PIN属于KeyImport用户。

2.应用SHA-1法建立传输密钥报文字段1到5的散列值。

3.确定签名密钥，应含有字段4标明的KeyID。

4.用该密钥加密在Point 2(CKM_DES3_CBC_PAD机制，初始化向量IV填0)生成的散列值，并与字段6比较。假若这两个值匹配，完整性可得到保证，而且可确保报文是由PC的免费系统建立的。

5.用KTM对报文字段5的内容解密(C_UnwrapKey法，CKM_KEY_WRAP_WEBSENTRY机制)。从而自动生成一个合适的传输密钥对象，储存在卡上。此外，该机制还再一次无保留地对密钥的完整性和正确的发送者进行检查。

6.如果一个具有相同KeyID的密钥业已存在于卡上，删除该密钥。

7.应用SHA-1法建立新输入密钥LABLE属性的散列值，该散列值与KeyID和肯定报文一起返回作为返回值。

8.用户会话结束。

9.从返回值生成协议报文，发送到ZinS中央系统。

10.在KeyID储存的任何失败的工作(见下面所述的变异)被重新设置。

该应用转换键的变异即指任何程序或MAC检查的失败。在这种情况下，进一步的加工会流产，返回的返回值包括KeyID、错误代码和出错信息。对于KeyID而言，储存的失败次数增加1。一旦该号码达到3，最新转移的返回值产生一分协议报文，发送到中央付费保险系统。

在手工初始化的情况下，输入结果还会呈现在安全管理员的监视器上。

步骤2到步骤7最好是直接在卡软件(嵌入代码)上进行，这样不仅可以提高性能，而且还可以增强安全，防止破坏。

为了进一步传输数据密钥报文，中央付费保险系统的服务器还提供另一个界面，通过该界面可以进行分发以及随后将数据密钥输入到本地付费保险系统的每个密码系统中。

该界面已实现session bean的功能，该项服务可从命名服务(Java命名目录界面，JNDI)查到。通过用来分发P/N目录的CWMS(计算机化工作管理系统)进行分发。

如果生成了一项新的分发作业，密钥报文便发送到所有当前注册的密码系统，并为每个案例撰写协议入口，通过分配系统对密码系统进行管理。如果数据密钥的分发作业已在流通中，且价值转移中心PP还未收到它的反馈，直到收到反馈之前，任何进一步接收数据密钥的分发作业都将被拒绝。

ImportController都要在固定时间间隔(根据分发机制而变化)为每个密码系统检查新密钥报文的收据。当收到新报文时，应用转换键“输入传输密钥”自动开启，并对该动作的返回值进行检查。如果收到负反馈，输入工作将重复高达3次。

如果重复3次后仍不可能输入，一份关于失败的协议报文发送到ZinS中央系统(同样根据传输机制而变化)。如果输入成功，则发出肯定的协议报文。

协议报文通过应用转换键“协议密钥加工”而集中加工，传输密钥的释放也由该应用转换键触发。

输入传输密钥要么由在现场初始化密码系统的安全管理员进行，要么当ImportController接收到一份新数据密钥报文时由密钥分发的ImportController自动触发输入。

该密钥的输入类似于传输密钥的输入，但应考虑数据密钥报文的特点：

1.进行卡上注册，使ID和PIN属于KeyImport用户。

2.应用SHA-1法建立数据密钥报文字段1到7的散列值。

3.确定签名密钥，应含有字段5标明的KeyID。

4.用该密钥加密在Point 2(CKM_DES3_CBC_PAD机制，初始化向量IV填0)生成的散列值，并与字段8比较。假若这两个值匹配，完整性可得到保证，而且可确保报文是由PC的免费系统建立的。

5.确定传输密钥，应含有字段6标明的KeyID。

6.用在Point 5(C_Decrypt法，CKM_DES3_CBC_PAD机制，初始化向量IV填0)确定的密钥对报文字段7的内容解密。解密结果是一份临时报文。

7.用KTM对临时报文字段1的内容解密(C_UnwrapKey法，CKM_KEY_WRAP_WEBSENTRY机制)。从而自动生成一个合适的数据密钥对象，储存在卡上。此外，该机制还再一次无保留地对密钥的完整性和正确的发送者进行检查。

8.如果一个具有相同KeyID的密钥业已存在在卡上，删除该密钥。

9.阅读和检查密码卡上的所有数据密钥，了解LABLE属性，即比特1中的生成计数器的值是否等于新输入的密钥。如果等于，这些密钥应从卡上清除，因为它们是由于输入到另一个本地付费保险系统的密码系统时出错而在价值转移中心PP没有释放的密钥。

10.应用SHA-1法建立新输入密钥LABLE属性2-65字节的散列值，该散列值与KeyID和肯定报文一起返回作为返回值。

11.用户使用密码卡的会话结束。

12.从返回值生成协议报文，发送到ZinS中央系统。

13.在KeyID储存的任何失败的工作(见下面所述的变异)被重新设置。

该应用转换键的变异即指任何程序或MAC检查的失败。在这种情况下，进一步的加工会流产，返回的返回值包括KeyID、错误代码和出错信息。对于KeyID而言，储存的失败次数增加1。一旦该号码达到3，最新转移的返回值产生一分协议报文，发送到中央付费保险系统(ZinS中央系统)。

在手工初始化的情况下，输入结果还会呈现在安全管理员的监视器上。

步骤2到步骤10最好是直接在卡软件(嵌入代码)上进行，这样不仅可以提高性能，而且还可以增强安全，防止破坏(特别是对初始化向量和KTM)。

数据密钥应能从尽量多的付费保险系统密码系统上重复清除，最好是从所有密码系统上定期清除，以便清除再也不需要的数据密钥.

清除数据密钥的程序：

1.确定位于卡上的所有数据密钥，按照它们ID(CKA_ID属性)的升序整理。

2.按下述程序对该清单中的每个密钥进行检查：

(1)确定一个密钥的继任者(下一个较大的ID)。

(2)如果存在，检验以下内容：

a.标明前任者有效性结束的继任者的CKA_END_DATE属性是否小于当前系统的日期。如果确实如此，输出该清单中当前加工的密钥。

b.继任者的生成计数器(CKA_LABLE属性的第一位比特)是否等于当前加工密钥的生成计数器。如果确实如此，输出该清单中当前加工的密钥。

中央付费保险系统(ZinS中央系统)的服务器上的密钥加工最好是按协议规定进行，经本应用转换键协议规定的密钥是传输密钥和数据密钥。

对于每个分发作业，协议规定了密钥报文应发向那一个有效的密码系统。对于每个系统和每个分发作业而言，都在“发送”状态时经首先设置而生成有一个独立的入口。

每次成功或失败的加工后，每个密码系统生成一份协议报文并发送给中央付费保险系统(ZinS中央系统)。这种分发工作不是通过JMS队列就是通过数据库复制进行。

在中央付费保险系统地区，收到报文之后，报文用来更新上述的协议入口。为了这一目的，“加工成功”/“不成功”的状态以及可能是错误的代码被储存下来。

伴随协议报文的加工，系统还检查是否有成功地进入到所有密码系统的分发作业。如果存在有分发作业，释放每个相关密钥的工作，特别是在价值转移中心启动。一旦系统报告出错，价值转移中心地区就会生成一份负状态的相关报文。

调用密钥释放这一事实被通知给分发作业，因此，对于一个作业而言不再有额外的释放进行。然而，只要未输入该通知，新的尝试就会在固定的时间间隔与释放服务系统取得联系。

当经历一段设定的时间后，最好是几天，例如3天，也会出现特殊的情况，从所有的密码系统接收不到反馈。过了这段时间后，一份否定的释放报文发送到价值转移中心。

密钥分配系统最好应有一个界面，可让管理员检查密钥分发作业的状态。此时，每个分发作业将显示以下数据：

·接收分发报文的系统的号码

·报告成功进行加工的系统的号码

·未报告加工结果的系统的号码

·报告加工失败的系统的号码

此外，还可编制一份详细的清单，可以显示每个系统的当前状态。作为一种替代方法，也可显示存储在有关卡上的本地密钥。

最好是能将生成分发作业所用的所有密钥在中央付费保险系统地区存档，而不要在本地系统存档。在本地系统，密钥存储在卡的非易失性存储器上，只有那些也被释放的密钥报文才存档。

为了一个特定的密码系统，传输密钥和数据密钥的密钥恢复可集中进行。在这种情况下，存档中的当前密钥被确定，并发送给特定的密码系统。为了这一目的，同样要生成协议报文。使用这种密钥分发方法，只是不需要释放报文。

如果主传输密钥KTM遗失，要么由相关的密码系统通知安全管理员要求重新初始化，要么安全管理员不得不对现场的每个系统初始化。

主传输密钥KTM可通过WebSentry卡的特殊安全措施和通过分发到几个智能卡以及通过多级密钥系统能做到安全可靠地储存，防止失密。

然而，如果要交换主传输密钥，则必须生成一个新的主传输密钥KTM以及新的签名密钥、传输密钥和数据密钥。

然后这些密钥又不得不输入到本地付费保险系统的所有密码系统中，这需要大量的精力，因为不是所有的密码系统都要向中央管理地区进行一个来回的传输，就是安全管理员不得不到本地付费保险系统的所有地区去走一趟。因此，使用本发明关于主传输密钥KTM的安全机制则特别有利。

早先保留在卡上的主传输密钥KTM称做所谓的“待用LMK”，应由安全管理员恰当地删除。

密钥处理和解密应作为嵌入代码反映在密码卡上。采用这种方式，不仅可以获得更高的安全度，而且有可能提高密码系统的性能。

密码卡最好能伴随所述的扩充包含下列标准的PKCS#11功能：

·C_CloseSession

·C_GetSlotList

·C_Init

·C_Login

·C_Logout

·C_OpenSession

此外，永久存储的功能则不应该包含第三方的进一步扩充，且这里所需的扩充应作为付费保险系统密码卡功能全部包括进来。

为了标志PKCS#11DLL嵌入密钥处理方法，这些方法都赋予一个前缀。该前缀定义为CE_。在这种情况下，CE代表密码扩充。

每种嵌入法提供一个CK_RV类型的返回值，定义为pkcs11.h include文件的固定组分。这样做十分有利，在执行嵌入法期间，另外的错误返回值可以定义，并提供加入到C++的头文件中。这种方法的好处在于通过调用嵌入法可以调用各种pkcs11方法，使它们嵌套在硬件上，另一个优点就是在密码卡软件中建立了完整的、全新的密钥处理部分。

下面是显示该方法语法的实例：

CK_RV＝CE_MethodName(parameter list)

在参数表中，必须用结果填写的参数通过引用调用而转移，通过有意义的字组合提供方法的明确含义，从而形成方法的名称。

通过字的选择使其组合后赋予有意义的内容，例如使用英语中的技术术语。

介绍两种枚举类别可用来检验不同嵌入法的功能。密钥类型和密钥属性的枚举类别存在着差异。

CK_EnumKey＝{CE_KT，CE_DT，CE_SE，CE_KA}

CE_KA承担特殊的位置，它不是一个密钥而是所有密钥的集合。如果显示EnumElement，这些方法将执行与卡上含有所有密钥有关的功能。

CE_EnumKeyAttribute＝{CE_ID，CE_LABLE，CE_STARTDATE，CE_ENDDATE}

pkcs11.h文件应引入必要的定义。定义的扩充可在包含在pkcs11.h文件中的独立头文件中找到，许多机制均可执行这些嵌入法。

在密码环境下，定义了一种方法，它可利用可资利用的pkcs11方法自主执行所有相关的检验。

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密钥属性，因此可以无歧义地发现该密钥。下面将进一步介绍的密钥处理应允许足够的密钥发现时间。

第三步：解密所含的加密报文。CK_MECHANISM使用的机制是CKM_DES3_CBC。比特f15-f38加密，它们长24比特。解密结果的前12比特用参数postageID输出，一旦成功地解密，该过程继续第四步，否则第五步。

第四步：生成和清除散列值。一个特殊构造的77比特长的数据块用作生成日期散列值的基础。

比特1到53：对应于矩阵码的前53个比特。

比特54到65：对应于当前未加密报文部分(PostageID)的前12个比特。

比特66到77：对应于当前未加密报文部分的后12个比特。

应用SHA-1建立散列值，然后，前4个比特必须匹配比特f54-f57。如果不匹配，则生成的日期无效。如果在执行散列期间出错或散列值存有差异，执行第五步中的过程。

第五步：成功指示符的返回。如果所有的作业步骤均成功，用“true”填写参数bOk。如果清除散列值发现差异或一个pkcs#11法引起出错，用“false”，填写参数bOk。返回值也应该同样用错误报文填写，如果没有出现错误，则用CKR_OK填写。

CK_RV DE_VerifyMsg(CK_SESSION_HANDLE session，

CK_BYTE[]message，int length，

CK_BBOOL bok)

用作检验程序的普通数据块报文如下：

未用的字段均填0，该方法的作业模式通过参数MsgType确定。

生成的数据块在MesType KT和KD报文中转移，数据块填写每个收到的报文。

MesType KT的功能分配CE_VerifyMsg KT接收MESSAGE属性中完整的传输密钥报文和LENGTH属性中的长度，这种嵌入报文可确保传输密钥报文在接收端的完整性。为了启动检验，必须履行下述步骤：

第一步：建立初始化向量IV。初始化向量填0。

第二步：解密收到的加密报文。CK_MECHANISM使用的机制是CKM_DES3_CBC_PAD。可变的MAC字段的字节解密。如果在解码过程中出错，程序进入第四步。

第三步：清除散列值。为了建立日期的散列值，从传输密钥报文的1+2+5+6+8字段建立散列，并与第二步的散列进行比较。用SHA-1建立散列值。如果这些散列值不相等，则日期无效。如果在执行散列期间出错或散列值存有差异，执行第四步中的过程。

第四步：成功指示符的返回。如果所有的作业步骤均成功，用“true”填写参数b0k。如果清除散列值发现差异或一个pkcs#11法引起出错，用“false”填写参数b0k。返回值也应该同样用错误报文填写，如果没有出现错误，则用CKR_OK填写。

MesType KD的功能分配CE_VerifyMsg后，完整的数据密钥报文转移到MESSAGE属性和LENGTH属性的长度中，这可确保传输密钥报文在接收端的完整性。为了启动检验，必须履行下述步骤：

第一步：建立初始化向量IV。初始化向量填0。

第二步：解密收到的加密报文。CK_MECHANISM使用的机制是CKM_DES3_CBC_PAD。解密可变的MAC字段的字节。如果在解码过程中出错，程序进入第四步。

第三步：清除散列值。为了建立日期的散列值，从数据密钥报文的字段1+2+4+3+6+7+8建立散列，并与第二步的散列进行比较，用SHA-1建立散列值。如果这些散列值不相等，则日期无效。如果在执行散列期间出错或散列值存有差异，执行第四步中的过程。

第四步：成功指示符的返回。如果所有的作业步骤均成功，用“true”填写参数b0k。如果清除散列值发现差异或一个pkcs#11法引起出错，用“false”填写参数b0k。返回值也应该同样用错误报文填写，如果没有出现错误，则用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参数检验且根据检验结果处理。

然后，密钥送到高速缓存作业的密钥管理。适合的话，将重复的前任者删除。

DT由KeyKTID参数发现的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表示在高速缓存作业的密钥管理中每种密钥有多少密钥在卡上注册。运用这种方式，密钥参数可与下面介绍的方法一起读出。

该方法定义如下：

CK_RV CE_GetAttribute(CK_SESSION_HANDLE session，

CE_EnumKey KeyType，

CE_EnumKeyAttribute KeyAttribute，

Int pos，

CK_BYTE[]^*attribute，

Int^*length)

密钥类型通过KeyType参数确定，因此，也就是根据密钥类型在不同清单中记录密码硬件上不同类型密钥的表来确定的。

密钥属性(KeyAttribute)参数规定读出的属性，ITEM参数指示其在表中的开始点。它必须首先用CE_GetKeyCount法为所有的密钥或一种密钥获取最大值，当CKA_END_DATE属性输出时，必须注意最后一个当前的密钥在理论上是无限期有效的(直至一个相同密钥的新密钥输入)，而且在其CKA_END_DATE属性中含有相同种类密钥前任密钥的结束日期。因此，这种表达的密钥的CKA_END_DATE也同时输出。

日期属性具有8个字节的固定长度，而CSK_ID和CKA_LABLE属性具有128个字节的固定长度。假若这两个参数的密钥属性短于128个字节，在128个字节长度的不足部分用0填写。因此，用户可始终为解决该问题的方法提供足够的存储空间。当用户提供一个相当小的缓冲区时，将信息进行调整，所得报文通过CK_RV传递。

CK_RV CE_DeleteExpiredKeys(CK_SESSIOV_HANDLE session，

CE_EnumKey KeyType，

Int^*counter)

功能分配CE_DeleteExpiredKeys在卡上搜索过期的密钥，并将它们从卡上删除。过期密钥可通过下述方法发现：系统日期比继任密钥的CKA_END_DATE更前，见2.5.8项。这也同样适用于KT和KS。通过EnumType可进行选择性删除，运用CE_KA可将整张卡删除(仅留下LMK)。必须注意，当进行密钥输入时，绝对不可使用该方法。这最好是在嵌入码中进行控制，并用适当的返回值予以指示，采用这种措施可避免任何对内部密钥管理不确定的负面影响。

付费保险系统与价值转移中心之间的界面最好是越窄越好，以便排除通过非正规渠道进行操作的可能性。

图3显示的是付费保险系统与价值转移中心(邮资端)之间的界面结构。

中央付费保险系统提供一个分发密钥的界面，价值转移中心(邮资端)的KeyManagement组份生成的密钥可通过该界面分发到付费保险系统的密码系统。

价值转移中心向付费保险系统提供一个密钥释放界面，当所述密钥成功地释放和加工后，付费保险系统可通过该界面释放该密钥。

由于这两者主要都使用Java，建议使用Session Bean实现应用界面。为了使这两个系统不要耦合，该服务应使用JNDI从命名服务中查出。

Session Bean提供向ZinS中央系统输入密钥数据的必要功能，图4显示的是其整个通信过程。图4显示了将数据密钥加入到中央付费保险系统(ZinS中央)的过程步骤。

过程程序ImpotKey将数据密钥集转移到ZinS中央。

依据使用ASN.1报文，该过程程序准备接收报文，并使该报文储存在数据库中。然后，过程程序ImpotKey通过CWMS启动密钥数据分发到ZinS中央系统。

将数据输入到数据库以及随后分发报文时应严格遵守次序，这样可确保在加工结束前或加工期间接收到的数据的安全。这种方法的优点是错误领域的事件可以较好地重建，在数据丢失时，如果需要可以访问数据库。

由于此时还不甚清楚是否支持ASN.1格式，插入密钥数据(InsertKeyData)法的参数还未指定。然而，该方法必须拥有两个参数，以便也能向邮资端发送详细的报文。

在ZinS中央系统，密钥分配系统的分发方法负责下述工作：

1.将密钥报文存档在ZinS中央的服务器上。

2.通过Vibris提供的CWMS界面从邮资端向各个邮件中心分发  密钥报文，CWMS服务的结构以及使用可查阅该界面的手册。

3.一旦分发和向各个邮件中心输入完成之后，生成一份有关的返回报文。

数据以ASN.1格式从价值转移中心(邮资端)传递，期待的有关返回回复也以ASN.1格式出现。不过，代替这种格式的其它格式当然也可使用，一些特殊的格式通过语法程序分析后经过改写也可使用。

下面是较好的ASN.1数据格式：

传输密钥的分发报文：

       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 all previous elements)

        }

数据密钥的分发报文：

       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 LMK

      And

      Encrypted with TransportKey)

      MAC OCTET STRING(MAC over all previous elements)

      }

      参见2.4.6节。

释放报文：

       KeyExchangeReceipt::＝SEQUENCE

       {

       KeyID OCTET STRING，(CKA_ID of received key

       KeyLableHash OCTET STRING，(SHA-1hash of CKA_LABLE of

   received key)

       State BOOLEAN，(TRUE/FALSE to enable/dismiss key)

       Message OCTET STRING(Description of success/failure)

       }

数据结构可以有不同的设定。不过，这里实施例提供的设定特别有利，因为它允许传输所有考虑到的信息且其开销仅占数据传输开销的一小部分，特别是数据可通过CWMS传递到位于邮件服务提供商的邮件中心的本地付费保险系统。

当使用ASN.1格式时，数据必须首先进行语法分析形成内部密钥报文。这样，如果该文件定义的报文被直接使用时，就可省却对它的使用。

通过CWMS接收到的数据包对应于该文件以前定义的密钥报文。这些报文在首先适合标题“数据密钥KD属性”上方的数据表后，然后经受嵌入码VerifyMsg法的检验。检验后，要么通过嵌入码开始输入该密钥，要么生成一个适当的错误报文。在使用CE_ImportKey嵌入码法时，比较密钥报文和第12页至14页输入数据的结构。此时上述嵌入码法会自动地删除和更新旧的密钥。

CE_DeleteExpiredKeys法会每天调用，只要需要，它每日随时都可用来从密码硬件上清除过时的密钥。在输入期间，CA_ImportKey法确保重复生成的密钥将被删除，新生的密钥将取代它们。

嵌入码法通过Java级密码适配器(CryptoAdapters)是与应用捆绑在一起的。CryptoAdapters可提供嵌入码和其他PKCS#11法提供的所有功能(命名也类似)。

DLL(CryptoAdapter.DLL)通过JNI可以使用，它静态地将Zaxus提供的DLL连接起来。这样，通过静态连接使安全风险进一步减小。

JNI界面执行C++也可提供每次所需会话的错误处理。关于这一点，见PCFM设计文件第三阶段“多线程操作”一栏。操作者的观念受到支持，在多线程操作模式时密码硬件已经启动，登录后每个操作者可得到他自己的会话(GetSession，C_GetSession)，结果该操作者在DLL注册，并专门为该操作者建立了错误处理。登录就会寻求DLL主流，并拥有其自己的用来执行PKCS#11法和嵌入法的错误处理。

图6显示的是执行总图，最好能将嵌入法提供的密钥清单和代码清除，否则，选定的结构设定就会完全一样。

DLL的连接

图7显示了一个实例中较好的封装结构和有利的错误处理。

如果密码硬件嵌入码中存有完整的密钥清单，可以不要执行密钥清单。GetAttribute法减少到只需一次调用嵌入的CE_GetAttribute法。而且输入及其执行的调用也得到减少，因为必需数据转移后嵌入码能自动地进行这一工作。

在嵌入码中还可提供一个扩充的误差常数清单。

邮资端的密钥报文存储在ZinS中央的数据库中，以便供有问题的本地付费保险系统日后取代使用。首先，这样的报文是必须收入数据库的；其次，管理信息也应收到。

因此，下面的数据库表是非常重要的。

密钥数据按照邮资端接收密钥数据的方式存储密钥报文。如果本地付费保险系统失败，存档的密钥报文就可通过输入存档的密钥来协调失败的本地付费保险系统与其它剩下的本地付费保险系统。在储存前，报文必需用ASN.1语法分析，以便向本地系统传递。最好是用相同的数据记录格式作为储存的形式，它对应于用来介绍CE_VerifyMessage嵌入法使用的数据块的表。

这条数据记录具有中心地位的作用。首先，它用来评价从邮件中心的本地付费保险系统收到的反馈。所有的邮件中心最好都能集成到邮件服务提供商的邮件系统，能进行错误分析，并在分发程序过程中一旦时间过期能向系统操作员报警。

而且，这张表还包括管理信息加工，如果合适，这使它能使用SNItemNo入口分配和评价有关的TransportKeyData表单个(83)邮件中心的TransportKeyReplayMessage。

在这张表中，本地付费保险系统的每个密钥应答报文伴随输入程序的变化存档在邮件服务提供商的邮件中心。

Claims (17)

1.一种检验使用免费密钥生成并将其用于邮件上的邮资邮戳的真实性的方法，凭借该方法，包含在邮资邮戳中的密码信息解密，并用来检验邮资邮戳的真实性，其特征在于，数据密钥(KD)生成，从中央付费保险中心(ZinS中央)传输到本地付费保险中心(ZinS本地)，并由后者输入，并且输入结果传输到中央付费保险中心(ZinS中央)，一旦所述的数据密钥(KD)成功地输入到所有的本地付费保险中心(ZinS本地)，该数据密钥(KD)在价值转移中心被释放并用来生成新的邮资邮戳。

2.根据权利要求1所述的方法，其特征在于，所述的数据密钥和前一个数据密钥的结束日期一起传输。

3.根据权利要求2所述的方法，其特征在于，所述的免费密钥传输到一个密码单元，此时该密码单元检查其它数据密钥是否也有结束日期，检查继任的数据密钥所储存的结束日期是否比本地付费保险中心中储存的日期更前。

4.根据权利要求1-3中任意一条所述的方法，其特征在于，所述的数据密钥和生成计数器一起传输。

5.根据权利要求4所述的方法，其特征在于，所述的数据密钥传输到一个密码单元，一旦该密码单元接收所述的数据密钥，它将删除所有与传输的数据密钥具有相同生成计数器值的数据密钥。

6.根据权利要求1-3中任意一条所述的方法，其特征在于，所述的输入结果是以一条数据记录传输。

7.根据权利要求6所述的方法，其特征在于，所述的数据记录包含有一个密钥。

8.根据权利要求1-3中任意一条所述的方法，其特征在于，所述的中央付费保险中心(ZinS中央系统)检查所述的输入结果，并将所述的结果传输给价值转移中心。

9.根据权利要求1-3中任意一条所述的方法，其特征在于，所述的结果用密钥解密进行检查。

10.根据权利要求1-3中任意一条所述的方法，其特征在于，所述的数据密钥是一个对称密钥。

11.根据权利要求1-3中任意一条所述的方法，其特征在于，所述的新数据密钥从价值转移中心向中央付费保险中心传输。

12.根据权利要求1-3中任意一条所述的方法，其特征在于，所述的价值转移中心用传输密钥(KT)对该数据密钥加密。

13.根据权利要求12所述的方法，其特征在于，所述的传输密钥用主传输密钥(KTM)加密。

14.根据权利要求1-3中任意一条所述的方法，其特征在于，所述的数据密钥是在价值转移中心地区生成的。

15.根据权利要求1-3中任意一条所述的方法，其特征在于，所述的数据密钥提供有密钥识别信息。

16.根据权利要求15所述的方法，其特征在于，所述的密钥识别信息以加密形式传输。

17.据权利要求1-3中任意一条所述的方法，其特征在于，所述的数据密钥或至少部分该密钥用来形成生成邮资邮戳的免费密钥的组分。

Images