huaqianzkh的专栏

NIST SP 800-108文档《Recommendation for Key Derivation Using Pseudorandom Functions》是一套详细的指导原则，旨在帮助开发者和安全专家理解并应用密钥推导函数。该文档定义了多种KDF的实现方式，以满足不同场景下的安全需求。这些KDF的实现基于伪随机函数（PRF，Pseudorandom Function），其中最常用的PRF包括HMAC（基于哈希的消息认证码）和CMAC（基于分组密码的消息认证码）。

KDF-HMAC-SHA-256是一个NIST SP800-1的08密钥推导函数（Key Derivation Function， KDF），在反馈模式下使用无初始化向量（Initialization Vector， IV）和无计数器，HMAC-SHA-256为伪随机函数，L字段为MSB-first的32位二进制值。DKGA04应该使用KDF-HMAC-SHA-256算法，其中HMAC在ISO 9797-2中定义，SHA-256在ISO 1 01 1 8-3中定义。表41给出了一个示例的输入参数。

DRN的13位数字在PANBlock中占据12 ~ 0的位置，IIN的3位最低有效数字在PANBlock中占据15 ~ 13的位置；如果IIN的长度不足以填补16位数字，则提取的数字在块内右对齐，并在左侧填充零（例如，对于IIN的600727和DRN的1 2345678903，PANBlock是007271 2345678903）。DRN的11位1在PANBlock中占据10到0的位置，IIN的5位最低有效数字在PANBlock中占据15到11的位置；最高有效位在位置15，最低有效位在位置0。

因此，过期的解码器密钥仍然可以用来加密替换的解码器密钥，以达到更改解码器密钥的目的。KEN中的每个单位对应持续时间2 1 6 -1（65535）分钟，在当前的STS基本日期时间戳被下一个STS基本时间戳取代之前，有2 8（256）个编号为0,1 .255的周期。如果TID的最高8位大于这个KEN，令牌将被拒绝。在实现中，密钥到期的概念仅适用于VDDK、VUDK和VCDK类型的VendingKey值，以及DDTK、DUTK和DCTK类型的DecoderKey值，这些值可以从相应的自动售货密钥类型生成。

该信息由管理系统管理，如果由于任何原因，付款计价器中的KRN与管理系统中记录的供应组最新售货密钥的KRN不一致，则应通过适当更改解码器密钥来纠正这种情况（另见6.5.2.1和C.1 3.2.4）。KRN是一个十进制数字，范围是1、2、..9. SGC、KRN和VendingKey之间的关联是由KMS设置的。支付计价器的解码器密钥与生成它的VendingKey的SGC和KRN相关联。DITK不得与KRN相关联。在任何给定的时刻，一个给定的供应集团的POS中可能不超过9个连续的VendingKey修订。

它改变的类型是父键，改变的类型是子键。为了改变解码器密钥，新密钥（或子密钥）与父密钥一起加密，然后通过密钥更改令牌集加载到支付计量表中。子密钥行指的是密钥更改令牌集密钥管理函数中用于加密解码器密钥类型的允许使用情况。类似地，management和credit行分别详细描述了用于加密其余meter特定管理功能和credit转换功能的解码器密钥类型的允许使用情况。虚线箭头表示可以使用KT的函数，即可以加密或解密的值。其中一个密钥用于加密另一个密钥（如在密钥更改令牌集中），前者称为父密钥，后者称为子密钥。

DCTK值用于支持使用可擦除磁卡令牌载体的付费仪表（即TCT值= 01），并分配给公共供应组。随后，在安装或操作时，必须重新分配给另一个公共供应组的付费仪表可以加载相应的DCTK值，该值已在父DCTK下加密。换句话说，有效的TransferCredit令牌可以被加密或解密，并由在其DKR中包含DCTK并使用磁卡令牌载体的付费表应用（TCT值= 01）。从制造商处购买或修复的带有可擦除磁卡令牌载体（TCT值= 01）的付费仪表可能包含由KMC在DecoderKeyRegister中提供的DCTK值。

