用于将客户端设备与网络相连的系统和方法

用于将客户端设备与网络相连的系统和方法
【专利摘要】本发明提供了一种用于使客户端设备能够与网络相连的系统和方法。所述方法包括：通过不同于网络的通信信道获得授权码，所述授权码与所述客户端设备相对应；以及在检测到由所述客户端设备发起安全协商协议之后，将所述授权码用于至少一个安全协商操作。
【专利说明】用于将客户端设备与网络相连的系统和方法

【技术领域】
[0001] 下文涉及用于将客户端设备与网络相连的系统和方法。

【背景技术】
[0002] 在网络环境中，希望加入网络的客户端设备首先发现网络，然后加入所发现的网 络。通常由路由器、服务器或其他网络控制器或接入设备（下文中，称作"信任中心"）来执 行针对网络的接受。在一些网络环境中，加入网络并且通过网络进行通信的客户端设备使 用少量用户接口或不使用用户接口来进行操作。尽管这种客户端设备的接口有限，然而客 户端设备应当能够不仅加入网络，而且加入正确网络。类似地，信任中心应当能够只允许可 接受的客户端设备加入其网络。
[0003] 诸如家域网（HAN)等的网络可以将安全协商协议（例如传输层安全（TLS)协议或 其前身（安全套接层（SSL)协议））用作该网络的基本安全协议。TLS协议是提供通信私密 性和数据完整性并且允许客户端/服务器应用以设计为防止或禁止窃听、篡改和消息伪造 的方式进行通信的公知通信协议。
[0004] 在使用TLS或SSL协议的环境（包括向客户端设备预配置数字证书（下文中，"证 书"）的环境）中，可能难以向正在加入的客户端设备指示它应当加入哪个网络和信任中 心。还可能难以提取来自正在加入的客户端设备的信息并且访问信任中心以限定哪些客户 端设备应当加入。通常将这种困难称作"操纵问题（steering problem)"。
[0005] 为了解决操纵问题，典型模型在于向信任中心提供与将加入网络的客户端设备有 关的少量标识信息。通常，标识信息应具有允许人们通过终端或键盘容易输入的形式。一 旦该信息在信任中心是已知的，信任中心就进入"允许加入"模式。此时，经验证的正在加 入的客户端设备可以证明它是与标识信息相关联的设备，并且被允许加入网络。
[0006] 该模型的安全问题在于：欺诈信任中心可以在混杂模式下接受加入，从而欺骗正 在加入的客户端设备加入错误网络。另一安全问题在于：欺诈客户端设备可以在允许加入 阶段期间和在预期设备能够加入之前尝试通过信任中心加入网络。


【发明内容】

[0007] 在一个方面，提供了一种使客户端设备能够与网络相连的方法，所述方法包括：通 过不同于网络的通信信道获得授权码，所述授权码与客户端设备相对应；以及在检测到由 客户端设备发起安全协商协议之后，将所述授权码用于至少一个安全协商操作。
[0008] 在另一方面，提供了一种与网络相连的方法，所述方法包括：客户端设备发起与网 络的服务器设备的安全协商协议；以及将授权码用于至少一个安全协商操作，所述授权码 已经通过不同于网络的通信信道提供给服务器设备，所述授权码与客户端设备相对应。
[0009] 在另一方面，提供了一种使客户端设备能够与网络相连的方法，所述方法包括：通 过不同于网络的通信信道向客户端设备提供授权码，所述授权码与客户端设备相对应；以 及在检测到由客户端设备发起安全协商协议之后，将所述授权码用于至少一个安全协商操 作。
[0010] 在另一方面，提供了一种计算机可读存储介质，包括用于使客户端设备能够与网 络相连的计算机可执行指令，所述计算机可执行指令包括用于以下操作的指令：通过不同 于网络的通信信道获得授权码，所述授权码与客户端设备相对应；以及在检测到由客户端 设备发起安全协商协议之后，将所述授权码用于至少一个安全协商操作。
[0011] 在另一方面，提供了一种计算机可读存储介质，包括用于与网络连接的计算机可 执行指令，所述计算机可执行指令包括用于以下操作的指令：客户端设备发起与网络的服 务器设备的安全协商协议；以及将授权码用于至少一个安全协商操作，所述授权码已经通 过不同于网络的通信信道提供给服务器设备，所述授权码与客户端设备相对应。
[0012] 在另一方面，提供了一种计算机可读存储介质，包括用于使客户端设备能够与网 络相连的计算机可执行指令，所述计算机可执行指令包括用于以下操作的指令：通过不同 于网络的通信信道向客户端设备提供授权码，所述授权码与客户端设备相对应；以及在检 测到由客户端设备发起安全协商协议之后，将所述授权码用于至少一个安全协商操作。
[0013] 在另一方面，提供了一种包括处理器和存储器的服务器设备，所述存储器包括计 算机可执行指令，所述计算机可执行指令用于通过操作所述处理器执行以下操作来使客户 端设备能够与网络相连：通过不同于网络的通信信道获得授权码，所述授权码与客户端设 备相对应；以及在检测到由客户端设备发起安全协商协议之后，将所述授权码用于至少一 个安全协商操作。
[0014] 在另一方面，提供了一种包括处理器和存储器的服务器设备，所述存储器包括计 算机可执行指令，所述计算机可执行指令用于通过操作所述处理器执行以下操作来使客户 端设备与网络相连：通过不同于网络的通信信道向客户端设备提供授权码，所述授权码与 客户端设备相对应；以及在检测到由客户端设备发起安全协商协议之后，将所述授权码用 于至少一个安全协商操作。
[0015] 在另一方面，提供了一种包括处理器和存储器的客户端设备，所述存储器包括计 算机可执行指令，所述计算机可执行指令用于通过操作所述处理器执行以下操作来与网络 连接：发起与网络的服务器设备的安全协商协议；以及将授权码用于至少一个安全协商操 作，所述授权码已经通过不同于网络的通信信道提供给服务器设备，所述授权码与客户端 设备相对应。

