CN104160656B - 用于将客户端设备与网络相连的***和方法 - Google Patents

用于将客户端设备与网络相连的***和方法 Download PDF

Info

Publication number
CN104160656B
CN104160656B CN201380012082.5A CN201380012082A CN104160656B CN 104160656 B CN104160656 B CN 104160656B CN 201380012082 A CN201380012082 A CN 201380012082A CN 104160656 B CN104160656 B CN 104160656B
Authority
CN
China
Prior art keywords
client device
network
authorization code
tls
key
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN201380012082.5A
Other languages
English (en)
Other versions
CN104160656A (zh
Inventor
马修·约翰·坎帕尼亚
丹尼尔·理查德·L·布朗
格雷戈里·马克·扎韦鲁哈
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Maliki Innovation Co ltd
Original Assignee
Certicom Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Certicom Corp filed Critical Certicom Corp
Publication of CN104160656A publication Critical patent/CN104160656A/zh
Application granted granted Critical
Publication of CN104160656B publication Critical patent/CN104160656B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • H04L63/126—Applying verification of the received information the source of the received data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/16—Implementing security features at a particular protocol layer
    • H04L63/166—Implementing security features at a particular protocol layer at the transport layer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/14—Session management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0838—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these
    • H04L9/0847—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these involving identity based encryption [IBE] schemes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
    • H04L9/0869—Generation of secret information including derivation or calculation of cryptographic keys or passwords involving random numbers or seeds
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/18—Network architectures or network communication protocols for network security using different networks or channels, e.g. using out of band channels
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/30—Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy
    • H04L9/3066—Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy involving algebraic varieties, e.g. elliptic or hyper-elliptic curves

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer And Data Communications (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Small-Scale Networks (AREA)

Abstract

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

Description

用于将客户端设备与网络相连的***和方法
技术领域
下文涉及用于将客户端设备与网络相连的***和方法。
背景技术
在网络环境中，希望加入网络的客户端设备首先发现网络，然后加入所发现的网络。通常由路由器、服务器或其他网络控制器或接入设备(下文中，称作“信任中心”)来执行针对网络的接受。在一些网络环境中，加入网络并且通过网络进行通信的客户端设备使用少量用户接口或不使用用户接口来进行操作。尽管这种客户端设备的接口有限，然而客户端设备应当能够不仅加入网络，而且加入正确网络。类似地，信任中心应当能够只允许可接受的客户端设备加入其网络。
诸如家域网(HAN)等的网络可以将安全协商协议(例如传输层安全(TLS)协议或其前身(安全套接层(SSL)协议))用作该网络的基本安全协议。TLS协议是提供通信私密性和数据完整性并且允许客户端/服务器应用以设计为防止或禁止窃听、篡改和消息伪造的方式进行通信的公知通信协议。
在使用TLS或SSL协议的环境(包括向客户端设备预配置数字证书(下文中，“证书”)的环境)中，可能难以向正在加入的客户端设备指示它应当加入哪个网络和信任中心。还可能难以提取来自正在加入的客户端设备的信息并且访问信任中心以限定哪些客户端设备应当加入。通常将这种困难称作“操纵问题(steering problem)”。
为了解决操纵问题，典型模型在于向信任中心提供与将加入网络的客户端设备有关的少量标识信息。通常，标识信息应具有允许人们通过终端或键盘容易输入的形式。一旦该信息在信任中心是已知的，信任中心就进入“允许加入”模式。此时，经验证的正在加入的客户端设备可以证明它是与标识信息相关联的设备，并且被允许加入网络。
该模型的安全问题在于：欺诈信任中心可以在混杂模式下接受加入，从而欺骗正在加入的客户端设备加入错误网络。另一安全问题在于：欺诈客户端设备可以在允许加入阶段期间和在预期设备能够加入之前尝试通过信任中心加入网络。
发明内容
在一个方面，提供了一种使客户端设备能够与网络相连的方法，所述方法包括：通过不同于网络的通信信道获得授权码，所述授权码与客户端设备相对应；以及在检测到由客户端设备发起安全协商协议之后，将所述授权码用于至少一个安全协商操作。
在另一方面，提供了一种与网络相连的方法，所述方法包括：客户端设备发起与网络的服务器设备的安全协商协议；以及将授权码用于至少一个安全协商操作，所述授权码已经通过不同于网络的通信信道提供给服务器设备，所述授权码与客户端设备相对应。
在另一方面，提供了一种使客户端设备能够与网络相连的方法，所述方法包括：通过不同于网络的通信信道向客户端设备提供授权码，所述授权码与客户端设备相对应；以及在检测到由客户端设备发起安全协商协议之后，将所述授权码用于至少一个安全协商操作。
在另一方面，提供了一种计算机可读存储介质，包括用于使客户端设备能够与网络相连的计算机可执行指令，所述计算机可执行指令包括用于以下操作的指令：通过不同于网络的通信信道获得授权码，所述授权码与客户端设备相对应；以及在检测到由客户端设备发起安全协商协议之后，将所述授权码用于至少一个安全协商操作。
在另一方面，提供了一种计算机可读存储介质，包括用于与网络连接的计算机可执行指令，所述计算机可执行指令包括用于以下操作的指令：客户端设备发起与网络的服务器设备的安全协商协议；以及将授权码用于至少一个安全协商操作，所述授权码已经通过不同于网络的通信信道提供给服务器设备，所述授权码与客户端设备相对应。
在另一方面，提供了一种计算机可读存储介质，包括用于使客户端设备能够与网络相连的计算机可执行指令，所述计算机可执行指令包括用于以下操作的指令：通过不同于网络的通信信道向客户端设备提供授权码，所述授权码与客户端设备相对应；以及在检测到由客户端设备发起安全协商协议之后，将所述授权码用于至少一个安全协商操作。
在另一方面，提供了一种包括处理器和存储器的服务器设备，所述存储器包括计算机可执行指令，所述计算机可执行指令用于通过操作所述处理器执行以下操作来使客户端设备能够与网络相连：通过不同于网络的通信信道获得授权码，所述授权码与客户端设备相对应；以及在检测到由客户端设备发起安全协商协议之后，将所述授权码用于至少一个安全协商操作。
在另一方面，提供了一种包括处理器和存储器的服务器设备，所述存储器包括计算机可执行指令，所述计算机可执行指令用于通过操作所述处理器执行以下操作来使客户端设备与网络相连：通过不同于网络的通信信道向客户端设备提供授权码，所述授权码与客户端设备相对应；以及在检测到由客户端设备发起安全协商协议之后，将所述授权码用于至少一个安全协商操作。
在另一方面，提供了一种包括处理器和存储器的客户端设备，所述存储器包括计算机可执行指令，所述计算机可执行指令用于通过操作所述处理器执行以下操作来与网络连接：发起与网络的服务器设备的安全协商协议；以及将授权码用于至少一个安全协商操作，所述授权码已经通过不同于网络的通信信道提供给服务器设备，所述授权码与客户端设备相对应。
附图说明
现在将参考附图仅通过举例说明的方式描述实施例，在附图中：
图1是包括网络环境的通信***的示意图；
图2是包括家庭网络的通信***的示意图；
图3是示出了网络环境中的客户端设备的配置的示例的框图；
图4是示出了网络环境中的信任中心的配置的示例的框图；
图5是示出了网络环境中使用的互联网协议(IP)栈的框图；
图6是示出了计算机可执行操作的集合的示例的流程图，其中可以执行所述计算机可执行操作的集合以通过带外信道向信任中心提供授权码(AUTHCODE)；
图7是示出了计算机可执行操作的集合的示例的流程图，其中可以执行所述计算机可执行操作的集合以使用AUTHCODE来执行TLS握手；
图8是示出了计算机可执行操作的集合的示例的流程图，其中可以执行所述计算机可执行操作的集合以使用AUTHCODE来执行TLS握手；
图9是示出了计算机可执行操作的集合的示例的流程图，其中可以执行所述计算机可执行操作的集合以使用AUTHCODE来执行TLS握手；
图10是示出了计算机可执行操作的集合的示例的流程图，其中可以执行所述计算机可执行操作的集合以使用AUTHCODE来执行TLS握手；
图11是示出了计算机可执行操作的集合的示例的流程图，其中可以执行所述计算机可执行操作的集合以使用AUTHCODE来执行针对TLS的密钥材料导出(key materialexporter)；
图12是示出了计算机可执行操作的集合的示例的流程图，其中可以执行所述计算机可执行操作的集合以在TLS建立之后验证AUTHCODE；以及
图13是示出了计算机可执行操作的集合的示例的流程图，其中可以执行所述计算机可执行操作的集合以使用AUTHCODE来执行经修改的TLS建立。
具体实施方式
应认识到，为了使阐述简单和清楚，在认为适当的情况下可以在附图中重复附图标记以指示相应或相似的元素。此外，阐述了大量具体细节以便提供对这里所述示例的全面理解。然而，本领域普通技术人员应理解，可以在没有这些具体细节的情况下实践这里所述的示例。在其他实例中，未详细描述公知的方法、过程和组件以免混淆这里所述的示例。此外，不应认为该描述限制这里所述示例的范围。
应认识到，这里所使用的示例和相应附图仅用于说明的目的。可以在不脱离这里所述原理的情况下，使用不同的配置和术语。例如，可以添加、删除、修改或用不同连接排列组件和模块，而不脱离这些原理。
为了解决提供通信安全的网络环境中的操纵问题，在信任中心和正在加入的客户端设备二者中建立针对特定客户端设备的授权码(AUTHCODE)，并且将AUTHCODE并入在相应的正在加入的客户端设备与信任中心之间的安全协商中使用的至少一个操作。AUTHCODE使信任中心能够识别正确的正在加入的设备并且使正在加入的设备能够识别正确的信任中心，从而确保它们加入了正确网络。
应认识到，以下所述的原理可以用于多种安全协商协议，其中可以在带外将AUTHCODE提供给信任中心，并且可以将这种AUTHCODE用于由基本安全协商协议使用的至少一个密码操作。示例包括但不限于多种TLS协议版本，包括前身SSL版本和数据报TLS(DTLS)、IPSec等。这里所提供的多种示例在使用TLS或SSL协议版本(下文中，为了说明目的，称作“TLS协议”)的网络环境中说明了这些原理。
在一个示例性场景中，客户端设备可以与信任中心建立TLS会话，其中客户端设备和信任中心具有彼此识别的来自证书管理中心(CA)的经验证的签名密钥(例如，椭圆曲线数字签名算法(ECDSA)签名密钥)。在接受会话之前，向信任中心提供带外的AUTHCODE。将要在加入阶段期间使用的TLS协议修改为利用AUTHCODE。在这种场景下，假定合法的信任中心和每个合法的客户端设备以及任何欺诈客户端设备具有或者另外能够具有包含适于ECDSA签名的公钥的有效证书并拥有相应的私钥。还假定所有正在加入的客户端设备具有相关联的AUTHCODE。可以以多种方式将AUTHCODE提供在客户端设备上或提供给客户端设备等，包括将其印刷在设备外部(例如，壳体背面)、相关包装材料中等。AUTHCODE是打算在带外提供给信任中心而不通过加入的网络来进行传输的随机产生值。
现在参考图1，示出了包括局域网12的网络环境10。通过信任中心14管理至少一些设备对局域网12的接入。可以认识到，信任中心14可以表示任何路由器、服务器或其他网络控制器、或负责允许或拒绝客户端设备接入局域网12的接入设备。在图1所示的示例中，示出了两种客户端设备，即，已注册的客户端设备16和正在加入的客户端设备18。已注册的客户端设备16包括已经通过向信任中心14进行注册成功加入局域网12的客户端设备。正在加入的客户端设备18包括正试图通过向信任中心14进行注册加入局域网12的客户端设备。可以认识到，正在加入的客户端设备18可以包括合法客户端设备和欺诈客户端设备二者。
已注册的客户端设备16和正在加入的客户端设备18都包括AUTHCODE20，可以从设备本身(例如，从设备的外部)确定所述AUTHCODE20。为了将AUTHCODE20用于至少一个TLS操作，在正在加入的客户端设备18与信任中心14之间建立带外信道22。尽管将带外信道22示出为在网络环境10内，然而，还可以将带外信道22建立在网络环境10的外部。带外信道22可以包括例如由信任中心14提供的用户接口，该用户接口能够实现向信任中心14、或由信任中心14控制的或另外信任中心14可访问的数据库或存储器手动输入AUTHCODE20。还可以使用与和信任中心14相关联的管理员26的基于电话或web的连接建立带外信道22，从而当试图向局域网12添加正在加入的客户端设备18时使正在加入的客户端设备18的用户能够提供AUTHCODE20。这样，管理员26可以通过诸如如图1所示的广域网24等的外部网络，向信任中心14下推AUTHCODE20。管理员26或信任中心14或管理员26和信任中心14二者还可以通过广域网24与证书管理中心(CA)28进行通信，以获得例如在TLS协议中使用的证书。在使用证书的情况下，已注册的客户端设备16和正在加入的客户端设备18还包括经验证的签名密钥，因此还可以通过广域网24与CA28进行通信。可以认识到，在其他示例中，客户端设备16、18可以不使用从CA28获得的证书。例如，客户端设备16、18可以利用自签名的证书或未签名的公钥，并且可以将AUTHCODE20用于向信任中心14认证这种客户端设备16、18。
图2示出了网络环境10的示例。图2示出了例如针对智能家庭***或高级计量基础设施(AMI)的包括家域网(HAN)12’的家庭环境10’。通过被管理的服务门户14’控制该示例中的HAN12’，其中被管理的服务门户14’允许已进行公共设施注册的客户端设备(utilityregistered client device)16’与HAN12’进行通信，并且允许或拒绝正在进行公共设施加入的客户端设备(utility joining client device)18’的接入。客户端设备16’、18’可以包括例如电子温控器、大型家用电器、HVAC***等。与上述内容相似，客户端设备16’、18’包括AUTHCODE20并且通过带外信道22’向被管理的服务门户14’提供AUTHCODE20。被管理的服务门户14’通过公共设施AMI网络24’与公共设施后端服务器26’进行通信。公共设施后端服务器26’负责与被管理的服务门户14’进行通信，并且传送与正在进行公共设施加入的设备18’有关的信息并发起用于添加这种正在加入的设备18’的加入周期。公共设施后端服务器26’还可以与CA28’进行通信，以获得公共设施所使用的被管理的服务门户14’的经验证的签名密钥。被管理的服务门户14’还可以安装有已通过采购实践(procurement practice)存储在其中的证书。然后，公共设施后端服务器26’可以查找加入被管理的服务门户14’的正在进行公共设施加入的设备18’的签名/标识信息，以确保还未撤销证书。
图3示出了客户端设备16、18的配置的示例。客户端设备16、18包括主体、壳体或提供外表面30的其他物理部分，可以将AUTHCODE20印刷在外表面30上或以其他方式使AUTHCODE20对用户是可见的。客户端设备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还存储AUTHCODE40的电子版本或表示，以使印刷在客户端设备16、18的外表面30上的AUTHCODE20能够用于TLS操作。
图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还包括或者另外有权访问客户端设备AUTHCODE数据库60，客户端设备AUTHCODE数据库60用于存储已注册的客户端设备16和那些利用带外信道22正在加入的客户端设备18的AUTHCODE40的电子版本或表示。
现在参考图5，在500，可以通过使用带外信道22从客户端设备16、18向信任中心14提供AUTHCODE20，来使用AUTHCODE40修改TLS协议。例如，当用户希望向局域网12添加新的正在加入的客户端设备18时，可以访问由信任中心14提供的用户接口，并且将AUTHCODE40的表示输入该用户接口。然后，在502，正在加入的客户端设备18可以发起与信任中心14的TLS会话。然后，在504，将由正在加入的客户端设备18存储的AUTHCODE40用于一个或多个TLS操作，下文提供了其示例。假定信任中心14已经成功地获得并使用了存储在AUTHCODE数据库60中的相同AUTHCODE40，则在506，允许正在加入的客户端设备18使用已建立的安全信道接入局域网12，此后信任中心14将正在加入的客户端设备18视作已加入的客户端设备16，从而提供对例如网络资源等的访问。类似地，已加入的客户端设备16现在确保已加入的客户端设备16已经加入了正确的信任中心14。
图6示出了操作集合的示例，该操作集合可以执行以使信任中心14和正在加入的客户端设备18能够参与TLS握手。CA28在600产生针对信任中心14的证书并且在602向信任中心14提供该证书，并且在604，信任中心获得该证书。可以认识到，操作600-604是可选的，这取决于是否使用证书，并且可以使用任意适合的证书实现过程(可以包括证书撤销检查或证书验证)来提供向信任中心14颁发的证书。在606，将正在加入的客户端设备18引入网络环境10，并且在608，确定在正在加入的客户端设备18的外表面30上提供的AUTHCODE20。在610，建立带外信道22，在612，由信任中心14启用带外信道22。例如，信任中心14可以提供基于浏览器的用户接口，以使得能够输入AUTHCODE20。在614，提供AUTHCODE20，并且在616，由信任中心14接收AUTHCODE20。在618，信任中心14将AUTHCODE40的表示存储在AUTHCODE数据库60中。然后，在620，信任中心14发起针对与所存储的AUTHCODE20相关联的正在加入的客户端设备18的允许加入阶段。一旦已经发起允许加入阶段，正在加入的客户端设备18就可以在622发起TLS会话，并参与TLS握手以便注册正在加入的客户端设备18。在624，信任中心14也参与TLS握手。
图7示出了计算机可执行操作的集合，该计算机可执行操作集合可以由正在加入的客户端设备18或信任中心14执行以使用通过带外信道22提供给信任中心14的AUTHCODE40。在700，从存储器38、60获得与已经发起TLS会话的正在加入的客户端设备18相关联的已存储的AUTHCODE40。在702，将AUTHCODE40用于一个或多个TLS操作，并且在704完成TLS握手。
可以认识到，存在用于执行TLS握手的多种基于TLS的机制。因此，当施加到使用TLS或SSL的应用时，存在多种方式来将AUTHCODE40用于解决上述操纵问题。下文提供了多个示例，在这些示例中，将AUTHCODE40用于一个或多个TLS操作，以促使正确的正在加入的客户端设备18与正确的信任中心14进行通信并且向正确的信任中心14注册，从而加入正确的局域网12。在以下示例中，可以假定所使用的TLS协议包括密钥交换算法，例如，在TLSRFC4492文档的椭圆曲线加密法(ECC)密码套件(cipher suite)中描述的算法。以下示例可以使用临时椭圆曲线迪菲-赫尔曼(Diffie Hellman)和ECDSA(ECDHE_ECDSA)密钥交换算法。然而，可以认识到，这里所述的原理还可以应用于其他密钥交换算法，例如ECDH_ECDSA、ECDH_RSA、ECDHE_RSA等，其中客户端设备16、18和信任中心14可以根据AUTHCODE40推衍(derive)最终的会话密钥。
现在参考图8，示出了正在加入的客户端设备18用AUTHCODE40代替在TLS握手期间使用的ClientHello消息中包括的随机值的示例。如本领域公知的，TLS握手中的ClientHello消息是在协商阶段期间发送的并且由客户端发送以指定客户端支持的最高的TLS协议版本并且提供随机数、建议密码套件的列表和压缩方法。对于如图8所示的示例，可以假定当在TLS中执行ECDHE_ECDSA时，ClientHello.random值对TLS会话的整体安全性没有贡献。应认识到，可以将ClientHello.random值重新目的化为AUTHCODE40的知识(knowledge)的证据，并且还应认识到在TLS握手期间，在产生master_secret(主密钥)和key_block(密钥块)的操作中可以用AUTHCODE40代替ClientHello.random值。
假定正在加入的客户端设备18和信任中心14都具有AUTHCODE40(即，在正在加入的客户端设备18发起TLS会话之后，已经通过带外信道22将AUTHCODE20发送或以其他方式提供给信任中心14)，在800，正在加入的客户端设备18使用HASH函数(例如，由TLS会话使用的密码散列)变换AUTHCODE40。然后，正在加入的客户端设备18在802将AUTHCODE40的散列用作ClientHello.random值来产生ClientHello消息，并且在804将ClientHello消息发送给信任中心14。信任中心14在806接收ClientHello消息，并且在808将该消息中的ClientHello.random值与由信任中心14产生的AUTHCODE40的散列进行比较。
信任中心14在810确定是否匹配。如果比较的值不同，则在812，TLS会话由于错误而停止，并且终止该处理。如果比较的值匹配，则在814，信任中心14在计算master_secret和key_block期间，在内部使用AUTHCODE40来执行TLS握手的其余部分。在816，正在加入的客户端设备18也在计算master_secret和key_block期间，在内部使用AUTHCODE40而不是ClientHello.random值来执行其余TLS握手操作。因此，仅当信任中心14得知AUTHCODE40并如上所述的将该AUTHCODE40用于执行master_secret和key_block计算时，在818和820处，TLS握手才将成功地完成并进入应用阶段。
现在参考图9，示出了信任中心14用AUTHCODE40代替在TLS握手期间使用的ServerHello消息中包括的随机值的示例。如本领域公知的，TLS握手中的ServerHello消息是在协商阶段期间作为对ClientHello消息的响应发送的，并且由服务器发送以指定所选的TLS协议版本并且根据由客户端提供的选择来提供随机数、密码套件和压缩方法。对于图9所示的示例，可以假定当在TLS中执行ECDHE_ECDSA时，ServerHello.random值对TLS会话的整体安全性没有贡献。应认识到，可以将ServerHello.random值重新目的化为AUTHCODE40的知识的证据，并且还应认识到在TLS握手期间，在产生master_secret和key_block的操作中可以用AUTHCODE40代替ServerHello.random值。
假定正在加入的客户端设备18和信任中心14都具有AUTHCODE40(即，在正在加入的客户端设备18发起TLS会话之后，已经通过带外信道22将AUTHCODE20发送或以其他方式提供给信任中心14)，在900，正在加入的客户端设备18向信任中心14发送ClientHello消息，在902，信任中心14接收该消息。在904，信任中心14使用HASH函数(例如，由TLS会话使用的密码散列)变换AUTHCODE40。然后，信任中心14在906将AUTHCODE40的散列用作ServerHello.random值来产生ServerHello消息，并且在908将ServerHello消息发送给正在加入的客户端设备18。正在加入的客户端设备18在910接收ServerHello消息，并且在912将该消息中的ServerHello.random值与由正在加入的客户端设备18产生的AUTHCODE40的散列进行比较。
正在加入的客户端设备18在914确定是否匹配。如果比较的值不同，则在916，TLS会话由于错误而停止，并且终止该处理。如果比较的值匹配，则在918，正在加入的客户端设备18在计算master_secret和key_block期间，在内部使用AUTHCODE40来执行TLS握手的其余部分。在920，信任中心14也在计算master_secret和key_block期间，在内部将AUTHCODE40用作ServerHello.random值来执行其余TLS握手操作。因此，仅当正在加入的客户端设备18得知AUTHCODE40并如上所述的将AUTHCODE40代入master_secret和key_block计算时，在922和924处，TLS握手才将成功地完成并进入应用阶段。
现在参考图10，还应认识到可以将AUTHCODE40用于产生针对ECDHE计算的第二基点，而不影响TLS会话的整体安全性。因此可以将第二基点用于在TLS握手中形成pre_master_secret。在图10所示的示例中，可以通过附加的标量乘法修改协商的ECDHE值Q，即：AUTHCODE*Q，其中将AUTHCODE解释为以TLS会话正在其中操作的椭圆曲线群的基点的阶数为模的整数。
在1000和1002，正在加入的客户端设备18和信任中心14根据所使用的TLS算法来分别执行一个或多个初始TLS握手操作。例如，正在加入的客户端设备18和信任中心14可以交换ClientHello和ServerHello消息、证书和证书请求消息等。在1004，正在加入的客户端设备18通过计算Q’＝AUTHCODE*Q，来修改密钥椭圆曲线点Q。如上所述，将AUTHCODE40解释为以TLS会话正在其中操作的椭圆曲线群的阶数为模的整数。然后，正在加入的客户端设备18在1006使用Q’的x坐标形成pre_master_secret，并且在1008执行任意其余TLS握手操作，其中仅当信任中心14同样得知AUTHCODE40并以类似方式修改共享的密钥椭圆曲线点Q时，TLS握手才将成功地完成。
因此，在1010，信任中心14通过计算Q’＝AUTHCODE*Q，来修改密钥椭圆曲线点Q。如上所述，将AUTHCODE40解释为以TLS会话正在其中操作的椭圆曲线群的阶数为模的整数。然后，信任中心14在1012使用Q’的x坐标形成pre_master_secret，并且在1014执行任意其余TLS握手操作，其中仅当正在加入的客户端设备18同样得知AUTHCODE40并以类似方式修改共享的密钥椭圆曲线点Q时，TLS握手才将成功地完成。
假定TLS握手是成功的，在1016和1018，正在加入的客户端设备18和信任中心14分别进入TLS应用阶段。
如在例如RFC5705中定义的，可以从协商的TLS会话中提取附加的密码密钥。参考图11，应认识到，可以通过在协商TLS会话之后交换PRF()函数的输出使客户端和服务器证明AUTHCODE40的知识，来修改TLS方法的密钥材料导出(keying material exporter)以提供针对操纵问题的解决方案。在1100和1102，正在加入的客户端设备18和信任中心14分别通过(例如使用ECDHE_ECDSA密钥交换算法)执行TLS握手来参与建立TLS会话。在1104，正在加入的客户端设备18通过将AUTHCODE40添加到PRF()函数中作为“标签”值的一部分或“上下文”值的一部分，来产生RFC5705中定义的导出操作。如本领域公知的，如果没有提供上下文，则PRF()函数计算：PRF(master_secret，label，client_random+server_random)[length]，其中PRF()是在会话中使用的TLS伪随机函数。如果提供了上下文，则PRF()函数计算：PRF(master_secret，label，client_random+server_random+context_value_length+context_value)[length]。PRF()的输出是根据master_secret产生的[length]个字节的伪随机比特串。
在1106，正在加入的客户端设备18将输出解析为两个不同数据要素：SERVER_PROOF||CLIENT_PROOF＝PRF(master_secret，label，client_random+server_random+context_value_length+context_value)[length]，并在1108发送CLIENT_PROOF。同时，信任中心14在1110也通过将AUTHCODE40添加到PRF()函数中作为“标签”值或“上下文”值来产生RFC5705中定义的导出操作，并在1112将输出标记为：SERVER_PROOF||CLIENT_PROOF＝PRF(master_secret，label，client_random+server_random+context_value_length+context_value)[length]。
信任中心14在1114接收CLIENT_PROOF，并且在接收到CLIENT_PROOF之后，在1116将接收到的CLIENT_PROOF与使用上述关系计算出的CLIENT_PROOF值进行比较。信任中心14在1118确定这些值是否匹配。如果比较的值不同，则TLS会话在1120由于错误而停止，并且认为正在加入的客户端设备18是不正确的。如果比较的值相匹配，则信任中心14在1122确定正确的客户端已经加入，并且在1124向正在加入的客户端设备18发送SERVER_PROOF。
正在加入的客户端设备18在1126接收SERVER_PROOF，并且在接收到SERVER_PROOF之后，在1128将接收到的SERVER_PROOF与上述计算出的SERVER_PROOF值进行比较。正在加入的客户端设备18在1130确定这些值是否匹配。如果比较的值不同，则TLS会话在1132由于错误而停止，并且认为正在加入的客户端设备18加入了错误的网络。如果比较的值相匹配，则正在加入的客户端设备18在1134确定它已加入正确的局域网12。
可以认识到，上述原理可以应用于其他安全协商协议(包括多种基于TLS和SSL的密钥协定方案)，例如，TLS_RSA_WITH_RC4_128_SHA、TLS_RSA_WITH_AES_256_CBC_SHA等。此外，如RFC2246的6.3节所述，可以通过例如在推衍key_block之前将AUTHCODE40附加到master_secret或者将AUTHCODE40与master_secret进行异或，使AUTHCODE40参与master_secret或key_block计算。
还可以认识到，由于印刷、读取和输入代码所需的任务的性质，使AUTHCODE40包括足够的熵或随机性(这可能导致有效AUTHCODE40的空间成为可耗尽的集合)是不切实际的。在这种情况下，攻击者可以通过填充与HASH(AUTHCODE)相对应的值的数据库，来执行字典式攻击，并且等待ClientHello消息并针对检测到的散列值查找正确的AUTHCODE。可以通过散布(salt)散列输出来部分地阻碍这种攻击。例如，可以将ClientHello.random值可以分为两个部分：ClientHello.random＝SALT||HASH(SALT||AUTHCODE)，其中SALT是随机产生的足够大的值，例如，大至足以针对(SALT，AUTHCODE)的所有值防止创建值″SALT||HASH(SALT||AUTHCODE)″的字典。例如，对于多个应用，将SALT设置为80比特随机值可能是足够的。尽管这种散布技术可以使得免受字典式攻击，然而这种情况下的较低熵AUTHCODE40仍然可能容易受到蛮力攻击，在蛮力攻击中，攻击者观察合法加入以及值ClientHello.random＝SALT||HASH(SALT||AUTHCODE)，并且离线以计算HASH(SALT||AUTHCODE)直到发现正确的AUTHCODE40为止。应认识到，当AUTHCODE40没有足够的随机性时，图8到图11所示的方法可能容易受到字典式攻击和蛮力攻击之一或二者。
为了解决这些可能的攻击，现在将描述对TLS协议的附加修改和附加的TLS会话建立后的验证，所述对TLS协议的附加修改和附加的TLS会话建立后的验证可以基于IEEE1363.2中所述的基于口令的密钥协定方案和安全远程口令的使用。
现在参考图12，示出了在加入过程期间通过已建立的TLS会话验证AUTHCODE40的方法。在1200和1202，图12所述的方法分别在正在加入的客户端设备18与信任中心14之间建立TLS连接，然后用密钥确认(例如，在IEEE1363.2中规定的EC-SPEKE)执行基于口令的密钥协定协议。
在1204，正在加入的客户端设备18通过计算：Q＝f(HASH(ClientID||″.″||(ClientHello.random||ServerHello.random||AUTHCODE)))在椭圆曲线上产生基点Q，其中f是得到HASH的输出并将该输出映射到期望曲线上的椭圆曲线点的适合函数。然后，正在加入的客户端设备18在1206产生随机值a并计算QA＝aQ。然后在1208将QA发送给信任中心14。信任中心14在1210也以与正在加入的客户端设备18相同的方式产生Q，并且在1212产生随机值b并计算QB＝bQ。信任中心14在1214接收到QA并在1216计算K＝KDF(bQA)。可以认识到，KDF是适合的密钥推衍函数，例如，IEEE1363.2中所述的KDF。然后，信任中心14产生块SERVER_PROOF
CLIENT_PROOF＝PRF(K，(其他信息，例如ClientHello.random、ServerHello.random等))。例如，所述块可以包括以下格式：SERVER_PROOF||CLIENT_PROOF＝PRF(master_Secret，label，client_random+server_random+context_value_length+context_value)[length]，如上文所使用的。信任中心14在1236向正在加入的客户端设备18发送QB和SERVER_PROOF。
正在加入的客户端设备18在1222接收到QB和SERVER_PROOF，并在1224产生K＝KDF(aQB)。然后，正在加入的客户端设备18在1226产生块SERVER_PROOF||CLIENT_PROOF＝PRF(K，(其他信息，例如ClientHello.random、ServerHello.random等))。例如，所述块可以包括以下格式：SERVER_PROOF||CLIENT_PROOF＝PRF(master_secret，label，client_random+server_random+context_value_length+context_value)[length]，如上文所使用的。正在加入的客户端设备18在1228将接收到的SERVER_PROOF与根据所述块计算出的SERVER_PROOF进行比较。正在加入的客户端设备18在1230确定这些值是否匹配。如果不匹配，则在1232停止会话并指示错误。如果SERVER_PROOF值匹配，则正在加入的客户端设备18在1234向信任中心14发送CLIENT_PROOF，信任中心14在1238接收到CLIENT_PROOF。信任中心14在1240将接收到的CLIENT PROOF与根据所述块计算出的CLIENT_PROOF进行比较，并且在1242确定这些值是否匹配。如果不匹配，则在1244断开连接从而指示错误。如果CLIENT_PROOF值匹配，则在1246允许正在加入的客户端设备18加入局域网12。
现在参考13，示出了在加入处理中在建立TLS会话期间验证AUTHCODE的方法。应认识到，在TLS会话的ECDH方案中使用的基点可以被修改以验证AUTHCODE，并且可以使用基于口令的密钥协定协议以便直接建立TLS会话密钥。仅当由两个端点使用的AUTHCODE40是相同的，TLS会话才是成功的。
如图13所示，当在1300和1302分别参与建立TLS会话之后，正在加入的客户端设备18和信任中心14可以在1304和1308分别产生新的基点Q。将新的基点用于ECDH操作，其中Q＝f(HASH(AGREED_UPON_STRING||″.″(ClientHello.random)||(ServerHello.random||AUTHCODE)))，其中f是得到HASH的输出并在TLS协商曲线上产生椭圆曲线点的适合函数。
客户端在1306将基点Q用作基点进行ECDHE密钥交换，并且信任中心14在1310类似地使用Q。
可以认识到，考虑到两种解决方案之间的相似性，上述原理还可以用于数据报TLS(DTLS)。DTLS协议确保UDP网络通信安全性，并且被设计为与TLS相似，以便使大多数协议消息保持相同，从而允许许多相同的TLS密码套件用于DTLS。一些机器到机器的网络(例如，如图1和2所示的网络)可以使用UDP和DTLS。针对这种环境设计的一个示例性应用层协议是CoAP，其目的在于通过UDP提供类似HTTP的协议，并且用DTLS确保安全性。当用“证书模式”确保CoAP的安全性时，即，用证书提供安全性，可能存在上述的操纵问题。因此，可以应用这里所述的原理以解决这种操纵问题。
类似地，如上所述，AUTHCODE40还可以用于诸如IPSec等的其他安全协商协议中。例如，可以通过将互联网密钥交换(IKE)修改为在密钥推衍步骤中包括AUTHCODE(RFC4306的2.13节中针对IKE v2所述的)，来修改IPSec中使用的密钥协定协议。
因此，提供了一种使客户端设备能够与网络相连的方法，所述方法包括：通过不同于网络的通信信道获得授权码，所述授权码与客户端设备相对应；以及在检测到由客户端设备发起安全协商协议之后，将所述授权码用于至少一个安全协商操作。
还提供了一种与网络相连的方法，所述方法包括：客户端设备发起与网络的服务器设备的安全协商协议；以及将授权码用于至少一个安全协商操作，所述授权码已经通过不同于网络的通信信道提供给服务器设备，所述授权码与客户端设备相对应。
提供了一种使客户端设备能够与网络相连的方法，所述方法包括：通过不同于网络的通信信道向客户端设备提供授权码，所述授权码与客户端设备相对应；以及在检测到由客户端设备发起安全协商协议之后，将所述授权码用于至少一个安全协商操作。
还提供了一种包括用于执行上述方法的指令的计算机可读介质、以及被配置用于执行上述方法的客户端设备和服务器设备。
应认识到，这里所例示的执行指令的任何模块或组件可以包括或另外有权访问计算机可读介质，例如，存储介质、计算机存储介质、或诸如磁盘、光盘或磁带等的数据存储设备(可移除的和/或不可移除的)。计算机存储介质可以包括易失性的和非易失性的、可移除的和不可移除的介质，所述介质实现在任何方法或技术中以用于存储信息，例如计算机可读指令、数据结构、程序模块或其他数据。计算机存储介质的示例包括：RAM、ROM、EEPROM、闪存或其他存储技术、CD-ROM、数字通用光盘(DVD)或其他光学存储设备、磁带盒、磁带、磁盘存储器或其他磁性存储设备、或可以用于存储所需信息并可以由应用、模块或二者访问的任何其他介质。任何这种计算机存储介质可以是**的一部分、**的任何组件或与**相关的任何组件等，或可访问或可连接。可以使用计算机可读/可执行指令来实现这里所述的任何应用或模块，其中通过这种计算机可读介质存储或另外保存所述计算机可读/可执行指令。
这里所述的流程图和示意图中的步骤或操作仅是示例性的。可以存在对这种步骤或操作的多种变型，而不脱离上述的原理。例如，可以以不同顺序执行所述步骤，或可以添加、删除或修改所述步骤。
尽管参考一些具体示例描述了以上原理，然而如所附权利要求所述，多种修改对于本领域技术人员而言将是显而易见的。

Claims (13)

1.一种能够在服务器(14、14’)中操作的使客户端设备(18、18’)能够与网络(12、12’)相连的方法，所述方法包括：
通过不同于所述网络(12、12’)的带外通信信道(22、22’)获得授权码(20、40)，所述授权码与所述客户端设备(18、18’)相对应；以及
在检测到由所述客户端设备发起(1002)安全协商协议之后，将所述授权码用于(624)在建立传输层安全TLS会话期间产生pre_master_secret包括：
获得经协商的密钥椭圆曲线点(Q)；
将椭圆曲线点值乘以(1010)所述授权码；以及
根据乘积的x坐标形成(1012)所述pre_master_secret。
2.根据权利要求1所述的方法，还包括至少一个以下操作：
当安全协商成功时，允许所述客户端设备访问至少一个网络资源；以及
获得所述客户端设备的公钥(C)，并将所述公钥和所述授权码(40)用于向所述服务器设备(14、14’)认证所述客户端设备。
3.根据权利要求2所述的方法，所述客户端设备的所述公钥是在数字证书中提供的。
4.根据权利要求1到3中任一项所述的方法，包括在所述服务器上手动地输入所述授权码。
5.根据权利要求1所述的方法，在使用所述安全协商协议完成安全会话之后，将所述授权码用于建立密钥。
6.一种将客户端设备(18、18’)与网络相连的方法，所述方法包括：
客户端设备(18)发起(1000)与所述网络的服务器设备(14、14’)的安全协商协议；以及
将授权码(20、40)用于在建立传输层安全TLS会话期间产生pre_master_secret包括：
获得经协商的密钥椭圆曲线点(Q)；
将椭圆曲线点值乘以(1004)所述授权码；以及
根据乘积的x坐标形成(1006)所述pre_master_secret，
所述授权码已经通过不同于所述网络(12、12’)的带外通信信道(22、22’)提供给所述服务器设备，所述授权码与所述客户端设备相对应。
7.根据权利要求6所述的方法，还包括至少一个以下操作：
在安全协商成功之后，访问至少一个网络资源；以及
获得所述服务器设备的公钥(T)，并将所述公钥和所述授权码用于向所述服务器设备认证所述客户端设备。
8.根据权利要求7所述的方法，所述服务器设备的所述公钥是在数字证书中提供的。
9.根据权利要求6到8中任一项所述的方法，其中，将所述授权码印刷在所述客户端设备(18、18’)上。
10.根据权利要求6所述的方法，在使用所述安全协商协议完成安全会话之后，将所述授权码用于建立密钥。
11.一种使客户端设备能够与网络相连的方法，所述方法包括：
通过不同于所述网络的带外通信信道向所述客户端设备提供授权码，所述授权码与所述客户端设备相对应；以及
在检测到由所述客户端设备发起(1000)安全协商协议之后，将所述授权码用于在建立传输层安全TLS会话期间产生pre_master_secret包括：
获得经协商的密钥椭圆曲线点(Q)；
将椭圆曲线点值乘以(1004)所述授权码；以及
根据乘积的x坐标形成(1006)所述pre_master_secret。
12.一种计算机可读存储介质，包括用于执行根据权利要求1到11中任一项所述方法的计算机可执行指令。
13.一种使客户端设备与网络相连的设备，包括处理器和存储器，所述存储器包括计算机可执行指令，所述计算机可执行指令用于作为服务器设备根据权利要求1到5或权利要求11中任一项所述的方法操作或者用于作为客户端设备根据权利要求6到10中任一项所述的方法操作。
CN201380012082.5A 2012-03-01 2013-02-28 用于将客户端设备与网络相连的***和方法 Active CN104160656B (zh)

Applications Claiming Priority (7)

Application Number Priority Date Filing Date Title
US201261605598P 2012-03-01 2012-03-01
US61/605,598 2012-03-01
EP13151270.9 2013-01-15
US13/741,598 US9106635B2 (en) 2012-03-01 2013-01-15 System and method for connecting client devices to a network
EP13151270.9A EP2634993B1 (en) 2012-03-01 2013-01-15 Devices and methods for connecting client devices to a network
US13/741,598 2013-01-15
PCT/CA2013/050150 WO2013127014A1 (en) 2012-03-01 2013-02-28 System and method for connecting client devices to a network

Publications (2)

Publication Number Publication Date
CN104160656A CN104160656A (zh) 2014-11-19
CN104160656B true CN104160656B (zh) 2017-08-29

Family

ID=47632834

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201380012082.5A Active CN104160656B (zh) 2012-03-01 2013-02-28 用于将客户端设备与网络相连的***和方法

Country Status (5)

Country Link
US (2) US9106635B2 (zh)
EP (1) EP2634993B1 (zh)
CN (1) CN104160656B (zh)
CA (1) CA2865835C (zh)
WO (1) WO2013127014A1 (zh)

Families Citing this family (28)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9531691B2 (en) 2011-12-16 2016-12-27 Akamai Technologies, Inc. Providing forward secrecy in a terminating TLS connection proxy
US9350550B2 (en) * 2013-09-10 2016-05-24 M2M And Iot Technologies, Llc Power management and security for wireless modules in “machine-to-machine” communications
WO2015095463A1 (en) * 2013-12-18 2015-06-25 Akamai Technologies, Inc. Providing forward secrecy in a terminating tls connection proxy
US10389714B2 (en) 2014-03-31 2019-08-20 Idaax Technologies Private Limited Increased communication security
US9426136B2 (en) 2014-03-31 2016-08-23 EXILANT Technologies Private Limited Increased communication security
US9419949B2 (en) 2014-03-31 2016-08-16 EXILANT Technologies Private Limited Increased communication security
US9602486B2 (en) * 2014-03-31 2017-03-21 EXILANT Technologies Private Limited Increased communication security
US9419979B2 (en) * 2014-03-31 2016-08-16 EXILANT Technologies Private Limited Increased communication security
US9426148B2 (en) * 2014-03-31 2016-08-23 EXILANT Technologies Private Limited Increased communication security
US9426135B2 (en) 2014-03-31 2016-08-23 EXILANT Technologies Private Limited Increased communication security
US9485091B2 (en) 2014-05-01 2016-11-01 International Business Machines Corporation Dual-party session key derivation
US9531542B2 (en) 2014-09-19 2016-12-27 Bank Of America Corporation Secure remote password
US9935925B2 (en) * 2014-10-03 2018-04-03 Intrinsic Id B.V. Method for establishing a cryptographically protected communication channel
CN105721409B (zh) * 2014-12-03 2019-06-25 西安西电捷通无线网络通信股份有限公司 具有wlan功能的设备接入网络的方法及实现该方法的设备
DE102015214267A1 (de) * 2015-07-28 2017-02-02 Siemens Aktiengesellschaft Verfahren und System zum Erzeugen eines sicheren Kommunikationskanals für Endgeräte
US9888037B1 (en) * 2015-08-27 2018-02-06 Amazon Technologies, Inc. Cipher suite negotiation
US9912486B1 (en) 2015-08-27 2018-03-06 Amazon Technologies, Inc. Countersigned certificates
US10454689B1 (en) 2015-08-27 2019-10-22 Amazon Technologies, Inc. Digital certificate management
US11197331B2 (en) * 2016-06-10 2021-12-07 Apple Inc. Zero-round-trip-time connectivity over the wider area network
US10484173B2 (en) * 2017-01-03 2019-11-19 Nxp B.V. X-only generic mapping function for PACE protocol
CN108667609B (zh) * 2017-04-01 2021-07-20 西安西电捷通无线网络通信股份有限公司 一种数字证书管理方法及设备
CN108667781A (zh) * 2017-04-01 2018-10-16 西安西电捷通无线网络通信股份有限公司 一种数字证书管理方法及设备
CN109474432B (zh) 2017-09-07 2021-11-02 西安西电捷通无线网络通信股份有限公司 数字证书管理方法及设备
CN108462575B (zh) * 2018-03-09 2020-10-09 西安电子科技大学 基于无可信中心门限混合加密的上传数据加密方法
MX2021012566A (es) * 2019-04-15 2022-01-04 Aclara Tech Llc Sistema y método para una mejor seguridad en redes de infraestructura de medición avanzada.
US10848481B1 (en) * 2019-05-17 2020-11-24 The Florida International University Board Of Trustees Systems and methods for revocation management in an AMI network
CN111259356B (zh) * 2020-02-17 2022-09-02 北京百度网讯科技有限公司 授权方法、辅助授权组件、管理服务器和计算机可读介质
JP2023008607A (ja) * 2021-07-06 2023-01-19 株式会社野村総合研究所 検証可能なクレームを取得するユーザ装置、当該ユーザ装置を含むシステム及び検証可能なクレームを取得する方法

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1969501A (zh) * 2004-04-30 2007-05-23 捷讯研究有限公司 安全地产生共享密钥的***和方法
US7814538B2 (en) * 2005-12-13 2010-10-12 Microsoft Corporation Two-way authentication using a combined code
CN102215487A (zh) * 2010-04-09 2011-10-12 国际商业机器公司 通过公共无线网络安全地接入专用网络的方法和***

Family Cites Families (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7139917B2 (en) * 2000-06-05 2006-11-21 Phoenix Technologies Ltd. Systems, methods and software for remote password authentication using multiple servers
WO2001097480A2 (en) 2000-06-12 2001-12-20 Mediashell Corp. System and method for controlling the access to digital works through a network
US7246236B2 (en) * 2002-04-18 2007-07-17 Nokia Corporation Method and apparatus for providing peer authentication for a transport layer session
US7448068B2 (en) 2002-10-21 2008-11-04 Microsoft Corporation Automatic client authentication for a wireless network protected by PEAP, EAP-TLS, or other extensible authentication protocols
US7467405B2 (en) 2004-06-22 2008-12-16 Taiwan Semiconductor Manufacturing Company, Ltd. Method and apparatus for detecting an unauthorized client in a network of computer systems
US20060095767A1 (en) * 2004-11-04 2006-05-04 Nokia Corporation Method for negotiating multiple security associations in advance for usage in future secure communication
US7764785B2 (en) * 2004-11-08 2010-07-27 King Fahd University Of Petroleum And Minerals Method for communicating securely over an insecure communication channel
DE602005020702D1 (de) * 2005-10-18 2010-05-27 Telecom Italia Spa Verfahren zur skalarmultiplikation in gruppen elliptischer kurven über primkörpern für nebenkanal-attacken-beständige kryptosysteme
US7664259B2 (en) * 2006-03-09 2010-02-16 Motorola, Inc. Encryption and verification using partial public key
US8311214B2 (en) * 2006-04-24 2012-11-13 Motorola Mobility Llc Method for elliptic curve public key cryptographic validation
US8074265B2 (en) * 2006-08-31 2011-12-06 Red Hat, Inc. Methods and systems for verifying a location factor associated with a token
GB0623101D0 (en) * 2006-11-20 2006-12-27 British Telecomm Secure network architecture
US20080263363A1 (en) * 2007-01-22 2008-10-23 Spyrus, Inc. Portable Data Encryption Device with Configurable Security Functionality and Method for File Encryption
EP2334008A1 (en) * 2009-12-10 2011-06-15 Tata Consultancy Services Limited A system and method for designing secure client-server communication protocols based on certificateless public key infrastructure
WO2011120125A1 (en) * 2010-03-31 2011-10-06 Irdeto Canada Corporation System and method for protecting cryptographic assets from a white-box attack
US8856509B2 (en) * 2010-08-10 2014-10-07 Motorola Mobility Llc System and method for cognizant transport layer security (CTLS)
WO2012158453A1 (en) * 2011-05-16 2012-11-22 Panasonic Corporation Duplication judgment device and duplication management system

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1969501A (zh) * 2004-04-30 2007-05-23 捷讯研究有限公司 安全地产生共享密钥的***和方法
US7814538B2 (en) * 2005-12-13 2010-10-12 Microsoft Corporation Two-way authentication using a combined code
CN102215487A (zh) * 2010-04-09 2011-10-12 国际商业机器公司 通过公共无线网络安全地接入专用网络的方法和***

Also Published As

Publication number Publication date
US9621545B2 (en) 2017-04-11
CA2865835A1 (en) 2013-09-06
EP2634993B1 (en) 2017-01-11
EP2634993A1 (en) 2013-09-04
CA2865835C (en) 2021-02-16
US20130232554A1 (en) 2013-09-05
US20150319164A1 (en) 2015-11-05
WO2013127014A1 (en) 2013-09-06
US9106635B2 (en) 2015-08-11
CN104160656A (zh) 2014-11-19

Similar Documents

Publication Publication Date Title
CN104160656B (zh) 用于将客户端设备与网络相连的***和方法
JP7454035B2 (ja) ブロックチェーンにより実装される方法及びシステム
EP3437247B1 (en) System and method for distribution of identity based key material and certificate
Karuppiah et al. A secure remote user mutual authentication scheme using smart cards
US9698985B2 (en) Authentication
CN108965338B (zh) 多服务器环境下的三因素身份认证及密钥协商的方法
US8971540B2 (en) Authentication
CN104378374B (zh) 一种基于安全套接层建立通信的方法及***
BR102019015369A2 (pt) Sistema para provisionar uma conexão segura a uma conexão interdispositivo e método para provisionar uma conexão segura a uma conexão interdispositivo entre um primeiro dispositivo e um segundo e sistema
CN107040373A (zh) 相互认证方法及认证设备
CN110268676A (zh) 基于身份的自认证签名方案的私有密钥计算***和方法
US9106644B2 (en) Authentication
Amin et al. A Two‐Factor RSA‐Based Robust Authentication System for Multiserver Environments
CN106797313A (zh) 利用动态密钥生成的网络认证***
CN105119894B (zh) 基于硬件安全模块的通信***及通信方法
Tsai et al. A chaotic map‐based anonymous multi‐server authenticated key agreement protocol using smart card
CN109075965A (zh) 使用口令码验证的前向安全密码技术的方法、***和装置
Guo et al. An efficient and secure certificateless authentication protocol for healthcare system on wireless medical sensor networks
CN112468983B (zh) 一种低功耗的电力物联网智能设备接入认证方法及其辅助装置
Rana et al. Cryptanalysis and improvement of biometric based content distribution framework for digital rights management systems
Malina et al. Efficient and secure access control system based on programmable smart cards
Truong et al. Chebyshev Polynomial‐Based Authentication Scheme in Multiserver Environment
Pippal et al. A novel smart card mutual authentication scheme for session transfer among registered devices
Kiiver NFC Security Solution for Web Applications

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
C10 Entry into substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant
TR01 Transfer of patent right

Effective date of registration: 20191031

Address after: Voight, Ontario, Canada

Patentee after: BlackBerry Ltd.

Address before: Rika Univ.

Patentee before: CERTICOM Corp.

TR01 Transfer of patent right
TR01 Transfer of patent right

Effective date of registration: 20240605

Address after: Ai Erlandubailin

Patentee after: Maliki Innovation Co.,Ltd.

Country or region after: Ireland

Address before: Voight, Ontario, Canada

Patentee before: BlackBerry Ltd.

Country or region before: Canada

TR01 Transfer of patent right