在制造或维修时分配给唯一SupplyGroup的付费表可以加载其DUTK值，该值与唯一组相对应，并在父DITK下进行加密。随后，在安装或操作时，必须重新分配给另一个唯一组的付费表可以加载相应的DUTK值，并在父DUTK下加密。上述功能可以通过密钥更改令牌集执行，也可以通过制造商专有的利用密钥更改令牌集的加载机制执行。类似地，DUTK不得用于加密DITK或DCTK，以便以令牌的形式将其转移到付费表。换句话说，有效的TransferCredit令牌可以被加密或解密，并由在其DKR中包含DUTK的付费表应用。

在制造或维修时未分配给通用供应组或唯一供应组的付费仪表不能加载其相应的DCTK或DUTK值。相反，它被分配给每个制造商唯一的默认组，并加载相应的DDTK值。随后，在安装或运行的时候，一个付费表计已经重新进行了分配给另一个特定的SupplyGroup可以加载相应的DUTK或DCTK值，该值在其父DDTK下加密。不得用于解密和接受STS信用转移功能；换句话说，有效的TransferCredit令牌不应被DKR中包含DDTK的付费仪表接受，即TransferCredit令牌已使用相同的DDTK值进行加密。

换句话说，有效的STS转让信用令牌可以由在其密钥寄存器中包含DITK的付费仪表解密和应用，以便于在生产或维修期间测试付费仪表。付费仪表应该只接受制造商提供的密钥更改令牌集格式的dtk下加密的DDTK、DUTK或DCTK。DITK值用于在制造商的场所生产或维修期间初始化DecoderKeyRegister。制造商有责任确保对任何DITK应用适当的安全措施，以便用DITK加密的DDTK、DUTK或DCTK值不会受到损害。在任何情况下，无论是加密的还是明文的，都不可能从支付表中读取或检索DecoderKey值。

给定供应组的VendingKey是用于生成供应组内所有支付仪表的DecoderKey值的种子键。类似地，定义了每个唯一供应组的唯一VUDK值和每个公共供应组的唯一VCDK值。这种类型的密钥用作生成DDTK值的种子密钥——它不能用于生成DITK、DUTK或DCTK值。这种类型的密钥用作生成DUTK值的种子密钥——它不能用于生成DITK、DDTK或DCTK值。这种类型的密钥用作生成DCTK值的种子密钥——它不能用于生成DITK、DDTK或DUTK值。

除DITK值外，VendingKey和DecoderKey值只能由负责令牌生成的设备生成，例如经sts认证的符合sts认证并受sts认证的密钥管理系统约束的POS（见第9条）。本款描述了此类设备使用的密钥生成方法，适用于这些设备的制造商。除DITK值外，STS密钥值只能在负责密钥管理的设备上引入或更改，例如认证为STS兼容的POS，并受STS密钥管理的约束。一个特定的SGC在其运行寿命期间可能同时与一个以上的VendingKey关联，在这种情况下，每个VendingKey应由其关联的KRN识别。

加密算法的密钥块输入由解码器密钥生成算法得到，解码器密钥生成算法使用APDU中SGC、KRN、KT、TI、IIN、DRN DKGA、EA和BDT的当前值生成当前解码器密钥。加密后，按照6.4.2中定义的方法将这2类比特重新插入到64位数字中，得到66位结果，并按照相关物理层协议标准的特定定义填充到TCDU的TokenData字段中；生成的新DecoderKey值的32位部分然后用于替换密钥更改令牌的NKHO、NKMO1、NKMO2或NKLO字段（见APDU提供的6.2.7和6.2.8）；

这是从APDU到TCDU的转换函数（参见图7），适用于所有类别0、类别1和类别2的令牌，但密钥更改令牌除外（参见6.2.7和6.2.8）。1类令牌的传输函数与第0类和第2类令牌的TCDUGeneration函数相同，只是令牌不加密。注2:TCDU中的数据元素定义在与具体TCT相关的IEC 62055-5x系列物理层协议标准中。注1:APDU中的数据元素定义在6.1 .1中。

TCDU可能对每个令牌载体类型不同，因此为与IEC 62055-5x系列的每个部分相关的每个物理层协议标准单独定义。