【专利附图】

【附图说明】
[0016] 现在将参考附图仅通过举例说明的方式描述实施例，在附图中：
[0017] 图1是包括网络环境的通信系统的示意图；
[0018] 图2是包括家庭网络的通信系统的示意图；
[0019] 图3是示出了网络环境中的客户端设备的配置的示例的框图；
[0020] 图4是示出了网络环境中的信任中心的配置的示例的框图；
[0021] 图5是示出了网络环境中使用的互联网协议（IP)栈的框图；
[0022] 图6是示出了计算机可执行操作的集合的示例的流程图，其中可以执行所述计算 机可执行操作的集合以通过带外信道向信任中心提供授权码（AUTOCODE);
[0023] 图7是示出了计算机可执行操作的集合的示例的流程图，其中可以执行所述计算 机可执行操作的集合以使用AUTOCODE来执行TLS握手；
[0024] 图8是示出了计算机可执行操作的集合的示例的流程图，其中可以执行所述计算 机可执行操作的集合以使用AUTOCODE来执行TLS握手；
[0025] 图9是示出了计算机可执行操作的集合的示例的流程图，其中可以执行所述计算 机可执行操作的集合以使用AUTOCODE来执行TLS握手；
[0026] 图10是示出了计算机可执行操作的集合的示例的流程图，其中可以执行所述计 算机可执行操作的集合以使用AUTOCODE来执行TLS握手；
[0027] 图11是示出了计算机可执行操作的集合的示例的流程图，其中可以执行所述计 算机可执行操作的集合以使用AUTOCODE来执行针对TLS的密钥材料导出（key material exporter)；
[0028] 图12是示出了计算机可执行操作的集合的示例的流程图，其中可以执行所述计 算机可执行操作的集合以在TLS建立之后验证AUTOCODE ;以及
[0029] 图13是示出了计算机可执行操作的集合的示例的流程图，其中可以执行所述计 算机可执行操作的集合以使用AUTHC0DE来执行经修改的TLS建立。

