针对受约束资源设备的密钥建立的制作方法_2

文档序号:9602825阅读:来源:国知局
束RD包括:生成单元,被配置为基于所导出的第一秘密密钥,生成数字签名。所述受约束RD包括:确定单元,被配置为确定所接收的数字签名是否等于所生成的数字签名。所述生成单元还被配置为:如果所接收的数字签名等于所生成的数字签名,则推断所导出的第一秘密密钥等于所述AS的第一秘密密钥,并且所接收的所述请求的标识符等于由所述AS确定的所述请求的标识符。
[0023]本发明的实施例的优点在于,不需要通过由受约束资源设备发送或接受任何附加消息来使得能够更新访问控制列表。
[0024]本发明的实施例的另一优点在于,可使用较小的成本采用灵活访问控制模型并且只根据由受约束RD进行的处理采用。
【附图说明】
[0025]将参照以下附图详细地描述实施例,其中:
[0026]图1是根据现有技术的针对客户端-服务器关系的信令图;
[0027]图2A和2B示意性地示出了已知协议架构;
[0028]图3和4示出了根据本发明的实施例的方法的流程图;
[0029]图5示出了本发明实施例的信令图;
[0030]图6和8示意性地示出了根据本发明的实施例的授权服务器;以及
[0031]图7和9示意性地示出了根据本发明的实施例的受约束资源设备。
【具体实施方式】
[0032]以下,将参照附图更详细地描述本发明的不同实施例。为了解释而不是限制的目的,阐述了诸如特定示例和技术等的具体细节,以便提供对透彻理解。
[0033]如上所述,限制对预先规定的可信用户的访问并不灵活,这是由于任何客户端或用户将不得不在受约束资源设备中预先规定,以使其能够访问受约束资源设备。这实在是一大缺陷。
[0034]为了不限于预先规定的可信客户端,在为新客户端许可访问的过程中引入可信第三方(TTP),而不用重新规定受约束资源设备。代表设备的拥有者的TTP自然地具有与受约束资源设备的信任关系。该信任关系可通过共享密钥或交换认证公共密钥的形式记载。
[0035]受约束资源设备和TTP之间所建立的信任关系可用来以更为灵活的机制为新客户端许可访问。
[0036]然而,非预先配置的客户端的配置将增加多个附加消息交换和设备处理,以建立受约束资源设备的访问控制列表中的新授权客户端的标识符/密钥。这可导致设置时间延长和能耗增加。
[0037]从而,还需要将为了建立可信客户端设备而进行的消息交换的数量和由受约束资源设备进行的处理最小化。
[0038]通过将访问控制列表更新集成到认证协议中,并且通过使用基于受约束RD和授权服务器(AS)之间的共享的秘密密钥的秘密密钥,不需要在认证协议中发送任何附加消息。
[0039]基于在受约束RD和AS之间共享的秘密密钥,受约束RD能够基于握手协议消息上所承载的信息,导出在客户端设备和受约束RD之间共享的秘密密钥。
[0040]从而,在认证协议期间更新了受约束RD的访问控制列表。
[0041]在受约束RD具有与AS共享的秘密密钥并且AS与客户端设备相关联的情况下,受约束RD将能够与任意客户端设备进行通信。
[0042]从而,AS和受约束RD共享密钥K。受约束RD和客户端设备不共享密钥,它们甚至没有意识到彼此的存在。
[0043]为了示出本发明的实施例,现在讨论图5。
[0044]图5示出了受约束RD 502,AS 504和客户端设备506之间为了建立在客户端设备和受约束RD 502之间共享的第一秘密密钥的信令的信令图。AS与客户端设备相关联。受约束RD、AS和客户端设备可属于相同或不同的通信网络。在508中,受约束RD和AS共享第二秘密密钥。该第二秘密密钥可在制造受约束RD 502和AS 504时安装。通常,它是在继续到510等之前共享的。
[0045]在510中,客户端设备发送针对到约束的密钥的请求,其中所述请求发送到AS504。该请求可包括客户端设备标识符。
[0046]在512中,AS 504确定所述请求的标识符。所述请求的该标识符可以基于客户端设备标识符确定。
[0047]所述请求的标识符可包括随机数(nonce)。如果所述请求的标识符被用作针对AS和受约束RD之间的加密数据的完整性保护通道,则数据将看起来是随机的,并且因此可以用作随机数。如果所述请求的标识符用作用于传输随机数据的通道,则在没有任何固有含义的情况下,随机数据也可用作随机数。
[0048]在514中,AS 504基于所述请求的所确定的标识符和所述第二秘密密钥RD,生成第一秘密密钥。
[0049]在516中,AS发送将所生成的第一秘密密钥和所述请求的所确定的标识符发送到客户端设备506。为此目的,AS通常使用到客户端设备506的安全或加密连接。
[0050]在518中,客户端设备向受约束RD 502发送“client hello”消息,作为4-传递握手协议(比如DTLS协议)的消息。
[0051]在520中,受约束RD 502在“server hello”消息中答复客户端设备506,该消息是4-传递握手协议的另一消息。
[0052]在522中,客户端设备506基于在516中所接收的第一秘密密钥生成数字签名。该数字签名可以是消息认证码(MAC)。
[0053]在524中,客户端设备506将在516中从AS接收的数字签名和所述请求的标识符发送到受约束RD 502。数字签名和所述请求的标识符可在“client finished (客户端完成)”消息中发送到受约束RD 502。备选地,可在不同的消息中发送它们,比如可在“clienthello”消息中发送所述请求的标识符(如上述518),可在“client finished”消息中发送数字签名(如524)。
[0054]所述请求的标识符可嵌入各种消息字段。嵌入所述请求的标识符的一个选项是重新使用现有的TLS或DTLS消息字段,比如“client hello”的“随机”或“会话标识(ID) ”字段,或“client key exchange (客户端密钥交换)”的“预先共享密钥(psk)标识”。另一选项是使用TLS扩展,其中可定义定制数据结构并与TLS —起发送。一种TLS扩展可包括所述请求的标识符,并可选地包括授权服务器的标识符或由授权服务器用于导出客户端设备和RD之间共享的第一秘密密钥的秘密密钥。
[0055]TLS扩展的另一用处是将所述请求的标识符嵌入授权声明中,所述授权声明承载在TLS授权扩展的“补充数据”中。
[0056]在526中,受约束RD 502基于所述请求的所接收的标识符和与AS 504共享的所述第二秘密密钥,导出第一秘密密钥。
[0057]在528中,受约束RD 502使用所导出的第一秘密密钥验证数字签名。这可通过以下操作来执行:基于所导出的第一秘密密钥,生成406数字签名,以及确定408所生成的数字签名是否等于在524中所接收的数字签名。
[0058]如果在528中验证了所述数字签名,或备选地,如果确定所生成的数字签名等于所接收的数字签名,则受约束RD 502推断所导出的第一秘密密钥等于所述AS生成的第一秘密密钥。所述受约束RD 502还可推断在524中所接收的所述请求的标识符等于由所述AS 504在512中确定的所述请求的标识符。根据510中的客户端设备的请求,在受约束RD502和客户端设备506之间建立了秘密密钥。从而,该秘密密钥还可在认证协议(比如TLSSdtls)期间建立。备选地,还可使用其他4-传递认证协议,例如互联网密钥交换(ike),在此期间,在受约束RD和客户端设备之间建立秘密密钥。
[0059]如果不能验证所述数字签名,或备选地,如果确定所生成的数字签名不等于所接收的数字签名,则不能在受约束RD 502和客户端设备506之间建立任何秘密密钥,并且不再执行任何其他操作。
[0060]参考图3,现在将描述根据本发明的实施例的用于使得能够建立在受约束RD和客户端设备之间共享的第一秘密密钥的方法的流程图。所述方法是在具有与受约束RD共享的第二秘密密钥的AS中执行的,其中所述AS与客户端设备相关联。所述方法包括从客户端设备接收32针对在受约束RD和客户端设备之间共享的第一秘密密钥的请求。所述方法还包括基于从客户端设备接收的请求,确定34所述请求的标识符,以及基于所述请求的所述标识符和所述第二秘密密钥生成36第一秘密密钥,其中所述第一秘密密钥与所述请求的标识符相关联。此外,所述方法包括向客户端设备发送38所述请求的标识符和所生成的第一秘密密钥,从而使得客户端设备能够生成将要在与受约束RD的通信中使用的数字签名,使得能够建立在受约束RD和客户端设备之间共享的第一秘密密钥。
[0061]针对第一秘密密钥的请求可包括客户端设备标识符,并且所述方法还可包括:基于所述客户端设备标识符认证客户端设备。
[0062]所述确定所述请求的标识符还可以基于客户端设备标识符。
[0063]同样,所述请求的标识符可包括客户端设备标识符,其还使得受约束RD能够认证客户端设备。
[0064]所述请求的标识符可包括针对客户端设备的访问信息,其还使得受约束RD能够对客户端设备对受约束RD的访问进行授权。
[0065]所述用于使得能够建立第一秘密密钥的方法中的所述请求的标识符可包括随机数。如果所述请求的标识符被用作针对AS和受约束RD之间的加密数据的完整性保护通道,则数据将看起来是随机的,并且因此可以用作随机数。如果所述请求的标识符用作用于传输随机数据的通道,则在没有任何固有含义的情况下,随机数据可用作随机数。
[0066]所述用于使得能够建立第一秘密密钥的方法可在认证协议内执行。
[0067]其中执行所述用于使得能够建立第一秘密密钥的方法的认证协议可包括传输层安全性(TLS)协议或数据报传输
当前第2页1 2 3 4 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1