当目的VendingKey/DecoderKey关联的BaseDate比源VendingKey/DecoderKey关联的BaseDate晚时，Set1stSectionDecoderKey token中的RO位设置为1，否则设置为0。已生成的1个28位DecoderKey（见6.4.4）中第二个最重要的32位，它将通过令牌传输到付费仪表。已生成的1个28位DecoderKey（见6.4.4）中第三个最重要的32位，它将通过令牌传输到付费仪表。这是KEN的低阶4位（见6.1 .10）。

最后的16位包含从前面的50位派生出来的CRC校验和。附加综合试验的可选选择取决于供应商和公用事业公司之间的供应协议，并应构成本文件的规范性部分。CRC是一个校验和字段，用于验证所有令牌传输数据的完整性，除了子类4到7的类0，它使用CRC_C（见6.3.22）。允许的字段值定义在表27中。如果测试是可选的，则应根据供应商和公用事业公司之间的供应协议，将该测试纳入其中，并应成为本文件的规范性部分。如果在单个令牌上指定了多个测试，则付费仪表的行为应由公用事业公司和供应商商定，并应构成本文件的规范性部分。

TransferAmount是编码到令牌的amount字段中并由仪表接收的服务单位或货币单位的数量。TransferAmount的相关单位定义在表17中。STS协会还保留表18中的传输类型，以用于其它用途。

表13中给出的数据元素以各种组合用于令牌中，并且都以二进制格式编码。表 13 令牌所采用的数据。

动作：由制造商定义。因此，这些代币的生成和控制应始终由相关制造商直接管理，并且不得在符合sts的支付计量系统中用于自动售货系统的一般用途。动作：将新的DecoderKey的NKMO1位传输到解码器。有关此令牌的处理，请参见8.9。动作：将新的DecoderKey的NKMO2位传输到解码器。有关此令牌的处理，请参见8.9。动作：将新的DecoderKey的NKHO位传输到解码器。有关此令牌的处理，请参见8.9。动作：将新的DecoderKey的NKLO位传输到解码器。有关此令牌的处理，请参见8.9。

APDU中的TokenData元素是一个66位二进制数，由几个较小数据元素的字段组成，根据这些字段在MeterApplicationProcess中启动各种进程，并将各种信息传送到。有关此令牌的处理，请参见8.9。有关此令牌的处理，请参见8.9。操作：按照控制字段中定义的位模式（见6.3.8）启动支付仪表中的测试或显示功能。操作：用MPL字段中给出的值加载付费电表中的最大功率限制寄存器（见6.3.9）。操作：将信贷转移到支付计量表中金额字段（参见6.3.6）中定义的值和子类字段中定义的服务类型。

KMS将KEN与每个VendingKey关联起来，并定义了VendingKey和任何相应的解码器密钥的过期时间，过期后将失效，以获得某些让步。KEN对应于24位TID的最高8位。任何最高8位大于给定密钥KEN的令牌标识符都不能用该密钥加密或解密。有关该数据元素的详细定义，请参见6.5.2.6。有关管理该数据元素的实践代码，请参见C.3.4。该日期的使用是可选的，并与身份相关数据的有效期相关联，这些数据被编码到携带身份的设备上。例如：支付表ID卡或与令牌数据一起编码到令牌运营商的第二个记录。

和具体费率有关的一个 2 位数字。此数字分配给具体客户。设施服务供应商负责费率表维护和费率表内容。这些值小于 10，其右边可变化，而左边为 0，如 01、02－09。TI 还可以编码到 DecoderKey 中，表示当客户的 TI 号码变成另一个号码，则他们的 DecodeKey 应作更改。参见 6.5.2.1。

这是分配给一个实用程序的唯一的6位十进制数，它在KMS中注册。供应组中的每个支付仪表都有一个从这些vendingkey之一派生的DecoderKey。SGC从VendingKey的KT属性继承其类型（参见6.5.2.2.1），它与该属性相关联，如表8所示。一个特定的SGC可以在SGC的运行生命周期同时继承一个以上的KT。这是一个 2 位号码，可唯一性地识别令牌载波器的类型。这是一个2位数，用于唯一地标识用于生成解码器密钥的算法。小于10的值应该右对齐，左填充0（例如01,02-09）。