【具体实施方式】
[0030] 应认识到，为了使阐述简单和清楚，在认为适当的情况下可以在附图中重复附图 标记以指示相应或相似的元素。此外，阐述了大量具体细节以便提供对这里所述示例的全 面理解。然而，本领域普通技术人员应理解，可以在没有这些具体细节的情况下实践这里所 述的示例。在其他实例中，未详细描述公知的方法、过程和组件以免混淆这里所述的示例。 此外，不应认为该描述限制这里所述示例的范围。
[0031] 应认识到，这里所使用的示例和相应附图仅用于说明的目的。可以在不脱离这里 所述原理的情况下，使用不同的配置和术语。例如，可以添加、删除、修改或用不同连接排列 组件和模块，而不脱离这些原理。
[0032] 为了解决提供通信安全的网络环境中的操纵问题，在信任中心和正在加入的客户 端设备二者中建立针对特定客户端设备的授权码（AUTHC0DE)，并且将AUTHC0DE并入在相 应的正在加入的客户端设备与信任中心之间的安全协商中使用的至少一个操作。AUTHC0DE 使信任中心能够识别正确的正在加入的设备并且使正在加入的设备能够识别正确的信任 中心，从而确保它们加入了正确网络。
[0033] 应认识到，以下所述的原理可以用于多种安全协商协议，其中可以在带外将 AUTHC0DE提供给信任中心，并且可以将这种AUTHC0DE用于由基本安全协商协议使用的 至少一个密码操作。示例包括但不限于多种TLS协议版本，包括前身SSL版本和数据报 TLS(DTLS)、IPSec等。这里所提供的多种示例在使用TLS或SSL协议版本（下文中，为了 说明目的，称作"TLS协议"）的网络环境中说明了这些原理。
[0034] 在一个示例性场景中，客户端设备可以与信任中心建立TLS会话，其中客户端设 备和信任中心具有彼此识别的来自证书管理中心（CA)的经验证的签名密钥（例如，椭圆曲 线数字签名算法（ECDSA)签名密钥）。在接受会话之前，向信任中心提供带外的AUTHC0DE。 将要在加入阶段期间使用的TLS协议修改为利用AUTOCODE。在这种场景下，假定合法的信 任中心和每个合法的客户端设备以及任何欺诈客户端设备具有或者另外能够具有包含适 于ECDSA签名的公钥的有效证书并拥有相应的私钥。还假定所有正在加入的客户端设备具 有相关联的AUTOCODE。可以以多种方式将AUTOCODE提供在客户端设备上或提供给客户端 设备等，包括将其印刷在设备外部（例如，壳体背面）、相关包装材料中等。AUTOCODE是打 算在带外提供给信任中心而不通过加入的网络来进行传输的随机产生值。
[0035] 现在参考图1，示出了包括局域网12的网络环境10。通过信任中心14管理至少 一些设备对局域网12的接入。可以认识到，信任中心14可以表示任何路由器、服务器或其 他网络控制器、或负责允许或拒绝客户端设备接入局域网12的接入设备。在图1所示的示 例中，示出了两种客户端设备，即，已注册的客户端设备16和正在加入的客户端设备18。已 注册的客户端设备16包括已经通过向信任中心14进行注册成功加入局域网12的客户端 设备。正在加入的客户端设备18包括正试图通过向信任中心14进行注册加入局域网12 的客户端设备。可以认识到，正在加入的客户端设备18可以包括合法客户端设备和欺诈客 户端设备二者。
[0036] 已注册的客户端设备16和正在加入的客户端设备18都包括AUTHC0DE20,可以从 设备本身（例如，从设备的外部）确定所述AUTHC0DE20。为了将AUTHC0DE20用于至少一 个TLS操作，在正在加入的客户端设备18与信任中心14之间建立带外信道22。尽管将带 外信道22示出为在网络环境10内，然而，还可以将带外信道22建立在网络环境10的外 部。带外信道22可以包括例如由信任中心14提供的用户接口，该用户接口能够实现向信 任中心14、或由信任中心14控制的或另外信任中心14可访问的数据库或存储器手动输入 AUTHC0DE20。还可以使用与和信任中心14相关联的管理员26的基于电话或web的连接建 立带外信道22,从而当试图向局域网12添加正在加入的客户端设备18时使正在加入的客 户端设备18的用户能够提供AUTHC0DE20。这样，管理员26可以通过诸如如图1所示的广 域网24等的外部网络，向信任中心14下推AUTHC0DE20。管理员26或信任中心14或管理 员26和信任中心14二者还可以通过广域网24与证书管理中心（CA) 28进行通信，以获得 例如在TLS协议中使用的证书。在使用证书的情况下，已注册的客户端设备16和正在加入 的客户端设备18还包括经验证的签名密钥，因此还可以通过广域网24与CA28进行通信。 可以认识到，在其他示例中，客户端设备16、18可以不使用从CA28获得的证书。例如，客户 端设备16、18可以利用自签名的证书或未签名的公钥，并且可以将AUTHC0DE20用于向信任 中心14认证这种客户端设备16、18。
[0037] 图2示出了网络环境10的示例。图2示出了例如针对智能家庭系统或高级计量 基础设施（AMI)的包括家域网（HAN) 12'的家庭环境10'。通过被管理的服务门户14'控 制该示例中的HAN12'，其中被管理的服务门户14'允许已进行公共设施注册的客户端设 备（utility registered client device) 16'与HAN12'进行通信，并且允许或拒绝正在 进行公共设施加入的客户端设备（utility joining client device) 18'的接入。客户端 设备16'、18'可以包括例如电子温控器、大型家用电器、HVAC系统等。与上述内容相似，客 户端设备16'、18'包括AUTHC0DE20并且通过带外信道22'向被管理的服务门户14'提供 AUTHC0DE20。被管理的服务门户14'通过公共设施AMI网络24'与公共设施后端服务器 26'进行通信。公共设施后端服务器26'负责与被管理的服务门户14'进行通信，并且传送 与正在进行公共设施加入的设备18'有关的信息并发起用于添加这种正在加入的设备18' 的加入周期。公共设施后端服务器26'还可以与CA28'进行通信，以获得公共设施所使用 的被管理的服务门户14'的经验证的签名密钥。被管理的服务门户14'还可以安装有已通 过采购实践（procurement practice)存储在其中的证书。然后，公共设施后端服务器26' 可以查找加入被管理的服务门户14'的正在进行公共设施加入的设备18'的签名/标识信 息，以确保还未撤销证书。
[0038] 图3示出了客户端设备16、18的配置的示例。客户端设备16、18包括主体、壳体 或提供外表面30的其他物理部分，可以将AUTHC0DE20印刷在外表面30上或以其他方式使 AUTHC0DE20对用户是可见的。客户端设备16、18还包括局域网接口 32,以使处理器34能 够例如使用TLS协议36与局域网12进行通信。如图3所示的TLS协议36表示操作处理 器34以使客户端设备16、18能够参与TLS操作（例如，TLS握手、TLS应用阶段等）的任 何计算机可执行指令。客户端设备16、18还包括用于存储数据的存储器38。在该示例中， 存储器38存储客户端设备16、18的私钥/公钥对（c，C)和信任中心14的公钥T。存储器 38还存储AUTHC0DE40的电子版本或表示，以使印刷在客户端设备16、18的外表面30上的 AUTHC0DE20能够用于TLS操作。
[0039] 图4示出了信任中心14的配置的示例。该示例中的信任中心14包括：处理器50 ; 局域网接口 52,用于通过局域网12进行通信；以及广域网接口 54,用于通过广域网24进行 通信。可以认识到，仅为了说明目的，将局域网接口 52和广域网接口 54示出为单独组件， 并且可以使用单个网络接口模块。处理器50有权访问TLS协议56并且有权访问存储器 58。存储器58存储信任中心14的私钥/公钥对（t，T)。存储器58还存储客户端设备16、 18的公钥C，通常在执行安全协商协议期间例如使用证书将公钥C提供给信任中心14。信 任中心14还包括或者另外有权访问客户端设备AUTOCODE数据库60,客户端设备AUTOCODE 数据库60用于存储已注册的客户端设备16和那些利用带外信道22正在加入的客户端设 备18的AUTHC0DE40的电子版本或表示。
[0040] 现在参考图5,在500,可以通过使用带外信道22从客户端设备16、18向信任中 心14提供AUTHC0DE20,来使用AUTHC0DE40修改TLS协议。例如，当用户希望向局域网12 添加新的正在加入的客户端设备18时，可以访问由信任中心14提供的用户接口，并且将 AUTHC0DE40的表示输入该用户接口。然后，在502,正在加入的客户端设备18可以发起与 信任中心14的TLS会话。然后，在504,将由正在加入的客户端设备18存储的AUTHC0DE40 用于一个或多个TLS操作，下文提供了其示例。假定信任中心14已经成功地获得并使用了 存储在AUTOCODE数据库60中的相同AUTHC0DE40,则在506,允许正在加入的客户端设备18 使用已建立的安全信道接入局域网12,此后信任中心14将正在加入的客户端设备18视作 已加入的客户端设备16,从而提供对例如网络资源等的访问。类似地，已加入的客户端设备 16现在确保已加入的客户端设备16已经加入了正确的信任中心14。
[0041] 图6示出了操作集合的示例，该操作集合可以执行以使信任中心14和正在加入的 客户端设备18能够参与TLS握手。CA28在600产生针对信任中心14的证书并且在602 向信任中心14提供该证书，并且在604,信任中心获得该证书。可以认识到，操作600-604 是可选的，这取决于是否使用证书，并且可以使用任意适合的证书实现过程（可以包括证 书撤销检查或证书验证）来提供向信任中心14颁发的证书。在606,将正在加入的客户端 设备18引入网络环境10,并且在608,确定在正在加入的客户端设备18的外表面30上提 供的AUTHC0DE20。在610,建立带外信道22,在612,由信任中心14启用带外信道22。例 如，信任中心14可以提供基于浏览器的用户接口，以使得能够输入AUTHC0DE20。在614， 提供AUTHC0DE20,并且在616,由信任中心14接收AUTHC0DE20。在618,信任中心14将 AUTHC0DE40的表示存储在AUTOCODE数据库60中。然后，在620,信任中心14发起针对与 所存储的AUTHC0DE20相关联的正在加入的客户端设备18的允许加入阶段。一旦已经发起 允许加入阶段，正在加入的客户端设备18就可以在622发起TLS会话，并参与TLS握手以 便注册正在加入的客户端设备18。在624,信任中心14也参与TLS握手。
[0042] 图7示出了计算机可执行操作的集合，该计算机可执行操作集合可以由正在加 入的客户端设备18或信任中心14执行以使用通过带外信道22提供给信任中心14的 AUTHC0DE40。在700,从存储器38、60获得与已经发起TLS会话的正在加入的客户端设备 18相关联的已存储的AUTHC0DE40。在702,将AUTHC0DE40用于一个或多个TLS操作，并且 在704完成TLS握手。
[0043] 可以认识到，存在用于执行TLS握手的多种基于TLS的机制。因此，当施加到使用 TLS或SSL的应用时，存在多种方式来将AUTHC0DE40用于解决上述操纵问题。下文提供了多 个示例，在这些示例中，将AUTHC0DE40用于一个或多个TLS操作，以促使正确的正在加入的 客户端设备18与正确的信任中心14进行通信并且向正确的信任中心14注册，从而加入正 确的局域网12。在以下示例中，可以假定所使用的TLS协议包括密钥交换算法，例如，在TLS RFC4492文档的椭圆曲线加密法（ECC)密码套件（cipher suite)中描述的算法。以下示例 可以使用临时椭圆曲线迪菲-赫尔曼（Diffie Heilman)和E⑶SA(E⑶HE_EOTSA)密钥交换算 法。然而，可以认识到，这里所述的原理还可以应用于其他密钥交换算法，例如ECDH_ECDSA、 EOTH_RSA、E⑶HE_RSA等，其中客户端设备16、18和信任中心14可以根据AUTHC0DE40推衍 (derive)最终的会话密钥。
[0044] 现在参考图8,示出了正在加入的客户端设备18用AUTHC0DE40代替在TLS握手 期间使用的ClientHello消息中包括的随机值的示例。如本领域公知的，TLS握手中的 ClientHello消息是在协商阶段期间发送的并且由客户端发送以指定客户端支持的最高的 TLS协议版本并且提供随机数、建议密码套件的列表和压缩方法。对于如图8所示的示例， 可以假定当在TLS中执行ECDHE_ECDSA时，ClientHello. random值对TLS会话的整体安全 性没有贡献。应认识到，可以将ClientHello. random值重新目的化为AUTHC0DE40的知识 (knowledge)的证据，并且还应认识到在TLS握手期间，在产生master_secret (主密钥）和 key_block(密钥块）的操作中可以用 AUTHC0DE40 代替 ClientHello. random 值。
[0045] 假定正在加入的客户端设备18和信任中心14都具有AUTHC0DE40 (即，在正在加 入的客户端设备18发起TLS会话之后，已经通过带外信道22将AUTHC0DE20发送或以其 他方式提供给信任中心14)，在800,正在加入的客户端设备18使用HASH函数（例如，由 TLS会话使用的密码散列）变换AUTHC0DE40。然后，正在加入的客户端设备18在802将 AUTHC0DE40的散列用作ClientHello. random值来产生ClientHello消息，并且在804将 ClientHello消息发送给信任中心14。信任中心14在806接收ClientHello消息，并且在 808将该消息中的ClientHello. random值与由信任中心14产生的AUTHC0DE40的散列进行 比较。
[0046] 信任中心14在810确定是否匹配。如果比较的值不同，则在812, TLS会话由于 错误而停止，并且终止该处理。如果比较的值匹配，贝1J在814,信任中心14在计算master_ secret和key_block期间，在内部使用AUTHC0DE40来执行TLS握手的其余部分。在 816,正在加入的客户端设备18也在计算master_secret和key_block期间，在内部使用 AUTHC0DE40而不是Cl ientHe 11 〇. random值来执行其余TLS握手操作。因此，仅当信任中心 14得知AUTHC0DE40并如上所述的将该AUTHC0DE40用于执行master_secret和key_block 计算时，在818和820处，TLS握手才将成功地完成并进入应用阶段。
[0047] 现在参考图9,示出了信任中心14用AUTHC0DE40代替在TLS握手期间使用的 ServerHello消息中包括的随机值的示例。如本领域公知的，TLS握手中的ServerHello消 息是在协商阶段期间作为对ClientHello消息的响应发送的，并且由服务器发送以指定所 选的TLS协议版本并且根据由客户端提供的选择来提供随机数、密码套件和压缩方法。对 于图9所示的示例，可以假定当在TLS中执行E⑶HE_EOTSA时，ServerHello. random值对 TLS会话的整体安全性没有贡献。应认识到，可以将ServerHello. random值重新目的化 为AUTHC0DE40的知识的证据，并且还应认识到在TLS握手期间，在产生master_secret和 key_block 的操作中可以用 AUTHC0DE40 代替 ServerHello. random 值。
[0048] 假定正在加入的客户端设备18和信任中心14都具有AUTHC0DE40( S卩，在正在 加入的客户端设备18发起TLS会话之后，已经通过带外信道22将AUTHC0DE20发送或 以其他方式提供给信任中心14)，在900,正在加入的客户端设备18向信任中心14发送 ClientHello消息，在902,信任中心14接收该消息。在904,信任中心14使用HASH函数（例 如，由TLS会话使用的密码散列）变换AUTHC0DE40。然后，信任中心14在906将AUTHC0DE40 的散列用作ServerHello. random值来产生ServerHello消息，并且在908将ServerHello 消息发送给正在加入的客户端设备18。正在加入的客户端设备18在910接收ServerHello 消息，并且在912将该消息中的ServerHello. random值与由正在加入的客户端设备18产 生的AUTHC0DE40的散列进行比较。
[0049] 正在加入的客户端设备18在914确定是否匹配。如果比较的值不同，则在916， TLS会话由于错误而停止，并且终止该处理。如果比较的值匹配，则在918,正在加入的客户 端设备18在计算master_secret和key_block期间，在内部使用AUTHC0DE40来执行TLS 握手的其余部分。在920,信任中心14也在计算master_secret和key_block期间，在内部 将AUTHC0DE40用作ServerHello. random值来执行其余TLS握手操作。因此，仅当正在加 入的客户端设备18得知AUTHC0DE40并如上所述的将AUTHC0DE40代入master_secret和 key_bl〇ck计算时，在922和924处，TLS握手才将成功地完成并进入应用阶段。
[0050] 现在参考图10,还应认识到可以将AUTHC0DE40用于产生针对E⑶HE计算的第二 基点，而不影响TLS会话的整体安全性。因此可以将第二基点用于在TLS握手中形成pre_ master_secret。在图10所示的示例中，可以通过附加的标量乘法修改协商的ECDHE值Q， 艮P :AUTHC0DE*Q，其中将AUTHC0DE解释为以TLS会话正在其中操作的椭圆曲线群的基点的 阶数为模的整数。
[0051] 在1000和1002,正在加入的客户端设备18和信任中心14根据所使用的TLS算 法来分别执行一个或多个初始TLS握手操作。例如，正在加入的客户端设备18和信任中 心14可以交换ClientHello和ServerHello消息、证书和证书请求消息等。在1004,正在 加入的客户端设备18通过计算Q' = AUTHC0DE*Q，来修改密钥椭圆曲线点Q。如上所述，将 AUTHC0DE40解释为以TLS会话正在其中操作的椭圆曲线群的阶数为模的整数。然后，正在 加入的客户端设备18在1006使用Q'的x坐标形成pre_master_secret，并且在1008执行 任意其余TLS握手操作，其中仅当信任中心14同样得知AUTHC0DE40并以类似方式修改共 享的密钥椭圆曲线点Q时，TLS握手才将成功地完成。
[0052] 因此，在1010,信任中心14通过计算Q' = AUTHC0DE*Q，来修改密钥椭圆曲线点 Q。如上所述，将AUTHC0DE40解释为以TLS会话正在其中操作的椭圆曲线群的阶数为模的 整数。然后，信任中心14在1012使用Q'的X坐标形成pre_master_secret，并且在1014 执行任意其余TLS握手操作，其中仅当正在加入的客户端设备18同样得知AUTHC0DE40并 以类似方式修改共享的密钥椭圆曲线点Q时，TLS握手才将成功地完成。
[0053] 假定TLS握手是成功的，在1016和1018,正在加入的客户端设备18和信任中心 14分别进入TLS应用阶段。
[0054] 如在例如RFC5705中定义的，可以从协商的TLS会话中提取附加的密码密钥。参考 图11，应认识到，可以通过在协商TLS会话之后交换PRF ()函数的输出使客户端和服务器证 明AUTHC0DE40的知识，来修改TLS方法的密钥材料导出（keying material exporter)以 提供针对操纵问题的解决方案。在1100和1102,正在加入的客户端设备18和信任中心14 分别通过（例如使用E⑶HE_EOTSA密钥交换算法）执行TLS握手来参与建立TLS会话。在 1104,正在加入的客户端设备18通过将AUTHC0DE40添加到PRF0函数中作为"标签"值的 一部分或"上下文"值的一部分，来产生RFC5705中定义的导出操作。如本领域公知的，如果 没有提供上下文，则 PRF()函数计算：PRF(master_secret，label，client_random+server_ random) [length],其中PRF()是在会话中使用的TLS伪随机函数。如果提供了上下文，贝丨J PRF()函数计算：PRF(master_secret, label, client_random+server_random+context_ value_length+context_value) [length]。PRF ()的输出是根据 master_secret 产生的 [length]个字节的伪随机比特串。
[0055] 在1106,正在加入的客户端设备18将输出解析为两个不同数据要素：SERVER_ PROOF]ICLIENT_PR00F = PRF(master_secret, label, client_random+server_ random+context_value_length+context_value)[length],并在 1108 发送 CLIENT_ PROOF。同时，信任中心14在1110也通过将AUTHC0DE40添加到PRF()函数中作为"标 签"值或"上下文"值来产生RFC5705中定义的导出操作，并在1112将输出标记为 ： SERVER_PR00F||CLIENT_PR00F = PRF(master_secret, label, client_random+server_ random+context_value_length+context_value)[length]〇
[0056] 信任中心14在1114接收CLIENT_PR00F，并且在接收到CLIENT_PR00F之后，在 1116将接收到的CLIENT_PR00F与使用上述关系计算出的CLIENT_PR00F值进行比较。信 任中心14在1118确定这些值是否匹配。如果比较的值不同，则TLS会话在1120由于错误 而停止，并且认为正在加入的客户端设备18是不正确的。如果比较的值相匹配，则信任中 心14在1122确定正确的客户端已经加入，并且在1124向正在加入的客户端设备18发送 SERVER_PR00F。
[0057] 正在加入的客户端设备18在1126接收SERVER_PR00F，并且在接收到SERVER_ PROOF之后，在1128将接收到的SERVER_PR00F与上述计算出的SERVER_PR00F值进行比较。 正在加入的客户端设备18在1130确定这些值是否匹配。如果比较的值不同，则TLS会话 在1132由于错误而停止，并且认为正在加入的客户端设备18加入了错误的网络。如果比 较的值相匹配，则正在加入的客户端设备18在1134确定它已加入正确的局域网12。
[0058] 可以认识到，上述原理可以应用于其他安全协商协议（包括多种基于TLS和SSL 的密钥协定方案），例如，TLS_RSA_WITH_RC4_128_SHA、TLS_RSA_WITH_AES_256_CBC_SHA 等。此外，如RFC2246的6. 3节所述，可以通过例如在推衍key_block之前将AUTHC0DE40 附加到 master_secret 或者将 AUTHC0DE40 与 master_secret 进行异或，使 AUTHC0DE40 参 与 master_secret 或 key_block 计算。
[0059] 还可以认识到，由于印刷、读取和输入代码所需的任务的性质，使AUTHC0DE40包 括足够的熵或随机性（这可能导致有效AUTHC0DE40的空间成为可耗尽的集合）是不切实 际的。在这种情况下，攻击者可以通过填充与HASH (AUTOCODE)相对应的值的数据库，来执 行字典式攻击，并且等待ClientHello消息并针对检测到的散列值查找正确的AUTOCODE。 可以通过散布（salt)散列输出来部分地阻碍这种攻击。例如，可以将ClientHello. random 值可以分为两个部分：ClientHello. random = SALT | | HASH (SALT | lAUTHCODE)， 其中SALT是随机产生的足够大的值，例如，大至足以针对（SALT，AUTOCODE)的所有值防 止创建值"SALT | | HASH (SALT | | AUTHC0DE)"的字典。例如，对于多个应用，将SALT设置 为80比特随机值可能是足够的。尽管这种散布技术可以使得免受字典式攻击，然而这种 情况下的较低熵AUTHC0DE40仍然可能容易受到蛮力攻击，在蛮力攻击中，攻击者观察合 法加入以及值 ClientHello. random = SALT | |HASH(SALT| IAUTHC0DE)，并且离线以计算 HASH(SALT| |AUTHC0DE)直到发现正确的AUTHC0DE40为止。应认识到，当AUTHC0DE40没有 足够的随机性时，图8到图11所示的方法可能容易受到字典式攻击和蛮力攻击之一或二 者。
[0060] 为了解决这些可能的攻击，现在将描述对TLS协议的附加修改和附加的TLS会 话建立后的验证，所述对TLS协议的附加修改和附加的TLS会话建立后的验证可以基于 IEEE1363. 2中所述的基于口令的密钥协定方案和安全远程口令的使用。
[0061] 现在参考图12,示出了在加入过程期间通过已建立的TLS会话验证AUTHC0DE40的 方法。在1200和1202,图12所述的方法分别在正在加入的客户端设备18与信任中心14 之间建立TLS连接，然后用密钥确认（例如，在IEEE1363. 2中规定的EC-SPEKE)执行基于 口令的密钥协定协议。
[0062] 在1204,正在加入的客户端设备18通过计算：Q = f(HASH(ClientID| | " · " | | (C lientHello. random | |ServerHello. random | |AUTHC0DE)))在捕圆曲线上产生基点 Q，其中 f是得到HASH的输出并将该输出映射到期望曲线上的椭圆曲线点的适合函数。然后，正在 加入的客户端设备18在1206产生随机值a并计算Q A = aQ。然后在1208将QA发送给信 任中心14。信任中心14在1210也以与正在加入的客户端设备18相同的方式产生Q，并且 在1212产生随机值b并计算Q B = bQ。信任中心14在1214接收到QA并在1216计算K = KDF(bQA)。可以认识到，KDF是适合的密钥推衍函数，例如，IEEE1363. 2中所述的KDF。然 后，信任中心14产生块SERVER_PR00F
[0063] CLIENT_PR00F = PRF(K,(其他信息，例如 ClientHello. random、ServerHello. random等））。例如，所述块可以包括以下格式：SERVER_PR00F| |CLIENT_PR00F =PRF (master_Secret, label, client_random+server_random+context_value_ length+context_value) [length]，如上文所使用的。信任中心14在1236向正在加入的客 户端设备18发送QB和SERVER_PROOF。
[0064] 正在加入的客户端设备18在1222接收到％和SERVER_PR00F，并在1224产生K = KDF (aQB)。然后，正在加入的客户端设备18在1226产生块SERVER_PR00F | | CLIENT_PR00F =PRF (K，（其他信息，例如 ClientHello. random、ServerHello. random 等））。例如，所述块 可以包括以下格式：SERVER_PR00F| |CLIENT_PR00F = PRF(master_secret，label，client_ random+server_random+context_value_length+context_value) [length],如上文所使用 的。正在加入的客户端设备18在1228将接收到的SERVER_PR00F与根据所述块计算出的 SERVER_PR00F进行比较。正在加入的客户端设备18在1230确定这些值是否匹配。如果不 匹配，则在1232停止会话并指示错误。如果SERVER_PR00F值匹配，则正在加入的客户端设 备18在1234向信任中心14发送CLIENT_PR00F，信任中心14在1238接收到CLIENT_PR00F。 信任中心14在1240将接收到的CLIENT PROOF与根据所述块计算出的CLIENT_PR00F进行 比较，并且在1242确定这些值是否匹配。如果不匹配，则在1244断开连接从而指示错误。 如果CLIENT_PR00F值匹配，则在1246允许正在加入的客户端设备18加入局域网12。
[0065] 现在参考13,示出了在加入处理中在建立TLS会话期间验证AUTHC0DE的方法。应 认识到，在TLS会话的ECDH方案中使用的基点可以被修改以验证AUTHC0DE，并且可以使用 基于口令的密钥协定协议以便直接建立TLS会话密钥。仅当由两个端点使用的AUTHC0DE40 是相同的，TLS会话才是成功的。
[0066] 如图13所示，当在1300和1302分别参与建立TLS会话之后，正在加入的客户端设 备18和信任中心14可以在1304和1308分别产生新的基点Q。将新的基点用于E⑶Η操作， 其中 Q = f(HASH(AGREED_UPON_STRING| | " (ClientHello. random) | | (ServerHello. random I I AUTOCODE)))，其中f是得到HASH的输出并在TLS协商曲线上产生椭圆曲线点的 适合函数。
[0067] 客户端在1306将基点Q用作基点进行E⑶HE密钥交换，并且信任中心14在1310 类似地使用Q。
[0068] 可以认识到，考虑到两种解决方案之间的相似性，上述原理还可以用于数据报 TLS (DTLS)。DTLS协议确保UDP网络通信安全性，并且被设计为与TLS相似，以便使大多数 协议消息保持相同，从而允许许多相同的TLS密码套件用于DTLS。一些机器到机器的网络 (例如，如图1和2所示的网络）可以使用UDP和DTLS。针对这种环境设计的一个示例性 应用层协议是CoAP，其目的在于通过UDP提供类似HTTP的协议，并且用DTLS确保安全性。 当用"证书模式"确保CoAP的安全性时，S卩，用证书提供安全性，可能存在上述的操纵问题。 因此，可以应用这里所述的原理以解决这种操纵问题。
[0069] 类似地，如上所述，AUTHC0DE40还可以用于诸如IPSec等的其他安全协商协议中。 例如，可以通过将互联网密钥交换（IKE)修改为在密钥推衍步骤中包括AUTOCODE (RFC4306 的2. 13节中针对IKE v2所述的），来修改IPSec中使用的密钥协定协议。
[0070] 因此，提供了一种使客户端设备能够与网络相连的方法，所述方法包括：通过不同 于网络的通信信道获得授权码，所述授权码与客户端设备相对应；以及在检测到由客户端 设备发起安全协商协议之后，将所述授权码用于至少一个安全协商操作。
[0071] 还提供了一种与网络相连的方法，所述方法包括：客户端设备发起与网络的服务 器设备的安全协商协议；以及将授权码用于至少一个安全协商操作，所述授权码已经通过 不同于网络的通信信道提供给服务器设备，所述授权码与客户端设备相对应。
[0072] 提供了一种使客户端设备能够与网络相连的方法，所述方法包括：通过不同于网 络的通信信道向客户端设备提供授权码，所述授权码与客户端设备相对应；以及在检测到 由客户端设备发起安全协商协议之后，将所述授权码用于至少一个安全协商操作。
[0073] 还提供了一种包括用于执行上述方法的指令的计算机可读介质、以及被配置用于 执行上述方法的客户端设备和服务器设备。
[0074] 应认识到，这里所例示的执行指令的任何模块或组件可以包括或另外有权访问计 算机可读介质，例如，存储介质、计算机存储介质、或诸如磁盘、光盘或磁带等的数据存储设 备（可移除的和/或不可移除的）。计算机存储介质可以包括易失性的和非易失性的、可移 除的和不可移除的介质，所述介质实现在任何方法或技术中以用于存储信息，例如计算机 可读指令、数据结构、程序模块或其他数据。计算机存储介质的示例包括：ram、rom、eeprom、 闪存或其他存储技术、CD-ROM、数字通用光盘（DVD)或其他光学存储设备、磁带盒、磁带、磁 盘存储器或其他磁性存储设备、或可以用于存储所需信息并可以由应用、模块或二者访问 的任何其他介质。任何这种计算机存储介质可以是**的一部分、**的任何组件或与**相 关的任何组件等，或可访问或可连接。可以使用计算机可读/可执行指令来实现这里所述 的任何应用或模块，其中通过这种计算机可读介质存储或另外保存所述计算机可读/可执 行指令。
[0075] 这里所述的流程图和示意图中的步骤或操作仅是示例性的。可以存在对这种步骤 或操作的多种变型，而不脱离上述的原理。例如，可以以不同顺序执行所述步骤，或可以添 力口、删除或修改所述步骤。
[0076] 尽管参考一些具体示例描述了以上原理，然而如所附权利要求所述，多种修改对 于本领域技术人员而言将是显而易见的。
【权利要求】
1. 一种使客户端设备能够与网络相连的方法，所述方法包括： 通过不同于所述网络的通信信道获得授权码，所述授权码与所述客户端设备相对应； 以及 在检测到由所述客户端设备发起安全协商协议之后，将所述授权码用于至少一个安全 协商操作。
2. 根据权利要求1所述的方法，还包括至少一个以下操作： 当安全协商成功时，允许所述客户端设备访问至少一个网络资源；以及 获得所述客户端设备的公钥，并将所述公钥和所述授权码用于向服务器设备认证所述 客户端设备。
3. 根据权利要求2所述的方法，所述客户端设备的所述公钥是在数字证书中提供的。
4. 根据权利要求1到3中任一项所述的方法，将所述授权码用于建立传输层安全TLS 会话。
5. 根据权利要求4所述的方法，还包括至少一个以下操作： 将所述授权码用于产生master_secret、key_block和pre_master_secret中的至少 一个，其中所述master_secret、所述key_block和所述pre_master_secret是在建立所述 TLS会话期间产生的； 将所述授权码用于PRFO函数； 将所述授权码用于在建立所述TLS会话期间的密钥交换；以及 将所述授权码用于在建立所述TLS会话期间的密钥推衍步骤。
6. 根据权利要求1到5中任一项所述的方法，在使用所述安全协商协议完成安全会话 之后，将所述授权码用于建立密钥。
7. -种与网络相连的方法，所述方法包括： 客户端设备发起与所述网络的服务器设备的安全协商协议；以及 将授权码用于至少一个安全协商操作，所述授权码已经通过不同于所述网络的通信信 道提供给所述服务器设备，所述授权码与所述客户端设备相对应。
8. 根据权利要求7所述的方法，还包括至少一个以下操作： 在安全协商成功之后，访问至少一个网络资源；以及 获得所述服务器设备的公钥，并将所述公钥和所述授权码用于向所述服务器设备认证 所述客户端设备。
9. 根据权利要求8所述的方法，所述服务器设备的所述公钥是在数字证书中提供的。
10. 根据权利要求7到9中任一项所述的方法，将所述授权码用于建立传输层安全TLS 会话。
11. 根据权利要求10所述的方法，还包括至少一个以下操作： 将所述授权码用于产生master_secret、key_block和pre_master_secret中的至少 一个，其中所述master_secret、所述key_block和所述pre_master_secret是在建立所述 TLS会话期间产生的； 将所述授权码用于PRF0函数； 将所述授权码用于在建立所述TLS会话期间的密钥交换；以及 将所述授权码用于在建立所述TLS会话期间的密钥推衍步骤。
12. 根据权利要求7到11中的任一项所述的方法，在使用所述安全协商协议完成安全 会话之后，将所述授权码用于建立密钥。
13. -种使客户端设备能够与网络相连的方法，所述方法包括： 通过不同于所述网络的通信信道向所述客户端设备提供授权码，所述授权码与所述客 户端设备相对应；以及 在检测到由所述客户端设备发起安全协商协议之后，将所述授权码用于至少一个安全 协商操作。
14. 一种计算机可读存储介质，包括用于执行根据权利要求1到13中任一项所述方法 的计算机可执行指令。
15. -种设备，包括处理器和存储器，所述存储器包括计算机可执行指令，所述计算机 可执行指令用于作为服务器设备根据权利要求1到6或权利要求13中任一项所述的方法 操作或者用于作为客户端设备根据权利要求7到12中任一项所述的方法操作。
【文档编号】H04L9/32GK104160656SQ201380012082
【公开日】2014年11月19日 申请日期:2013年2月28日 优先权日:2012年3月1日
【发明者】马修·约翰·坎帕尼亚, 丹尼尔·理查德·L·布朗, 格雷戈里·马克·扎韦鲁哈 申请人:塞尔蒂卡姆公司