220。
[0049] 该交换之后，两个端点(客户和服务器)已经收到密钥对(服务器写密钥、客户写密 钥），并且建立安全通道。一旦建立了安全通道，包含密钥的对话参数就会被送到跨层接口 (如附图中的图7所示），并且接着送到传输层，以安全交换信息。除了密钥对，记录加密还要 求服务器初始化向量(Server IV)和客户初始化向量(Client IV)。在示例性实施例中，利 用server_nonce和client_nonce，求得这些初始化向量（IVs)。步骤222中表示生成该IV。一 旦获得包含密钥对和IVs的加密参数，就可以利用传输层安全进行加密消息交换224。
[0050] 因此，利用本公开的确保防止重放攻击的系统可以实现安全对话建立和事务。
[0051] 下面是参考附图中的图3和图5使用的记数法：
[0052] Y:客户与服务器之间的共享保密(Shared secret)
[0053] AES{. }k:利用密钥k对明文进行AES运算
[0054] ?：X0R
[0055] I I:并置
[0056] 参考附图，图3示出了在服务器与客户之间信号交换期间对话建立中所涉及的步 骤。其示出了轻型安全对话建立算法，其中(^代表客户，而S代表服务器。在安全对话建立处 理开始之前，在准备阶段，在离线的匕与3之间共享保密Y={0，1}128。然后，安全对话建立处 理以客户匕将"册1^0，#(^"和11611〇_^11(1发送到服务器3 300的对话启动开始。在此，#(^是 唯一客户设备ID，并且hell〇_rand={0，l}96。启动了对话后，服务器S通过将服务器挑战代 码(exi - fe//o - ra姻?十C _ c| | .semT - )丨} "发送到服务器30 2响应，其中K_c = {0， 1 }128, server_rand = {0，1 }96· ext_hello_rand = hello_rand | | hello_rand[0: 31 ]。客户Ci 对挑战代码解密，并且通过发送另一个挑战代码"AES{ (server_rand | | client_rand) }k_c" 304,做出响应，其中client_rand={0，l}96是客户响应和挑战。在服务器端，服务器检验 c 1 ient_rand，并且通过发送"'仏S{(时 _ _ 層十人二 Λ'|| _ /训i/儿 ^ 出口向应，其中6叉1：_361^1'_瓜11(1 = 361^1'_瓜11(1||361^1'_瓜11(1[0:31].1(_3〇
[0057] 在一个实施例中，可选地将AES加密实现为AES_128_CCM_8。对于每个加密和附加 数据，CCM模式需要 12位随机数。"hello_rand"、"server_rand" 和 "client_rand" 在步骤 302、304和306分别用作要求的随机数值。"附加数据"能够作为应用层协议的每个消息的标 题（ex.CoAP)。
[0058]参考附图，图4示出了用于获得如在传统DTLS记录加密机制中使用的AES加密要求 的服务器和客户初始化向量的示例性方法。本公开的系统使得能够与安全传输层(DTLS)接 口。实际上，接口生成被下面的安全层进行加密消息交换所使用的必需对话参数。对话参数 的基本分量是K_c和K_s。可以以不同方式产生所要求的其他参数。将DTLS记录看作安全传 送消息的示例性机制，在客户和服务器端都需要对话密钥参数元组"{K_c，K_S，Client_IV， SerVer_IV}"。在此，"在此，代表初始化向量。生成IVs存在几种选择。客户和服务器对相同 的参数值采用相同的机制，以确保相同的{Client_IV，Server_IV}对。对于AES_128_CCM，加 密DTLS记录IV为4字节长。图4所示为低计算开销的示例性机制。可以将本公开中公开的安 全对话建立集成为嵌有CoAP的净荷载。将采用可确认(CON)数据传输模式的POST方法应用 于在客户与服务器之间实现安全对话建立。在CoAP标题中引入新字段"AUTH"，使能够实施 安全(认证)模式。该字段利用未使用的指出关键选择类的选项。还与"AUTH"一起引入了另 一个被称为"AUTH_MSG_TYPE"的选项，以指出用于建立认证对话的不同消息。
[0059] 在CoAP消息中，CoAP标题中的任选字段承载可选请求/响应特征。下面是为本公开 定义的字段：
[0060] · AUTH:指出启动认证/关闭认证模式。能够对该字段设定真值或者假值。
[0061] · AUTH_MSG_TYPE:该字段可以是 "0" 或者 "Γ，其中0 = auth_init，而1 = "response-against_challenge'，。
[0062] 对于认证阶段交换的所有关联消息，可以通过利用标题中的常数"令牌环 (Token)"值，在通过设定"AUTH=真"启动时保持认证对话。
[0063] 参考附图，图5示出了在客户与服务器端点之间通过CoAP的对话建立和通过UDP传 输的后续加密消息交换的示例性实施。下面的步骤描述流程：
[0064] ?在启动时，客户将C0N模式下的POST消息发送到专用服务器URI，该专用服务器 URI专用于对话启动。例如，在净荷载400中，具有AUTH= "真"的/some_uri_for_session_ initiation，并且AUTH_MSG_TYPE = auth_init、以及"设备标识符"（DevID)和随机数 "hello_rand"。
[0065] ?服务器从净荷载中获得设备标识符，并且在收到选项"AUTH"以及AUTH_MSG_ TYPE的"auth_init"值后，确定与该设备标识符关联的预共享保密。然后，产生随机数， server_rand作为电话的挑战和客户写密钥K_c402。
[0066] ?服务器利用指出已经创建新资源的响应代码对客户做出回响。该响应中的URI 指出安全对话的对话ID。对于无效设备标识符，服务器发送响应代码"Unauthorized"。步骤 402的加密净荷载可以寄生发送到客户，也可以单独发送到客户。
[0067] ?客户对从服务器收到的响应解密，获得server_rand和"K_c"。客户还通过产生 随机数 Client_rand生成挑战，之后，如在算法1的步骤3中所描述的，利用具有选项字段 "AUTH=true" 和 AUTH_MSG_TYPE 值作为 "response_against_challenge" 并且与最后 POST 消 息中具有相同令牌环值的POST消息，发送净荷载404。
[0068] ?利用"K_c"，服务器对在标题中具有上面提及的任选值的上述POST的净荷载进 行解密，并且校验收到的server_rand。服务器发送校验响应代码"Changed"的响应，以当 s er ver_rand与其先前值(在步骤40 2产生的）相同时，指出资源中的变化被验证，否则，发送 "Unauthorized"。该步骤完成客户验证406。
[0069] ?客户利用Y对来自服务器的响应解密，并且使收到的c 1 i en t_rand与其拥有的拷 贝匹配。此外，客户接收K_s。该步骤完成服务器认证。
[0070] ?一旦对客户和服务器完成认证，服务器就会产生对话密钥元组{K_c，K_s， Client_IV，Server_IV}。如图4所示，实现IV生成。
[0071] ?现在，与DTLS-PSK记录加密类似，客户和服务器可以任选地通过安全传输层通 信。客户利用K_c和Cl ient_IV加密408，服务器利用K_s和Server_IV加密410。
[0072] 步骤400、402、404和406示出了安全对话建立一CoAP，而步骤408和410示出了利用 重放保护的加密消息交换一 DTLS。
[0073] 安全对话建立时的AES加密可以任选地实现为AES_128_CCM_8<XCM模式需要每个 加密的12位随机数和附加数据。"hello_rand"、"server_rand"和"client_rand"分别用作 图3的步骤302、304和306中的要求随机数值。CCM加密要求的"附加数据"可以来自CoAP标题 部。
[0074] 参考附图，图6示出了作为如本公开所公开的安全对话建立结果的不同对话参数 之间的映射以及如传统DTLS记录加密机制要求的对话参数结构。其示出DTLS-PSK记录加密 的对话元组的元素，其中500、502和504代表用于安全对话建立的对话参数。
[0075] 参考附图，图7示出了利用示例性协议在应用层