IIN 原来的目的是用来标识财务交易，以便唯一性地进行识别，使交易记录到适当的交易财务的账户中。但是，这被证明不可行的。自那时候起，IIN 的 600727 值成为事实标准，并在世界上广泛应用在所有标准传输规格兼容的用电式的付费计量系统上。因此，在用电标准传输规格兼容系统的应用上，对于本标准的目的， IIN 应是 600727。计算PANCheckDigit值的方法由ISO/IEC 781 2-1:2006的4.4给出，由IIN值和IAIN值拼接得到的MeterPAN的前17位进行计算。

在令牌被编码到载波器上的同时，该数据可打印。有些令牌载波器，例如纸质磁卡设备，可允许在卡表面上打印，并且这种操作可集成于磁卡编码设备上。系统可根据具体要求来规定。KeyExpiryNumber VendingKey 和 DecoderKey 相关的号码。指引应用哪个 TokenCarrierType 于物理层协议使令牌送到电表上。该数据被编码到付费电表 IC 卡或令牌载波器上（带令牌）加密和处理以前，此数据被传输到付费电表。指引用哪个加密算法对令牌数据加密。和应用层协议之间的数据介面，并由表。

PrimaryAccountNumber(PAN)，在 ISO/IEC7812-1 中有所定义，标识交易记录、信息、请求、授权和通知，其 中交易双方可以唯一被识别。以令牌为基础的交易（见第 3 节）是一种财务活动，需要遵循标准财务惯例。ISO 交易参考号码的组成包括数据元素及其关系，见图 5。它用于定义付费电表功能（标准化），并采 用面向对象的方法。

对于某些类型（例如高速虚拟令牌载波器），物理层协议可以采用令牌进入锁定功能，以保护付费电表避免作弊行为。在普通情形下，这种锁定功能可能会降低有效速率，这时令牌进入应通过特殊令牌载波器介面（例如见 IEC62055-52。其它类型连接器可以要求支持其它类型令牌载波器，例如内存 KEY 阅读器和插入式连接器（手持装置 中），它们可作为虚拟令牌载波器。发送指令给物理层协议，以便完成令牌进入过程，其中所采用方式是删除令牌数据（如合适），或其它相关数据写回到TokenCarrier 中（如合适）。

被传送到付费电表上（通常是由客户传送）。当它进入付费电表时，将通过 TokenCarrierInterface。编码到 TokenCarrier 上。可选择的情况是，付费电表识别数据也可被编码到。PosApplicationProcess 向 APDU。出示令牌，同时它将用于令牌加密。应用层 协议产生 DecoderKey。重要的是，此过程部分通过 TokenCarrier。），同时打印文本可编码到外部表层（例如见。上的数据编码而结束。

标准传输规格是一个 POS 和付费电表之间的安全传输协议，并采用令牌载波器作为传输介质。应用层协议 涉及令牌、加密过程和函数，同时物理层协议涉及令牌载波器上令牌数据的实际编码。在本标准中，标准传输规格定义了单向数据传输协议（例如从 POS 到付费电表），虽然参考模型也适用于双向传输协议。在本标准中，虽然采用了折叠式 2 层 OSI 结构，但是它可容许未来的扩展，包括需要更多层，以及在此模型所示的二层之间加入其它层。在单体付费电表中，所有重要功能分布在单一装置上。

Decoder ReferenceNumber [known as a “meter number” in systems in use prior to the development of this document] 解码器参考号码（此标准制订之前，系统使用中也称为“电表号码”）Standard Transfer Specification Association 标准传输规格协会。Vending Unique Derivation Key 销售唯一数据加密标准钥匙。

定时器： 时间信息计数和为对其他功能提供参考信号。例如：为微处理器提供时钟信号，表具的运行寿命计算，预期事件的终止，显示值得显示时间。备用：当预付费表没有连接到电源电压期间提供维持计时运行的手段。时间功能的持续日期、时间信息和时间参考信息供其他功能使用。持续日期、时间信息与实际日期和时间同步，并且可用做备用。时间参考记录： 例如：时区、夏令时起始日期、结束端日期和偏差。定时记录：持续时间：几天、几小时、分钟、秒钟、几百。时间记录： 时刻：小时、分钟、秒钟、百毫秒。日期记录： 日期： 年、月、日、周。

