CN106105137A - 使用终端用户联合登录来检测密钥交换加密信道中的破坏 - Google Patents

使用终端用户联合登录来检测密钥交换加密信道中的破坏 Download PDF

Info

Publication number
CN106105137A
CN106105137A CN201580011495.0A CN201580011495A CN106105137A CN 106105137 A CN106105137 A CN 106105137A CN 201580011495 A CN201580011495 A CN 201580011495A CN 106105137 A CN106105137 A CN 106105137A
Authority
CN
China
Prior art keywords
peer device
provider
authentication response
equipment
certification
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.)
Pending
Application number
CN201580011495.0A
Other languages
English (en)
Inventor
P·T·恩古延
C·A·G·麦克唐纳德
G·伯恩斯
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.)
Qualcomm Inc
Original Assignee
Qualcomm Inc
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 Qualcomm Inc filed Critical Qualcomm Inc
Publication of CN106105137A publication Critical patent/CN106105137A/zh
Pending legal-status Critical Current

Links

Classifications

    • 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/0841—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 Diffie-Hellman or related key agreement protocols
    • 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/0815—Network architectures or network communication protocols for network security for authentication of entities providing single-sign-on or federations
    • 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
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/14—Session management
    • H04L67/141—Setup of application sessions
    • 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/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • 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/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3271—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using challenge-response
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H04W12/069—Authentication using certificates or pre-shared keys
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/70—Services for machine-to-machine communication [M2M] or machine type communication [MTC]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/80—Services using short range communication, e.g. near-field communication [NFC], radio-frequency identification [RFID] or low energy communication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/24—Key scheduling, i.e. generating round keys or sub-keys for block encryption

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer And Data Communications (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

公开了用于认证第一对等设备和第二对等设备之间的密钥交换的方法和系统。在一方面，第一对等设备将用户的联合登录凭证和第一标识符发送到第一联合登录提供方，从第一联合登录提供方接收第一认证响应，从第二对等设备接收第二认证响应，向第二联合登录提供方认证第二认证响应，将第一认证响应发送到第二对等设备，从第二对等设备接收指示第二对等设备已经向联合登录提供方认证第一认证响应的确认，向第二对等设备发送指示第一对等设备已经认证第二认证响应的确认，并且基于来自第二对等设备的确认来认证密钥交换。

Description

使用终端用户联合登录来检测密钥交换加密信道中的破坏
相关申请的交叉引用
本专利申请要求于2014年3月5日提交的题为“USING END-USER FEDERATED LOGINTO DETECT A BREACH IN A DIFFIE-HELLMAN KEY EXCHANGE ENCRYPTED CHANNEL(使用终端用户联合登录来检测DIFFIE-HELLMAN密钥交换加密信道中的破坏)”的美国临时申请No.61/948,433的权益，该临时申请已被转让给本申请受让人并由此通过援引明确地整体纳入于此。
技术领域
本文描述的各种实施例一般涉及使用终端用户联合登录来检测密钥交换加密信道中的破坏。
背景
因特网是使用标准网际协议套件(例如，传输控制协议(TCP)和网际协议(IP))来彼此通信的互联的计算机和计算机网络的全球系统。物联网(IoT)基于日常对象(不仅是计算机和计算机网络)可经由IoT通信网络(例如，自组织(ad-hoc)系统或因特网)可读、可识别、可定位、可寻址、以及可控制的理念。
数个市场趋势正推动IoT设备的开发。例如，增加的能源成本正推动政府在智能电网以及将来消费支持(诸如电动车辆和公共充电站)中的战略性投资。增加的卫生保健成本和老龄化人口正推动对远程/联网卫生保健和健康服务的开发。家庭中的技术革命正推动对新的“智能”服务的开发，包括由营销‘N’种活动(‘N’play)(例如，数据、语音、视频、安全性、能源管理等)并扩展家庭网络的服务提供者所进行的联合。作为降低企业设施的运作成本的手段，建筑物正变得更智能和更方便。
存在用于IoT的数个关键应用。例如，在智能电网和能源管理领域，公共事业公司可以优化能源到家庭和企业的递送，同时消费者能更好地管理能源使用。在家庭和建筑物自动化领域，智能家居和建筑物可具有对家或办公室中的实质上任何设备或系统的集中式控制，从电器到插入式电动车辆(PEV)安全性系统。在资产跟踪领域，企业、医院、工厂和其他大型组织能准确跟踪高价值装备、患者、车辆等的位置。在卫生和健康领域，医生能远程监视患者的健康，同时人们能跟踪健康例程的进度。
概述
以下呈现了涉及与本文公开的使用终端用户联合登录来检测密钥交换加密信道中的破坏的机制相关联的一个或多个方面和/或实施例的简要概述。如此，以下概述既不应被视为与所有构想的方面和/或实施例相关的详尽纵览，以下概述也不应被认为标识与所有构想的方面和/或实施例相关的关键性或决定性要素或描绘与任何特定方面和/或实施例相关联的范围。相应地，以下概述的唯一目的是在以下给出的详细描述之前以简化形式呈现与关于本文所公开的机制的一个或多个方面和/或实施例相关的某些概念。
公开了用于认证第一对等设备和第二对等设备之间的密钥交换的系统和方法。一种认证第一对等设备与第二对等设备之间的密钥交换的方法包括：由第一对等设备将第一对等设备的用户的联合登录凭证和第一标识符发送到第一联合登录提供方，其中第二对等设备将该用户的联合登录凭证和第二标识符发送到第二联合登录提供方；由第一对等设备从第一联合登录提供方接收第一认证响应，其中第二对等设备从第二联合登录提供方接收第二认证响应；由第一对等设备从第二对等设备接收第二认证响应；由第一对等设备向第二联合登录提供方认证第二认证响应；由第一对等设备将第一认证响应发送到第二对等设备，其中第二对等设备向第一联合登录提供方认证第一认证响应；由第一对等设备从第二对等设备接收指示第二对等设备已经认证第一认证响应的确认；由第一对等设备向第二对等设备发送指示第一对等设备已经认证第二认证响应的确认；以及由第一对等设备基于来自第二对等设备的确认来认证密钥交换，其中第二对等设备基于来自第一对等设备的确认来认证密钥交换。
一种用于认证第一对等设备与第二对等设备之间的密钥交换的装置包括：被配置成由第一对等设备将第一对等设备的用户的联合登录凭证和第一标识符发送到第一联合登录提供方的逻辑，其中第二对等设备将该用户的联合登录凭证和第二标识符发送到第二联合登录提供方；被配置成由第一对等设备从第一联合登录提供方接收第一认证响应的逻辑，其中第二对等设备从第二联合登录提供方接收第二认证响应；被配置成由第一对等设备从第二对等设备接收第二认证响应的逻辑；被配置成由第一对等设备向第二联合登录提供方认证第二认证响应的逻辑；被配置成由第一对等设备将第一认证响应发送到第二对等设备的逻辑，其中第二对等设备向第一联合登录提供方认证第一认证响应；被配置成由第一对等设备从第二对等设备接收指示第二对等设备已经认证第一认证响应的确认的逻辑；被配置成由第一对等设备向第二对等设备发送指示第一对等设备已经认证第二认证响应的确认的逻辑；以及被配置成由第一对等设备基于来自第二对等设备的确认来认证密钥交换的逻辑，其中第二对等设备基于来自第一对等设备的确认来认证密钥交换。
一种用于认证第一对等设备与第二对等设备之间的密钥交换的装备包括：用于由第一对等设备将第一对等设备的用户的联合登录凭证和第一标识符发送到第一联合登录提供方的装置，其中第二对等设备将该用户的联合登录凭证和第二标识符发送到第二联合登录提供方；用于由第一对等设备从第一联合登录提供方接收第一认证响应的装置，其中第二对等设备从第二联合登录提供方接收第二认证响应；用于由第一对等设备从第二对等设备接收第二认证响应的装置；用于由第一对等设备向第二联合登录提供方认证第二认证响应的装置；用于由第一对等设备将第一认证响应发送到第二对等设备的装置，其中第二对等设备向第一联合登录提供方认证第一认证响应；用于由第一对等设备从第二对等设备接收指示第二对等设备已经认证第一认证响应的确认的装置；用于由第一对等设备向第二对等设备发送指示第一对等设备已经认证第二认证响应的确认的装置；以及由第一对等设备基于来自第二对等设备的确认来认证密钥交换的装置，其中第二对等设备基于来自第一对等设备的确认来认证密钥交换。
一种用于认证第一对等设备与第二对等设备之间的密钥交换的非瞬态计算机可读介质包括：用于由第一对等设备将第一对等设备的用户的联合登录凭证和第一标识符发送到第一联合登录提供方的至少一条指令，其中第二对等设备将该用户的联合登录凭证和第二标识符发送到第二联合登录提供方；用于由第一对等设备从第一联合登录提供方接收第一认证响应的至少一条指令，其中第二对等设备从第二联合登录提供方接收第二认证响应；用于由第一对等设备从第二对等设备接收第二认证响应的至少一条指令；用于由第一对等设备向第二联合登录提供方认证第二认证响应的至少一条指令；用于由第一对等设备将第一认证响应发送到第二对等设备的至少一条指令，其中第二对等设备向第一联合登录提供方认证第一认证响应；用于由第一对等设备从第二对等设备接收指示第二对等设备已经认证第一认证响应的确认的至少一条指令；用于由第一对等设备向第二对等设备发送指示第一对等设备已经认证第二认证响应的确认的至少一条指令；以及用于由第一对等设备基于来自第二对等设备的确认来认证密钥交换的至少一条指令，其中第二对等设备基于来自第一对等设备的确认来认证密钥交换。
基于附图和详细描述，与本文公开的各机制相关联的其它目标和优点对本领域的技术人员而言将是显而易见的。
附图简述
对本公开的各方面及其许多伴随优点的更完整领会将因其在参考结合附图考虑的以下详细描述时变得更好理解而易于获得，附图仅出于解说目的被给出而不对本公开构成任何限定，并且其中：
图1A解说了根据本公开的一方面的无线通信系统的高级系统架构。
图1B解说了根据本公开的另一方面的无线通信系统的高级系统架构。
图1C解说了根据本公开的一方面的无线通信系统的高级系统架构。
图1D解说了根据本公开的一方面的无线通信系统的高级系统架构。
图1E解说了根据本公开的一方面的无线通信系统的高级系统架构。
图2A解说了根据本公开的各方面的示例性物联网(IoT)设备，而图2B解说了根据本公开的各方面的示例性无源IoT设备。
图3解说了根据本公开的一方面的包括被配置成执行功能性的逻辑的通信设备。
图4解说了根据本公开各方面的示例性服务器。
图5解说了根据本公开的一个方面的可支持可发现对等(P2P)服务的无线通信网络。
图6解说了根据本公开的一个方面的示例性环境，其中可发现P2P服务可被用于建立基于邻近性的分布式总线，各个设备可在该总线上通信。
图7解说了根据本公开的一个方面的示例性消息序列，其中可发现P2P服务可被用于建立基于邻近性的分布式总线，各个设备可在该总线上通信。
图8解说了本公开的安全服务的示例性系统架构。
图9解说了根据本公开的一方面的使用OpenID提供方来认证的示例性流程。
图10解说根据本公开的一方面的用于建立两个客户端之间的安全信道的示例性流程。
图11解说了根据本公开的一方面的图8中所解说的控制方和受控方之间的OpenID验证，其中受控方包括集束式安全桥。
图12解说了根据本公开的一方面的图8中所解说的控制方和受控方之间的OAuth验证，其中受控方不包括集束式安全桥。
图13解说了根据本公开的一方面的用于认证第一对等设备与第二对等设备之间的密钥交换的示例性流程。
图14是被配置成支持本文教导的通信的装备的若干范例方面的简化框图。
详细描述
本公开涉及用于认证第一对等设备和第二对等设备之间的密钥交换的方法和系统。在一方面，第一对等设备将第一对等设备的用户的联合登录凭证和第一标识符发送到第一联合登录提供方，其中第二对等设备将该用户的联合登录凭证和第二标识符发送到第二联合登录提供方，从第一联合登录提供方接收第一认证响应，其中第二对等设备从第二联合登录提供方接收第二认证响应，从第二对等设备接收第二认证响应，向第二联合登录提供方认证第二认证响应，将第一认证响应发送到第二对等设备，其中第二对等设备向第一联合登录提供方认证第一认证响应，从第二对等设备接收指示第二对等设备已经认证第一认证响应的确认，向第二对等设备发送指示第一对等设备已经认证第二认证响应的确认，并且基于来自第二对等设备的确认来认证密钥交换，其中第二对等设备基于来自第一对等设备的确认来认证密钥交换。
在以下描述和相关附图中公开了这些和其它方面以示出与本公开的示例性实施例相关的具体示例。替换实施例在相关领域的技术人员阅读本公开之后将是显而易见的，且可被构造并实施，而不背离本文公开的范围或精神。另外，众所周知的元素将不被详细描述或可将被省去以便不模糊本文公开的各方面和实施例的相关细节。
措辞“示例性”在本文中用于表示“用作示例、实例或解说”。本文中描述为“示例性”的任何实施例不必被解释为优于或胜过其他实施例。同样，术语“实施例”并不要求所有实施例都包括所讨论的特征、优点、或工作模式。
本文所使用的术语仅描述了特定实施例并且不应当被解读成限定本文所公开的任何实施例。如本文所使用的，单数形式的“一”、“一个”和“该”旨在也包括复数形式，除非上下文另有明确指示并非如此。还将理解，术语“包括”、“具有”、“包含”和/或“含有”在本文中使用时指定所陈述的特征、整数、步骤、操作、要素、和/或组件的存在，但并不排除一个或多个其他特征、整数、步骤、操作、要素、组件和/或其群组的存在或添加。
此外，许多方面以将由例如计算设备的元件执行的动作序列的方式来描述。将认识到，本文描述的各种动作能由专用电路(例如，专用集成电路(ASIC))、由正被一个或多个处理器执行的程序指令、或由这两者的组合来执行。另外，本文描述的这些动作序列可被认为是完全体现在任何形式的计算机可读存储介质内，其内存储有一经执行就将使相关联的处理器执行本文所描述的功能性的相应计算机指令集。因此，本公开的各种方面可以用数种不同形式来体现，所有这些形式都已被构想为落在所要求保护的主题内容的范围内。另外，对于本文所描述的每一个方面，任何此类方面的相应形式可在本文中被描述为例如“配置成执行所描述的动作的逻辑”。
如本文所使用的，术语“物联网设备”(或即“IoT设备”)可指代具有可寻址接口(例如，网际协议(IP)地址、蓝牙标识符(ID)、近场通信(NFC)ID等)并且可在有线或无线连接上向一个或多个其他设备传送信息的任何物体(例如，设施、传感器等)。IoT设备可具有无源通信接口(诸如快速响应(QR)码、射频标识(RFID)标签、NFC标签或类似物)或有源通信接口(诸如调制解调器、收发机、发射机-接收机、或类似物)。IoT设备可具有特定属性集(例如，设备状态或状况(诸如该IoT设备是开启还是关断、打开还是关闭、空闲还是活跃、可用于任务执行还是繁忙等)、冷却或加热功能、环境监视或记录功能、发光功能、发声功能等)，其可被嵌入到中央处理单元(CPU)、微处理器、ASIC或类似物等中，和/或由其控制/监视，并被配置用于连接至IoT网络(诸如局域自组织网络或因特网)。例如，IoT设备可包括但不限于：冰箱、烤面包机、烤箱、微波炉、冷冻机、洗碗机、器皿、手持工具、洗衣机、干衣机、炉子、空调、恒温器、电视机、灯具、吸尘器、洒水器、电表、燃气表等，只要这些设备装备有用于与IoT网络通信的可寻址通信接口即可。IoT设备还可包括蜂窝电话、智能电话、台式计算机、膝上型计算机、平板计算机、个人数字助理(PDA)等等。相应地，IoT网络可由“传统的”可接入因特网的设备(例如，膝上型或台式计算机、蜂窝电话等)以及通常不具有因特网连通性的设备(例如，洗碗机等)的组合构成。
图1A解说了根据本公开一方面的无线通信系统100A的高级系统架构。无线通信系统100A包含多个IoT设备，包括电视机110、室外空调单元112、恒温器114、冰箱116、以及洗衣机和干衣机118。
参照图1A，IoT设备110-118被配置成在物理通信接口或层(在图1A中被示为空中接口108和直接有线连接109)上与接入网(例如，接入点125)通信。空中接口108可遵循无线网际协议(IP)，诸如IEEE 802.11。尽管图1A解说了IoT设备110-118在空中接口108上通信，并且IoT设备118在直接有线连接109上通信，但每个IoT设备可在有线或无线连接、或这两者上通信。
因特网175包括数个路由代理和处理代理(出于方便起见未在图1A中示出)。因特网175是互联的计算机和计算机网络的全球系统，其使用标准网际协议套件(例如，传输控制协议(TCP)和IP)在不同的设备/网络之间通信。TCP/IP提供了端到端连通性，该连通性指定了数据应当如何被格式化、寻址、传送、路由和在目的地处被接收。
在图1A中，计算机120(诸如台式计算机或个人计算机(PC))被示为直接连接至因特网175(例如在以太网连接或者基于Wi-Fi或802.11网络上)。计算机120可具有到因特网175的有线连接，诸如到调制解调器或路由器的直接连接，在一示例中该路由器可对应于接入点125自身(例如，对于具有有线和无线连通性两者的Wi-Fi路由器)。替换地，并非在有线连接上被连接至接入点125和因特网175，计算机120可在空中接口108或另一无线接口上被连接至接入点125，并在空中接口108上接入因特网175。尽管被解说为台式计算机，但计算机120可以是膝上型计算机、平板计算机、PDA、智能电话、或类似物。计算机120可以是IoT设备和/或包含用于管理IoT网络/群(诸如IoT设备110-118的网络/群)的功能性。
接入点125可例如经由光学通信系统(诸如FiOS)、电缆调制解调器、数字订户线(DSL)调制解调器等被连接至因特网175。接入点125可使用标准网际协议(例如，TCP/IP)与IoT设备110-120和因特网175通信。
参照图1A，IoT服务器170被示为连接至因特网175。IoT服务器170可被实现为多个在结构上分开的服务器，或者替换地可对应于单个服务器。在一方面，IoT服务器170是可任选的(如由点线所指示的)，并且IoT设备110-120的群可以是对等(P2P)网络。在此种情形中，IoT设备110-120可在空中接口108和/或直接有线连接109上彼此直接通信。替换或附加地，IoT设备110-120中的一些或所有IoT设备可配置有独立于空中接口108和直接有线连接109的通信接口。例如，如果空中接口108对应于Wi-Fi接口，则IoT设备110-120中的一个或多个IoT设备可具有蓝牙或NFC接口以用于彼此直接通信或者与其他启用蓝牙或NFC的设备直接通信。
在对等网络中，服务发现方案可多播节点的存在、它们的能力、和群成员资格。对等设备可基于此信息来建立关联和后续交互。
根据本公开的一方面，图1B解说了包含多个IoT设备的另一无线通信系统100B的高级架构。一般而言，图1B中示出的无线通信系统100B可包括与以上更详细地描述的在图1A中示出的无线通信系统100A相同和/或基本相似的各种组件(例如，各种IoT设备，包括被配置成在空中接口108和/或直接有线连接109上与接入点125通信的电视机110、室外空调单元112、恒温器114、冰箱116、以及洗衣机和干衣机118，直接连接至因特网175和/或通过接入点125连接至因特网175的计算机120，以及可经由因特网175来访问的IoT服务器170等)。如此，出于描述的简洁和方便起见，与图1B中示出的无线通信系统100B中的某些组件相关的各种细节可在本文中省略，既然上面已关于图1A中解说的无线通信系统100A提供了相同或类似细节。
参照图1B，无线通信系统100B可包括监管器设备130，其可替换地被称为IoT监管器130或IoT监管器设备130。如此，在以下描述使用术语“监管器设备”130的情况下，本领域技术人员将领会，对IoT管理器、群主、或类似术语的任何引述可指代监管器设备130或提供相同或基本相似功能性的另一物理或逻辑组件。
在一个实施例中，监管器设备130一般可观察、监视、控制、或以其他方式管理无线通信系统100B中的各种其他组件。例如，监管器设备130可在空中接口108和/或直接有线连接109上与接入网(例如，接入点125)通信以监视或管理与无线通信系统100B中的各种IoT设备110-120相关联的属性、活动、或其他状态。监管器设备130可具有到因特网175的有线或无线连接，以及可任选地到IoT服务器170的有线或无线连接(被示为点线)。监管器设备130可从因特网175和/或IoT服务器170获得可被用来进一步监视或管理与各种IoT设备110-120相关联的属性、活动、或其他状态的信息。监管器设备130可以是自立设备或是IoT设备110-120之一，诸如计算机120。监管器设备130可以是物理设备或在物理设备上运行的软件应用。监管器设备130可包括用户接口，其可输出与所监视的关联于IoT设备110-120的属性、活动、或其他状态相关的信息并接收输入信息以控制或以其他方式管理与其相关联的属性、活动、或其他状态。相应地，监管器设备130一般可包括各种组件且支持各种有线和无线通信接口以观察、监视、控制、或以其他方式管理无线通信系统100B中的各种组件。
图1B中示出的无线通信系统100B可包括一个或多个无源IoT设备105(与有源IoT设备110-120形成对比)，其可被耦合至无线通信系统100B或以其他方式成为其一部分。一般而言，无源IoT设备105可包括条形码设备、蓝牙设备、射频(RF)设备、带RFID标签的设备、红外(IR)设备、带NFC标签的设备、或在短程接口上被查询时可向另一设备提供其标识符和属性的任何其他合适设备。有源IoT设备可对无源IoT设备的属性变化进行检测、存储、传达、动作等。
例如，无源IoT设备105可包括咖啡杯和橙汁容器，其各自具有RFID标签或条形码。橱柜IoT设备和冰箱IoT设备116可各自具有恰适的扫描器或读卡器，其可读取RFID标签或条形码以检测咖啡杯和/或橙汁容器无源IoT设备105何时已经被添加或移除。响应于橱柜IoT设备检测到咖啡杯无源IoT设备105的移除，并且冰箱IoT设备116检测到橙汁容器无源IoT设备的移除，监管器设备130可接收到与在橱柜IoT设备和冰箱IoT设备116处检测到的活动相关的一个或多个信号。监管器设备130随后可推断出用户正在用咖啡杯喝橙汁和/或想要用咖啡杯喝橙汁。
尽管前面将无源IoT设备105描述为具有某种形式的RFID标签或条形码通信接口，但无源IoT设备105也可包括不具有此类通信能力的一个或多个设备或其他物理对象。例如，某些IoT设备可具有恰适的扫描器或读取器机构，其可检测与无源IoT设备105相关联的形状、大小、色彩、和/或其他可观察特征以标识无源IoT设备105。以此方式，任何合适的物理对象可传达其身份和属性并且成为无线通信系统100B的一部分，且通过监管器设备130被观察、监视、控制、或以其他方式管理。此外，无源IoT设备105可被耦合至图1A中的无线通信系统100A或以其他方式成为其一部分，并且以基本类似的方式被观察、监视、控制、或以其他方式管理。
根据本公开的另一方面，图1C解说了包含多个IoT设备的另一无线通信系统100C的高级架构。一般而言，图1C中示出的无线通信系统100C可包括与以上更详细地描述的分别在图1A和1B中示出的无线通信系统100A和100B相同和/或基本相似的各种组件。如此，出于描述的简洁和方便起见，与图1C中示出的无线通信系统100C中的某些组件相关的各种细节可在本文中省略，既然上面已关于分别在图1A和1B中解说的无线通信系统100A和100B提供了相同或类似细节。
图1C中示出的通信系统100C解说了IoT设备110-118与监管器设备130之间的示例性对等通信。如图1C中所示，监管器设备130在IoT监管器接口上与IoT设备110-118中的每一个IoT设备通信。进一步，IoT设备110和114彼此直接通信，IoT设备112、114和116彼此直接通信，以及IoT设备116和118彼此直接通信。
IoT设备110-118组成IoT群160。IoT设备群160是本地连接的IoT设备(诸如连接至用户的家庭网络的IoT设备)的群。尽管未示出，但多个IoT设备群可经由连接至因特网175的IoT超级代理140来彼此连接和/或通信。在高层级，监管器设备130管理群内通信，而IoT超级代理140可管理群间通信。尽管被示为分开的设备，但监管器设备130和IoT超级代理140可以是相同设备或驻留在相同设备上(例如，自立设备或IoT设备，诸如图1A中示出的计算机120)。替换地，IoT超级代理140可对应于或包括接入点125的功能性。作为又一替换，IoT超级代理140可对应于或包括IoT服务器(诸如IoT服务器170)的功能性。IoT超级代理140可封装网关功能性145。
每个IoT设备110-118可将监管器设备130视为对等方并且向监管器设备130传送属性/纲要更新。当IoT设备需要与另一IoT设备通信时，它可向监管器设备130请求指向该IoT设备的指针，并且随后作为对等方与该目标IoT设备通信。IoT设备110-118使用共用消息接发协议(CMP)在对等通信网络上彼此通信。只要两个IoT设备都启用了CMP并且通过共用通信传输来连接，它们就可彼此通信。在协议栈中，CMP层154在应用层152之下并在传输层156和物理层158之上。
根据本公开的另一方面，图1D解说了包含多个IoT设备的另一无线通信系统100D的高级架构。一般而言，图1D中示出的无线通信系统100D可包括与以上更详细地描述的分别在图1A-C中示出的无线通信系统100A-C相同和/或基本相似的各种组件。如此，出于描述的简洁和容易起见，与图1D中所示的无线通信系统100D中的某些组件相关的各个细节在相同或类似细节已在以上分别关于图1A-C中解说的无线通信系统100A-C提供的程度上可在本文中省略。
因特网175是可使用IoT概念来管控的“资源”。然而，因特网175仅仅是被管控的资源的一个示例，并且任何资源可使用IoT概念来管控。可被管控的其他资源包括但不限于电力、燃气、存储、安全性等。IoT设备可被连接至该资源并由此管控它，或者该资源可在因特网175上被管控。图1D解说了若干资源180，诸如天然气、汽油、热水、以及电力，其中资源180可作为因特网175的补充和/或在因特网175上被管控。
IoT设备可彼此通信以管控它们对资源180的使用。例如，IoT设备(诸如烤面包机、计算机、和吹风机)可在蓝牙通信接口上彼此通信以管控它们对电力(资源180)的使用。作为另一示例，IoT设备(诸如台式计算机、电话、和平板计算机)可在Wi-Fi通信接口上通信以管控它们对因特网175(资源180)的接入。作为又一示例，IoT设备(诸如炉子、干衣机、和热水器)可在Wi-Fi通信接口上通信以管控它们对燃气的使用。替换或附加地，每个IoT设备可被连接至IoT服务器(诸如IoT服务器170)，该服务器具有用于基于从各IoT设备接收到的信息来管控它们对资源180的使用的逻辑。
根据本公开的另一方面，图1E解说了包含多个IoT设备的另一无线通信系统100E的高级架构。一般而言，图1E中示出的无线通信系统100E可包括与以上更详细地描述的分别在图1A-D中示出的无线通信系统100A-D相同和/或基本相似的各种组件。如此，出于描述的简洁和方便起见，与图1E中示出的无线通信系统100E中的某些组件相关的各种细节可在本文中省略，既然上面已关于分别在图1A-D中解说的无线通信系统100A-D提供了相同或类似细节。
通信系统100E包括两个IoT设备群160A和160B。多个IoT设备群可经由连接至因特网175的IoT超级代理彼此连接和/或通信。在高层级，IoT超级代理可管理各IoT设备群之间的群间通信。例如，在图1E中，IoT设备群160A包括IoT设备116A、122A和124A以及IoT超级代理140A，而IoT设备群160B包括IoT设备116B、122B和124B以及IoT超级代理140B。如此，IoT超级代理140A和140B可连接至因特网175并通过因特网175彼此通信，和/或彼此直接通信以促成IoT设备群160A与160B之间的通信。此外，尽管图1E解说了两个IoT设备群160A和160B经由IoT超级代理140A和140B彼此通信，但本领域技术人员将领会，任何数目的IoT设备群可合适地使用IoT超级代理来彼此通信。
图2A解说了根据本公开各方面的IoT设备200A的高级示例。尽管外观和/或内部组件在各IoT设备之间可能显著不同，但大部分IoT设备将具有某种类别的用户接口，该用户接口可包括显示器和用于用户输入的装置。可在有线或无线网络上与没有用户接口(诸如图1A-B的空中接口108)的IoT设备远程地通信。
如图2A中所示，在关于IoT设备200A的示例配置中，IoT设备200A的外壳可配置有显示器226、电源按钮222、以及两个控制按钮224A和224B、以及其他组件，如本领域已知的。显示器226可以是触摸屏显示器，在此情形中控制按钮224A和224B可以不是必需的。尽管未被明确地示为IoT设备200A的一部分，但IoT设备200A可包括一个或多个外部天线和/或被构建到外壳中的一个或多个集成天线，包括但不限于Wi-Fi天线、蜂窝天线、卫星定位系统(SPS)天线(例如，全球定位系统(GPS)天线)，等等。
尽管IoT设备(诸如IoT设备200A)的内部组件可使用不同硬件配置来实施，但内部硬件组件的基本高级配置在图2A中被示为平台202。平台202可接收和执行在网络接口(诸如图1A-B中的空中接口108和/或有线接口)上传送的软件应用、数据和/或命令。平台202还可独立地执行本地存储的应用。平台202可包括被配置用于有线和/或无线通信的一个或多个收发机206(例如，Wi-Fi收发机、蓝牙收发机、蜂窝收发机、卫星收发机、GPS或SPS接收机等)，其可操作地耦合至一个或多个处理器208，诸如微控制器、微处理器、专用集成电路、数字信号处理器(DSP)、可编程逻辑电路、或其他数据处理设备，其将一般性地被称为处理器208。处理器208可执行IoT设备的存储器212内的应用编程指令。存储器212可包括只读存储器(ROM)、随机存取存储器(RAM)、电可擦除可编程ROM(EEPROM)、闪存卡或计算机平台通用的任何存储器中的一者或多者。一个或多个输入/输出(I/O)接口214可被配置成允许处理器208与各种I/O设备(诸如所解说的显示器226、电源按钮222、控制按钮224A和224B，以及任何其他设备，诸如与IoT设备200A相关联的传感器、致动器、中继、阀、开关等)通信并从其进行控制。平台202还可包括密钥交换认证模块216，该模块可以是存储在存储器212中的可执行模块或者被纳入或耦合到处理器208的硬件/固件模块。
相应地，本公开的一方面可包括含有执行本文描述的功能的能力的IoT设备(例如，IoT设备200A)。如将由本领域技术人员领会的，各种逻辑元件可在分立元件、处理器(例如，处理器208)上执行的软件模块、或软件与硬件的任何组合中实施以达成本文公开的功能性。例如，收发机206、处理器208、存储器212、I/O接口214和/或密钥交换认证模块216可以全部协作地用来加载、存储和执行本文公开的各种功能，并且用于执行这些功能的逻辑因此可分布在各种元件上。替换地，该功能性可被纳入到一个分立的组件(诸如密钥交换认证模块216)中。因此，图2A中的IoT设备200A的特征将仅被视为解说性的，且本公开不被限定于所解说的特征或安排。
例如，在IoT设备200A是被配置成认证其自身与第二对等设备之间的密钥交换的第一对等设备的情况下，收发机206、处理器208、密钥交换认证模块216以及可任选的I/O接口214可以：将IoT设备200A的用户的联合登录凭证和第一标识符协同发送到第一联合登录提供方，其中第二对等设备将该用户的联合登录凭证和第二标识符发送到第二联合登录提供方；从第一联合登录提供方接收第一认证响应，其中第二对等设备从第二联合登录提供方接收第二认证响应；从第二对等设备接收第二认证响应；向第二联合登录提供方认证第二认证响应；将第一认证响应发送到第二对等设备，其中第二对等设备向第一联合登录提供方认证第一认证响应；从第二对等设备接收指示第二对等设备已经认证第一认证响应的确认；向第二对等设备发送指示IoT设备200A已经认证第二认证响应的确认；并且基于来自第二对等设备的确认来认证密钥交换，其中第二对等设备基于来自IoT设备200A的确认来认证密钥交换，如本文所描述的。在该情形中，IoT设备200A可以是控制方或受控方，如本文进一步描述的。
图2B解说了根据本公开各方面的无源IoT设备200B的高级示例。一般而言，图2B中示出的无源IoT设备200B可包括与以上更详细地描述的在图2A中示出的IoT设备200A相同和/或基本相似的各种组件。如此，出于描述的简洁和方便起见，与图2B中示出的无源IoT设备200B中的某些组件相关的各种细节可在本文中省略，既然上面已关于图2A中解说的IoT设备200A提供了相同或类似细节。
图2B中示出的无源IoT设备200B一般可不同于图2A中示出的IoT设备200A，不同之处在于无源IoT设备200B可不具有处理器、内部存储器、或某些其他组件。替代地，在一个实施例中，无源IoT设备200B可仅包括I/O接口214或者允许无源IoT设备200B在受控IoT网络内被观察、监视、控制、管理、或以其他方式知晓的其他合适的机构。例如，在一个实施例中，与无源IoT设备200B相关联的I/O接口214可包括条形码、蓝牙接口、射频(RF)接口、RFID标签、IR接口、NFC接口、或者在短程接口上被查询时可向另一设备(例如，有源IoT设备(诸如IoT设备200A)，其可对关于与无源IoT设备200B相关联的属性的信息进行检测、存储、传达、动作、或以其他方式处理)提供与无源IoT设备200B相关联的标识符和属性的任何其他合适的I/O接口。
在一方面，在IoT设备200B是被配置成认证其自身与第二对等设备之间的密钥交换的第一对等设备的情况下，收发机206、密钥交换认证模块216以及可任选的I/O接口214可以将IoT设备200B的用户的联合登录凭证和第一标识符协同发送到第一联合登录提供方，其中第二对等设备将该用户的联合登录凭证和第二标识符发送到第二联合登录提供方，从第一联合登录提供方接收第一认证响应，其中第二对等设备从第二联合登录提供方接收第二认证响应，从第二对等设备接收第二认证响应，向第二联合登录提供方认证第二认证响应，将第一认证响应发送到第二对等设备，其中第二对等设备向第一联合登录提供方认证第一认证响应，从第二对等设备接收指示第二对等设备已经认证第一认证响应的确认，向第二对等设备发送指示IoT设备200A已经认证第二认证响应的确认，并且基于来自第二对等设备的确认来认证密钥交换，其中第二对等设备基于来自IoT设备200B的确认来认证密钥交换，如本文所描述的。在该情形中，IoT设备200B可以是受控方设备，如本文进一步描述的。密钥交换认证模块216被解说为是可任选的，因为不是每一无源IoT设备都可包括密钥交换认证模块216。
尽管前面将无源IoT设备200B描述为具有某种形式的RF、条形码、或其他I/O接口214，但无源IoT设备200B可包括不具有此类I/O接口214的设备或其他物理对象。例如，某些IoT设备可具有恰适的扫描器或读取器机构，其可检测与无源IoT设备200B相关联的形状、大小、色彩、和/或其他可观察特征以标识无源IoT设备200B。以此方式，任何合适的物理对象可传达其身份和属性并且在受控IoT网络内被观察、监视、控制、或以其他方式被管理。
图3解说了包括配置成执行功能性的逻辑的通信设备300。通信设备300可对应于以上提及的通信设备中的任一者，包括但不限于IoT设备110-120、IoT设备200A、耦合至因特网175的任何组件(例如，IoT服务器170)等等。因此，通信设备300可对应于被配置成在图1A-B的无线通信系统100A-B上与一个或多个其它实体通信(或促成与一个或多个其它实体的通信)的任何电子设备。
参照图3，通信设备300包括配置成接收和/或传送信息的逻辑305。在一示例中，如果通信设备300对应于无线通信设备(例如，IoT设备200A和/或无源IoT设备200B)，则配置成接收和/或传送信息的逻辑305可包括无线通信接口(例如，蓝牙、WiFi、Wi-Fi直连、长期演进(LTE)直连等)，诸如无线收发机和相关联的硬件(例如，RF天线、调制解调器、调制器和/或解调器等)。在另一示例中，配置成接收和/或传送信息的逻辑305可对应于有线通信接口(例如，串行连接、USB或火线连接、可藉以接入因特网175的以太网连接等)。因此，如果通信设备300对应于某种类型的基于网络的服务器(例如，应用170)，则配置成接收和/或传送信息的逻辑305在一示例中可对应于以太网卡，该以太网卡经由以太网协议将基于网络的服务器连接至其它通信实体。在进一步示例中，配置成接收和/或传送信息的逻辑305可包括传感或测量硬件(例如，加速计、温度传感器、光传感器、用于监视本地RF信号的天线等)，通信设备300可藉由该传感或测量硬件来监视其本地环境。配置成接收和/或传送信息的逻辑305还可包括在被执行时准许配置成接收和/或传送信息的逻辑305的相关联硬件执行其接收和/或传送功能的软件。然而，配置成接收和/或传送信息的逻辑305不单单对应于软件，并且配置成接收和/或传送信息的逻辑305至少部分地依赖于硬件来实现其功能性。
参照图3，通信设备300进一步包括配置成处理信息的逻辑310。在一示例中，配置成处理信息的逻辑310可至少包括处理器。可由配置成处理信息的逻辑310执行的处理类型的示例实现包括但不限于执行确定、建立连接、在不同信息选项之间作出选择、执行与数据有关的评价、与耦合至通信设备300的传感器交互以执行测量操作、将信息从一种格式转换为另一种格式(例如，在不同协议之间转换，诸如，.wmv到.avi等)，等等。例如，包括在配置成处理信息的逻辑310中的处理器可对应于被设计成执行本文描述功能的通用处理器、DSP、ASIC、现场可编程门阵列(FPGA)或其他可编程逻辑器件、分立的门或晶体管逻辑、分立的硬件组件、或其任何组合。通用处理器可以是微处理器，但在替换方案中，该处理器可以是任何常规的处理器、控制器、微控制器、或状态机。处理器还可以被实现为计算设备的组合(例如DSP与微处理器的组合、多个微处理器、与DSP核协作的一个或多个微处理器、或任何其他此类配置)。配置成处理信息的逻辑310还可包括在被执行时准许配置成处理信息的逻辑310的相关联硬件执行其处理功能的软件。然而，配置成处理信息的逻辑310不单单对应于软件，并且配置成处理信息的逻辑310至少部分地依赖于硬件来实现其功能性。
参照图3，通信设备300进一步包括配置成存储信息的逻辑315。在一示例中，配置成存储信息的逻辑315可至少包括非瞬态存储器和相关联的硬件(例如，存储器控制器等)。例如，包括在配置成存储信息的逻辑315中的非瞬态存储器可对应于RAM、闪存、ROM、可擦除式可编程ROM(EPROM)、EEPROM、寄存器、硬盘、可移动盘、CD-ROM、或本领域中已知的任何其他形式的存储介质。配置成存储信息的逻辑315还可包括在被执行时准许配置成存储信息的逻辑315的相关联硬件执行其存储功能的软件。然而，配置成存储信息的逻辑315不单单对应于软件，并且配置成存储信息的逻辑315至少部分地依赖于硬件来实现其功能性。
在一方面，在通信设备300是被配置成认证其自身与第二对等设备之间的密钥交换的第一对等设备的情况下，被配置成接收和/或发送信息的逻辑305、被配置成处理信息的逻辑310以及被配置成存储信息的逻辑315可以将通信设备300的用户的联合登录凭证和第一标识符协同发送到第一联合登录提供方，其中第二对等设备将该用户的联合登录凭证和第二标识符发送到第二联合登录提供方，从第一联合登录提供方接收第一认证响应，其中第二对等设备从第二联合登录提供方接收第二认证响应，从第二对等设备接收第二认证响应，向第二联合登录提供方认证第二认证响应，将第一认证响应发送到第二对等设备，其中第二对等设备向第一联合登录提供方认证第一认证响应，从第二对等设备接收指示第二对等设备已经认证第一认证响应的确认，向第二对等设备发送指示通信设备300已经认证第二认证响应的确认，并且基于来自第二对等设备的确认来认证密钥交换，其中第二对等设备基于来自通信设备300的确认来认证密钥交换，如本文所描述的。在该情形中，通信设备300可以是控制方或受控方设备，如本文进一步描述的。
参照图3，通信设备300进一步可任选地包括配置成呈现信息的逻辑320。在一示例中，配置成呈现信息的逻辑320可至少包括输出设备和相关联的硬件。例如，输出设备可包括视频输出设备(例如，显示屏、能承载视频信息的端口，诸如USB、HDMI等)、音频输出设备(例如，扬声器、能承载音频信息的端口，诸如话筒插孔、USB、HDMI等)、振动设备和/或信息可此被格式化以供输出或实际上由通信设备300的用户或操作者输出的任何其它设备。例如，如果通信设备300对应于如图2A中所示的IoT设备200A和/或如图2B中所示的无源IoT设备200B，则配置成呈现信息的逻辑320可包括显示器226。在进一步示例中，对于某些通信设备(诸如不具有本地用户的网络通信设备(例如，网络交换机或路由器、远程服务器等))而言，配置成呈现信息的逻辑320可被省略。配置成呈现信息的逻辑320还可包括在被执行时准许配置成呈现信息的逻辑320的相关联硬件执行其呈现功能的软件。然而，配置成呈现信息的逻辑320不单单对应于软件，并且配置成呈现信息的逻辑320至少部分地依赖于硬件来实现其功能性。
参照图3，通信设备300进一步可任选地包括配置成接收本地用户输入的逻辑325。在一示例中，配置成接收本地用户输入的逻辑325可至少包括用户输入设备和相关联的硬件。例如，用户输入设备可包括按钮、触摸屏显示器、键盘、相机、音频输入设备(例如，话筒或可携带音频信息的端口，诸如话筒插孔等)、和/或可用来从通信设备300的用户或操作者接收信息的任何其它设备。例如，如果通信设备300对应于如图2A中所示的IoT设备200A和/或如图2B中所示的无源IoT设备200B，则配置成接收本地用户输入的逻辑325可包括按钮222、224A和224B、显示器226(在触摸屏的情况下)，等等。在进一步示例中，对于某些通信设备(诸如不具有本地用户的网络通信设备(例如，网络交换机或路由器、远程服务器等))而言，配置成接收本地用户输入的逻辑325可被省略。配置成接收本地用户输入的逻辑325还可包括在被执行时准许配置成接收本地用户输入的逻辑325的相关联硬件执行其输入接收功能的软件。然而，配置成接收本地用户输入的逻辑325不单单对应于软件，并且配置成接收本地用户输入的逻辑325至少部分地依赖于硬件来实现其功能性。
参照图3，尽管所配置的逻辑305到325在图3中被示出为分开或相异的块，但将领会，相应各个所配置的逻辑藉以执行其功能性的硬件和/或软件可部分交迭。例如，用于促成所配置的逻辑305到325的功能性的任何软件可被存储在与配置成存储信息的逻辑315相关联的非瞬态存储器中，从而所配置的逻辑305到325各自部分地基于由配置成存储信息的逻辑315所存储的软件的操作来执行其功能性(即，在这一情形中为软件执行)。同样地，直接与所配置的逻辑之一相关联的硬件可不时地被其它所配置的逻辑借用或使用。例如，配置成处理信息的逻辑310的处理器可在数据由配置成接收和/或传送信息的逻辑305传送之前将此数据格式化为恰适格式，从而配置成接收和/或传送信息的逻辑305部分地基于与配置成处理信息的逻辑310相关联的硬件(即，处理器)的操作来执行其功能性(即，在这一情形中为数据传输)。
一般而言，除非另外明确声明，如贯穿本公开所使用的短语“配置成…逻辑”旨在调用至少部分用硬件实现的方面，而并非旨在映射到独立于硬件的仅软件实现。同样，将领会，各个框中的所配置的逻辑或“配置成…的逻辑”并不限于具体的逻辑门或元件，而是一般地指代执行本文描述的功能性的能力(经由硬件或硬件和软件的组合)因此，尽管共享措词“逻辑”，但如各个框中所解说的所配置的逻辑或“配置成...的逻辑”不必被实现为逻辑门或逻辑元件。从以下更详细地描述的各方面的概览中，各个框中的逻辑之间的其它交互或协作将对本领域普通技术人员而言变得清楚。
各实施例可实现在各种市售的服务器设备中的任何服务器设备上，诸如图4中所解说的服务器400。在一示例中，服务器400可对应于以上描述的IoT服务器170的一个示例配置或者如本文进一步描述的OpenID/OAuth/FaceConnect提供方。在图4中，服务器400包括耦合至易失性存储器401和大容量非易失性存储器(诸如盘驱动器402)的处理器403。服务器400还可包括耦合至处理器401的软盘驱动器、压缩碟(CD)或DVD碟驱动器406。服务器400还可包括耦合至处理器401的用于建立与网络407(诸如耦合至其他广播系统计算机和服务器或耦合至因特网的局域网)的数据连接的网络接入端口404。在图3的上下文中，将领会，图4的服务器400解说了通信设备300的一个示例实现，藉此配置成传送和/或接收信息的逻辑305对应于由服务器400用来与网络407通信的网络接入点404，配置成处理信息的逻辑310对应于处理器401，而配置成存储信息的逻辑315对应于易失性存储器402、盘驱动器403和/或碟驱动器406的任何组合。配置成呈现信息的可任选逻辑320和配置成接收本地用户输入的可任选逻辑325未在图4中明确示出，并且可以被或可以不被包括在其中。因此，图4帮助表明除了如图2A中的IoT设备实现之外，通信设备300还可被实现为服务器。
一般而言，用户装备(UE)(诸如电话、平板计算机、膝上型和台式计算机、某些车辆等)可被配置成在本地(例如，蓝牙、本地Wi-Fi等)或远程地(例如，经由蜂窝网络、通过因特网等)彼此连接。此外，某些UE还可使用使得设备能进行一对一连接或同时连接至包括若干设备的群以便彼此直接通信的某些无线联网技术(例如，Wi-Fi、蓝牙、Wi-Fi直连等)来支持基于邻近性的对等(P2P)通信。为此，图5解说了可支持可发现P2P服务的示例性无线通信网络或WAN 500。例如，在一个实施例中，无线通信网络500可包括LTE网络或另一合适的WAN，其包括各种基站510和其他网络实体。出于简化起见，在图5中仅示出三个基站510a、510b和510c，一个网络控制器530，以及一个动态主机配置协议(DHCP)服务器540。基站510可以是与设备520通信的实体并且还可被称为B节点、演进型B节点(eNB)、接入点等。每个基站510可提供对特定地理区域的通信覆盖，并可支持位于该覆盖区内的设备520的通信。为了提高网络容量，基站510的整个覆盖区可被划分成多个(例如，三个)较小的区域，其中每个较小的区域可由各自的基站510来服务。在3GPP中，术语“蜂窝小区”可指代基站510的覆盖区和/或服务该覆盖区的基站子系统510，这取决于使用该术语的上下文。在3GPP2中，术语“扇区”或“蜂窝小区-扇区”可指代基站510的覆盖区和/或服务该覆盖区的基站子系统510。为简明起见，在本文的描述中可使用3GPP概念“蜂窝小区”。
基站510可提供对宏蜂窝小区、微微蜂窝小区、毫微微蜂窝小区、和/或其他蜂窝小区类型的通信覆盖。宏蜂窝小区可覆盖相对较大的地理区域(例如，半径为数千米的区域)，并且可允许无约束地由具有服务订阅的设备520接入。微微蜂窝小区可覆盖相对较小的地理区域并且可允许无约束地由具有服务订阅的设备520接入。毫微微蜂窝小区可覆盖相对较小的地理区域(例如，住宅)且可允许有约束地由与该毫微微蜂窝小区有关联的设备520(例如，封闭订户群(CSG)中的设备520)接入。在图5所示的示例中，无线网络500包括用于宏蜂窝小区的宏基站510a、510b和510c。无线网络500还可包括用于微微蜂窝小区的微微基站510、和/或用于毫微微蜂窝小区的家用基站510(图5中未示出)。
网络控制器530可耦合至一组基站510并可为这些基站510提供协调和控制。网络控制器530可以是可经由回程与基站通信的单个网络实体或网络实体集合。基站还可以例如直接或经由无线或有线回程间接地彼此通信。DHCP服务器540可支持P2P通信，如以下描述的。DHCP服务器540可以是无线网络500的一部分、在无线网络500外部、经由因特网连接共享(ICS)来运行、或其任何组合。DHCP服务器540可以是单独实体(例如，如图5中所示)，或者可以是基站510、网络控制器530、或某种其他实体的一部分。在任何情形中，DHCP服务器540可由期望对等通信的设备520联系到。
设备520可分散遍及无线网络500，且每个设备520可以是驻定的或移动的。设备520也可被称为节点、用户装备(UE)、站、移动站、终端、接入终端、订户单元等。设备520可以是蜂窝电话、个人数字助理(PDA)、无线调制解调器、无线通信设备、手持式设备、膝上型计算机、无绳电话、无线本地环路(WLL)站、智能电话、上网本、智能本、平板电脑等等。设备520可与无线网络500中的基站510通信并且可进一步与其他设备520进行对等通信。例如，如图5中所示，设备520a和520b可进行对等通信，设备520c和520d可进行对等通信，设备520e和520f可进行对等通信，以及设备520g、520h和520i可进行对等通信，而其余设备520可与基站510通信。如图5中进一步所示的，设备520a、520d、520f和520h也可以与基站500通信，例如在不进行P2P通信时或者可能与P2P通信并发地与基站500通信。
在本文的描述中，WAN通信可以指无线网络500中的设备520与基站510之间的通信，例如用于与远程实体(诸如另一设备520)的呼叫。WAN设备是有兴趣进行或正参与WAN通信的设备520。P2P通信是指两个或更多个设备520之间的直接通信而不经过任何基站510。P2P设备是有兴趣进行或正参与P2P通信的设备520，例如具有要给另一设备520的话务数据的设备520，该另一设备420邻近该P2P设备。例如，两个设备在若每个设备520能检测到另一方设备520的情况下可被认为彼此邻近。一般而言，设备520可针对P2P通信直接与另一设备520通信，或者针对WAN通信经由至少一个基站510与另一设备420通信。
在一个实施例中，P2P设备520之间的直接通信可被组织成P2P群。更具体地，P2P群一般是指有兴趣进行或正参与P2P通信的两个或更多个设备520的群，而P2P链路是指用于P2P群的通信链路。此外，在一个实施例中，P2P群可包括被指定为P2P群主(或P2P服务器)的一个设备520以及被指定为由该P2P群主服务的P2P客户端的一个或多个设备520。P2P群主可执行某些管理功能，诸如与WAN交换信令，协调P2P群主与P2P客户端之间的数据传输，等等。例如，如图5中所示，第一P2P群包括在基站510a的覆盖下的设备520a和520b，第二P2P群包括在基站510b的覆盖下的设备520c和520d，第三P2P群包括在不同基站510b和510c的覆盖下的设备520e和520f，以及第四P2P群包括在基站510c的覆盖下的设备520g、520h和520i。设备520a、520d、520f和520h可以是其相应P2P群的P2P群主，而设备520b、520c、520e、520g和520i可以是其相应P2P群中的P2P客户端。图5中的其他设备520可参与WAN通信。
在一个实施例中，P2P通信可仅在P2P群内发生，并且可进一步仅在P2P群主和与之相关联的P2P客户端之间发生。例如，如果同一P2P群内的两个P2P客户端(例如，设备520g和520i)期望交换信息，则这些P2P客户端之一可向P2P群主(例如，设备520h)发送信息并且P2P群主可随后将传输中继至另一P2P客户端。在一个实施例中，特定设备520可属于多个P2P群，并且可在每个P2P群中要么充当P2P群主要么充当P2P客户端。此外，在一个实施例中，特定P2P客户端可属于仅一个P2P群，或者属于多个P2P群并在任何特定时刻与这多个P2P群中的任一个P2P群中的P2P设备520通信。一般而言，可经由下行链路和上行链路上的传输来促成通信。对于WAN通信，下行链路(或即前向链路)是指从基站510至设备520的通信链路，而上行链路(或即反向链路)是指从设备520至基站510的通信链路。对于P2P通信，P2P下行链路是指从P2P群主至P2P客户端的通信链路，而P2P上行链路是指从P2P客户端至P2P群主的通信链路。在某些实施例中，并非使用WAN技术来进行P2P通信，而是两个或更多个设备可形成较小P2P群并使用诸如Wi-Fi、蓝牙或Wi-Fi直连等技术在无线局域网(WLAN)上进行P2P通信。例如，使用Wi-Fi、蓝牙、Wi-Fi直连、或其他WLAN技术的P2P通信可在两个或更多个移动电话、游戏控制台、膝上型计算机、或其他合适的通信实体之间实现P2P通信。
根据本公开的一个方面，图6解说了示例性环境600，其中可发现P2P服务可被用于建立基于邻近性的分布式总线，各个设备610、630、640可在该总线上通信。例如，在一个实施例中，可使用进程间通信协议(IPC)框架在分布式总线625上促成单个平台上的应用等之间的通信，分布式总线625可包括用于在联网计算环境中实现应用到应用通信的软件总线，其中应用向分布式总线625注册以向其他应用提供服务，并且其他应用向分布式总线540查询关于经注册的应用的信息。此类协议可提供异步通知和远程规程调用(RPC)，其中信号消息(例如，通知)可以是点到点的或是广播，方法调用消息(例如，RPC)可以是同步或异步的，并且分布式总线625(例如，“守护进程”总线进程)可处置各种设备610、630、640之间的消息路由。
在一个实施例中，分布式总线625可得到各种传输协议(例如，蓝牙、TCP/IP、Wi-Fi、CDMA、GPRS、UMTS等)的支持。例如，根据一个方面，第一设备610可包括分布式总线节点612以及一个或多个本地端点614，其中分布式总线节点612可促成与第一设备614相关联的本地端点610和与第二设备634及第三设备644相关联的本地端点630和640之间通过分布式总线625(例如，经由第二设备632和第三设备642上的分布式总线节点630和640)的通信。如以下将参照图7进一步详细描述的，分布式总线625可支持对称多设备网络拓扑并且可在存在设备退出的情况下提供稳健的操作。如此，虚拟分布式总线625(其一般可独立于任何底层传输协议(例如，蓝牙、TCP/IP、Wi-Fi等))可允许各种安全性选项，从不安全(例如，开放)到安全(例如，经认证和加密)，其中可在第一设备610、第二设备630和第三设备640来到彼此的射程或邻域中时在无需干预的情况下促成各个设备610、630、640之间的自发连接时使用安全性选项。
根据本公开的一个方面，图7解说了示例性消息序列700，其中可发现P2P服务可被用于建立基于邻近性的分布式总线，第一设备(“设备A”)710和第二设备(“设备B”)730可在该总线上通信。一般而言，设备A 710可请求与设备B 730通信，其中设备A 710可包括可作出通信请求的本地端点714(例如，本地应用、服务等)以及可辅助促成此类通信的总线节点712。此外，设备B 730可包括本地端点734和总线节点732，本地端点714可尝试与本地端点734通信，总线节点730可辅助促成设备A 714上的本地端点710与设备B 620上的本地端点624之间的通信。
在一个实施例中，总线节点712和732可在消息序列步骤754执行合适的发现机制。例如，可使用由蓝牙、TCP/IP、UNIX等支持的用于发现连接的机制。在消息序列步骤756，设备A 710上的本地端点714可请求连接至通过总线节点712可用的实体、服务、端点等。在一个实施例中，该请求可包括本地端点714与总线节点712之间的请求-响应过程。在消息序列步骤758，可形成分布式消息总线以将总线节点712连接至总线节点732并由此建立设备A710与设备B 730之间的P2P连接。在一个实施例中，用于在总线节点712和732之间形成分布式总线的通信可使用合适的基于邻近性的P2P协议(例如，被设计成实现来自不同制造商的连通的产品和软件应用之间的互操作性以动态地创建邻近网络并促成邻近P2P通信的AllJoynTM软件框架)来促成。替换地，在一个实施例中，服务器(未示出)可促成总线节点712和732之间的连接。此外，在一个实施例中，在形成总线节点712和732之间的连接之前可使用合适的认证机制(例如，SASL认证，其中客户端可发送认证命令以发起认证对话)。再进一步，在消息序列步骤758期间，总线节点712和732可交换关于其他可用端点(例如，图6中的设备C 640上的本地端点644)的信息。在此类实施例中，总线节点维护的每个本地端点可被宣告给其他总线节点，其中该宣告可包括唯一性端点名称、传输类型、连接参数、或其他合适的信息。
在一个实施例中，在消息序列步骤760，总线节点712和总线节点732可分别使用所获得的与本地端点734和714相关联的信息来创建虚拟端点，虚拟端点可表示通过各个总线节点可用的真实获得的端点。在一个实施例中，总线节点712上的消息路由可使用真实端点和虚拟端点来递送消息。此外，对于远程设备(例如，设备A 710)上存在的每个端点，可以有一个本地虚拟端点。再进一步，此类虚拟端点可复用和/或分用在分布式总线(例如，总线节点712与总线节点732之间的连接)上发送的消息。在一个方面，虚拟端点可以就像真实端点那样接收来自本地总线节点712或732的消息，并且可在分布式总线上转发消息。如此，虚拟端点可从端点复用的分布式总线连接将消息转发到本地总线节点712和732。此外，在一个实施例中，与远程设备上的虚拟端点相对应的虚拟端点可在任何时间被重新连接以容适特定传输类型的期望拓扑。在此类方面，基于UNIX的虚拟端点可被认为是本地的，且由此可不被认为是用于重新连接的候选。此外，基于TCP的虚拟端点可被优化用于一跳路由(例如，每个总线节点712和732可彼此直接连接)。再进一步，基于蓝牙的虚拟端点可被优化用于单个微微网(例如，一个主设备和n个从设备)，其中基于蓝牙的主设备可以是与本地主节点相同的总线节点。
在消息序列步骤762，总线节点712和总线节点732可交换总线状态信息以合并总线实例并实现分布式总线上的通信。例如，在一个实施例中，总线状态信息可包括公知名称到唯一性端点名称的映射、匹配规则、路由群、或其他合适的信息。在一个实施例中，可使用接口在总线节点712实例和总线节点732实例之间传达状态信息，其中本地端点714和734使用基于分布式总线的本地名称来通信。在另一方面，总线节点712和总线节点732可各自维护负责向分布式总线提供反馈的本地总线控制器，其中总线控制器可将全局方法、自变量、信号和其他信息转译成与分布式总线相关联的标准。在消息序列步骤764，总线节点712和总线节点732可传达(例如，广播)信号以向相应的本地端点714和734通知在总线节点连接期间引入的任何改变，诸如以上所述的。在一个实施例中，可用名称所有者已改变信号来指示新的和/或被移除的全局和/或经转译名称。此外，可用名称丢失信号来指示可能在本地丢失(例如，由于名称冲突)的全局名称。再进一步，可用名称所有者已改变信号来指示由于名称冲突而被转移的全局名称，并且可用名称所有者改变信号来指示在总线节点712和总线节点732变为断开连接的情况下和/或之时消失的唯一性名称。
如以上使用的，公知名称可被用于唯一性地描述本地端点714和734。在一个实施例中，当在设备A 710与设备B 730之间发生通信时，可使用不同的公知名称类型。例如，设备本地名称可仅存在于与总线节点712直接附连至的设备A 710相关联的总线节点712上。在另一示例中，全局名称可存在于所有已知的总线节点712和732上，其中该名称的唯一所有者可存在于所有总线区段上。换言之，当总线节点712和总线节点732加入并且发生任何冲突时，所有者之一可能丢失全局名称。在又一示例中，在客户端连接至与虚拟总线相关联的其他总线节点时，可使用经转译名称。在此类方面，经转译名称可包括附加结尾(例如，连接至具有全局唯一性标识符“1234”的分布式总线的具有公知名称“org.foo”的本地端点714可被视为“G1234.org.foo”)。
在消息序列步骤766，总线节点712和总线节点732可传达(例如，广播)信号以向其他总线节点通知对端点总线拓扑的改变。此后，来自本地端点714的话务可移动通过虚拟端点到达设备B 734上的目标本地端点730。此外，在操作中，本地端点714与本地端点734之间的通信可使用路由群。在一个方面，路由群可使得端点能接收来自端点子集的信号、方法调用、或其他合适的信息。如此，路由名称可由连接至总线节点712或732的应用来确定。例如，P2P应用可使用构建到该应用中的唯一性的、公知的路由群名称。此外，总线节点712和732可支持本地端点714和734向路由群的注册和/或注销。在一个实施例中，路由群可不具有超出当前总线实例的持久性。在另一方面，应用可在每次连接至分布式总线时针对其优选路由群进行注册。再进一步，群可以是开放的(例如，任何端点都可以加入)或封闭的(例如，只有群创建者能修改该群)。此外，总线节点712或732可发送信号以向其他远程总线节点通知对路由群端点的添加、移除、或其他改变。在此类实施例中，总线节点712或732可每当向/从群添加和/或移除成员时就向其他群成员发送路由群改变信号。此外，总线节点712或732可向与分布式总线断开连接的端点发送路由群改变信号，而不是先将它们从路由群移除。
表1和2定义了本公开中所使用的各种术语和缩写词。
表1：术语
表2：缩写词
基于邻近度的P2P协议安全服务(诸如由高通公司提供的AllJoynTM安全服务)的目标是允许受控方设备(或受控方)基于该受控方与控制方的关系来限制对安全接口和/或安全对象的访问。除了控制方与受控方之间的安全信道之外，这一安全服务将管理凭证的数据库以及用于访问设备应用的访问控制列表(ACL)。
特定控制方可访问的安全对象或安全接口的集合被编群到“角色”中。控制方可访问一个或多个角色。角色由受控方的开发者设置并且通常不可在部署后配置。
每一受控方都可具有一个或多个所有者控制方。所有者控制方负责维护安全服务数据库。所有者控制方可通过经由例如OpenID或局部GUID标识其它控制方来将访问权准予给这些其它控制方。
由于基于邻近度的P2P协议网络上的所有设备可能不具有直接因特网接入(OpenID验证所必需的)，因此要求OpenID认证的所有网络都可能需要运行安全桥服务(SBS)。SBS将采取对OpenID验证的本地请求并通过与云通信来执行认证。
OpenID是为许多流行的服务(例如，和)提供覆盖的全局标识符(ID)。在具有OpenID的情况下，消费者知道他们的朋友和家人的全局身份或者能请求这些身份。消费者无需为了访问他们的设备而创建或共享身份和凭证。消费者也无需记住不同位置的身份。
图8解说了根据本公开的一方面的使用OpenID/OAuth/FaceConnect提供方(OP)830来认证的示例性流程。OpenID/OAuth提供方830可对应于图4中的服务器400。在802，客户端810(当图2A中的IoT设备200A被体现为蜂窝电话、智能电话、台式计算机、膝上型计算机、平板计算机、PDA等时，客户端810可对应于该IoT设备200A)向OpenID/OAuth提供方830发送认证请求(例如，HTTP GET)。在804，OpenID/OAuth提供方830向客户端810发送认证响应(例如，HTTP Redirect)。
注意，OpenID/OAuth提供方830发送作为HTTP重定向的响应。然而，在客户端810不是web浏览器的情况下，无需遵循该重定向。取而代之的是，从重定向中检索到的信息仅仅是签名。结果是签名绑定return_to(返回至)(包含散列/对象)以及OpenID身份。另外，客户端810的电子邮件地址可被包括在该交换中。
图9解说了本公开的安全服务的示例性系统架构。图9中所解说的系统包括运行应用912的控制方设备910、运行应用922的受控方设备920以及OpenID/OAuth提供方830。控制方设备910可以是“智能”设备，并且当图2A中的IoT设备200A被体现为蜂窝电话、智能电话、台式计算机、膝上型计算机、平板计算机、PDA等时可对应于IoT设备200A。受控方设备920可以是任何IoT设备，诸如分别在图2A和2B中的IoT设备200A或200B。应用912和922可以在加密信道上彼此通信，但该信道直到控制方用OpenID认证并且受控方验证该OpenID才被验证。
控制方设备910和受控方设备920两者还分别包括密钥交换认证模块916和926以执行本文描述的功能性。密钥交换认证模块916/926可对应于图2A/2B中的密钥交换认证模块216。
每一应用912和922具有出于认证目的而被指派的GUID。关于给定应用的所有加密相关数据都被存储在通过GUID索引的密钥存储中。典型的加密数据包括主密钥、会话密钥和群密钥。本公开将密钥存储扩展成存储Diffie-Hellman密钥、终端用户OpenID信息和许可。
当终端用户使用控制方(诸如控制方设备910)时，他/她能通过执行他/她的OpenID/OAuth提供方(诸如OpenID/OAuth提供方(OP)830)的认证规程来向特定受控方(诸如受控方设备920)验证应用912。该规程将该应用的认证GUID与该用户的OpenID标识符相关联。为了执行本文描述的验证，安全服务需要能访问终端用户的OpenID凭证。安全服务可以在终端用户向他/她的OpenID登录站点提供该终端用户的OpenID凭证时获得这些凭证。
在交换密码密钥的领域中，Diffie-Hellman密钥交换(DHE)是用以建立这两个对等应用912和922之间的加密信道的实用方法。这允许不具有彼此的先验知识的两方在不安全的通信信道上联合建立共享密钥。该密钥然后可用于使用对称密钥密码来加密后续通信。然而，通信易遭受中间人攻击。
存在能检测到针对Diffie-Hellman密钥交换的通信破坏的方法。本公开提供了使用终端用户联合登录(诸如OpenID或OAuth协议)来认证密钥交换机制(诸如Diffie-Hellman密钥交换)以使得通信各方检测到破坏的方法。所公开的方法要求终端用户登录到他/她的帐户(交互式地或者用所存储的登录信息)。不管源如何，到终端用户的帐户的登录用OpenID协议(示例提供方包括和)或者OAuth协议(示例提供方包括)来执行以准予对应用的访问，并且使用OpenID或OAuth协议的信令能力来对只被两个通信方知晓的令牌进行签名以验证通信信道未被破坏。
图10解说了根据本公开的一方面的用于建立图9中的控制方设备910和受控方设备920之间的安全信道(例如，经由Diffie-Hellman交换)的示例性流程。在该情形中，两个客户端都对共同的某一事物(例如，Diffie-Hellman会话参数)进行签名和验证。替换地，这两个客户端能对其公钥进行签名。
参照图10解说的功能性可由每一设备的密钥交换认证模块916/926与每一设备的处理器、收发机和/或I/O接口协同执行。例如，在密钥交换认证模块是可执行模块的情况下，控制方设备910/受控方设备920的处理器可分别执行密钥交换认证模块916/926的功能性，由此使得收发机与OP 820以及受控方设备920/控制方设备910通信。
在1002-1004，控制方设备910和受控方设备920交换Diffie-Hellman密钥并生成共享密钥。在1002，控制方设备910将其Diffie-Hellman密钥(被表示为“A_PublicKey”)发送到受控方设备920。在1004，受控方设备920将其Diffie-Hellman密钥(被表示为“B_PublicKey”)发送到控制方设备910。在该交换后，控制方设备910和受控方设备920各自生成供交换的标识符。这是公钥本身、公钥的散列或者使用伪随机函数(PRF)计算出的验证符。
在1006，控制方设备910将认证请求发送到OpenID/OAuth提供方830。该请求包含为了供在1002-1004交换而生成的标识符。对于OpenID和OAuth，该标识符被嵌入return_to参数。在图10的示例中，供交换的标识符包括被表示为“HASH(A_PK|B_PK)”的“A_PublicKey”和“B_PublicKey”的散列。在1008，控制方设备910从OpenID/OAuth提供方830接收经签名的响应。该签名覆盖标识符。
在1010，受控方设备920向OpenID/OAuth提供方830发送独立于控制方设备910在1006发送的请求的认证请求。该请求也包含为了供在1002-1004交换而生成的标识符。对于OpenID和OAuth，该标识符被嵌入return_to参数。在1012，受控方设备920从OpenID/OAuth提供方830接收经签名的响应。该签名覆盖标识符。
在1014-1016，控制方设备910和受控方设备920交换经签名的响应。在1018-1020，控制方设备910和受控方设备920两者(独立地)通过OpenID/OAuth提供方830作出认证校验。该校验验证在1014-1016进行的数据交换是有效的，并由此该标识符是有效的。在1022-1024，控制方设备910和受控方设备920两者交换认证完成确认。
图11是使用OpenID提供方(即，OpenID提供方830)在图10中所解说的流程的示例。具体而言，图11解说了图9中所解说的控制方设备910和受控方设备920之间的OpenID验证的示例性流程，其中受控方设备920包括集束式安全桥924。图11中所解说的流程示出了验证终端用户的OpenID凭证的规程。在图11的示例中，控制方设备910被假定为是包括控制方应用的智能设备(诸如智能电话)。受控方设备920使用集束式安全桥924来向OpenID提供方进行验证。受控方设备920的开发者可决定是否在受控方设备920中包括安全桥924特征。安全桥924可以基于HTTPS代码以及有保证的因特网连接。尽管设备910和920在图11的示例中被解说为控制方和受控方，但它们可以是任意两个对等设备。
参照图11解说的功能性可由每一设备的密钥交换认证模块916/926与每一设备的处理器、收发机和/或I/O接口协同执行。例如，在密钥交换认证模块是可执行模块的情况下，控制方设备910/受控方设备920的处理器可分别执行密钥交换认证模块916/926的功能性，由此使得控制方应用912/受控方应用922、安全桥924和相应的AlljoynTM核执行图11中所解说的功能性。
图11中所解说的流程开始于在1102控制方设备910上的控制方应用912使用Diffie-Hellman来建立客户端(CGUID)与服务(SGUID)之间的安全会话。注意，安全信道只在它尚不可用的情况下被建立。在1104，控制方应用912将对两个公钥(即，Diffie-Hellman密钥)的散列的请求发送到例如控制方设备910中的AllJoynTM核。在1108，响应于在1106接收到来自AllJoynTM核的散列，控制方应用912打开WebView客户端或其它类似客户端。例如，控制方应用912可使用Android上的WebViewClient或者iOS上的UIWebView来打开web浏览器会话。
在1110，在打开WebView客户端后，控制方应用912在WebView客户端中将HTTPS“mode＝checked_setup”消息发送到OpenID提供方830。控制方应用912可使用OpenID登录请求中的域www.alljoyn-security.org并在返回地址中添加会话密钥。在1112，OpenID提供方830用OpenID登录页的HTML内容来进行响应。在1114，控制方应用912向终端用户显示登录屏幕，或替换地访问终端用户的先前存储的登录信息来登录，并且接收终端用户的OpenID凭证。替换地，如果终端用户当前已登入并且该终端用户的OpenID凭证仍然有效，则这些OpenID凭证可以在无需附加登录的情况下使用。
响应于接收到终端用户的OpenID凭证，在1116，控制方应用912将登录屏幕内容提交给OpenID提供方830。在1118，OpenID提供方830用具备具有“mode＝id_res”的认证响应散列的HTML重定向来进行响应。在1120，控制方应用912不执行重定向，而是提取认证响应的内容。在1122，控制方应用912将由OpenID提供方830签名的认证响应发送到例如受控方设备920上的AllJoynTM核。
响应于接收到来自控制方应用912的认证响应，在1124，AllJoynTM核验证会话散列。在1120和1124两者，验证openid.return_to字段中的会话ID散列以确保这两个公钥的完整性。在1126，AllJoynTM核用函数ValidateOpenID(authResp)来调用内部安全桥924。在1128，安全桥924调用OpenID提供方830来使用mode＝check_authentication(校验认证)验证认证签名。在1130，OpenID提供方830用消息“is_valid:true”来进行响应。然而，注意如果会话散列不同于控制方设备910中所使用的值，则check_authorization使签名校验失败。
在1132，安全桥924向AllJoynTM核发送指示全局ID验证为“OK”的消息。作为响应，在1134，AllJoynTM核将CGUID标记为已用全局ID验证，并且在1136向控制方应用912发送指示全局ID验证为“OK”的消息。
图12是使用OAuth提供方(即，OAuth提供方830(诸如))的图10中所解说的流程的示例。具体而言，图12解说了图9中所解说的控制方设备910和受控方设备920之间的OAuth验证，其中受控方设备920不包括它在图11中包括的集束式安全桥。在图12中所解说的示例中，OAuth提供方被解说为是为了支持帐户的验证，受控方应用922或者安全桥924需要在需要应用ID时提供这一信息。具体而言，需要已注册的应用ID以调用OAuth登录屏幕。尽管设备910和920在图12的示例中被解说为控制方和受控方，但它们可以是任意两个对等设备。
参照图12解说的功能性可由每一设备的密钥交换认证模块916/926与每一设备的处理器、收发机和/或I/O接口协同执行。例如，在密钥交换认证模块是可执行模块的情况下，控制方设备910/受控方设备920的处理器可分别执行密钥交换认证模块916/926的功能性，由此使得控制方应用912/受控方应用922和相应的AlljoynTM核执行图12中所解说的功能性。
图12中所解说的流程开始于在1202控制方应用912使用Diffie-Hellman来建立CGUID与SGUID之间的安全会话。注意，安全信道只在它尚不可用的情况下被建立。在1204，控制方应用912将对两个公钥的散列的请求发送到例如控制方设备910中的AllJoynTM核。响应于在1206接收到来自AllJoynTM核的散列，在1208，控制方应用912启动到的登录。响应于接收到登录请求，在1210，外部安全桥924将FacebookTM应用ID和应用回调URL发送到例如受控方设备920的AllJoynTM核，该AllJoynTM核将该信息转发至控制方应用912。
在1212，控制方应用912打开WebView客户端或类似客户端，并且在1214在WebView客户端中将具有应用ID的OAuth请求发送到服务器。例如，控制方应用912可使用Android上的WebViewClient或者iOS上的UIWebView来打开web浏览器会话。控制方应用912可将应用回调URL用作redirect_uri，并添加会话密钥散列回调URL和状态字段。在1216，服务器用登录页的HTML内容来进行响应。在1218，控制方应用912向终端用户显示登录屏幕，并接收该终端用户的凭证。
响应于接收到终端用户的凭证，在1220，控制方应用912将登录屏幕内容提交给服务器。在1222，服务器用具备具有访问令牌的认证响应的HTML重定向来进行响应。在1224，控制方应用912不执行重定向，而是提取并解析认证响应以获得代码。控制方应用912还验证状态字段中的会话ID散列。在1226，控制方应用912将代码发送到受控方设备920上的AllJoynTM核。
响应于接收到来自控制方应用912的代码，在1228，AllJoynTM核用函数ValidateFacebook(会话散列,代码)来调用外部安全桥924。在1230，安全桥924然后用请求“https://graph.facebook.com/oauth/access_token？redirect_uri＝&code＝,”来调用服务器，并且在1232接收作为响应的访问令牌。注意，交换代码以获得访问令牌是OAuth专用方法。另外，redirect_uri是用应用回调URL和会话散列形成的。如果redirect_uri不匹配验证会话散列的控制方，则access_token调用失败。
在1234，安全桥924用请求“https://graph.facebook.com/me？scope＝email&access_token＝,”来调用服务器，并且在1236接收作为响应的终端用户的用户名和电子邮件。在1238，安全桥924将终端用户的用户名和电子邮件发送到受控方设备920的AllJoynTM核，在1240该AllJoynTM核将CGUID标记为已用全局ID验证。在1242，AllJoynTM核向控制方应用912发送指示全局ID验证为“OK”的消息。
如将会领会的，尽管图11和12解说了与控制方设备910和/或受控方设备920交换各种消息，但这仅仅是示例性实施例，且可使用其它通信协议。
下表描述了控制方设备910和受控方设备920必须提供给全局ID提供方的必需信息数据。
表3：供全局ID验证的必需应用数据
图13解说了根据本公开的一方面的用于认证第一对等设备与第二对等设备之间的密钥交换的示例性流程。图13中解说的流程可由图9中的控制方设备910或受控方设备920执行。为了方便起见，图13中所解说的流程将被描述为由控制方设备910执行。
图13中所解说的流程开始于在1302第一对等设备将该第一对等设备的用户的联合登录凭证和第一标识符发送到第一联合登录提供方(诸如在图10的1006、图11的1116以及图12的1220)。类似地，第二对等设备将该用户的联合登录凭证和第二标识符发送到第二联合登录提供方(诸如在图10的1010)。
第一联合登录提供方和第二联合登录提供方可以是相同或不同的联合登录提供方。然而，第一联合登录提供方和第二联合登录提供方两者都应支持相同的联合登录协议(诸如OpenID、OAuth或FaceConnect)。
第一标识符和第二标识符可以是相同或不同的标识符。如果相同，则第一标识符和第二标识符可以是共用的散列或计算出的验证符。如果不同，则第一标识符可以是由第一对等设备生成的第一公钥，而第二标识符可以是由第二对等设备生成的第二公钥。
在1304，第一对等设备从第一联合登录提供方接收第一认证响应(诸如在图10的1008、图11的1118和图12的1222)。类似地，第二对等设备从第二联合登录提供方接收第二认证响应(诸如在图10的1012)。
在1306，第一对等设备从第二对等设备接收第二认证响应(诸如在图10的1016)。
在1308，第一对等设备向第二联合登录提供方认证第二认证响应(诸如在图10的1018)。
在1310，第一对等设备向第二对等设备发送第一认证响应(诸如在图10的1014)。第二对等设备向第一联合登录提供方认证第一认证响应(诸如在图10的1020、图11的1126-1132和图12的1228-1238)。
在1312，第一对等设备从第二对等设备接收指示第二对等设备已经认证第一认证响应的确认(诸如在图10的1022、图11的1136和图12的1242)。
在1314，第一对等设备向第二对等设备发送指示第一对等设备已经认证第二认证响应的确认(诸如在图10的1024)。
在1316，第一对等设备基于来自第二对等设备的确认来认证密钥交换，其中第二对等设备基于来自第一对等设备的确认来认证密钥交换。
图14解说了被表示为一系列相互关联的功能模块的示例用户设备装置1400。用于发送的模块1402至少在一些方面可对应于例如通信设备(诸如图2A中的收发机206)，如本文所讨论的。用于接收的模块1404至少在一些方面可对应于例如通信设备(诸如图2A中的收发机206)，如本文所讨论的。用于接收的模块1406至少在一些方面可对应于例如通信设备(诸如图2A中的收发机206)，如本文所讨论的。用于认证的模块1408在至少一些方面可对应于例如与处理系统协同的通信设备(诸如图2A中的收发机206)(诸如在图2A中密钥交换认证模块216与处理器208协同)，如本文所讨论的。用于发送的模块1410至少在一些方面可对应于例如通信设备(诸如图2A中的收发机206)，如本文所讨论的。用于接收的模块1412至少在一些方面可对应于例如通信设备(诸如图2A中的收发机206)，如本文所讨论的。用于发送的模块1414至少在一些方面可对应于例如通信设备(诸如图2A中的收发机206)，如本文所讨论的。用于认证的模块1416在至少一些方面可对应于例如与处理系统协同的通信设备(诸如图2A中的收发机206)(诸如在图2A中密钥交换认证模块216与处理器208协同)，如本文所讨论的。
可以按与本文中的教导相一致的各种方式来实现图14的各模块的功能性。在一些设计中，这些模块的功能性可以被实现为一个或多个电组件。在一些设计中，这些框的功能性可以被实现为包括一个或多个处理器组件的处理系统。在一些设计中，可以使用例如一个或多个集成电路(例如，AISC)的至少一部分来实现这些模块的功能性。如本文中所讨论的，集成电路可包括处理器、软件、其他相关组件、或其某种组合。因此，不同模块的功能性可以例如实现为集成电路的不同子集、软件模块集合的不同子集、或其组合。同样，将领会，(例如，集成电路和/或软件模块集合的)给定子集可以提供一个以上模块的功能性的至少一部分。
另外，图14表示的组件和功能以及本文所描述的其它组件和功能可使用任何合适的手段来实现。此类装置还可至少部分地使用本文所教导的相应结构来实现。例如，以上结合图14的“用于组件的模块”来描述的组件也可对应于类似指定的“用于功能性的装置”。因而，在一些方面，此类装置中的一个或多个可使用本文所教导的处理器组件、集成电路、或其他合适结构中的一个或多个来实现。
本领域技术人员将领会，信息和信号可使用各种不同技术和技艺中的任何一种来表示。例如，贯穿上面描述始终可能被述及的数据、指令、命令、信息、信号、位(比特)、码元、以及码片可由电压、电流、电磁波、磁场或磁粒子、光场或光粒子、或其任何组合来表示。
此外，本领域技术人员将领会，结合本文中所公开的方面描述的各种解说性逻辑块、模块、电路、和算法步骤可被实现为电子硬件、计算机软件、或两者的组合。为清楚地解说硬件与软件的这一可互换性，各种解说性组件、块、模块、电路、以及步骤在上面是以其功能性的形式作一般化描述的。此类功能性是被实现为硬件还是软件取决于具体应用和施加于整体系统的设计约束。技术人员可针对每种特定应用以不同方式来实现所描述的功能性，但此类实现决策不应被解读为脱离本公开的范围。
结合本文中公开的方面描述的各种解说性逻辑块、模块、以及电路可用设计成执行本文中描述的功能的通用处理器、数字信号处理器(DSP)、专用集成电路(ASIC)、现场可编程门阵列(FPGA)或其他可编程逻辑器件、分立的门或晶体管逻辑、分立的硬件组件、或其任何组合来实现或执行。通用处理器可以是微处理器，但在替换方案中，该处理器可以是任何常规的处理器、控制器、微控制器、或状态机。处理器还可以被实现为计算设备的组合(例如DSP与微处理器的组合、多个微处理器、与DSP核协作的一个或多个微处理器、或任何其他此类配置)。
结合本文公开的方面描述的方法、序列和/或算法可直接在硬件中、在由处理器执行的软件模块中、或在这两者的组合中体现。软件模块可驻留在RAM、闪存、ROM、EPROM、EEPROM、寄存器、硬盘、可移动盘、CD-ROM或本领域中所知的任何其他形式的存储介质中。示例性存储介质耦合到处理器以使得该处理器能从/向该存储介质读写信息。在替换方案中，存储介质可以被整合到处理器。处理器和存储介质可驻留在ASIC中。ASIC可驻留在IoT设备中。替换地，处理器和存储介质可作为分立组件驻留在用户终端中。
在一个或多个示例性方面，所描述的功能可在硬件、软件、固件或其任何组合中实现。如果在软件中实现，则各功能可以作为一条或多条指令或代码存储在计算机可读介质上或藉其进行传送。计算机可读介质包括计算机存储介质和通信介质两者，包括促成计算机程序从一地向另一地转移的任何介质。存储介质可以是能被计算机访问的任何可用介质。作为示例而非限定，此类计算机可读介质可包括RAM、ROM、EEPROM、CD-ROM或其他光盘存储、磁盘存储或其他磁存储设备、或能用于携带或存储指令或数据结构形式的期望程序代码且能被计算机访问的任何其他介质。任何连接也被正当地称为计算机可读介质。例如，如果软件是使用同轴电缆、光纤电缆、双绞线、DSL、或诸如红外、无线电、以及微波之类的无线技术从web网站、服务器、或其他远程源传送而来，则该同轴电缆、光纤电缆、双绞线、DSL、或诸如红外、无线电、以及微波之类的无线技术就被包括在介质的定义之中。如本文所使用的，盘(disk)和碟(disc)包括CD、激光碟、光碟、DVD、软盘和蓝光碟，其中盘(disk)常常磁性地和/或用激光来光学地再现数据。上述的组合应当也被包括在计算机可读介质的范围内。
尽管前面的公开示出了本公开的解说性方面，但是应当注意在其中可作出各种变更和修改而不会脱离如所附权利要求定义的本发明的范围。根据本文中所描述的本公开的各方面的方法权利要求中的功能、步骤和/或动作不一定要以任何特定次序执行。此外，尽管本公开的要素可能是以单数来描述或主张权利的，但是复数也是已料想了的，除非显式地声明了限定于单数。

Claims (30)

1.一种认证第一对等设备与第二对等设备之间的密钥交换的方法，包括：
由所述第一对等设备将所述第一对等设备的用户的联合登录凭证和第一标识符发送到第一联合登录提供方，其中所述第二对等设备将所述用户的所述联合登录凭证和第二标识符发送到第二联合登录提供方；
由所述第一对等设备从所述第一联合登录提供方接收第一认证响应，其中所述第二对等设备从所述第二联合登录提供方接收第二认证响应；
由所述第一对等设备从所述第二对等设备接收所述第二认证响应；
由所述第一对等设备向所述第二联合登录提供方认证所述第二认证响应；
由所述第一对等设备将所述第一认证响应发送到所述第二对等设备，其中所述第二对等设备向所述第一联合登录提供方认证所述第一认证响应；
由所述第一对等设备从所述第二对等设备接收指示所述第二对等设备已经认证所述第一认证响应的确认；
由所述第一对等设备向所述第二对等设备发送指示所述第一对等设备已经认证所述第二认证响应的确认；以及
由所述第一对等设备基于来自所述第二对等设备的确认来认证所述密钥交换，其中所述第二对等设备基于来自所述第一对等设备的确认来认证所述密钥交换。
2.如权利要求1所述的方法，其特征在于，接收所述第一认证响应包括接收具有所述第一认证响应的HTML重定向。
3.如权利要求2所述的方法，其特征在于，所述第一对等设备向所述第二对等设备发送所述第一认证响应，而不是遵循所述HTML重定向。
4.如权利要求1所述的方法，其特征在于，进一步包括：
在将所述用户的所述联合登录凭证和所述第一标识符发送到所述第一联合登录提供方之前使用所述密钥交换来建立所述第一对等设备与所述第二对等设备之间的安全会话。
5.如权利要求4所述的方法，其特征在于，所述安全会话使用Diffie-Helman密钥交换来建立。
6.如权利要求1所述的方法，其特征在于，所述第一联合登录提供方和所述第二联合登录提供方是不同的联合登录提供方，并且其中所述第一联合登录提供方和所述第二联合登录提供方包括OpenID提供方、OAuth提供方或FaceConnect提供方。
7.如权利要求1所述的方法，其特征在于，所述第一联合登录提供方和所述第二联合登录提供方是相同的联合登录提供方。
8.如权利要求1所述的方法，其特征在于，所述第一对等设备包括控制方对等设备，而所述第二对等设备包括受控方对等设备。
9.如权利要求1所述的方法，其特征在于，进一步包括：
由所述第一对等设备生成供进行所述密钥交换的第一公钥；
由所述第一对等设备将所述第一公钥发送到所述第二对等设备；以及
由所述第一对等设备从所述第二对等设备接收第二公钥。
10.如权利要求9所述的方法，其特征在于，所述第一标识符包括第一公钥、所述第一公钥和所述第二公钥的组合、所述第一公钥和所述第二公钥的散列、或者使用伪随机函数(PRF)计算出的所述第一公钥和所述第二公钥的验证符。
11.如权利要求1所述的方法，其特征在于，所述第一标识符和所述第二标识符是相同的标识符，并且其中所述第一标识符和所述第二标识符包括共用的散列或计算出的验证符。
12.如权利要求1所述的方法，其特征在于，所述第一标识符和所述第二标识符是不同的标识符，并且其中所述第一标识符包括由所述第一对等设备生成的第一公钥，而所述第二标识符包括由所述第二对等设备生成的第二公钥。
13.如权利要求1所述的方法，其特征在于，基于来自所述第二对等设备的确认来认证所述密钥交换包括基于接收到来自所述第二对等设备的确认来认证所述密钥交换。
14.一种用于认证第一对等设备与第二对等设备之间的密钥交换的装置，包括：
被配置成由所述第一对等设备将所述第一对等设备的用户的联合登录凭证和第一标识符发送到第一联合登录提供方的逻辑，其中所述第二对等设备将所述用户的所述联合登录凭证和第二标识符发送到第二联合登录提供方；
被配置成由所述第一对等设备从所述第一联合登录提供方接收第一认证响应的逻辑，其中所述第二对等设备从所述第二联合登录提供方接收第二认证响应；
被配置成由所述第一对等设备从所述第二对等设备接收所述第二认证响应的逻辑；
被配置成由所述第一对等设备向所述第二联合登录提供方认证所述第二认证响应的逻辑；
被配置成由所述第一对等设备将所述第一认证响应发送到所述第二对等设备的逻辑，其中所述第二对等设备向所述第一联合登录提供方认证所述第一认证响应；
被配置成由所述第一对等设备从所述第二对等设备接收指示所述第二对等设备已经认证所述第一认证响应的确认的逻辑；
被配置成由所述第一对等设备向所述第二对等设备发送指示所述第一对等设备已经认证所述第二认证响应的确认的逻辑；以及
被配置成由所述第一对等设备基于来自所述第二对等设备的确认来认证所述密钥交换的逻辑，其中所述第二对等设备基于来自所述第一对等设备的确认来认证所述密钥交换。
15.如权利要求14所述的装置，其特征在于，被配置成接收所述第一认证响应的逻辑包括被配置成接收具有所述第一认证响应的HTML重定向的逻辑。
16.如权利要求15所述的装置，其特征在于，所述第一对等设备向所述第二对等设备发送所述第一认证响应，而不是遵循所述HTML重定向。
17.如权利要求14所述的装置，其特征在于，进一步包括：
被配置成在将所述用户的所述联合登录凭证和所述第一标识符发送到所述第一联合登录提供方之前使用所述密钥交换来建立所述第一对等设备与所述第二对等设备之间的安全会话的逻辑。
18.如权利要求17所述的装置，其特征在于，所述安全会话使用Diffie-Helman密钥交换来建立。
19.如权利要求14所述的装置，其特征在于，所述第一联合登录提供方和所述第二联合登录提供方是不同的联合登录提供方，并且其中所述第一联合登录提供方和所述第二联合登录提供方包括OpenID提供方、OAuth提供方或FaceConnect提供方。
20.如权利要求14所述的装置，其特征在于，所述第一联合登录提供方和所述第二联合登录提供方是相同的联合登录提供方。
21.如权利要求14所述的装置，其特征在于，所述第一对等设备包括控制方对等设备，而所述第二对等设备包括受控方对等设备。
22.如权利要求14所述的装置，其特征在于，进一步包括：
被配置成由所述第一对等设备生成供进行所述密钥交换的第一公钥的逻辑；
被配置成由所述第一对等设备将所述第一公钥发送到所述第二对等设备的逻辑；以及
被配置成由所述第一对等设备从所述第二对等设备接收第二公钥的逻辑。
23.如权利要求22所述的装置，其特征在于，所述第一标识符包括第一公钥、所述第一公钥和所述第二公钥的组合、所述第一公钥和所述第二公钥的散列、或者使用伪随机函数(PRF)计算出的所述第一公钥和所述第二公钥的验证符。
24.如权利要求14所述的装置，其特征在于，所述第一标识符和所述第二标识符是相同的标识符，并且其中所述第一标识符和所述第二标识符包括共用的散列或计算出的验证符。
25.如权利要求14所述的装置，其特征在于，所述第一标识符和所述第二标识符是不同的标识符，并且其中所述第一标识符包括由所述第一对等设备生成的第一公钥，而所述第二标识符包括由所述第二对等设备生成的第二公钥。
26.如权利要求14所述的装置，其特征在于，被配置成基于来自所述第二对等设备的确认来认证所述密钥交换的逻辑包括被配置成基于接收到来自所述第二对等设备的确认来认证所述密钥交换的逻辑。
27.一种用于认证第一对等设备与第二对等设备之间的密钥交换的装备，包括：
用于由所述第一对等设备将所述第一对等设备的用户的联合登录凭证和第一标识符发送到第一联合登录提供方的装置，其中所述第二对等设备将所述用户的所述联合登录凭证和第二标识符发送到第二联合登录提供方；
用于由所述第一对等设备从所述第一联合登录提供方接收第一认证响应的装置，其中所述第二对等设备从所述第二联合登录提供方接收第二认证响应；
用于由所述第一对等设备从所述第二对等设备接收所述第二认证响应的装置；
用于由所述第一对等设备向所述第二联合登录提供方认证所述第二认证响应的装置；
用于由所述第一对等设备将所述第一认证响应发送到所述第二对等设备的装置，其中所述第二对等设备向所述第一联合登录提供方认证所述第一认证响应；
用于由所述第一对等设备从所述第二对等设备接收指示所述第二对等设备已经认证所述第一认证响应的确认的装置；
用于由所述第一对等设备向所述第二对等设备发送指示所述第一对等设备已经认证所述第二认证响应的确认的装置；以及
用于由所述第一对等设备基于来自所述第二对等设备的确认来认证所述密钥交换的装置，其中所述第二对等设备基于来自所述第一对等设备的确认来认证所述密钥交换。
28.如权利要求27所述的装置，其特征在于，进一步包括：
用于在将所述用户的所述联合登录凭证和所述第一标识符发送到所述第一联合登录提供方之前使用所述密钥交换来建立所述第一对等设备与所述第二对等设备之间的安全会话的装置。
29.一种用于认证第一对等设备与第二对等设备之间的密钥交换的非瞬态计算机可读介质，包括：
用于由所述第一对等设备将所述第一对等设备的用户的联合登录凭证和第一标识符发送到第一联合登录提供方的至少一条指令，其中所述第二对等设备将所述用户的所述联合登录凭证和第二标识符发送到第二联合登录提供方；
用于由所述第一对等设备从所述第一联合登录提供方接收第一认证响应的至少一条指令，其中所述第二对等设备从所述第二联合登录提供方接收第二认证响应；
用于由所述第一对等设备从所述第二对等设备接收所述第二认证响应的至少一条指令；
用于由所述第一对等设备向所述第二联合登录提供方认证所述第二认证响应的至少一条指令；
用于由所述第一对等设备将所述第一认证响应发送到所述第二对等设备的至少一条指令，其中所述第二对等设备向所述第一联合登录提供方认证所述第一认证响应；
用于由所述第一对等设备从所述第二对等设备接收指示所述第二对等设备已经认证所述第一认证响应的确认的至少一条指令；
用于由所述第一对等设备向所述第二对等设备发送指示所述第一对等设备已经认证所述第二认证响应的确认的至少一条指令；以及
用于由所述第一对等设备基于来自所述第二对等设备的确认来认证所述密钥交换的至少一条指令，其中所述第二对等设备基于来自所述第一对等设备的确认来认证所述密钥交换。
30.如权利要求29所述的非瞬态计算机可读介质，其特征在于，进一步包括：
用于在将所述用户的所述联合登录凭证和所述第一标识符发送到所述第一联合登录提供方之前使用所述密钥交换来建立所述第一对等设备与所述第二对等设备之间的安全会话的至少一条指令。
CN201580011495.0A 2014-03-05 2015-03-05 使用终端用户联合登录来检测密钥交换加密信道中的破坏 Pending CN106105137A (zh)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US201461948433P 2014-03-05 2014-03-05
US61/948,433 2014-03-05
US14/638,290 2015-03-04
US14/638,290 US9954679B2 (en) 2014-03-05 2015-03-04 Using end-user federated login to detect a breach in a key exchange encrypted channel
PCT/US2015/019006 WO2015134771A1 (en) 2014-03-05 2015-03-05 Using end-user federated login to detect a breach in a key exchange encrypted channel

Publications (1)

Publication Number Publication Date
CN106105137A true CN106105137A (zh) 2016-11-09

Family

ID=54018515

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201580011495.0A Pending CN106105137A (zh) 2014-03-05 2015-03-05 使用终端用户联合登录来检测密钥交换加密信道中的破坏

Country Status (6)

Country Link
US (1) US9954679B2 (zh)
EP (1) EP3114808A1 (zh)
JP (1) JP2017516328A (zh)
KR (1) KR20160127747A (zh)
CN (1) CN106105137A (zh)
WO (1) WO2015134771A1 (zh)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108199851A (zh) * 2018-02-01 2018-06-22 北京华大智宝电子系统有限公司 一种数据安全传输方法、装置及系统
CN110582773A (zh) * 2017-05-23 2019-12-17 谷歌有限责任公司 使用发现与启动协议的移动辅助电视登入
CN113141671A (zh) * 2021-04-23 2021-07-20 Tcl通讯（宁波）有限公司 wifi设备的通信方法、设备和计算机可读存储介质

Families Citing this family (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10153966B1 (en) * 2015-03-12 2018-12-11 Alarm.Com Incorporated Hybrid mesh network monitoring signaling environment
US9900775B2 (en) * 2015-09-02 2018-02-20 International Business Machines Corporation On-device authorization of devices for collaboration and association
US10834586B2 (en) * 2016-07-29 2020-11-10 Amzetta Technologies, Llc System and method for controlling heterogeneous internet of things (IoT) devices using single application
US10291609B2 (en) * 2016-08-23 2019-05-14 Reavire, Inc. Vault appliance for identity verification and secure dispatch of rights
US10321313B2 (en) 2016-09-09 2019-06-11 Dell Products L.P. Enabling remote access to a service controller having a factory-installed unique default password
CN106572160B (zh) * 2016-10-24 2019-07-23 天津科技大学 一种物联网网关的通信信道扩展系统
US10789386B2 (en) * 2016-11-09 2020-09-29 Reavire, Inc. Dispatching identity information from secure hardware appliance
CN115755687A (zh) * 2017-02-20 2023-03-07 路创技术有限责任公司 集成和控制多个负载控制系统
CN107911483A (zh) 2017-12-12 2018-04-13 阿里巴巴集团控股有限公司 一种信息传输方法和装置
US11218466B2 (en) * 2018-10-31 2022-01-04 Salesforce.Com, Inc. Endpoint security
US11048793B2 (en) 2018-12-05 2021-06-29 Bank Of America Corporation Dynamically generating activity prompts to build and refine machine learning authentication models
US11159510B2 (en) * 2018-12-05 2021-10-26 Bank Of America Corporation Utilizing federated user identifiers to enable secure information sharing
US11113370B2 (en) 2018-12-05 2021-09-07 Bank Of America Corporation Processing authentication requests to secured information systems using machine-learned user-account behavior profiles
US11120109B2 (en) 2018-12-05 2021-09-14 Bank Of America Corporation Processing authentication requests to secured information systems based on machine-learned event profiles
US11036838B2 (en) 2018-12-05 2021-06-15 Bank Of America Corporation Processing authentication requests to secured information systems using machine-learned user-account behavior profiles
US11176230B2 (en) 2018-12-05 2021-11-16 Bank Of America Corporation Processing authentication requests to secured information systems based on user behavior profiles
US11372387B2 (en) * 2020-03-03 2022-06-28 Charter Communications Operating, Llc Metadata-based smart home automation
DE102020110034A1 (de) * 2020-04-09 2021-10-14 Bundesdruckerei Gmbh Überwachungssystem mit mehrstufiger Anfrageprüfung
US11722499B1 (en) * 2022-02-05 2023-08-08 Uab 360 It Optimized messaging in a mesh network

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1833216B1 (en) * 2006-03-07 2010-07-14 Hitachi, Ltd. Method and system for mediation of authentication within a communication network
US20110314287A1 (en) * 2010-06-16 2011-12-22 Qualcomm Incorporated Method and apparatus for binding subscriber authentication and device authentication in communication systems
CN102355662A (zh) * 2011-06-10 2012-02-15 合肥联正电子科技有限公司 一种基于无线低成本设备的密钥交换方法
CN103118009A (zh) * 2013-01-08 2013-05-22 深圳大学 一种认证密钥交换方法及系统

Family Cites Families (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3253060B2 (ja) * 1997-12-25 2002-02-04 日本電信電話株式会社 相互認証方法及びその装置
US7055036B2 (en) * 2001-04-06 2006-05-30 Mcafee, Inc. System and method to verify trusted status of peer in a peer-to-peer network environment
US7596690B2 (en) * 2004-09-09 2009-09-29 International Business Machines Corporation Peer-to-peer communications
KR100988179B1 (ko) * 2006-04-11 2010-10-18 퀄컴 인코포레이티드 다중 인증을 바인딩하는 방법 및 장치
EP1865656A1 (en) * 2006-06-08 2007-12-12 BRITISH TELECOMMUNICATIONS public limited company Provision of secure communications connection using third party authentication
JP4779988B2 (ja) * 2007-02-13 2011-09-28 トヨタ自動車株式会社 全固体リチウム二次電池
JP2009282561A (ja) * 2008-05-19 2009-12-03 Kddi Corp ユーザ認証システム、ユーザ認証方法およびプログラム
US20100228726A1 (en) 2009-02-06 2010-09-09 Slinker Scott W Determining associative intent in a database containing linked entities
WO2011128183A2 (en) 2010-04-13 2011-10-20 Telefonaktiebolaget L M Ericsson (Publ) Method and apparatus for interworking with single sign-on authentication architecture
US9350708B2 (en) * 2010-06-01 2016-05-24 Good Technology Corporation System and method for providing secured access to services
US8799656B2 (en) * 2010-07-26 2014-08-05 Intel Corporation Methods for anonymous authentication and key agreement
US8509431B2 (en) 2010-09-20 2013-08-13 Interdigital Patent Holdings, Inc. Identity management on a wireless device
US9237142B2 (en) * 2011-01-07 2016-01-12 Interdigital Patent Holdings, Inc. Client and server group SSO with local openID
KR20120091635A (ko) * 2011-02-09 2012-08-20 삼성전자주식회사 통신 시스템에서 인증 방법 및 장치
CN103460738B (zh) 2011-03-23 2018-06-01 交互数字专利控股公司 用于使网络通信安全的方法和用户设备
US8839395B2 (en) * 2011-05-13 2014-09-16 Cch Incorporated Single sign-on between applications
WO2012175667A1 (en) * 2011-06-22 2012-12-27 Nec Europe Ltd. Method and system for performing single sign-in user authentication
US10044713B2 (en) 2011-08-19 2018-08-07 Interdigital Patent Holdings, Inc. OpenID/local openID security
WO2013049587A2 (en) * 2011-09-29 2013-04-04 Interdigital Patent Holdings Inc. Method and apparatus for enabling access to applications integrated with a visited network
US9189645B2 (en) * 2012-10-12 2015-11-17 Citrix Systems, Inc. Sharing content across applications and devices having multiple operation modes in an orchestration framework for connected devices

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1833216B1 (en) * 2006-03-07 2010-07-14 Hitachi, Ltd. Method and system for mediation of authentication within a communication network
US20110314287A1 (en) * 2010-06-16 2011-12-22 Qualcomm Incorporated Method and apparatus for binding subscriber authentication and device authentication in communication systems
CN102355662A (zh) * 2011-06-10 2012-02-15 合肥联正电子科技有限公司 一种基于无线低成本设备的密钥交换方法
CN103118009A (zh) * 2013-01-08 2013-05-22 深圳大学 一种认证密钥交换方法及系统

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
MENEZES，VANSTONE，OORSCHOT: "Handbook of Applied Cryptography", 《CRC PRESS LLC，USA》 *

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110582773A (zh) * 2017-05-23 2019-12-17 谷歌有限责任公司 使用发现与启动协议的移动辅助电视登入
CN110582773B (zh) * 2017-05-23 2023-09-26 谷歌有限责任公司 使用发现与启动协议的移动辅助电视登入
CN108199851A (zh) * 2018-02-01 2018-06-22 北京华大智宝电子系统有限公司 一种数据安全传输方法、装置及系统
CN113141671A (zh) * 2021-04-23 2021-07-20 Tcl通讯（宁波）有限公司 wifi设备的通信方法、设备和计算机可读存储介质
CN113141671B (zh) * 2021-04-23 2023-06-20 Tcl通讯（宁波）有限公司 wifi设备的通信方法、设备和计算机可读存储介质

Also Published As

Publication number Publication date
EP3114808A1 (en) 2017-01-11
KR20160127747A (ko) 2016-11-04
JP2017516328A (ja) 2017-06-15
WO2015134771A1 (en) 2015-09-11
US20150256337A1 (en) 2015-09-10
US9954679B2 (en) 2018-04-24

Similar Documents

Publication Publication Date Title
CN106105137A (zh) 使用终端用户联合登录来检测密钥交换加密信道中的破坏
CN105684389B (zh) 基于对等方的认证
CN105531971B (zh) 启用交互式用户应用的网关
Das et al. Taxonomy and analysis of security protocols for Internet of Things
US20230009787A1 (en) Secure device onboarding techniques
CN105874750A (zh) 用于标识物理iot设备的方法和装置
Liu et al. A security framework for the internet of things in the future internet architecture
CN107079055B (zh) 用于物联网(iot)设备的连通性模块
CN106256105A (zh) 用于设置用户偏好或设备配置的方法和装置
Zhang et al. Emerging security threats and countermeasures in IoT
CN105849745A (zh) 使用超声签名的受托设备定位方案
CN105009518B (zh) 用于发现、配置和利用物联网（IoT）网络中的关系的方法
EP2487863B1 (en) Enabling secure access to sensor network infrastructure using multiple interfaces and application based group key selection
CN107155405A (zh) 用于在用户设备之间增量式地共享更大信息量的方法和装置
CN106465048A (zh) 响应于经广播的事件通知而触发目标设备上的命令
CN107409073A (zh) 用于自动化对物联网设备健康状况的直接和间接本地监视的行为分析
CN107148784A (zh) 动态移动自组织物联网(iot)网关
CN106576220A (zh) 用于自动生成物联网（iot）网络中的事件字典的方法和装置
CN105794176A (zh) 为与用户相关联的IoT网络中的IoT设备发现基于云的服务
CN106576244A (zh) 使设备接入到安全本地网络
CN102687547A (zh) 机器对机器网关体系结构
CN106464692A (zh) 确定对接收授权的设备的信任级别
US20210105337A1 (en) Profile information sharing
CN105519204A (zh) 通过数据的智能同步提高功率节省
CN106576229A (zh) 主机设备的自适应宣告以及嵌入式设备的发现

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
C10 Entry into substantive examination
SE01 Entry into force of request for substantive examination
AD01 Patent right deemed abandoned
AD01 Patent right deemed abandoned

Effective date of abandoning: 20190924