例如：直接连接到付费表计的负荷端，用户直接将负荷插到表计的输出插座上，一个外接负荷开关（单或多相）连接到负荷端，负荷开关被预付费表中的继电器控制。专门的负荷开关有自动和手动恢复功能，在某些条件使用自动恢复，其他情况下使用手动恢复。交付功能首先处理和用户负荷线路的电能交付相关的功能。根据检测功能定义的规约，交付功能处理供电部门到负荷的中断。监视和检测其他功能的属性状态的变化，从而中断或恢复负荷。不需要用户的干预，交付功能处理供电部门到负荷的自动恢复。根据检测功能定义的规约交付处理供电部门到负荷的恢复。

每一个收费功能都有一个寄存器，代表一个发生的和交易过的费用，该寄存器与详细情况和收费功能类型保持一致。例如：一个多费率的表计对应每一个费率就应该有一个该费率的寄存器，每个寄存器存储每月的对应每个费率的费用。每一个信用度功能都有一个寄存器，代表一个发生的和交易过的信用度，该寄存器与详细情况和信用度功能类型保持一致。计费功能维持了预付费表计中信用度和付费交易的现金平衡。衡量一定时间内通过表计计费过程进行的历史信用度和消费交易，包含未决的信用度和费用。规定计费功能是基于金钱的还是基于单位的。

应注意在付费电表中一个特定的部件可能会用于实现一个或多个功能，反之，一个特定的功能会涉及到很多部件。这样，没有一个明确的规则来描述功能和部件之间的关系，其关系可能是一对一、一对多或多对一。Charge功能和Credit功能在图7中是独立的两个功能，这样是为了更清楚，实际上它们是Accounting功能的子功能。图六给出了独立付费电表的功能方框图，指出了核心功能（见 13.7.1 到 13.7.5）和支持功能（没有进一步详细讨论）。一个特定的宏过程甚至可能由更小的过程或一组更小的过程和功能组成。

物理 token 的例子是: 印在纸上的的数字, 磁卡上的磁性代码, 印在纸上的条形码, 可记忆的电子存储卡类似智能卡和钥匙,被记录下的声音信息。虚拟 token 例子是: PLC 调制解调器, PSTN 调制解调器, GSM 调制解调器, 收音机, 调制解调器、红外线的光学联结、区域网络,广域网, 本地直接连接, 等等。

一个POS可以使用本地数据库 (脱机的) 操作，或者使用远端在线数据库（客户/伺候器模态）操作。与以物理的TOKEN 载体为基础的系统不同，一些系统可以建立以虚拟的TOKEN 载体为基础的POS操作和接口系统。在下面表13显示POS功能的例子。表 13 例子的 POS 功能。

一个实体说明应该明确实现的功能和相关的接口。系统主要实体包括: CIS（用户_信息_系统）, 售电点；表计, Token 字和系统用户。接口允许这些个体之间进行数据和信息的交换。Examples of typical interfaces are:典型接口事例:付费表计用户接口允许用户与预付费表计互相影响，相互作用。这个典型接口元素包括: 显示(LCD, LED, 标签, 标号), 按钮和手柄;

这样的面向对象型数据库设计就是非常好的,因为经过对关系仔细的考虑，它可以非常有效地建立预付费系统，并且使操作过程的处理更加简单和容易处理，使数据错误相应减少。数据元素可能被分组到一条记录或者一个记录表，在关系型数据库条件下，这些表相互关系，相互连接，并且指定在记录中的哪些数据元素和另外表中哪些数据元素相关联；在一个标准数据库中,一个特殊数据元素将首先记录在整个数据库唯一的一条记录中，尔后, 它。总之, 在预付费系统中的所有个体安全通过分配唯一的标志符和分配只读或读/写数据元素的存。取权限，实现控制目的。

功能目标是一个抽象的功能属性的定义，功能目标的定义应该用以下属性（Name名称、Class类型、Data_Elements数据单元、Methods方法、Operation操作、Association联系）。