CN109891416A - 用于认证和授权装置的系统和方法 - Google Patents
用于认证和授权装置的系统和方法 Download PDFInfo
- Publication number
- CN109891416A CN109891416A CN201780065045.9A CN201780065045A CN109891416A CN 109891416 A CN109891416 A CN 109891416A CN 201780065045 A CN201780065045 A CN 201780065045A CN 109891416 A CN109891416 A CN 109891416A
- Authority
- CN
- China
- Prior art keywords
- key
- scm
- authorization
- acp
- cloud
- 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
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/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/3263—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 involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
- G06F21/31—User authentication
- G06F21/33—User authentication using certificates
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
- G06F21/44—Program or device authentication
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
- G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
- G06F21/572—Secure firmware programming, e.g. of basic input output system [BIOS]
-
- 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/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
- H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
-
- 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/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
- H04L63/062—Network architectures or network communication protocols for network security for supporting key management in a packet data network for key distribution, e.g. centrally by trusted party
-
- 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/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/0869—Network architectures or network communication protocols for network security for authentication of entities for achieving mutual authentication
-
- 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/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
- H04L9/0825—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) using asymmetric-key encryption or public key infrastructure [PKI], e.g. key signature or public key certificates
-
- 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
-
- 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
-
- 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/321—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 involving a third party or a trusted authority
- H04L9/3213—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 involving a third party or a trusted authority using tickets or tokens, e.g. Kerberos
-
- 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/3234—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 involving additional secure or trusted devices, e.g. TPM, smartcard, USB or software token
-
- 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/3247—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 involving digital signatures
-
- 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
- H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
- H04W12/08—Access security
-
- 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
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W76/00—Connection management
- H04W76/10—Connection setup
-
- 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/80—Wireless
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Hardware Design (AREA)
- General Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Computing Systems (AREA)
- Software Systems (AREA)
- General Physics & Mathematics (AREA)
- Physics & Mathematics (AREA)
- Mobile Radio Communication Systems (AREA)
- Telephonic Communication Services (AREA)
- Lock And Its Accessories (AREA)
Abstract
一种用于分布式安全模型的系统和方法,其可以用于实现以下中的一个或更多个:认证系统组件;在系统组件之间安全地传送消息;在受约束链路上建立安全的通信信道;认证消息内容;授权动作;以及在装置‑作为‑密钥的系统中的用户的系统组件之间分发授权和配置数据。
Description
技术领域
本申请涉及用于认证和授权装置和/或分发密钥的系统和方法。
背景技术
已经为了使得能够利用智能电话作为用于使得能够访问或命令诸如门或车辆的设备装置的操作的密钥做出了极大努力。然而,这些常规系统依赖于被认为是简化形式的安全性,该安全性依赖于进行网络访问以认证智能电话是否具有指挥设备装置的操作的授权的设备装置。当授权装置先前未与设备装置进行通信以识别对密钥、装置或用户的授权时,这样的常规设备装置不能认证和/或授权密钥、装置和用户中的至少一个。换言之,在授权装置与设备装置之间缺少通信链路或缺少连接的情况下,该常规系统中的设备装置不能确定尝试与设备装置进行通信的智能电话是否已经被职权装置授权。
在车辆制造商利用的常规密钥卡(key fob)系统中,关于密钥卡的密钥和/或认证信息在密钥卡被认证和/或授权之前被分发给授权装置,并且授权装置能够将授权信息传送到设备装置。
因为例如系统可能在认证和/或授权过程期间依赖于能够与云系统(或者由于缺少连接而不能到达的其他系统组件)进行通信的设备装置,因此类似的常规系统可能无法在不存在通信链路期间认证和/或授权任何密钥、装置或用户。这种场景(缺少连接)可能看起来像困境情况;然而,这种情况实际上非常普遍——在没有蜂窝连接的情况下,考虑停车库或偏远地区的汽车或森林里的屋舍。在这种情况下缺少连接可以防止使得能够对智能电话或其他装置授予权利以操作车辆或获得对屋舍的访问。
发明内容
本公开内容大部分涉及一种用于分布式安全模型的系统和方法,该系统和方法可以用于实现以下中的一个或更多个:认证系统组件,在系统组件之间安全地传送消息,在受约束的链路上建立安全通信信道,认证消息内容,授权动作,以及在装置-作为-密钥系统中的用户的系统组件之间分发授权和配置数据。
根据一个实施方式的系统可以利用用于以下中的一个或更多个的可能唯一的标识符来便于认证:便携式装置、云或网络服务器或系统、硬件、改变和撤销。
在一个实施方式中,系统可以使得能够以安全且私密的方式在系统组件之间传输信息。在一个实施方式中,可以存在跨所有通信链路提供的端到端加密。系统可以形成分布式系统,其中,一些数据可以通过未加密的信道来发送,但数据本身是完全加密的。
在一个实施方式中,系统可以基于a)认证的实体的一个或更多个签名链、b)可能的独立云以及c)信任根与认证根之间的可能的分离来提供授权。授权可以在所有者与客户之间被区分并且提供所有权的转移。
根据一个实施方式的系统可以便于授权的分发以及包括新密钥生成、改变的密钥标识、黑名单/撤销通知、密钥的循环、所有权的转移、重新设置,用于配置的信任根、密钥和其他数据的一个或更多个相关特征。
根据一个实施方式的系统可以提供一个或更多个安全检查,包括例如配置排序、时间增量和破解检测。
在一个实施方式中,系统可以提供密钥属性授权模型,其中,每个授权可以具有被认为将授权标识为有效所必需的一个或更多个属性。这样的一个或更多个属性的示例包括时间、使用次数、位置和自定义属性。
在一个实施方式中,系统可以便于共享模型,其中,授权可以是每个装置、每个装置+帐户和/或每个帐户(例如,甚至在组织级别处)专用或授予的。
在一个实施方式中,系统可以在可信装置级别和/或云级别处提供时间同步。
根据一个实施方式的系统可以使得能够在即使第一眼看上去没有工作的因特网连接的情况下在装置之间授予认证和授权。
该系统可以提供移动软件可信执行环境、硬件TEE或安全元件(安全存储装置)以便于安全操作。
在一个实施方式中,提供了一种用于将命令从第一装置传送到第二装置的系统。第一装置可以被配置成:在在线模式下与网络服务器进行无线通信,并且从网络服务器获得授权配置信息。授权配置信息可以涉及关于第一装置向第二装置发布命令的授权,并且授权配置信息可以包括由与第二装置相关联的第一密钥加密的数据。
第二装置可以是设备组件,并且可以被配置成指挥设备控制执行命令。
第二装置可以被配置成在离线模式下与第一装置进行无线通信,在所述离线模式下,第一装置和第二装置都不能够与网络服务器有效通信。第一装置和第二装置可以被配置成建立用于交换通信的通信链路,其中,在建立通信链路之前,第二装置没有接收到指示第一装置已经获得授权配置信息的信息,所述授权配置信息涉及关于第一装置向第二装置发布命令的授权。
第一装置可以经由通信链路将授权配置信息传送到第二装置。第一装置还可以经由通信链路传送与执行命令的请求有关的命令信息。第二装置可以基于授权配置信息来认证第一装置的身份并且确定关于第一装置向第二装置发布命令的授权。
在一个实施方式中,用于控制设备组件的操作的控制单元包括通信接口、存储器、设备接口和控制器。通信接口可以可操作成与远程装置进行无线通信,并且存储器可以被配置成存储涉及远程装置的认证和授权的一个或更多个加密密钥。设备接口可以可操作成响应于从远程装置接收的命令来指挥设备控制的操作。
控制单元的控制器可以被配置成:建立经由通信接口与远程装置的通信链路,并且从远程装置接收授权配置信息。授权配置信息可以包括被加密的授权数据,其中,仅控制器能够解密来自授权配置信息的授权数据。
至少部分地基于授权数据,控制器可以认证远程装置的身份并且确定远程装置向远程装置发布命令的授权。
提供了一种根据一个实施方式的在第一装置与第二装置之间通信的方法。该方法可以包括在第一装置中从网络服务器获得授权配置信息,其中,授权配置信息包括由与第二装置相关联的第一密钥加密的数据。该方法可以包括建立用于在第一装置与第二装置之间交换通信的通信链路,其中,在建立通信链路之前,第二装置没有接收到指示第一装置已经获得授权配置信息的信息。
该方法可以包括:在第二装置中接收授权配置信息,以及在第二装置中解密授权配置信息以获得涉及关于第一装置指挥第二装置的操作的一个或更多个授权的装置密钥和授权数据。
第二装置可以基于从授权配置信息获得的装置密钥来认证第一装置的身份,并且从第一装置接收命令。
该方法可以包括:确定第一装置是否被授权发布命令,并且响应于确定第一装置被授权发布命令,指挥设备组件执行命令。
在一个实施方式中,提供了一种与依赖于集中式云和与云的连接的常规密钥分发系统不同的系统。例如,在本公开内容的一个实施方式中,可以将密钥发送到装置,并且可以由授权方(例如,锁)验证该密钥。
在一个实施方式中,可以提供一种安全模型,其中不存在高价值目标,可以在没有知识的情况下不损害组件(没有单个组件漏洞损害系统的安全)。
在详细说明本发明的实施方式之前,应当理解,本发明不限于以下描述中阐述的或附图中示出的操作细节或组件的构造细节和布置。本发明可以在各种其他实施方式中实现,并且可以以本文未明确公开的可替选方式来实践或来执行。此外,应当理解,本文使用的措辞和术语是为了描述的目的,而不应被认为是限制性的。“包括”和“包含”及其变型的使用意在涵盖其后列出的项及其等同物以及附加项及其等同物。此外,列举可以用在各种实施方式的描述中。除非另外明确说明,否则列举的使用不应被解释为将本发明限制于任何特定顺序或数量的组件。也不应该将列举的使用解释为从本发明的范围中排除可以与所列举的步骤或组件组合或者被组合到所列举的步骤或组件中的任何附加步骤或组件。
附图说明
图1是根据一个实施方式的系统的代表性视图。
图2是一个实施方式中的系统组件的代表性视图。
图3示出了根据一个实施方式的微位置系统。
图4示出了根据一个实施方式的ACP容器。
图5描绘了根据一个实施方式的ACP容器和ACP容器版本包。
图6描绘了根据一个实施方式的信任和授权树。
图7示出了根据一个实施方式的另一信任和授权树。
图8描绘了根据一个实施方式的发布关于SCM的授权的方法。
图9示出了根据一个实施方式的注册装置的方法。
图10示出了根据一个实施方式的生成用户帐户的方法。
图11A至图11B是根据一个实施方式的数据分发的代表性视图。
图12是根据一个实施方式的对密钥进行循环的方法。
图13示出了根据一个实施方式的建立微位置连接的方法。
图14示出了根据一个实施方式的建立安全且可信的通信链路的方法。
图15示出了根据一个实施方式的用于授予权利的区块扇(blockfan)分发方案。
图16示出了根据一个实施方式的数据分发的代表性视图。
图17示出了根据一个实施方式的系统的代表性视图。
具体实施方式
本公开内容涉及用于分布式安全模型的系统和方法,其可以用于实现以下中的一个或更多个:认证系统组件,在系统组件之间安全地传输消息,在受约束的链路上建立安全的通信信道,认证消息内容,授权动作,以及在装置-作为-密钥的系统中的用户系统组件之间分发授权和配置数据。系统的一个或更多个方面可以结合于2015年2月12日提交的发布为美国专利9,666,005并且题为“SYSTEM AND METHOD FOR COMMUNICATING WITH AVEHICLE”的J.Michael Ellis等人的美国非临时申请第14/620,959号以及于2017年4月14日提交的发布为美国专利9,794,753并且题为“SYSTEM AND METHOD FOR ESTABLISHINGREAL-TIME LOCATION”的Raymond Michael Stitt的美国非临时申请第15/488,136号中描述的微位置系统的一个或更多个方面来实现——这两个申请的公开内容以其整体并入本文中,并且其中,硬件可以是监视器或主装置,导致认证验证的、授权验证的和位置验证的便携式装置与具有端到端加密(安全、可信和私有)的其他系统的交互。
I.系统架构
根据一个实施方式的系统在图1和图17中示出并且通常被指定为100。系统100可能受到以下系统组件的损害:a)一个或更多个用户10(例如,人);b)一个或更多个装置110,诸如便携式装置(例如,智能电话、卡或密钥卡或其组合)和/或固定装置(例如,计算机/服务器或壁挂式面板/显示器或其组合);c)一个或更多个系统控制模块(SCM)120,也被描述为硬件;d)云130,其可以包括来自一个或更多个供应商的一个或更多个后端服务器或计算机的集合(例如,云的集合);以及e)一个或更多个设备组件140,其可以被配置成用于:控制设备操作,激活其上的服务,将信息中继到系统100的另一方面,或者从系统100的另一方面重新得到信息,或者其组合。在示出的实施方式中,云130和/或设备140是可选的。
系统100可以使得一个或更多个用户10能够使用装置110与设备140交互或访问设备140。装置110可以通过与SCM 120通信来与设备140(诸如车辆、锁或桌子)进行通信。在一个实施方式中,SCM 120可以认证装置110,提供或接收配置数据,授权动作(例如,以连接或发送和/或接收请求、命令、更新或响应、或其组合),或者与设备组件140进行通信以实现期望的动作,或其组合。装置110可以与云130进行通信以在相关装置和用户之间获得、改变或分发或其组合授权(本文中描述的)和其他配置数据。存在与安全模型不显著相关的其他系统交互,并且出于公开的目的,没有进一步详细示出或描述。例如,存在与SCM 120和云130进行通信的工厂工具,云130可以与其他系统的云交互。
A.通信和交互概述
在图1的示出的实施方式中描绘的一个或更多个系统组件之间的通信链路可以是无线的或有线的或者无线的和有线的这两者。诸如装置110的一个系统组件可以相对于诸如SCM 120的另一系统组件是本地的或远程的。系统100可以包括任意数量的每个系统组件,包括数量为零诸如不存在云和/或设备的情况的实施方式。
在一个实施方式中,系统100中的系统组件的角色不一定固定为一种类型的组件。例如,系统组件可以在操作期间动态地改变角色,或者系统组件可以担任系统100的两个或更多个组件的角色。例如,SCM 120可以是关于另一SCM 120的设备组件140。在该示例的更具体的形式中,SCM 120可以是与其他SCM 120进行通信的设备组件140。出于公开的目的,剩余讨论集中于存在一个或更多个设备组件140和云130的系统100——但是应当理解这些系统组件中的一个或更多个可以不存在。
B.组件概述
示出的实施方式中的系统100可以包括如本文所概述的一个或更多个系统组件。系统组件可以是用户或电子系统组件,电子系统组件可以是装置110、SCM 120、设备组件140和云130或其组合。如本文讨论的,电子系统组件可以被配置成操作为这些装置中的任意一个或更多个。在这个意义上,在一个实施方式中,可以存在装置110、SCM 120、设备组件140和云130之间共有的若干方面或特征。出于公开的目的,结合图2中描绘的并且通常被指定为200的电子组件来描述这些特征。
电子系统组件200(例如,除用户之外的所有系统组件)可以包括:执行一个或更多个应用232(软件和/或包括固件)的一个或更多个处理器210、一个或更多个存储器单元212(例如,RAM和/或ROM)以及一个或更多个通信单元214,其他电子硬件也在其中。电子系统组件200可以具有或可以不具有操作系统230,该操作系统230控制经由通信单元214对较低级别的装置/电子器件的访问。电子系统组件200可以具有或可以不具有基于硬件的加密单元222——在它们不存在的情况下,加密功能可以在软件中执行。电子系统组件200可以具有或可以不具有(或可以访问)安全存储器单元220(例如,安全元件或硬件安全模块(HSM))。在示出的实施方式中,可选的组件和通信路径以虚线示出。
示出的实施方式中的系统100不依赖于任何组件中的安全存储器单元220的存在。在可选的不存在安全存储器单元220的情况下,可以在静止时(在可能的情况下)对将被存储在安全存储器单元220中的数据(例如,私有密钥和/或秘密密钥)进行加密。可以利用基于软件的缓解和基于硬件的缓解两者来基本上防止对这样的数据的访问,以及基本上防止或检测或者防止并检测总的系统组件损害。这样的缓解特征的示例包括:实现物理障碍或屏蔽、禁用JTAG和其他端口、硬化软件接口以消除攻击向量、使用可信执行环境(例如,硬件或软件或者硬件和软件这两者)以及检测操作系统根访问或损害。
出于公开的目的,通常认为安全的是机密的(加密的)、认证的和完整性验证的。然而,应当理解,本公开内容不限于此,并且术语“安全的”可以是这些方面的子集,或者可以包括与数据安全性相关的另外方面。
通信接口214可以是任何类型的通信链路,包括本文描述的任何类型的通信链路,包括有线或无线。通信接口214可以便于外部或内部或者外部和内部这两者的通信。例如,通信接口214可以为以装置110的形式的另一系统电子装置200提供无线通信链路,诸如根据蓝牙LE标准的无线通信或者经由WiFi以太网通信链路的云130。在另一示例中,通信接口214可以被配置成:经由便于多个装置之间的通信的有线链路如基于CAN的有线网络与设备组件140(例如,车辆组件)进行通信。在一个实施方式中,通信接口214可以包括用于向用户10传送信息以及/或者从用户10接收信息的显示器和/或输入接口。
在一个实施方式中,如图2所示,电子系统组件200可以被配置成与除了另一电子系统组件200或用户之外的一个或更多个辅助装置300进行通信。辅助装置300可以与电子系统组件200不同地被配置——例如,辅助装置300可以不包括处理器210,而是可以包括用于与电子系统组件200进行信息的发送或接收或者发送和接收这两者的至少一个直接连接和/或通信接口。例如,辅助装置300可以是从电子系统组件200接受输入的螺线管,或者辅助装置300可以是向电子系统组件200提供模拟和/或数字反馈的传感器(例如,接近传感器)。
C.微位置
示出的实施方式中的系统100可以被配置成实时地确定关于装置110的位置信息。在图1的示出的实施方式中,用户10可以携带装置110(例如,智能电话)。系统100可以便于以足够的精度实时地相对于设备140(例如,车辆)定位装置110,以确定用户是否位于应当授权对设备的访问或对设备命令的许可的位置处。
例如,在车辆领域中,设备140是车辆,系统100可以便于确定装置110是否在车辆外部但是非常接近驾驶员侧的门,诸如5英尺、3英尺或2英尺或更短的距离内。该确定可以形成用于识别系统100是否应当解锁车辆的基础。另一方面,如果系统100确定装置110在车辆外部但不非常接近驾驶员侧的门(例如,在2英尺、3英尺或5英尺的范围之外),则系统100可以确定锁定驾驶员侧的门。作为另一示例,如果系统100确定装置110非常接近驾驶员侧的座位但不接近乘客座位或后座位,则系统100可以确定能够动用车辆。相比之下,如果确定装置110在非常接近驾驶员侧的座位之外,则系统100可以确定要固定或保持车辆的固定。
该背景下的车辆还可以包括其他类型的设备140,诸如与结合图3的示出的实施方式描述的远程装置310类似并且如图16和图17中以传感器和传感器集线器配置示出的一个或更多个传感器。形成图16中的传感器和传感器集线器配置的设备140可以包括如本文讨论的以便于认证从传感器和传感器集线器接收的信息的一个或更多个密钥。应当注意,一个或更多个密钥可以并入到系统100中,以与传感器或远程装置310和/或传感器集线器一起使用。在结构上类似于设备装置或系统100的另一组件的一个或更多个附加密钥可以驻留在SCM 120和传感器网络中的传感器/传感器集线器上。另外地或可替选地,这些密钥中的一个或更多个和/或系统100的一个或更多个其他密钥可以用于识别传感器网络中的传感器/传感器集线器的真实性并授权传感器网络中的传感器/传感器集线器的参与。
可以以各种方式——诸如使用从全球定位系统获得的信息、来自装置110以及一个或更多个传感器(例如,接近传感器、限位开关或视觉传感器)的通信的一个或更多个信号特性、或其组合——确定设备140的微位置。用于可以配置系统100的微位置技术的示例公开在于2017年4月14日提交的题为“SYSTEM AND METHOD FOR ESTABLISHING REAL-TIMELOCATION”的Raymond Michael Stitt等人的美国非临时专利申请第15/488,136号中——该专利的公开内容在此通过引用整体并入本文中。更具体地,在图3的示出的实施方式中描绘的一个示例中,SCM 120和多个远程装置310(在一些方面类似于装置110)可以相对于设备组件140设置在固定位置上或固定位置中。设备组件140的示例用例包括在先前示例中识别的车辆或者由设备组件140控制访问的建筑。
装置110可以经由通信链路与SCM 120进行无线通信(例如,经由蓝牙LE)。多个远程装置310可以被配置成:嗅探装置110与SCM 120之间的通信,以确定通信的一个或更多个信号特性如信号强度。确定的信号特性可以被传送或分析并且然后经由和装置110与SCM120之间的通信链路分开的通信链路被传送到SCM 120。另外地或可替选地,装置110可以与远程装置310中的一个或更多个建立直接通信链路,并且可以基于该直接通信链路来确定一个或更多个信号特性。
例如,如示出的实施方式中所示,从装置110到SCM 120的通信的传播波被示出并且被指定为302、304、306。距装置110(源)的距离越大,无线通信的强度就越小。关于传播波306的通信强度小于传播波302的强度。此外,在时间t0处发送通信的情况下,传播波302处的通信的行进时间(tpl-t0)小于传播波306处的通信的行进时间(tp3-t0)。因此,如果远程装置320在传播波302处接收到通信,则通信到达的时间戳将早于如果在传播波306处接收到通信的时间戳。可以分析一个或更多个信号特性如信号强度和到达时间,以确定关于装置110相对于SCM 120的位置信息。例如,可以处理远程装置310与SCM 120之间的到达时间差,以确定装置110的相对位置。一个或更多个远程装置310相对于SCM 120的位置可能是已知的,使得装置110相对于远程装置310和SCM 120的相对位置可以被转换成绝对位置。可以获得信号特性的另外示例或可替选示例以便于根据一个或更多个算法确定位置,所述一个或更多个算法包括距离函数、三边测量函数、三角测量函数、多点定位函数、指纹识别函数、微分函数、飞行时间函数、到达时间函数、到达的时间差函数、到达角度函数、出发角度函数、几何函数等或其任意组合。
应当注意,出于说明的目的,传播波302、304、306被描绘为均匀圆形——然而,传播波的形状可以根据诸如干扰或定向天线的使用的其他因素而变化。
在一个实施方式中,可以将与装置110和SCM 120之间的通信相关的信息提供给多个远程装置320。例如,可以将与蓝牙LE信道相关的连接参数提供给远程装置320,使得多个远程装置320可以监视通信。例如,通信信道可以在通信期间改变一个或更多个参数,诸如从分组到分组或在分组中发送的比特之间的传输频率。这些一个或更多个可变参数可以被传送到远程装置320,以使得能够接收分组或通信。
如本文所讨论的,系统100可以利用安全模型以便于以下中的一个或更多个:认证系统组件,在系统组件之间安全地传输消息,在受约束的链路上建立安全的通信信道,认证消息内容,授权动作,以及在装置作为密钥的系统中的用户的系统组件之间分发授权和配置数据。
II.授权
如本文所描述的,系统100可以将一个或更多个权利与装置110相关联,便于利用系统内的一个或更多个权利的授权。如本文所讨论的,授权通常是使得装置110(用作用于特定用户10的代理)能够在一个或更多个约束(也被描述为访问属性)内与SCM 120(用作用于特定设备的代理)交互的访问权利或权利,所述一个或更多个约束可以特定于SCM 120和/或装置110。
在一个实施方式中,密钥(凭证或虚拟/电子/移动密钥)被分发给装置110,然后在用于验证(或其某些变型)时被传递给SCM 120。
在系统100的示出的实施方式中,装置110本身(其身份)可以是密钥,并且SCM 120可以基于SCM 120已经被配置成用于装置110的一个或更多个授权来授权装置110的期望动作。装置110的“身份”可以是(或可以基于)对装置110而言唯一的加密身份或任何其他标识符或者其中的多个和/或其任意组合中的一个或更多个。加密标识符的示例包括唯一的公开密钥/私有秘钥,诸如在非对称加密中生成的密钥对、诸如在对称加密中生成的密钥的共享秘密密钥。对装置110而言唯一的另一标识符的示例包括硬件序列号、硬件安全模块(HSM)以及一个或更多个应用实例标识符。装置110的一个或更多个加密身份和/或一个或更多个其他标识符的示例组合包括多个加密身份以及加密身份和非加密身份。
装置110可以在任何给定时间处具有零个或更多个授权,包括关于同一SCM 120的多个授权或者关于另一SCM 120的不同授权。授权是本文描述的安全模型的有用部分,原因是授权提供可以便于以下中的一个或更多个的信息:使得装置110能够与SCM 120进行通信,相互认证多于一个的装置110和多于一个的SCM 120,以及识别装置110可以与SCM 120交互的条件。除了对于认证有用的信息之外,授权可以关于SCM 120为每个装置110定义它们的访问属性。根据一个实施方式的访问属性可以包括以下中的一个或更多个:
1)类型(例如,所有者、客户、代客等)——标准。各种授权类型可以导致不同的授权分发/共享权利(例如,所有者可以使另一装置成为所有者而不是客户等)。还可能存在只有具有所有者(或其他类型的)授权的用户才能访问的命令或其他系统级功能。对于附加信息,参考章节VII的授权类型。
2)有效时间戳范围开始——标准
3)有效时间戳范围结束——可选的。如果存在,则授权可以在特定日期/时间自动撤销。
4)有效时间表——可选的。如果存在,则授权仅可以按照定义的时间表(例如,指定在一周的每一天可以利用的时间期间的重复发生的每周时间表、每月时间表或自定义时间表)来使用。
5)有效使用次数——可选的。如果存在,则授权仅可以使用多达一定次数(例如,命令的数量、使用的天数/小时数)。
6)附加认证类型和标识符——可选的。如果存在,则授权可以利用除系统已经提供的之外的附加(主动或被动)认证(例如,要求装置解锁/登录/按钮按压/密码输入/指纹/需要存在另一装置/等以发布特定命令)。
7)分发权利——可选的。如果存在,则引用权利管理服务中的授权的权利(参见本文的描述),其标识和/或描述装置110必须向关于SCM 120的另一装置110发布新授权的权利。换言之,分发权利涉及装置110与另一装置共享授权的权利。如果不存在,则这可以完全或部分基于至少在章节1)和章节VII处描述的授权类型。在可替选实施方式中,授权类型和数字权利管理服务两者都可以诸如通过彼此交叉检查一起使用。
8)命令权利——可选的。如果存在,则引用权利管理服务中的授权的权利(参见本文的描述),其标识和/或描述装置110必须发布或接收或者发布和接收特定命令或响应或者命令和响应的权利。例如,装置110可以发布打开门而不是关闭门的命令。可以基于每个命令或基于每个类授予权利。如果不存在,则命令权利可以完全或部分基于至少在章节1)和章节VII处描述的授权类型。在可替选实施方式中,授权类型和数字权利管理服务两者可以诸如通过彼此交叉检查一起使用。在另一可替选实施方式中,可以改为提供授权命令(以及其他可能必需的元数据)的列表。在又一可替选实施方式中,可以改为提供禁止命令(以及其他可能必需的元数据)的列表。
9)SCM 120可以同意或拒绝交互的其他可能属性。在一个实施方式中,只有当装置110拥有对这样的安全通信的授权时,装置110才可以与SCM 120安全地通信——但是应当理解,可能存在装置110可能与SCM120不安全地通信的场景或情况。
应当注意,可能并非所有属性都需要被传送到SCM 120或装置110。例如,一些属性可以仅存在于云130中。
SCM 120可以基于以下中的至少一个来授权装置110发送或接收或者发送和接收请求、命令、更新和响应中的一个或更多个:1)一个或更多个授权已经被认证(例如,至少在章节III处参见ACP);2)满足一个或更多个被认证的授权中的所有或一些可能的必要条件;以及3)装置110已经被认证。照此,除了上面标识的条件之外,每个授权可以包含加密密钥(例如,装置-SCM-密钥和/或用户-SCM-密钥)以及用于装置110建立与目标SCM 120的加密通信链路、用于装置110认证目标SCM 120以及用于目标SCM 120认证装置110的数据。在该背景下用于装置110的数据在本文中在系统密钥描述章节中进一步详细描述,其在章节XII处也被指定为密钥系统。
III.授权配置包
在一个实施方式中,可以经由根据图4中的一个实施方式示出的并且被指定为400的授权配置包(ACP)以安全方式将信息传送到SCM 120。ACP 400可以包括可以被递送到SCM120的授权或其他配置数据或者授权和其他配置数据这两者。装置110中的一个或更多个可以将ACP 400递送到SCM 120——但是应当理解,ACP 400可以经由其他装置被递送到SCM120并且本公开内容不限于经由装置110递送。
ACP 400可以封装在ACP容器410中,ACP容器410可以封装在如根据图5中的一个实施方式示出的ACP容器集合414中。ACP 400、ACP容器410或ACP容器集合414或其任意组合可以基于有序的多层加密。ACP容器410可以包括嵌套层,每个层以不同的方式被加密,诸如通过根据不同的加密密钥加密每个层。以这种方式,嵌套层可以被概念化为洋葱的层,其中,在不解密外层的情况下不能访问每个内层。
在一个实施方式中,ACP容器410可以是通过分布式系统将配置数据递送到SCM120的安全装置。示出的实施方式中的ACP容器410可以由云130递送到装置110。ACP容器410可以以提供以下中的一个或更多个的方式利用有序的多层加密:
·无论装置或通信安全性如何(例如,不安全装置使用不安全通信链路),基本保证机密性和完整性
·基本保证真实性,并且多个认证的系统组件已经批准ACP 400的内容(例如,如本文所述,当使用单独的云授权请求和云授权批准服务时的所有者装置110、所有者装置110的用户以及包括例如两个或更多个云服务130的一个或更多个云服务130)
·基本保证ACP 400意在用于目标SCM 120并且其他系统组件可能无法解密ACP400的未授权内容
·基本保证系统100的状态(例如,合适的系统组件已经按照定义的顺序批准配置)
·即使目标SCM 120先前未与装置110进行通信,也使得能够仅使用装置110与目标SCM 120之间的通信链路来执行认证和授权(例如,当从因特网断开连接时,此时装置110和SCM 120都不能访问任何云服务130——换言之,装置110和SCM 120两者都可能离线——仍然可以执行认证)
ACP容器410的结构以及可以由云130强制执行的授权改变处理和包层的加密排序可以确保:仅目标SCM 120能够完整地解密ACP容器410,并且多个系统组件(例如,用户10、云130和所有者装置110或其组合)已经批准了ACP 400。ACP容器410的加密序列在下面从最内层(最后解密的)到最外层(首先解密的)进一步详细描述。ACP容器410的结构可以随应用而变化。然而,在示出的实施方式中,ACP容器410可以包括完整性散列(例如,加密散列和/或签名)、时间戳、版本、发送者身份、接收者身份以及其他数据位置和封装属性(图4或图5中未示出)中的至少一个。
在SCM 120的所有必要的授权的层已经被解密、认证、完整性验证以及针对一致性的跨层检查属性之后,ACP容器410或其层中的任意层(包括ACP 400)可以由SCM 120处理和/或存储。在示出的实施方式中,SCM 120被授权处理和解密ACP容器410的所有层,然而,应当理解,可能存在SCM 120未被授权或未被配置成处理或解密的ACP容器410的其他层。还应注意,本文描述的ACP容器410具有许多层;然而,ACP容器410的层数和配置或结构可以根据应用而变化。还应理解,虽然可以存储ACP容器410的任何部分(包括ACP 400),但这样的层可以以接收格式(加密的)、接收但解密的格式、以可替选格式(例如,针对存储效率或运行时检索优化的)或其任意组合来存储。
A.ACP外层1
在图4的示出的实施方式中,ACP 400包含在被指定为401的ACP外层1内。ACP外层1可以确认:ACP 400源自云130并且目的地为目标SCM 120。云130可以用密钥(诸如,在本文中至少在章节XII处更详细描述的云-SCM-密钥密钥)加密ACP外层1,该密钥可以特定于由目标SCM 120和云130定义的对。在一个实施方式中,可选地,仅云130、目标SCM 120和具有关于该目标SCM 120的授权的装置110能够解密该ACP外层1。
在可替选实施方式中,用于加密ACP外层1的密钥可以是不特定于由目标SCM 120和云130限定的对的云-SCM-密钥密钥——例如,可以利用在SCM 120的系统中的所有SCM120之间共享的公开密钥。在不存在云-SCM-密钥密钥的一个实施方式中,可以以与不限于使用云-SCM-密钥不同的方式来完成ACP源自云130并且目的地为目标SCM 120的验证。在可替选实施方式中,系统100可以不利用基于云-SCM-密钥对ACP外层1的验证,而改为可以依赖于其他层的加密和排序或云130的认证(本文描述的)。
B.ACP外层2
在图4的示出的实施方式中,ACP外层1包含在被指定为402的ACP外层2内。ACP外层2可以确认:用于目标SCM 120的ACP 400(源自云130)由用户10在关于目标SCM 120的所有者装置110上查看并批准。云130的用户帐户服务可以用密钥——诸如在本文中至少在章节XII处更详细描述的并且可以特定于由目标SCM 120和与装置110相关联的用户帐户限定的对的用户-SCM-密钥密钥——来加密ACP外层2。在一个实施方式中,可以针对目标SCM 120向用户帐户发布授权,通过该用户帐户授权与该用户帐户相关联的装置110中的所有装置。
在一个实施方式中,可选地,仅云130、目标SCM 120和与用户帐户相关联的批准ACP 400的装置110能够解密ACP外层2。
在可替选实施方式中,装置110可以用密钥——诸如,在本文中至少在章节XII处更详细描述的并且可以特定于由目标SCM 120和装置110定义的对的装置-SCM-密钥密钥——来加密ACP外层2。在一个实施方式中,可以针对目标SCM 120向特定装置110发布授权。在一个实施方式中,可选地,仅云130、目标SCM 120和关于目标SCM 120的批准ACP 400的特定所有者装置110能够解密ACP外层2。
在可替选实施方式中,ACP外层2可以用不特定于由目标SCM 120和装置110或用户帐户限定的对的装置-SCM-密钥或用户-SCM-密钥密钥来加密——例如,可以利用在SCM120的系统中的所有SCM 120之间共享的公开密钥来加密。在一个实施方式中,在装置-SCM-密钥或用户-SCM-密钥密钥并非不同于云-SCM-密钥密钥的情况下,或者在装置-SCM-密钥或用户-SCM-密钥不存在的情况下,ACP 400由用户10在关于目标SCM 120的所有者装置110上查看并批准的验证可以以与不限于使用云-SCM-密钥不同的方式来完成。在可替选实施方式中,系统100可以不利用基于云-SCM-密钥或用户-SCM-密钥对ACP外层2的验证,而是改为可以依赖于其他层的加密和排序或云的认证(本文描述的)。
C.ACP外层3
在图4的示出的实施方式中,ACP外层2包含在被标记为403的ACP外层3内。ACP外层3可以确认:用于目标SCM 120的ACP 400(源自云130)由用户10在关于目标SCM 120的所有者装置110上查看并批准,由云130验证为已经由用户10在关于目标SCM 120的所有者装置110上经由带外认证机制(本文描述的)批准而没有改变。云130可以用密钥——诸如在本文中至少在章节XII处更详细描述的并且可以特定于目标SCM 120的SCM-密钥密钥——加密该层。在一个实施方式中,仅目标SCM 120能够解密ACP外层3。因为ACP外层2可以由可能的多个所有者帐户(用户-SCM-密钥密钥)和/或装置110(装置-SCM-密钥密钥)中的一个加密,所以用于该层的元数据包括哪个帐户和/或装置110签名ACP外层2(例如,装置-SCM-ID或用户-SCM-ID)的指示。
在可替选实施方式中,ACP外层3可以用不特定于目标SCM 120的SCM密钥密钥加密——可以利用在SCM 120的系统中的所有SCM 120之间共享的公开密钥加密。在一个实施方式中,在SCM-密钥密钥并非不同于装置-SCM-密钥密钥的情况下,或者在SCM-密钥不存在的情况下,由用户10在关于目标SCM 120的所有者装置110上经由带外认证机制(本文描述的)在云130批准ACP 400而没有改变的情况下的验证可以以与不限于使用SCM-密钥密钥不同的方式完成。在可替选实施方式中,系统100可以不利用基于SCM密钥对ACP外层3的验证,而改为可以依赖于其他层的加密和排序或云的认证(本文描述的)。在该验证中涉及带外认证的所有实施方式中,存在完全移除带外认证或者仅某些类型的改变需要带外认证的可替选配置。
D.ACP外层4
在图4的示出的实施方式中,ACP外层3包含在被指定为404的ACP外层4内。ACP外层4可以确认:完成的ACP容器410被云130批准并源自云130并且目的地为目标SCM 120。云130可以用密钥——诸如在本文中至少在章节XII处更详细描述的并且可以特定于由目标SCM120和云130限定的对的云-SCM-批准-密钥密钥——来加密ACP外层4。在一个实施方式中,可选地,仅云130、目标SCM 120和具有关于该目标SCM 120的授权的装置110能够解密ACP外层4。
在一个实施方式中,云授权请求和云授权批准服务可以不分开,因此ACP外层4可以用在本文中至少在章节XII处更详细描述的并且可以特定于由目标SCM 120和云130限定的对的云-SCM-密钥密钥来加密。
在一个实施方式中,ACP外层4可以用不特定于由目标SCM 120和云130限定的对的云-SCM-批准-密钥或云-SCM-密钥密钥来加密。例如,可以利用在SCM 120的系统中的所有SCM 120之间共享的公开密钥。在一个实施方式中,在云-SCM-批准-密钥或云-SCM-密钥密钥并非不同于SCM-密钥密钥的情况下,或者在云-SCM-批准-密钥或云-SCM-密钥不存在的情况下,完成的ACP容器410被云130批准并源自云130并且目的地为目标SCM 120的验证可以以不同的方式完成。在可替选实施方式中,系统100可以不利用基于云-SCM-批准-密钥或云-SCM-密钥对ACP外层4的验证,而改为可以依赖于其他层的加密和排序或云的认证(本文描述的)。
如在安全模型内利用的ACP容器410的结构可以实现或基本实现认证和授权的分离。虽然安全模型可以将这些动作分离成不同的服务和结构,但是安全模型可能不会将认证和授权明确地隔离到被单独认证的两个单独的树(即,单独的信任根)中。而是,可以通过分布式加密和顺序解密对认证和授权树进行单独认证。可以通过要求黑客从多个单独的物理云服务器130获得密钥以生成和/或解密ACP容器410(除了装置110之外)来近似认证和授权的分离。
用于近似认证和授权的分离的一个示例配置是分离a)生成初始ACP 400并且请求用户10批准ACP 400的服务(云授权请求服务)以及b)验证用户10批准初始ACP 400并且生成最终的ACP容器410的服务(云授权批准服务)。在一个实施方式中,ACP外层4中使用的密钥(例如,由云授权批准服务使用的云-SCM-批准-密钥)可以不同于ACP外层1中使用的密钥(例如,由云授权请求服务使用的云-SCM-密钥)。在一个实施方式中,签名ACP外层4的云服务130如云授权批准服务与签名ACP外层1的云服务130如云授权请求服务分离。在一个实施方式中,签名ACP外层4的云服务130如云授权批准服务与签名ACP外层1的云服务130如云授权请求服务在不同的服务器上。
IV.ACP容器的分发
在一个实施方式中,ACP容器410可以包含关于目标SCM 120的所有当前授权。每当用于SCM 120的ACP 400内包含的数据经由推送机制改变时,云130可以自动地创建和/或更新完整的(即,非部分更新)ACP容器410并将其分发给所有相关装置110。示例改变包括:a)授权和ACP 400中的数据是对SCM 120的添加、改变和撤销中的至少一个,b)SCM 120被指示恢复出厂设置,c)第一所有者装置被授权,以及d)加密密钥被循环。
A.推送ACP容器
推送机制可以用于所有ACP容器410分发,或者推送机制的使用可以限于响应于某些改变和/或事件的ACP容器410的分发。相关装置110可以被认为是具有当前授权或者先前具有一个或更多个授权但尚未被递送用于目标SCM 120的更新的ACP容器410(例如,SCM120具有较新的ACP 400)的装置110。当前授权是尚未被撤销(即,移除、禁用、删除等)并且尚未到期的授权(即,有效的授权)。使用的推送机制可以基于装置110的类型而变化,推送机制包括但不限于移动、web或桌面平台推送通知服务(例如,websocket、Apple推送通知服务(APNS)、谷歌云消息接发(GCM)和Urban Airship)的任意组合;基于持久轮询的装置-云连接或基于长轮询的装置-云连接或类似的装置-云连接;网状、星形和/或其他拓扑装置-装置消息接发;以及短信。
推送机制可以直接递送ACP容器410,或者推送机制可以向装置110通知更新的ACP容器410(使得装置110能够立即或稍后请求ACP容器410)。装置110可以被配置成不准许某些类型的推送机制(例如,APNS),在这种情况下,云130可以使用可替选的推送机制(例如,SMS)或不使用推送机制(例如,装置110可以周期性地轮询更新的ACP容器410)。在可替选实施方式中,系统100可以始终使用推送机制来分发ACP容器410。在可替选实施方式中,系统100可以不使用推送机制或者不总是使用推送机制来分发ACP容器410。在可替选实施方式中,系统100可以使用推送机制将ACP容器410分发给在相关装置中具有授权(当前或非当前)的所有装置110。在可替选实施方式中,系统100可以分发ACP容器410以在相关装置中分发仅当前授权。在可替选实施方式中,当前授权的范围可以被扩展成包括在固定或可配置的预定时间量(例如,每个云、每个装置、每个SCM、每个设备)内已经到期的授权。例如,分发的当前授权可以包括过去两天内已经到期的授权。
在示出的实施方式中,云130可以在没有当前授权的情况下将当前ACP容器410分发给相关装置110。在可替选实施方式中,云130可以在没有当前授权的情况下分发给每个相关装置110、ACP容器110的该装置110不再具有任何当前授权的第一版本。
当某些事件发生时,装置110可以自动地从云130请求用于SCM 120(或者用于装置110具有当前授权的所有SCM 120)的当前批准的ACP 400。当应用改变执行状态(例如,开始、暂停、重新开始、停止或终止)时,或者周期性地,当到SCM 120和/或云130的连接被建立时或者当用户请求到SCM 120和/或云130的连接时,示例事件包括紧随其后的重置。在一个或更多个可替选实施方式中,可以实现以上分发和/或请求触发组合的所有排列。
一个或更多个SCM 120或者一个或更多个装置110或其任意组合可以位于到云130的通信链路不可用的环境中。例如,通信链路可以通过任何方式——包括间接地通过其他系统组件,诸如通过另一装置110或设备组件140路由通信链路——不存在或不可用。这样的通信链路的缺少可以是永久的或临时的。
在一个实施方式中,主要因为SCM 120在授权装置110之前不必完全与云130通信,因此系统100的安全模型不会显著地遭遇通信的缺乏。SCM 120可能仅期望装置110在与SCM120进行通信之前的某个时刻处与云130进行通信。在这种情况下可能出现的一个问题是:除非SCM 120已经存储了包含关于装置110的授权的ACP 400,否则SCM 120可能无法建立与装置110的安全通信链路。然而,至少部分地由于ACP容器410的加密排序或分层或加密排序和分层这两者并且由于ACP容器410可以仅由目标SCM 120解密,因此ACP容器410可以通过不安全的通信链路被递送到SCM 120。照此,SCM 120可以通过任何通信链路从任何源——包括从SCM 120可能从未与之通信的装置110以及从不拥有授权的装置110(或其他系统组件/源)——接收更新的ACP 400。例如,其授权被撤销的装置110可以传送包括更新的ACP400的ACP容器410。
在一个实施方式中,在建立安全通信链路之前,装置110可以将更新的ACP 400递送到SCM 120。在安全通信链路已经被建立之后,装置110还可以将更新的ACP 400递送到SCM 120——如果更新的ACP 400不包含关于连接的装置110的授权,则可以终止这样的现有安全通信链路。在一个实施方式中,SCM 120可以拒绝建立与系统组件的安全通信链路,该系统组件拥有ACP容器410的比SCM 120存储的版本更新的版本。在一个实施方式中,SCM120可以拒绝建立与系统组件的安全通信链路,该系统组件拥有ACP容器410的与SCM 120存储的版本不匹配的版本。
B.ACP容器版本包
为了便于消除SCM 120用每个连接从每个装置110接收和处理ACP容器410以确定装置110是否具有不同的ACP 400的需要,作为装置110与SCM 120之间的连接建立过程(本文描述的)的一部分,ACP容器410的第一N个字节(其中,N是获得所需信息所必需的字节数,在本文中也被称为ACP容器版本包412)可以被发送用于SCM 120进行解密以获得所需信息,其中,所需信息可以包括ACP版本和/或用于比较的其他属性,诸如完整性散列或签名或者完整性散列和签名这两者。在一个实施方式中,如本文中描述的,ACP容器版本包412作为ACP容器410的第一N个字节(其中N是被认为获得所需信息所必需的字节数)被递送到装置110。如果SCM 120确定装置110具有ACP 400的较新版本,则SCM 120可以在安全连接可以被建立之前利用装置110来提供更新的ACP 400。在可替选实施方式中,如果装置110具有可能不比存储在SCM 120中的ACP 400更新的不同的ACP 400,则SCM 120可以确定执行ACP更新处理。如果SCM 120不处于等待第一所有者装置110与SCM 120相关联的恢复出厂设置模式,并且ACP容器版本包412没有被提供,则可以拒绝或终止或者拒绝和终止与装置110的连接。这种恢复出厂设置操作模式在本文中至少在章节X.D处另外详细描述。
如果装置110已经与SCM 120建立了安全连接,则SCM 120可以周期性地请求装置110发送它的ACP容器版本包412,然后,如果存在更新的ACP 400,则断开连接并且需要装置110重新连接(因此发送更新的ACP 400),或者请求装置110通过安全连接发送更新的ACP400。另外地或可替选地,如果装置110已经与SCM 120建立了安全连接,则装置110可以向SCM 120通知更新的ACP 400(伴随有ACP容器版本包412),如果SCM 120确定更新是合适的(如本文中描述的),则断开连接并且期望装置110重新连接(因此发送更新的ACP 400),或者请求装置110通过安全连接发送更新的ACP 400。如果装置110不能响应于发送它的ACP容器版本包412的请求(例如,在一段时间内),则SCM 120可以与装置110断开连接。
在一个实施方式中,作为在本文中至少在章节XIV处描述的连接建立过程的一部分,ACP容器版本包412可以作为单独的加密包由云130递送到很可能是装置110的发送者以递送到SCM。如在图5中由ACP容器集合414描绘的,ACP容器版本包412可以与ACP容器410一起递送,或者作为ACP容器410的第一部分递送。应当注意,在整个本公开内容中,ACP容器410和ACP容器集合414可以互换使用。还应注意,在ACP 400的递送被描述的情况下,可以经由ACP容器410完成这样的递送。
在一个实施方式中,如图5中所示,ACP容器版本包412可以包括ACP版本、诸如大的随机数或序列号的一个或更多个嵌入的标识符以及消息认证代码或签名。嵌入的标识符、消息认证代码、签名以及ACP-版本-密钥密钥的一部分或全部中的一个或更多个可以存储在ACP容器410内用于验证。ACP容器版本包412可以用由云130生成并且如本文描述的特定于目标SCM 120的密钥如ACP-版本-密钥密钥来加密。在可替选实施方式中,ACP容器版本包412可以用ACP-版本-密钥密钥来加密,另外用一个或更多个其他密钥如装置-SCM-密钥密钥或SCM-密钥密钥或这两者来加密。
在可替选实施方式中,ACP容器版本包412仅仅是ACP 400的ACP版本,该ACP版本由装置110拥有、由装置110先前生成或提供,并且在ACP容器410中没有相应的加密密钥。作为示例,在该实施方式中,SCM 120可以信任由装置110提供的版本并且使用该版本来确定是否请求ACP容器410。ACP版本可以由数字或字符串限定,所述数字或字符串可以或可以不经由装置110用共享的加密密钥来加密。
应该认识到,该可替选实施方式与先前描述的实施方式相比不太安全并且具有潜在的弱点,由此装置110可以说它具有装置110期望的ACP 400的任何版本;然而,通常,这不太可能发生,并且最可能的缺点可能是:装置110将(a)不发送ACP 400用于更新(因为版本比当前版本旧)或者(b)发送ACP 400用于更新(如果版本号非常高,则每次在处理之后被拒绝)。实际上认为装置110不可能制造ACP 400;因此,最可能的缺点是SCM 120变得承担许多额外的工作——即,拒绝服务(DoS)。
C.验证
当SCM 120接收ACP容器410时,SCM 120可以通过以下操作来验证ACP容器410的真实性:依次解密ACP容器410的层,确保ACP容器410的内容没有被改变并且已经通过计算和比较完整性散列(签名)而被正确地解密,验证提供的ACP容器版本包412及其内容与ACP容器410的各个层处的相应内容(例如,ACP版本和任何其他可适用属性)一致,并且当在每层处理ACP容器410时执行其他一致性和数据完整性/验证检查(未列出)。
如果在任何时刻ACP容器410验证失败,则ACP容器410可以被认为无效并被拒绝(没有存储)。如果新ACP容器410被接受(例如,所有验证成功完成并且新ACP 400被认为与当前ACP 400不同),则新ACP容器410被存储在SCM 120中并且可以被立即激活或立即成为当前ACP 400。
因为解密ACP容器410被认为是密集处理并且可能存在用于实时系统的更优化的数据结构/组织,所以ACP容器410(或ACP 400)本身在被接收时可以或可以不存储在SCM120的存储器212中。ACP容器410或ACP 400可以存储在安全存储器220或等同的硬件模块如安全包体(Secure Enclave)或硬件安全模块(HSM)中。ACP容器410或ACP 400可以以其整体或仅其一部分存储。可替选地,ACP容器410或ACP 400可以用ROM中的可替选加密密钥来加密(并且在执行期间被解密并被存储在RAM中),或者ACP容器410或ACP 400可以没有加密而存储在受保护的ROM中,或者以上技术或其他技术的一些组合。附加技术或其他技术的示例包括基于软件的缓解或基于硬件的缓解,其可以防止对这样的数据的访问,提供硬件障碍或屏蔽,提供物理障碍或屏蔽,禁用JTAG和其他端口,硬化软件接口以消除攻击向量,建立可信执行环境(硬件或软件),并且检测操作系统根访问或损害。
在可替选实施方式中,ACP容器410的内容而非ACP容器410的原始形式可以没有加密而存储在ROM中。在另一可替选实施方式中,ACP容器410可以在被接收时存储在ROM中(具有所有加密层),并且然后在操作期间被解密并存储在RAM中。
D.获得ACP容器——递送路径
根据本公开内容的一个实施方式的ACP容器410和/或ACP容器版本包412可以由装置110或SCM 120或者装置110和SCM 120这两者以各种方式接收或获得。
在一个实施方式中,可选地,ACP容器版本包412由装置110提供给SCM 120。如果ACP容器版本包412没有被提供给SCM 120,则可能需要SCM 120来获得并解密ACP容器410的第一层以确定封装的ACP 400的ACP版本。在可替选实施方式中,装置110可以不提供ACP容器版本包412。这可以要求装置110或SCM 120通知或请求ACP容器410的更新并且完整地处理ACP容器410。
在另一可替选实施方式中,装置110可以从SCM 120请求SCM 120当前拥有的ACP容器版本包412。然后,装置110可以将在ACP容器版本包412中标识的ACP 400的版本与在存储器中存储的ACP 400的版本进行比较,并且决定是否向SCM 120发送ACP容器410。在该实施方式中,作为如在本文中至少在章节XIV处描述的关于装置110和SCM 120的连接建立过程的一部分,可以不发送对ACP容器版本包412的请求。
在一个实施方式中,装置110可以以其整体将ACP容器410的完整版本发送到SCM120。在一个实施方式中,装置110可以将ACP容器410发送到听凭装置110处理的SCM 120,这可以基于用户请求、云请求或装置处理或其任意组合。在一个实施方式中,可以使用可用的通信链路通过除装置110之外的系统组件如设备组件140或连接至装置110的其他附件将ACP容器410递送到SCM 120。可用的通信链路可以根据应用而变化或在不同情况下变化,并且可以是物理介质、无线链路、或有线链路或其任意组合。
在一个实施方式中,ACP容器410可以经由云130直接被递送到SCM 120。另外地或可替选地,ACP容器410可以被递送到可替选和/或中间系统组件如设备组件140或另一装置,然后使用可用的通信链路被递送到SCM 120。可用的通信链路可以根据情况而变化,并且可以是物理介质、无线链路和有线链路中的至少一个。
在示出的实施方式中,ACP容器410的完整形式可以被发送到SCM 120,原因是存在系统状态随着部分更新易变的潜在风险,包括由于因特网连接不稳定导致的意外行为以及部分更新失败的可能性。示例风险场景包括:如果所有者添加装置A并且然后移除装置B,则存在SCM 120处的作为结果的配置可以是装置A和装置B都不能访问的状态。换言之,第一更新可能已经失败。然而,可以通过添加属性以跟踪部分更新版本和排序来克服或减少这些风险。
在一个实施方式中,可以从云130获得对ACP容器410的部分或渐进式更新。更新可以包括授权的添加、移除、或改变或其组合以及循环加密密钥中的至少一个。在一个实施方式中,对ACP容器410的部分或渐进式更新可以被发送到SCM 120。在可替选实施方式中,ACP容器410可以被分成较小的配置包,诸如SCM身份配置包和ACP 400。
在一个实施方式中,可能需要或期望减小发送的ACP容器410的大小。这样做的一种方法是使用增量更新,其中,可以仅发送两个特定ACP容器410之间的差异。考虑到可能存在ACP容器410的大量版本并且增量更新镜像特定于ACP容器410的之前和之后版本,增量更新镜像(被发送到SCM 120的完成更新的镜像)可以由将增量更新镜像发送到SCM 120的系统组件(例如,装置110)生成。在一个实施方式中,增量更新镜像可以用于将ACP容器410发送到SCM 120,其中,增量更新镜像由将增量更新镜像发送到SCM 120的系统组件(例如,装置110)创建。在一个实施方式中,增量更新镜像可以用于将ACP容器410发送到SCM 120,其中,增量更新镜像由云130创建。在一个实施方式中,增量更新镜像可以用于系统100内的其他消息和配置包。
另外地或可替选地,可以通过压缩来实现发送的ACP容器410的大小的减小。压缩可以由云130或由发送ACP容器410的系统组件(例如,装置110)执行。在一个实施方式中,压缩可以用于将ACP容器410发送到SCM 120。在一个实施方式中,压缩和增量更新镜像两者都可以用于按照任一顺序(首先压缩,然后增量,或者首先增量,然后压缩)将ACP容器410发送到SCM。在一个实施方式中,压缩可以用于系统100内的其他消息和配置包。
在一个实施方式中,SCM 120可以连接至云130,并且其中,SCM 120不将授权存储在ACP 400中,而是在适当或必要时请求云130确定特定装置110是否被授权。例如,可以请求云130确定装置110身份被授权。如果装置110确实具有授权,则然后可以在装置110连接至SCM 120的持续时间内(或者如果存储器允许,则更长)将授权高速缓存在SCM 120上。另外地或可替选地,授权可以被高速缓存在本地服务器(或服务器的集合)上以减少网络时延。
在一个实施方式中,存储在装置110上的用于特定SCM 120的ACP 400可以仅包含关于该装置110的授权。另外地或可替选地,SCM 120可以将来自多个装置110的授权并入存储在SCM 120中的合并的ACP 400中。
在一个实施方式中,每个SCM 120可以接收和存储多个ACP 400,其中,每个ACP400包含关于SCM 120发布的总授权集的子集。这可以防止ACP 400在许多装置110被授权的环境(例如,数百或数千名雇员被授权解锁特定锁的建筑访问管理系统或车队环境)中变得太大。每个子集ACP 400的内容可以仅包含关于用户帐户和/或装置110的特定集合的授权。例如,在一个实施方式中,可以为每个用户帐户创建子集ACP 400(其中,ACP 400仅包含与该用户帐户相关联的装置110)。例如,在另一实施方式中,可以为每个10用户帐户的集合创建子集ACP 400。例如,在又一实施方式中,可以为每个100个装置110的集合创建子集ACP400。子集ACP 400可以作为包含所有子集ACP的组合ACP容器410、包含任意数量的子集ACP400(例如,改变的子集ACP 400)的组合ACP容器410、单独的ACP容器410(即,用于每个子集ACP 400中的一个)或其任意组合的一部分被递送。在一个实施方式中,每个ACP容器410可以具有包含被认为是每个子集ACP 400所必需的版本化信息的一个ACP容器版本包412。在另一实施方式中,每个ACP容器410可以具有多个ACP容器版本包412。
V.可替选的包管理和递送
可以存在目的地为SCM 120的其他数据包,所述数据包可以根据本文关于ACP容器410描述的实施方式中的一个或更多个来构造和生成,所述数据包包括与ACP容器410类似的语义、操作和编码。因此,应当理解,可以利用并且可以以类似方式管理和/或递送可替选的配置(和其他)包。还可以存在目的地为其他系统组件(例如,装置110或设备组件140)的包。以下是可能存在的示例包(示例包中的一些可能在本文中进一步详细讨论):
1)应用配置
2)固件更新包
3)子组件配置
4)设备协议配置
5)设备模型
6)黑名单包
7)系统日志包
在本文描述的安全模型/系统被应用于微位置系统的实施方式中,微位置系统的示例在于2015年2月12日提交的并且题为“SYSTEM AND METHOD FOR COMMUNICATING WITHA VEHICLE”的J.Michael Ellis等人的美国非临时申请第14/620,959号以及于2017年4月14日提交的并且题为“SYSTEM AND METHOD FOR ESTABLISHING REAL-TIME LOCATION”的Raymond Michael Stitt的美国非临时申请第15/488,136号中被描述——这两个申请的公开内容通过引用整体并入本文中。可以根据微位置系统的一个实施方式提供的信息的示例包括以下:
1)区域配置或相关数据可以标识相对于SCM 120的被认为与设备140的用户或所有者的使用相关的一个或更多个区域或空间。例如,门的5英尺内的区域或空间可以被认为与门的操作相关——例如,存在于该区域内可以触发通过门进入的实现。
2)监视器配置和放置或相关数据——诸如用于与SCM 120进行通信以及远程装置310相对于SCM 120的定位的连接参数——可以标识结合图3的示出的实施方式描述的远程装置310的配置。
3)算法调整配置或相关数据可以指示关于用于确定装置110相对于SCM 120的位置的算法的一个或更多个补偿因子。
4)算法模型或相关数据可以指示用于确定装置110相对于SCM 120的位置的算法。
VI.候选ACP
在示出的实施方式中,云130可以为每个SCM 120保持ACP 400的当前工作副本(候选ACP)。候选ACP可以在版本控制下可能由ACP 400的版本标识,其中每当进行改变时版本都会改变。例如,可以创建新版本,并且每当进行改变时可以递增ACP 400的版本。
当创建新的候选ACP时,该ACP被识别用于从所有者帐户的批准,可以诸如经由推送通知或SMS来通知所有者帐户装置110中的每个(因此,相应的用户10)已经创建了新的ACP 400用于批准。然后,用户10可以在装置110上获得最新的候选ACP用于批准。用户10可以从与所有者用户帐户(即,已经被授权为SCM 120的所有者的用户帐户)相关联的装置110中的任何装置110批准候选ACP。
在一个实施方式中,仅向特定装置110(即,而不是向用户帐户)发布授权;照此,当创建新的候选ACP时,该ACP被识别用于从所有者装置110批准,可以诸如经由推送通知或SMS来通知所有者装置110(及其相应的用户10)已经创建了新的ACP 400用于批准。然后,用户10可以在该装置110上获得最新的候选ACP用于批准。
在一个实施方式中,候选ACP可以包括来自其他所有者10的另外改变,这些改变中的一些或所有可能是不需要的。因此,用户10可以(a)通过不批准候选ACP来拒绝候选ACP,在这种情况下不会发生任何事情,或者(b)编辑候选ACP直到它是可接受的为止,将改变提交给云130(将另一批准请求推送给所有者装置10),然后批准ACP。编辑、提交和批准的步骤可以在装置110的用户界面中进行组合。在被拒绝的候选ACP的情况下,候选ACP可以保留,并且未来的改变可以建立在被拒绝的版本之上。
如果提交对候选ACP的编辑并且候选ACP的ACP版本不再是当前ACP版本,则云130可以拒绝提交并且允许装置110获得较新的候选ACP用于评估。例如,如果候选ACP在批准过程期间已经由另一装置110更新,则可能已经在ACP 400的较旧版本上执行了对装置110的编辑,因此云130可以拒绝由装置110提交的任何改变并且基于ACP 400的当前版本重新开始用于接受和编辑候选ACP的批准过程。
在由用户10与所有者装置110一起批准候选ACP之后或者响应于由用户10与所有者装置110一起批准候选ACP,候选ACP可以由批准装置110的装置-SCM-密钥(私有)密钥签名。在一个实施方式中,候选ACP可以另外由与批准装置110相关联的用户-SCM-密钥密钥签名。在另一实施方式中,可替选地,候选ACP可以由与批准装置110相关联的用户-SCM-密钥密钥签名。候选ACP的签名的版本可以被提交给云130,云130可以确定候选ACP的签名的版本是否与在云130中存储的候选ACP的当前版本匹配以及/或者合适的装置110是否批准(签名)它。可选地,云130可以确定所有者装置110的用户10是否还没有禁用双因素认证(2FA),如果所有者装置110的用户10还没有禁用双因素认证,则云130可以(经由一个或更多个选择的介质,诸如用户10的装置110或与用户10相关联的另一装置)向用户10发送2FA代码。
如果由装置110向云130提交的候选ACP的签名的版本与在云130中存储的候选ACP的当前版本不匹配,或者它没有被合适的装置110批准,则提交可以被拒绝(并且可以重复批准过程)。如果由装置110提交的候选ACP的签名的版本与云130中的当前候选ACP匹配,则候选ACP被标识为已经被合适的装置110批准,并且用户10没有使2FA被启用,提交被接受。可选地,如果用户接收到2FA代码,则用户可以在他们的所有者装置110上输入2FA代码,然后该所有者装置110将输入的2FA代码提交给云130。然后,云130可以验证提交的2FA与被发送的2FA代码匹配。如果匹配,则假设其他标准也满足时认为该提交被接受;如果不匹配,则提交被拒绝(并且可以重复批准过程)。在可替选实施方式中,云130可以在接收到一个或更多个用户相关密钥——诸如在本文中至少在章节XII.N处描述的那些(例如,视网膜、面部和/或触摸ID)——时进行接受。
在云130确定接受由装置110对候选ACP的签名的版本的提交之后,云130可以将相应的候选ACP标记为已批准,生成最终ACP容器410,并且将ACP容器410分发给与SCM 120相关联的各种装置。在一个实施方式中,如果提交的ACP版本比候选ACP更旧,则提交被拒绝。
候选ACP方法可以向系统110提供ACP 400的区块链类型分类账(ledger)以及可以避免可能并发或阻塞问题的方法这两者,可能并发或阻塞问题可以在可能力图要批准ACP400的多个版本的情况下或者在可能一次力图要批准ACP 400的仅一个版本的情况下出现。ACP 400的分类账可以提供审计历史,其中,每个编辑产生新版本,并且每个版本与特定装置110相关联。
在可替选实施方式中,可以不利用分发和批准ACP 400的候选ACP处理。而是,每当进行引起批准的改变时,可以生成新的ACP 400用于批准。另外地或可替选地,每当在批准新的ACP 400之前的后续改变被拒绝的情况下进行引起批准的改变时,可以生成新的ACP400用于批准。
VII.授权类型
在一个实施方式中,系统100可以利用一个或更多个权利或者将所述一个或更多个权利与装置100相关联,所述一个或更多个权利被限定为一个或更多个授权并且在本文中至少在章节II处被讨论。授权可以具有与其相关联的类型(例如,参见章节1)和VII)),该类型被称为授权类型。
授权可以与在装置110与SCM 120之间限定的配对相关联。应当理解,出于公开的目的,结合与一个SCM 120配对的一个装置110来描述授权和授权类型。然而,在装置110与SCM 120之间可能存在许多配对的组合,包括多个装置110与一个或更多个SCM 120相关联。
在一个实施方式中,对于用户帐户被授权的每个SCM 120,授权类型可以与用户帐户相关联。于是,授权类型可以流向针对每个装置110创建的并与用户的帐户相关联的授权。例如,用户帐户服务可以为用户的装置110中的每个创建授权,将关于特定SCM 120的用户帐户授权类型应用于创建的授权中的每个。在一个实施方式中,对于用户帐户被授权的每个SCM 120,用户帐户可以具有零个或更多个授权类型,根据已经与用户帐户相关联的授权,每个授权类型在不同时间和/或在不同条件(例如,下周的客户管理员,然后之后是客户)下有效。
在又一实施方式中,授权可以仅与特定装置110相关联。例如,一个或更多个或所有授权可以不与用户帐户相关联以及/或者在用户帐户的相关联装置110之间共享。
授权类型可以最终指示特定装置110在特定SCM 120上具有的角色的类型。在系统100中,授权类型还可以确定与特定授权相关联的授权权利,包括但不限于要进行以下中的一个或更多个的权利:授予另一权利;转移所有权;使某人成为所有者;添加客户;与他人共享;以及/或者发布特定命令。在可替选实施方式中,可以分开管理授权类型和授权权利,诸如根据在本文中至少在关于区块扇权利管理的章节XX处描述的一个或更多个实施方式。因为授权类型可以控制特定装置110(以及通过代理,其用户10)能够针对特定SCM 120(以及通过代理,与SCM 120通信的设备组件)执行的各种动作,因此授权类型可以是安全模型的有用方面。出于公开的目的,下面列出了示例授权类型,示例授权类型包括但不限于所有者授权类型、客户管理员授权类型、客户授权类型、代客授权类型和组织授权类型。
A.所有者
可以为在给定SCM 120上具有完全授权的用户帐户和/或装置110保留所有者授权类型。具有所有者授权类型的用户帐户可以被称为所有者帐户。具有所有者授权的装置110可以被称为所有者装置110。每个帐户和/或装置110可以与关于给定SCM 120的多达一个所有者授权相关联;然而,SCM 120可以与多个所有者帐户和/或装置110相关联。在一个实施方式中,关于给定SCM 120的所有者帐户和/或装置110可以不具有关于同一SCM 120的其他有效授权。诸如根据在本文中至少在章节VIII处描述的授权发布方法,如果在其他授权已经被发布之后向帐户和/或装置110发布所有者授权,则可以撤销所有其他授权。
在可替选实施方式中,SCM 120可以具有多达一个所有者帐户。
在可替选实施方式中,SCM 120可以具有多达一个所有者装置。
在图1的示出的实施方式中,所有者帐户和/或装置110可以查看、发布(创建)、修改和撤销(移除)关于给定SCM 120的任何授权。所有者帐户和/或装置110可以将SCM 120转移到新帐户和/或装置110,从而撤销源自所有者帐户和/或装置110的关于SCM 120的所有授权,然后分别为目标帐户和/或装置110创建所有者授权。在一个实施方式中,所有者帐户和/或装置110可以被配置成使得所有者帐户和/或装置110必须批准关于给定SCM 120的所有授权改变。可能需要或可能不需要涉及用户10,这取决于改变的类型。在一个实施方式中,任何所有者帐户和/或装置110可以批准授权改变。当帐户和/或装置110的所有者授权被撤销时,源自帐户和/或装置110的所有授权也可以被撤销。
在可替选实施方式中,当帐户和/或装置110的所有者授权被撤销时,源自该帐户和/或装置110的所有授权可以被移动到关于SCM 120的另一所有者帐户和/或装置110或客户管理员帐户和/或装置110。
如本文所讨论的,授权可以与包括授权是否包括所有者授权类型的一个或更多个访问属性相关联。将访问属性限制或改变为已发布的授权的修改可以应用于包括访问属性的已发布授权中的所有授权(包括可以基于访问属性被限制或改变而发布的所有授权)。例如,如果所有者授权类型或访问属性被改变,则可以以类似方式修改从该所有者授权类型发布的任何授权。在可替选实施方式中,将访问属性(例如,对开始/结束日期的改变)限制为发布授权的修改可以不影响基于发布授权的访问属性的已发布授权中的任何授权。
在一个实施方式中,除非在处于恢复出厂设置的状态下——在这种情况下,SCM120在等待其第一所有者帐户和/或装置110的分配时处于过渡状态——否则系统100中的SCM 120的所有或子集可以被配置成使得SCM 120中的每个具有至少一个所有者帐户和/或装置110。应当理解,并非所有实施方式都可以以这种方式配置。在至少一个所有者帐户和/或装置110与给定SCM 120相关联之后,至少一个所有者帐户和/或装置110可以保持与给定SCM 120相关联。例如,除非给定SCM 120被转移到新的所有者帐户和/或装置110,否则可以不撤销关于给定SCM 120的最后所有者授权。在可替选实施方式中,关于SCM 120的最后所有者授权可以被撤销,并且当最后的所有者授权被撤销时,SCM 120进入恢复出厂设置模式。
在一个实施方式中,一旦所有者授权被创建,所有者授权就无法被改变为另一授权类型。在可替选实施方式中,所有者授权可以被改变为任何其他授权类型。到另一授权类型的改变可以导致先前被发布但现在不再被允许的授权。这些授权可以自动或手动地被移动到具有可适用的授权的可替选帐户和/或装置110,或者被撤销。
B.客户管理员
客户管理员授权类型可以与在给定SCM 120上具有几乎全部授权的帐户和/或装置110相关联。具有客户管理员授权的装置110可以被称为客户管理员装置(或者在关于客户授权类型不存在行为差异时仅被称为客户装置)。具有客户管理员授权类型的用户帐户可以被称为客户管理员帐户(或者在关于客户授权类型不存在行为差异时仅被称为客户帐户)。每个帐户和/或装置110可以具有关于给定SCM 120的多达一个客户管理员授权;然而,SCM 120可以具有多个客户管理员帐户和/或装置。关于给定SCM 120的客户管理员帐户和/或装置110可以不具有关于同一SCM 120的其他有效授权。在一个实施方式中,诸如根据在本文中至少在章节VIII处描述的授权发布方法,如果在其他授权已经被发布之后向帐户和/或装置110发布客户管理员授权,则所有其他授权可以被撤销。
在可替选实施方式中,每个帐户和/或装置110可以具有关于给定SCM 120的零个或更多个客户管理员授权。在另一可替选实施方式中,可以向每个帐户和/或装置110发布关于同一SCM 120的零个或更多个其他可允许授权。在再一可替选实施方式中,如果其他授权已经被发布,则可以不向帐户和/或装置110发布客户管理员授权。诸如根据在本文中至少在章节VIII处描述的授权发布方法,在又一可替选实施方式中,如果在其他授权已经被发布之后向帐户和/或装置110发布客户管理员授权,则冗余或不允许的授权可以被撤销。
在图1的示出的实施方式中,客户管理员帐户和/或装置110可以发布(创建)非所有者授权,但是可以仅查看、修改和撤销(移除)它们关于给定SCM 120发布(或已发布)的授权。可以向客户管理员帐户和/或装置110发布具有有限访问属性的授权。例如,可以向客户管理员帐户和/或装置110发布具有有限有效日期的授权。
客户管理员帐户和/或装置110可以不发布具有比客户管理员帐户和/或装置110的授权更广泛的访问属性的授权。为了提供示例,客户管理员帐户和/或装置110可以不发布具有在与客户管理员授权类型相关联的有效日期之外的有效日期的授权。
当客户管理员帐户和/或装置110的授权访问属性被修改成进一步受到限制时,由客户管理员帐户和/或装置110发布的授权可以相应地被修改成保持可允许或者可以被撤销。在一个实施方式中,当对帐户和/或装置110的客户管理员授权被撤销时,源自来自帐户和/或装置110的客户管理员授权的所有授权也被撤销。关于SCM 120的客户管理员帐户和/或装置110可以不关于同一SCM 120向自身(即,向同一帐户和/或装置110)发布授权。
在可替选实施方式中,关于SCM 120的客户管理员帐户和/或装置110可以关于同一SCM 120向自身(即,向同一帐户和/或装置110)发布授权。在一个实施方式中,客户管理员授权可以没有有限的访问属性。在一个实施方式中,对于给定SCM 120,听凭发布帐户和/或装置110处理,从发布帐户和/或装置110(例如,所有者帐户和/或装置110)发布授权的客户管理员帐户和/或装置110可以查看发布给从发布帐户和/或装置110——包括或排除发布帐户和/或装置110——发布授权的其他帐户和/或装置110的授权。在可替选实施方式中,当帐户和/或装置110的客户管理员授权被撤销时,源自帐户和/或装置110的客户管理员授权的所有授权可以被移动到关于SCM 120的另一所有者帐户和/或装置110或客户管理员帐户和/或装置110。
在一个实施方式中,客户管理员帐户和/或装置110可以提交授权修改请求,用于由发布帐户和/或装置110(例如,所有者帐户和/或装置110)批准。
在一个实施方式中,一旦客户管理员授权被创建,客户管理员授权就不能被改变为另一授权类型。在一个实施方式中,客户管理员授权可以被改变为任何其他授权类型,可能导致从客户管理员授权发布的将不再被允许的一个或更多个授权。这样的授权可以自动或手动地被移动到具有可适用的授权的可替选帐户和/或装置110,或者被撤销。
C.客户
客户授权类型可以与在给定SCM 120上具有有限授权的帐户和/或装置110相关联。具有客户授权的装置110可以被称为客户装置110。具有客户授权类型的用户帐户可以被称为客户帐户。每个帐户和/或装置110可以具有关于给定SCM 120的零个或更多个客户授权,而SCM 120可以具有多个客户帐户和/或装置110。关于给定SCM 120的客户帐户和/或装置110可以不具有关于同一SCM 120的有效所有者或客户管理员授权。诸如根据在本文中至少在章节VIII处描述的授权发布方法,如果在其他授权已经被发布之后向帐户和/或装置110发布客户授权,则冗余或不允许的授权可以被撤销。
在可替选实施方式中,每个帐户和/或装置110可以具有关于给定SCM 120的多达一个客户授权。在另一可替选实施方式中,诸如根据在本文中至少在章节VIII处描述的授权发布方法,如果在其他授权已经被发布之后向帐户和/或装置110发布客户授权,则所有其他授权可以被撤销。在再一可替选实施方式中,可以向每个帐户和/或装置110发布关于同一SCM 120的零个或更多个其他可允许的授权。在又一可替选实施方式中,如果其他授权已经被发布,则可以不向帐户和/或装置110发布客户授权。在又一可替选实施方式中,诸如根据在本文中至少在章节VIII处描述的授权发布方法,如果在其他授权已经被发布之后向帐户和/或装置110发布客户授权,则冗余或不允许的授权可以被撤销。
在图1的示出的实施方式中,客户帐户和/或装置110可以发布(创建)代客授权,但是可以仅查看和撤销(移除)关于给定SCM 120向客户帐户和/或装置110发布的授权。可以向客户帐户和/或装置110发布具有有限访问属性的一个或更多个授权。例如,可以向客户帐户和/或装置110发布具有有限有效日期的授权。
客户帐户和/或装置110可以不发布具有比客户帐户和/或装置110的授权更广泛的访问属性的授权。为了提供示例,客户帐户和/或装置110可以不发布具有在与提供给客户帐户和/或装置110的客户授权类型相关联的有效日期之外的有效日期的授权。
当客户帐户和/或装置110的授权访问属性被修改成进一步受到限制时,由客户帐户和/或装置110发布的授权可以相应地被修改成保持可允许或者可以被撤销。当帐户和/或装置110的客户授权被撤销时,源自客户授权的所有授权也可以被撤销。
在可替选实施方式中,客户帐户和/或装置110可以不撤销其自己的客户授权。关于SCM 120的客户帐户和/或装置110可以不关于同一SCM 120向自身(即,向同一帐户和/或装置110)发布授权。
在可替选实施方式中,对于给定SCM 120,听凭发布帐户和/或装置110处理,从发布帐户和/或装置110(例如,所有者帐户和/或装置110)发布授权的客户帐户和/或装置110可以查看发布给从发布帐户和/或装置110——包括或排除发布帐户和/或装置110——发布授权的其他帐户和/或装置110的授权。在可替选实施方式中,当帐户和/或装置110的客户授权被撤销时,源自帐户和/或装置110的客户授权的所有授权可以被移动到关于SCM120的另一所有者帐户和/或装置110、客户管理员帐户和/或装置110或者客户帐户和/或装置110。在一个实施方式中,客户帐户和/或装置110可以提交授权修改请求,用于由发布帐户和/或装置110批准。
在示出的实施方式中,在客户授权被创建之后,客户授权可能无法被改变为另一授权类型。在可替选实施方式中,客户授权可以被改变为任何其他授权类型,可能导致从客户授权发布的将不再被允许的一个或更多个授权。这样的一个或更多个授权可以自动或手动地被移动到具有可适用的授权的可替选帐户和/或装置110,或者被撤销。
D.代客
代客授权类型可以被认为是用于在给定SCM 120上具有有限授权的帐户和/或装置110的专用授权类型。具有代客授权的装置110可以被称为代客装置。具有代客授权类型的用户帐户可以被称为代客帐户。每个帐户和/或装置110可以具有关于给定SCM 120的零个或更多个代客授权;然而,SCM 120可以具有多个代客帐户和/或装置110。关于给定SCM120的代客帐户和/或装置110可以不具有关于同一SCM 120的有效所有者授权、客户管理员授权或客户授权。诸如根据在本文中至少在章节VIII处描述的授权发布方法,如果在其他授权已经被发布之后向帐户和/或装置110发布代客授权,则冗余或不允许的授权可以被撤销。
代客帐户和/或装置110可以仅查看关于给定SCM 120向代客帐户和/或装置110发布的授权。可以向代客帐户和/或装置110发布具有有限访问属性的授权——例如,可以向代客帐户和/或装置110发布具有有限有效日期的授权。
在可替选实施方式中,可以不存在代客授权。在另一可替选实施方式中,可以针对给定SCM 120向帐户和/或装置110提供有限数量的代客授权。该数量可以是固定数量(例如,一个)。在又一可替选实施方式中,代客授权可以被转移到属于与代客帐户和/或装置110相同的实体(例如,代客服务组织)或和与代客帐户和/或装置110相同的实体(例如,代客服务组织)相关联的另一帐户和/或装置110。
在一个实施方式中,当一些事件发生(例如,非代客帐户和/或装置110已经连接至SCM 120或者设备组件140指示SCM 120已经行进超过某个合理的阈值)时,代客授权可以被自动撤销。
在示出的实施方式中,在代客授权被创建之后,代客授权可能无法被改变为另一授权类型。可替选地,代客授权可以被改变为任何其他授权类型,可能导致从代客授权发布的将不再被允许的一个或更多个授权。这样的授权可以自动或手动地被移动到具有可适用的授权的可替选帐户和/或装置110,或者被撤销。
E.组织
在一个实施方式中,可以为组织授权类型提供关于帐户和/或装置110的集合向一个或更多个其他帐户和/或装置110授予关于一个或更多个SCM 120的与组织相关联的所有者授权的能力。
F.转移
在一个实施方式中,如本文所述,可以在SCM 120所有权转移过程期间使用转移授权类型。这种授权类型是暂时的;它用于用信号通知期望这样的转移,使得可以执行适当的批准和撤销,并且一旦批准,所有者授权类型就可以应用于目标帐户(及其装置110)。
G.其他,可能的动态类型
在一个实施方式中,可用于系统100的授权类型可以是动态的。授权类型的集合可以在运行时间处、经由运行时间之前的配置或以编程方式变化。例如,可以经由ACP 400为帐户和/或装置110以及SCM 120引入先前未在系统100中使用的新类型的授权类型。
H.授权树
根据本文描述的一个或更多个实施方式,特别是关于一个或更多个授权类型,应当理解,可以根据授予第一和第二帐户和/或装置110的权利从第一帐户和/或装置110向第二帐户和/或装置110等授予授权类型和相关联的访问权利。以这种方式,可以生成授权树,该授权树可以由于新授权被授予并且旧授权被撤销或被修改而随时间动态地变化。在图6和图7的示出的实施方式中示出了两种类型的这样的树的示例。
在图6和图7的示出的实施方式中,在系统100中存在多个SCM 120,每个SCM 120与一个或更多个所有者帐户和/或装置110相关联。一个或更多个所有者帐户和/或装置110已经直接或间接地为客户管理员帐户和/或装置110、客户帐户和/或装置110以及代客帐户和/或装置110提供授权。
VIII.授权发布顺序
在图1的示出的实施方式中,用户10可以向用户帐户(并且然后,经由用户帐户服务向装置110)和/或装置110发布关于SCM 120的各种类型的授权,修改和撤销关于SCM 120的各种类型的授权。安全模型可以利用多个系统组件的参与来发布授权,包括用户10(以接受授权发布请求和作为结果的ACP 400这两者)。授权修改和撤销可能不总是需要用户参与。
根据一个实施方式的发布一个或更多个授权的方法在图8中描绘并且通常被指定为800。方法800包括各种步骤,包括:步骤801)具有发布授权的权利的用户10使用装置110(具有权利)向关于特定SCM 120的接收用户的帐户和/或装置110发送授权发布请求;步骤802)接收用户使用他们的装置110(例如,与他们的用户帐户相关联的任何装置110、特定装置110)接受授权发布请求;以及步骤803)关于SCM 120的所有者装置110接受由发布的授权产生的对ACP 400的改变。
除了以上之外,如本文描述的,可以在以上一个或更多个步骤中添加双因素认证(2FA)作为系统级要求;然而,2FA消息没有在以上序列图上示出以便于理解。应当注意,可以使用与可适用的用户帐户相关联的装置110中的任意装置来完成双因素认证请求。
在一个实施方式中,为第一用户10提供通信路径以将授权发布请求发送到不具有现有用户帐户和/或原始设备制造商(OEM)云帐户的第二用户10。通信路径可以至少部分地基于电子邮件和/或SMS通信。递送到第二用户10的消息可以请求第二用户10获得用于第二用户10的装置110的应用(如果有的话)或者访问网站,以创建用户帐户和/或OEM帐户并且然后接受请求。
如本文结合一个或更多个实施方式描述的,所有权转移请求可以被认为是典型授权发布过程的特殊情况。原因在于所有权转移请求导致关于给定SCM 120的所有者授权的发布以及所有其他授权的撤销。在图8的示出的实施方式中,可能需要新的和先前的所有者这两者批准所有权转移请求;然而,由于所有权转移请求的性质,可以直到在转移请求被批准之后才修改候选ACP。
在至少在步骤803处描绘的示出的实施方式中,所有者帐户和/或装置110(以及通过代理,其用户10)可以批准由任何用户10针对SCM 120发起的对ACP 400的改变。如果所有者帐户和/或装置110发布非所有者授权(例如,客户),则可以不需要发布用户10参与关于ACP 400的批准过程。即使不需要用户10的参与(例如,不需要2FA或不需要批准按钮按压),所有者装置110仍然可以参与(例如,通过在没有用户干预的情况下在后台执行操作)。
可以存在可能期望不需要用户参与的其他授权和/或授权操作——本文描述的授权和/或授权操作中的任意可以以这种方式被调整成不需要用户参与。期望通过不需要用户10参与他们发起的事物的批准来改善用户体验。即使他们发起了改变,如果用户10具有与他们的用户帐户相关联的多个装置110,则可以期望需要来自用户的装置110中的另一个的批准。在可替选实施方式中,对ACP 400的改变的范围可以被限制成使得a)可能需要用户10参与关于SCM 120的批准,或者b)可能仅在新的所有者授权被发布时才需要用户10参与关于SCM 120的批准过程。当新的所有者授权被发布时,可能需要用户参与。如果不需要用户参与,诸如在没有启用2FA或没有启用批准按钮按压的情况下,所有者装置110仍然可以参与(例如,通过在没有用户干预的情况下在后台执行操作)。
在可替选实施方式中,可以委托对ACP 400的改变。如本文所讨论的,所有者帐户和/或装置110可以被配置成批准用于SCM 120的ACP 400。所有者帐户和/或装置110还可以将ACP 400的批准授权委托给试图发布授权的另一帐户和/或装置110。批准授权可以限于对所有者帐户和/或装置110可用的授权类型的子集,或者可以包括可用的授权类型中的所有授权类型。例如,如果所有者C已经向客户A授予客户授权以及委托客户授权的授权,则客户A可以在不涉及所有者C的情况下向客户B发布客户授权。在另一示例中,如果不存在对ACP 400的其他改变,则可以委托批准授权。否则,发布链中的所有者帐户和/或装置110或非所有者发布帐户和/或装置110可以批准对ACP 400的改变。
在确定诸如装置110的系统组件已经被破解的情况下,系统组件(或被检测到异常的系统组件)可以警告云130。破解装置110或其他组件可以被限定为使其操作系统或其基础设施软件(例如,标准库或应用)受到损害的组件。云130可以认为破解装置110被盗并且目的在于恶意使用,因此撤销向破解装置110发布的任何授权或由破解装置110发布的任何授权。在一个实施方式中,云130可以撤销向与破解装置110相关联的用户帐户发布的授权或由与破解装置110相关联的用户帐户发布的授权。
图8的示出的实施方式包括如本文强调的若干步骤,包括发送授权发布请求、接受授权发布请求以及接受由发布的授权产生的对ACP 400的改变。步骤801、802、803。示出的实施方式强调这些步骤中的一个或更多个可以涉及一个或更多个附加步骤。
例如,涉及发送授权发布请求的步骤801可以由当前被分类为所有者的用户A和因此是所有者装置110的用户A的装置A限定。用户B和她的被标记为装置B的装置110可以是发布授权的目标。用户A可以请求用户B的用户名,用户B可以响应于该用户名(例如,“B”)。步骤821、822。用户A可以指示她的装置A向用户B发布客户授权。装置110将请求发送到云130。步骤823。云130验证用户A的装置110被授权成发布关于给定SCM 120的授权。步骤824。在一个实施方式中,授权应用于用户B的装置110中的所有装置110。在另一实施方式中,如果用户B具有多个装置110,则用户A可以选择将向用户B的装置110中的哪个发送授权。步骤825。云130请求用户B的装置110中的一个接受或拒绝授权。步骤826。如果用户B接受授权,则用户B的装置110生成装置-SCM-密钥密钥并且将相关部分(例如,公开密钥)发送到云130,云130使用所述相关部分来更新候选ACP。步骤827。更新的候选ACP的存在被传送给用户A(经由其装置110)并且用户A接受候选ACP改变。由用户A用来批准改变的装置110签名批准的候选ACP并且将其发送到云130。步骤828。在一个实施方式中,如果改变是所有权转移,即使始发者是所有者装置,该批准的步骤仍然可以被认为是要求。
云130验证签名的候选ACP并且生成最终的ACP 400并且向所有可适用的装置110通知其存在。步骤829。装置110获得更新的ACP 400(例如,经由ACP容器410、ACP容器集合414或其他装置)。步骤830。用户B的装置110将更新的ACP 400(例如,经由ACP容器410或任何其他装置)发送到SCM 120。步骤831。
IX.用户帐户模型和装置注册
在一个实施方式中,系统100可以利用用户熟悉的经由帐户模型如基于用户名和密码的帐户模型的访问服务。另外地或可替选地,系统100可以基于装置110的身份来利用基于密钥的标识系统(即,加密身份)。基于密钥的标识(即,加密身份)可以向用户提供一定程度的匿名并且便于根据区块链分类账跟踪对ACP 400的改变或交易。类似于并且至少部分地基于使用作为非对称加密/加密身份的一部分的匿名公开密钥来标识和认证用户的加密货币系统以及跟踪交易的区块链分类账,系统100可以利用装置身份作为授权发布序列中的密钥。装置身份可以基于装置的一个或更多个特性而是动态的或固定的,并且可能避免通过帐户和密码标识、跟踪和认证用户10。系统100可以基本上将装置110的物理性等同于机械钥匙的物理性并且将装置110的身份作为关于用户10的代理。
系统100中利用的装置身份可以被限定成从各种系统组件有意地省略尽可能多的用户和设备标识信息,以保护用户10和设备140的身份以及基本上防止在存在安全漏洞的情况下黑客获得这样的信息。然而,为了便于用户10聚集装置110的商业和用户体验,当装置110被注册时,云130可以为每个装置110提供云用户标识符(云用户ID)(用户帐户服务)。
对于与同一OEM用户标识符(OEM-ID)相关联的每个装置,云用户ID可以相同。因此,可以确定与特定云用户ID相关联的装置110的集合。云130的用户帐户服务可以使用安全数据库方法来抽象地将OEM用户帐户(经由OEM用户标识符)链接到云用户ID,其中,存储和执行该映射的云130的服务(用户帐户服务)可以与云130和OEM云的其他服务隔离或分离,允许用户可识别信息保留在外部OEM云中。除非黑客潜入三个单独的系统组件(其中的至少两个位于单独的管理基础设施、域或控制范围内)以将个人可识别信息(PII)拼凑在一起——诸如将用户10映射到OEM用户帐户,再映射到装置110,再映射到SCM 120或设备140——否则这种方法可以防止黑客的未授权访问。
在可替选实施方式中,云130可以不使用安全数据库方法,但是仍然可以提供与云130的其他服务集成的单独的用户帐户服务。例如,用户帐户服务可能在同一基础设施、网络上或经由虚拟专用网络运行。在可替选实施方式中,云130可以不将OEM帐户信息与其他用户信息分离。为了提供示例,云130可以不使用安全数据库方法,并且OEM用户标识符和云用户ID可以不存在或者可以不是抽象的。
在示出的实施方式中,云130可以不保持可以是个人可识别的帐户信息。因此,云130可能不具有用户帐户的常规概念,并且可能缺乏实现直接访问的非OEM云登录API。装置110可以使用OEM云来注册并与OEM用户帐户相关联,OEM云又可以与云130进行交互。
根据一个实施方式的注册装置的方法在图9的示出的实施方式中描述,并且通常被指定为900。装置110与OEM云安全地连接(例如,经由TLS)。步骤901。装置110使用来自用户10的输入向OEM云发送用户的用户名和密码。步骤902。如果用户名和密码被验证(即,正确),则OEM云向装置110提供云用户ID、OEM标识符、必要的令牌(例如,会话令牌和/或云令牌)以及成功注册装置所必需的任何其他数据。OEM云可以与云130的其他部分进行交互。步骤903。装置110向OEM云发送注册请求,即会话令牌(其可以映射到特定的云用户ID和OEM-ID,允许装置110不单独地发送它们——或者单独地要求它们作为附加验证)、任何其他必要的令牌(诸如推送通知服务令牌)、装置权利公开密钥(如果使用装置权利服务,如本文描述的区块扇系统)以及装置特定签名(例如,从装置操作系统软件获得的)。步骤904。在一个实施方式中,为了基本上避免或防止恶意装置多次注册同一装置,可以在注册过程中利用装置特定签名(例如,标识符或供应商应用标识符)。
在方法900中,OEM云可以验证注册请求。步骤905。如果注册请求是成功的,则OEM云向注册装置110提供装置ID。步骤906。
为了帮助防止同一装置110的意外重复注册,提供装置特定签名作为装置注册请求的一部分。装置签名可能不是加密意义上的签名,也不需要是真正的装置特定的(例如,它可以是应用安装特定的)。而是,装置签名可以是可以用于尝试唯一地标识特定装置的标识符(例如,序列号或应用实例号,诸如随机生成的数字或由操作系统提供的数字)。装置注册过程——当成功时——可以将生成的装置ID提供给装置110,以用于诸如发布授权的稍后操作。
在可替选实施方式中,可以不利用OEM云。云130可以允许装置110用随机生成的(可能是唯一的)云用户ID来注册。在这种情况下,云用户ID可以包括特定的全局定义或可配置的OEM标识符——并且装置110可以负责保持或提供装置聚集信息以及用于获得信息以执行期望的交叉装置操作的所有设施。
在许多情况下,OEM为其设备组件140提供用户界面,诸如但不限于品牌网站和移动应用。因此,OEM可以管理递送设备组件140所必需的相应系统组件,其可以包括由OEM云提供的OEM品牌用户帐户和装置关联服务。
通过应用程序接口(API)的集合,使用合适的隐私和信任(加密、认证和授权),OEM云能够从云130获得与特定用户相关联的装置110,管理授权,并且执行可能在OEM的设备组件140的整个寿命期间必需的任何装置所有权调整。隐私和信任可以以各种方式来建立,包括经由使用X.509证书的TLS 1.2+相互认证和OAuth2或可替选/自定义质询/响应机制(OEM云)。用于OEM云、用户10与云130之间的交互的OAuth2质询/响应流程或方法1000的示例在图10的示出的实施方式中示出。
在示出的实施方式中,用户10可以从可以与本文描述的云130类似地被配置的OEM云135获得用户帐户。步骤1002。然后,用户10可以登录到OEM云135以获得临时OEM云标识符和/或云令牌(例如,用于OAuth2认证操作)。步骤1004。用户10可以从云130请求云用户ID,向云130提供先前从OEM云135获得的临时OEM云标识符和/或云令牌。步骤1006。云130可以与OEM云135一起验证由用户10提供的云令牌和/或临时OEM云标识符。步骤1008。如果云令牌和/或临时OEM云标识符被验证,则云130可以向用户10发送云用户ID,可能伴随有OEM云标识符(OEM用户标识符)(其可以是临时OEM云标识符,但已清除其临时状态);上面使用的临时OEM云标识符可以仅用作进一步验证OEM云135和云130是指同一用户的手段。临时OEM云标识符可以用于其他目的,诸如指示连接至哪个服务器或者指示允许OEM云135使用与云130不同的OEM云标识符(云用户ID)。
在可替选实施方式中,可以经由使用X.509证书的TLS 1.2+服务器侧(云)认证和与OEM云135建立的OAuth2或可替选或自定义质询和响应机制来建立隐私和信任。在另一可替选实施方式中,可以使用TLS 1.2+、或具有OAuth2或可替选或自定义质询和响应机制的自定义或可替选加密和认证协议来建立隐私和信任。
如本文描述的,在一个实施方式中,云130可以不提供允许用户创建帐户并且然后使用网络或移动应用将其装置110与帐户相关联的用户帐户服务。而是,OEM云可以提供这些服务。为了由OEM云使用,用户帐户服务提供识别与OEM用户帐户相关联的装置110的能力(经由OEM用户标识符)——云130的用户帐户服务可以提供匿名的用户帐户。在一个实施方式中,云130可以提供可以由OEM云、其他OEM服务、应用以及诸如用户10、装置110、SCM 120、设备140和云130本身等的系统组件使用的常规用户帐户管理和装置110关联服务(例如,经由用户帐户管理服务)。该实施方式可以或可以不使用本文描述的安全数据库方法,并且可以或可以不暴露云生成的OEM用户标识符(或OEM云标识符),以由OEM在它们的系统中使用。由云130的用户帐户管理服务提供的用户帐户管理和装置关联服务可以包括(但不限于)以下:
1)用双因素认证和电子邮件验证创建并激活用户帐户(通过名称、电子邮件、电话号码和密码)
2)向用户帐户添加装置或从用户帐户移除装置或者向用户帐户添加装置和从用户帐户移除装置这两者
3)查看与用户帐户相关联的装置以及与装置相关联的授权
在一个实施方式中,可以在与用户10的用户帐户相关联的所有装置110之间共享授权。授权改变可以由与用户帐户相关联的任何装置110批准,用户账户与SCM 120的所有者装置110相关联。用户10可能能够或可能不能够配置如何在他们的装置110之间共享授权。例如,用户10可能能够或可能不能够配置哪些装置110接收关于哪个SCM 120的授权。用户帐户服务可以确保每个任意配置的偏好和系统规则代表用户执行这些操作。
X.货币化
在一个实施方式中,系统100可以被配置成要求用户10对由系统100执行的某些操作进行支付。这样,系统100可以使由系统100提供的方面或功能货币化。维护用于系统组件操作并安全地通信的技术和基础设施可能是艰巨且昂贵的过程。另外,用户10可能期望技术进步、改进、与市场上提供的新产品和技术的兼容性以及安全补丁或增强,这些中的所有都可能需要资金。本文描述的许多系统操作在计算上是昂贵的,但是用户10没有直接或实际参与。存在确实涉及用户10的许多计算上昂贵的系统操作(即,服务),诸如发布、修改或撤销授权、装置注册、转移SCM 120的所有权或对SCM 120进行恢复出厂设置、更新固件等。对服务的支付可以由用户10、OEM或其他实体汇出。关于本文描述的安全模型/系统的操作,可以使以下动作货币化:发布授权;注册装置110;转移SCM 120的所有权;对SCM 120恢复出厂设置;以及更新固件。应当理解,货币化不限于这些事件,并且其他事件或情况可以形成货币化的基础。
A.发布授权
可以针对由其用户10成功发布的每个授权向OEM收费,其中,针对在诸如每天、每周或每月的预定时间间隔期间产生的聚集收费生成发票。可替选地,可以针对成功发布的每个授权对OEM进行实时收费。该实时收费模型可以导致微支付(micro-payment)。
可以针对由用户10成功发布的每个授权向用户10收费,其中,可以针对在诸如每天、每周或每月的预定时间间隔期间产生的聚集收费生成发票。可替选地,可以针对由用户10成功发布的每个授权对用户10进行实时收费,以产生基于微支付的货币化。利用该实施方式,支付可以由用户10授权,指示用户10同意被收费。可以在授权请求被发送时获得同意,并且可以在接收者接受授权时或者在对ACP 400的作为结果的改变被批准时向用户收费。同意的证明可以作为请求的一部分而被提供,如果不存在支付授权的证明,则可以拒绝该请求。
在可替选实施方式中,如果授予授权的序列不成功,则可以向用户10立即收费并且交易被取消/退款。
在一个实施方式中,可以针对云130成功发布给用户10的每个授权向用户10收费,其中,可以针对在诸如每天、每周或每月的预定时间间隔期间产生的聚集收费生成发票。在一个实施方式中,可以针对由用户10成功接收或订购的每个授权对用户10进行实时收费,以产生基于微支付的货币化系统。利用该实施方式,支付可以由用户10授权,指示用户同意被收费。同意可以与接收的授权请求一起获得。同意的证明可以作为请求接受响应的一部分而被提供,如果不存在支付授权的证明,则可以拒绝该请求接受响应。可以在请求接受响应被云130接收时或者在对ACP 400的作为结果的改变被批准时向用户10收费。在可替选实施方式中,如果序列不成功,则可以立即向用户收费并且交易被取消或退款。
B.注册装置
可以针对由其用户10成功注册的每个装置向OEM收费,其中,可以针对在诸如每天、每周或每月的预定时间间隔期间产生的聚集收费生成发票。在一个实施方式中,可以针对成功注册的每个装置10对OEM进行实时收费,产生微支付类型的系统。
在一个实施方式中,可以针对由用户10成功注册的每个装置10向用户10收费,其中,可以针对在诸如每天、每周或每月的预定时间间隔期间产生的聚集收费生成发票。在一个实施方式中,可以针对用户成功注册的每个装置10对用户10进行实时收费,产生微支付类型的系统。利用这种布置,支付可以由用户授权,指示用户同意被收费。同意可以与发送装置注册请求一起获得,并且同意的证明可以作为请求的一部分而被提供。如果不存在支付授权的证明,则可以拒绝请求,并且可以在成功处理装置注册时向用户收费。在可替选实施方式中,如果装置注册序列不成功,则可以立即向用户10收费并且交易被取消或退款。
C.转移SCM的所有权
在一个实施方式中,可以针对由OEM的用户10对SCM 120的所有权的每次成功转移向OEM收费。可以针对在预定时间间隔(例如,每天、每周、每月等)期间产生的聚集收费生成发票。可以针对SCM所有权的每次成功转移对OEM进行实时收费,产生基于微支付的货币化系统。
在一个实施方式中,可以针对SCM 120的所有权的每次成功转移向用户10收费。可以针对在诸如每天、每周或每月的预定时间间隔期间产生的聚集收费生成发票。在一个实施方式中,可以针对SCM 120的所有权的每次成功转移对用户10进行实时收费,产生基于微支付的货币化系统。利用这种布置,支付可以由用户授权,指示用户同意被收费。同意可以与发送的装置注册请求一起获得,并且同意的证明可以作为请求的一部分而被提供。如果不存在支付授权的证明,则可以拒绝请求,并且可以在装置注册被成功处理时向用户收费。在可替选实施方式中,如果装置注册序列不成功,则可以立即向用户10收费并且交易被取消或退款。
D.对SCM进行恢复出厂设置
可以针对由与OEM相关联的用户对SCM 120的每次成功的恢复出厂设置向OEM收费。可以针对在诸如每天、每周或每月的预定时间间隔期间产生的聚集收费生成发票。在一个实施方式中,可以针对每次成功的SCM恢复出厂设置对OEM进行实时收费,产生基于微支付的货币化系统。
在一个实施方式中,可以针对SCM 120的每次成功的恢复出厂设置向用户10收费,其中,可以针对在诸如每天、每周或每月的预定时间间隔期间产生的聚集收费生成发票。在一个实施方式中,可以针对SCM 120的每次成功的恢复出厂设置对用户10进行实时收费,产生基于微支付的货币化系统。利用该实施方式,支付可以由用户10授权,指示用户10同意被收费。可以在新的所有者发起请求被发送时获得同意,并且同意的证明可以作为请求的一部分而被提供。如果不存在支付授权的证明,则可以拒绝请求。当云130生成作为结果的ACP400时,可以向用户10收费。在可替选实施方式中,如果序列不成功,则可以立即向用户10收费并且交易被取消或退款。
E.固件更新
可以针对由它们的用户10进行的每次成功的固件更新向OEM收费,其中,可以针对在诸如每天、每周或每月的预定时间间隔期间产生的聚集收费生成发票。在一个实施方式中,可以针对每个成功的固件更新对OEM进行实时收费,可能产生基于微支付的货币化系统。
可以针对每个成功的固件更新向用户10收费,其中,针对在诸如每天、每周或每月的预定时间间隔期间产生的聚集收费生成发票。在一个实施方式中,可以针对每个成功的固件更新对用户10进行实时收费(例如,微支付)。利用该实施方式,当固件更新被发送或开始时,支付可以由用户10授权(指示用户同意被收费)。授权的证明可以作为请求的一部分而被提供,如果不存在支付授权的证明,则将拒绝该请求。当系统100的组件检测到固件更新成功时,可以向用户10收费。在可替选实施方式中,如果序列不成功,则可以立即向用户10收费并且交易被取消或退款。
XI.分布式信任模型
根据一个实施方式的系统100可以利用分布式信任模型。该分布式信任模型可以使装置110、SCM 120以及设备系统组件140能够在线和/或离线,同时仍然能够建立信任、安全地通信和操作。例如,装置110、SCM 120以及设备系统组件140可以实现系统组件的在线和/或离线认证以及动作的授权。
A.概述
在一个实施方式中,系统100可以并入最小特权原则以增强机密性和隐私,隔离系统组件,以及减少攻击面。可以通过将安全标准与处理唯一地组合来安全且机密地完成系统组件之间的通信和系统组件内的数据存储。标准可以包括加密、认证、完整性验证或安全协议或其组合,并且处理可以涉及协议、工作流程或系统状态管理或验证或其任意组合。
出于公开的目的,如果系统组件能够经由因特网与服务进行通信——包括例如如果系统组件能够与证书颁发机构进行通信——则系统组件在线。
在某种意义上的加密可以仅提供一定程度的机密性。加密的消息或密文可以仅由具有合适密钥的实体查看或解密。密钥可以是共享秘密或密钥,或者密钥可以是由公开密钥和私有密钥限定的非对称对的一部分。
为了验证消息的完整性或者消息尚未被改变,可以在加密消息内存储安全(加密的)散列。为了验证消息的真实性,可以在加密消息内存储始发者标识信息。可以通过在加密消息中(或与加密消息一起)包括对称加密、消息认证代码(MAC)或非对称加密(例如,公开密钥加密)、数字签名来同时验证消息完整性和真实性。
利用非对称加密,数字签名本身可能无法保证作者对消息进行了签名和加密。可以将这样的保证描述为加密不可否认性或作者身份和/或起源的证明。
传统的签名然后加密(S-E)方法被认为易受秘密转发的影响——即,具有始发者的公开密钥的任何人都可以解密,并且然后使用可替选的私有密钥重新签名和重新加密该消息。加密(-E)步骤可以在加密处理中的一个或更多个步骤处发生或者可以不发生。例如,加密步骤可以作为消息包的一部分立即发生,或者消息可以是签名且加密的配置或命令消息。加密步骤可以作为诸如TLS的通信信道传输的一部分而发生。诸如在不需要包的机密性或者由诸如通信信道的一些其他装置提供包的机密性的情况下,可以不存在加密步骤。不需要的机密性的具体示例可以仅是签名的消息。
如果公开密钥与消息一起被分发,则接收方可能不知道作者身份的改变。可能由公开密钥基础设施(PKI)管理的数字证书(X.509)可以提供特定公开密钥是特定作者的密钥并且因此特定数字签名是由特定作者创建的证据。在不存在数字证书的情况下,当使用S-E方法时,可以通过在适当的时候在加密消息中包括作者的身份、目的地的身份或这两者来建立作者身份的证明以及可能的预期目的地的证明。S-E方法可以包括以下两者:a)消息的双重或更多签名,诸如对S-E消息进行签名(S-S-E);以及b)对消息进行双重或更多加密,诸如对加密-然后-签名(E-S)消息进行加密,加密-然后-签名(E-S)消息可以被设计为E-E-S消息。
对称加密可能不会遭遇秘密转发。接收者可以确保作者是已知的并且发送者意在将消息发送给接收者。然而,因为双方拥有共享的秘密,因此对称加密可能不提供加密不可否认性。基于对称加密的系统可以通过一个或更多个层的选定的安全协议、消息打包或存储以及通信方案来考虑和缓解该问题。
在整个系统100中使用在有和/或没有数字证书的情况下使用消息完整性和认证机制的对称和/或非对称加密,以在系统组件之间进行通信并在系统组件内存储数据。本文描述了许多示例。为了基本上克服识别的非对称加密的弱点以及没有明确被识别但安全共同体通常已知的其他已知弱点或考虑因素,在实现非对称加密的任何地方,可以在系统100中使用以下特征中的一个或更多个:
1.数字证书
数字证书(X.509)可以用于验证始终或基本上始终在线的系统组件如云130的身份。系统组件可以实现公共证书颁发机构、私有云证书颁发机构或自签名证书中的一个或更多个。
2.公共证书和密钥
可以用于解密消息的公共证书和/或公开密钥很可能永远不会与消息一起递送。也就是说,在一个实施方式中,接收者必须先前已经从可信源接收公共证书和/或公开密钥并且验证公共证书和/或公开密钥。公开密钥和公共证书可以针对实际或被认为有价值的特定关系,诸如在由装置110和云130限定的对与由装置110和SCM 120限定的对之间,而不是每个云130或每个SCM 120。公开密钥和公共证书可以仅由被利用的系统组件存储。
3.签名
在不使用数字证书的情况下,可以使用签名,如果适当的话,可以将消息内容的功能和安全要求、作者身份和/或接收者身份包括在消息内。消息可以是加密的或未加密的,或者消息可以是双重签名或更多签名的和/或双重加密或更多加密的。
4.作者身份的证明
由于系统100的分布式信任性质,系统100可以被配置成基本上确保特定消息源自特定源。例如,只要作者的身份被保留并且消息可以被认证为源自特定源,消息就可以由任意源递送。消息可以以以下这样的方式来构造和递送:意在用于特定系统组件的消息的内部可能不被其他组件查看,但仍然可以被所有或一些组件验证为由可信组件编写。
可以循环或改变对称和非对称密钥,诸如共享秘密和公开密钥/私有密钥和证书。该循环或改变可以作为漏洞恢复过程的一部分或者经由系统100的正常操作来执行。系统100可以周期性地循环密钥。系统组件和消息定义可以支持这样的动作,提供更新的密钥作为包括在线系统组件、离线系统组件以及在离线与在线之间切换的组件的系统组件或系统通信之间的密钥循环协议的一部分。示例在线系统组件或通信包括云130或云130与装置110之间的配对。示例离线系统组件或通信包括装置110、装置110与SCM 120之间的配对、SCM 120、设备140与SCM 120之间的配对以及设备140。在一个实施方式中,可以在诸如ACP400的消息内容内递送密钥循环指令和一个或更多个密钥。
使用数字证书的系统组件或通信——诸如云130以及云130与装置110之间的通信——可以用适当的证书颁发机构的证书撤销列表(CRL)注册撤销的证书。撤销的证书可以用CRL实时注册。在可替选实施方式中,撤销的证书可以以诸如每小时、每四小时或每天的预定义时间间隔批量注册。在可替选实施方式中,撤销的证书可以不用CRL来注册。
使用数字证书的系统组件或通信——诸如云130以及云130与装置110之间的通信——可以在认证过程期间验证证书没有到期且没有被撤销。可以使用适当的证书颁发机构的CRL来执行验证。在可替选实施方式中,可以不检查证书撤销。在另一可替选实施方式中,可以不检查证书到期。
在再一可替选实施方式中,可以使用在线证书状态协议(OCSP)来代替适当的证书颁发机构的CRL。OCSP响应器可以驻留在证书颁发机构、第三方服务或云130内。
在一个实施方式中,系统组件可以用质询/响应安全协议、包含加密身份的消息、包络公开密钥加密(EPKE)和/或其他手段如过程和/或双因素认证中的一个或更多个利用对称和/或非对称加密来验证身份或作者身份。另外,在有或没有证书的情况下,可以利用多个基于硬件或软件的安全和认证层。为了提供示例,可以存在用于底层通信信道的认证和加密如BLE认证、DTLS、TLS、NFC或RFID或其组合的一个或更多个安全层和认证层。
身份改变和撤销(以及身份验证或认证改变)可以诸如经由ACP 400、恢复出厂设置过程或密钥循环或其组合从所有或一些系统组件向云分发或者从云向所有或一些系统组件分发。
在一个实施方式中,证书可以用于在线系统组件身份验证,而“原始的”非对称加密可以用于可能离线的系统组件。虽然证书可能看起来有用,但证书通常涉及可能不可用于受约束装置的重要资源,诸如具有很少ROM、RAM、处理能力或通信带宽/吞吐量的系统组件。
在示出的实施方式中的系统100中,SCM 120、装置110和设备140可以被认为是受约束装置。虽然一个或两个证书可能是可行的,但是验证每个授权的真实性以及每个连接装置110的身份可能需要的证书的数量可能是不可行的。因此,在这样的系统组件下,可以使用“原始的”非对称和/或对称加密,原因是这种类型的加密可以涉及明显更少的存储器,相应地具有更低的处理开销。较少的存储器使用也可以导致传输信息的通信带宽减少。
在一个实施方式中,与仅生成非对称私有密钥对/公开密钥对相反,装置110可以生成一个或更多个自签名的数字证书以建立装置110的身份。
在可替选实施方式中,可以在利用原始的公开密钥加密的任何地方使用对称加密——例如,基于非证书的使用。
在一个实施方式中,使用P-256(secp256rl)椭圆曲线(ECC)(非对称)和AES-128(对称)加密。一个或更多个可替选实施方式可以利用以下类型的加密中的一种或更多种:P-192(secp121r1)椭圆曲线(非对称)加密(ECC);P-384(secp384rl)椭圆曲线(非对称)加密(ECC);P-521(secp521rl)椭圆曲线(非对称)加密(ECC);RSA(非对称)加密;AES-192(对称)加密;以及AES-256(对称)加密。应当注意,该系统不限于以上加密算法。
B.证书验证
在一个实施方式中,一个或更多个证书可以用来验证关于(在线和离线)系统组件、授权以及其他重要数据项和配置的所有或子集的真实性或作者身份。在可替选实施方式中,证书可以被链接(或签名被链接在证书中),以验证适当的各方已经批准关于在线和离线系统组件两者、授权以及其他重要数据项和配置的消息或委托的认证或授权。
在另一可替选实施方式中,系统组件身份和授权(以及可能的其他类或子类)可以是被表示为证书的单独实体,其中每个类和/或子类(例如,身份和授权)具有不同的证书颁发机构。例如,每个实体可以具有单独的认证和授权树。在一个实施方式中,认证和授权证书颁发机构可以驻留在不同的服务器上。
在可替选实施方式中,每个类可以使用同一证书颁发机构。在另一可替选实施方式中,属性(授权)证书(RFC 5755)可以用于表示授权或其他信息,诸如配置参数或标识符。
XII.分布式密钥系统
存在以以下方式分布在系统100中的系统组件上的许多加密密钥:可以允许每个系统组件彼此认证,并且以数据可以被组件(可能只针对数据被认为是必需的那些组件)访问的方式机密且安全地递送数据。数据可以在线和/或离线地被传送。根据一个实施方式的密钥或标识符的分发在图11A至图11B中描绘,包括多个系统组件以及这些系统组件拥有的加密密钥(以及一些标识符)。另外,图16的示出的实施方式还描绘了具有每个系统组件以及仅这些系统组件拥有的私有/对称加密密钥的系统100。下面更详细地描述根据一个或更多个实施方式的加密密钥中的每个。
A.SCM-密钥和SCM-ID
SCM-密钥密钥可以唯一地标识特定SCM 120。SCM-密钥密钥可以是仅在制造过程期间直接由SCM 120或由制造工具生成和存储的非对称私有密钥对/公开密钥对。SCM-密钥私有密钥可以安全地存储在SCM 120上的安全存储器220或安全元件中,安全元件包括安全硬件模块如安全包体或硬件安全模块(HSM)。
SCM-密钥私有密钥不被发送到其他系统组件。另一方面,SCM-密钥公开密钥可以被安全地发送到利用SCM-密钥公开密钥的系统组件如装置110或云130并由利用SCM-密钥公开密钥的系统组件如装置110或云130存储。SCM-密钥私有密钥可以由SCM 120用来对由SCM 120发送到其他系统组件的消息进行加密和/或签名,并且可以用于解密和/或验证从其他系统组件发送到SCM 120的消息。SCM-密钥公开密钥可以由系统组件用来解密和/或验证源自特定SCM 120的消息,并且可以用于对意在用于特定SCM 120的消息进行加密和/或签名。
在一个实施方式中,与SCM-密钥密钥相比,SCM-ID可以提供不同但相关的目的。可以认为SCM-ID对于特定SCM 120是唯一的;然而,SCM-ID可以不直接参与系统100的安全模型。与SCM-密钥密钥相比,SCM-ID在存储和/或表示方面大小可能相对较小(例如,32位或64位对比256位)。SCM-ID可以通过系统100被传输到其他系统组件并由其他系统组件用来帮助用户10识别SCM 120。因此,SCM-ID可以以安全方式传输和存储。SCM-ID可以存储(高速缓存)在其他系统组件如装置110和云130上,以进一步帮助用户10或其他系统服务识别SCM120。
因为预期SCM-ID不会改变,所以系统组件可以将改变作为安全异常如篡改、欺骗企图或协议违规的指示报告给用户10。可替选地,可以将改变作为产品故障如存储器损坏的指示报告给SCM 120的所有者10。
SCM-ID可以是仅用于标识SCM 120的随机生成的标识符,或者SCM-ID还可以用于其他目的。这样的另一目的的示例是充当通信协议标识符,诸如媒体访问控制(MAC)地址和/或与包括例如蓝牙低功耗/BLE的其他服务共享的全局/通用唯一标识符(GUID/UUID)。SCM-ID的另一示例目的是作为人/机器可读标识符,诸如序列号、制造商部件号(MPN)、通用产品代码(UPC)、国际/欧洲物品号(EAN)、车辆标识号码(VIN)、或者对于特定SCM 120可以是唯一的任何其他标识符。
在可替选实施方式中,SCM-ID对于特定SCM 120可以不是唯一的。非唯一类型的SCM-ID的示例包括国际标准书号(ISBN)、USB装置标识符以及产品模型、类或者类型。
在一个实施方式中,可以不安全地存储SCM-ID。例如,因为SCM-ID仅用于日志记录或报告目的或者作为任何系统组件不依赖的附加标识信息,因此可以不使用安全存储。在又一可替选实施方式中,SCM-ID可以不存在。
在一个实施方式中,可以存在与SCM-ID类似的多个标识符,这些标识符中的每个对于特定SCM 120可以是或可以不是唯一的。例如,SCM 120可以包括随机和内部SCM-ID、外部可见序列号、以太网MAC、BLE UUID、包括电子序列号(ESN)的一个或更多个蜂窝标识符、国际移动站设备标识(IMEI)和/或移动设备标识符(MEID)。
在可替选实施方式中,SCM-密钥密钥可以在使用中的所有SCM 120之间共享。
在一个实施方式中,利用SCM-密钥公开密钥的系统组件可能不会安全地发送和/或存储SCM-密钥公开密钥。
在一个实施方式中,SCM-密钥私有密钥不存储在安全存储器220或安全元件或等同的硬件模块中,但仍然被安全地存储。例如,可以在静止时加密SCM-密钥私有密钥,可以实现基于软件的缓解和/或基于硬件的缓解以防止对这样的数据的访问,并且可以实现硬件和/或物理障碍或屏蔽。可以禁用JTAG和其他端口。可以实现硬化的软件接口以消除攻击向量。可以安装可信执行环境、硬件或软件,并且可以实现用于检测操作系统根访问或损害的检测系统。在可替选实施方式中,SCM-密钥私有密钥不被安全存储。
在一个实施方式中,SCM-密钥公开密钥/私有密钥可以由于密钥循环或恢复出厂设置而改变和/或生成。
在一个实施方式中,一个或更多个证书可以被用作SCM-密钥密钥。在可替选实施方式中,SCM-密钥密钥是对称密钥。在另一可替选实施方式中,SCM-密钥密钥是OAuth2令牌。在再一可替选实施方式中,可以使用可替选认证密钥或令牌类型和/或质询/响应机制来代替SCM-密钥密钥。
在可替选实施方式中,可以创建一个或更多个SCM-密钥密钥,并将所述一个或更多个SCM-密钥密钥存储在SCM 120上用于稍后时间使用。如果SCM 120不具有在正常操作期间生成这样的密钥的能力,则该方法可能是有用的。在一个实施方式中,可以利用多个密钥,使得SCM 120可以在恢复出厂设置之后支持密钥循环和/或不同的密钥。在该实施方式中,SCM 120可以管理哪些SCM-密钥密钥可用但不在使用中、在使用中、或者被处置或退出。可替选地,SCM-密钥密钥可以在正常操作期间由云130(或另一系统组件)生成并且存储在SCM 120上,诸如按需(一次一个)或批量(如本文描述的,供稍后时间使用)。
在一个实施方式中,不存在SCM-密钥密钥,在这种情况下,其他装置可以用于系统组件与SCM 120通信以及/或者验证SCM 120的真实性。
B.设备-密钥
可以利用或者可以不利用设备-密钥密钥;设备-密钥密钥意在用于希望生成由SCM 120持有的其自己的密钥以与一个或更多个设备140系统进行通信的设备制造商(OEM);SCM-设备-密钥密钥是反向使用模型(可能是优选)。
对于对它附接的SCM 120,设备-密钥密钥可以唯一地标识特定设备140。设备-密钥密钥可以是仅在设备制造过程期间直接由设备140或由制造工具生成的非对称私有密钥对/公开密钥对。设备-密钥私有密钥可以安全地存储在设备上的安全存储器220中或安全元件或等同的硬件模块如安全包体或硬件安全模块(HSM)中。
在示出的实施方式中,设备-密钥私有密钥没有被发送到其他系统组件;设备-密钥公开密钥可以被安全地发送到利用设备-密钥公开密钥的系统组件如SCM 120并由利用设备-密钥公开密钥的系统组件如SCM 120存储。可以通过制造工具在设备140或SCM 120的制造期间将设备-密钥公开密钥发送到SCM 120(或其他设备)。设备-密钥公开密钥可以由设备140或其他系统组件经由通信链路或物理介质发送到SCM 120(或其他设备)。设备-密钥私有密钥可以由特定设备140用于对设备140发送给其他系统组件的消息进行加密和/或签名,并且可以用于解密和/或验证从其他系统组件发送到设备140的消息。
设备-密钥公开密钥可以由系统组件用于解密和/或验证源自特定设备140的消息,并且可以用于对意在用于特定设备140的消息进行加密和/或签名。
在可替选实施方式中,设备-密钥公开密钥没有被利用该设备-密钥公开密钥的系统组件安全地发送和/或存储。
在一个实施方式中,设备-密钥公开密钥可以在该系统组件尚未具有存储的设备-密钥公开密钥时才被发送到诸如SCM 120的系统组件(或者可以仅被诸如SCM 120的系统组件接受)。这可以在制造或恢复出厂设置后发生。另外地或可替选地,设备-密钥公开密钥可以仅由制造工具发送到另一系统组件。在可替选实施方式中,设备-密钥公开密钥可以不由制造工具发送到另一系统组件。
在可替选实施方式中,设备-密钥密钥可以在使用中的所有设备140之间共享。
在一个实施方式中,在没有由一个或更多个其他系统组件批准的情况下,设备-密钥公开密钥可以不被发送到系统组件以及/或者由系统组件使用。例如,在没有来自装置110、用户10或云130的批准的情况下,SCM 120可以不与特定设备140进行通信。另外地或可替选地,设备140可以不批准它自己。
在一个实施方式中,设备-密钥私有密钥不存储在安全存储器220或安全元件或等同的硬件模块中。然而,设备-密钥私有密钥仍然可以被安全地存储。例如,可以在静止时加密设备-密钥私有密钥,可以实现基于软件的缓解和/或基于硬件的缓解以防止对这样的数据的访问,并且可以实现硬件和/或物理障碍或屏蔽。可以禁用JTAG和其他端口。可以实现硬化的软件接口以消除攻击向量。可以安装可信执行环境、硬件或软件,以及可以实现用于检测操作系统根访问或损害的检测系统。在可替选实施方式中,设备-密钥私有密钥不被安全地存储。
在一个实施方式中,设备-密钥公开密钥/私有密钥可以由于密钥循环或恢复出厂设置而改变和/或生成。
在一个实施方式中,一个或更多个证书可以用于设备-密钥密钥。在可替选实施方式中,设备-密钥密钥是对称密钥。在另一可替选实施方式中,设备-密钥密钥是OAuth2令牌。在再一可替选实施方式中,使用可替选认证密钥或令牌类型和/或质询/响应机制来代替设备-密钥密钥。
在一个实施方式中,包括SCM 120的系统组件可以与多个设备140进行通信,因此,系统组件可以拥有多个不同的设备-密钥公开密钥。
在一个实施方式中,可以不存在设备-密钥密钥,在这种情况下,其他装置可以用于SCM与设备140进行通信以及/或者验证设备140的真实性。
C.SCM-设备-密钥
可以利用或者可以不利用SCM-设备-密钥密钥;SCM-设备-密钥密钥意在用于希望使用由SCM 120提供的外部生成的密钥与一个或更多个设备140系统进行通信的设备制造商;设备-密钥密钥是反向使用模型。
对于它附接的设备140,SCM-设备-密钥密钥可以唯一地标识SCM 120。SCM-设备-密钥密钥可以是可以仅在制造过程期间直接由SCM 120或由制造工具生成和存储的非对称私有密钥对/公开密钥对。
SCM-设备-密钥密钥可以与SCM-密钥密钥分离,以允许设备制造商使用被认为令人满意的任何安全模型,包括设备140可能没有被良好保护的模型,因此,认为优选的甚至不暴露SCM-密钥公开密钥。
SCM-设备-密钥私有密钥可以安全地存储在SCM 120上的安全存储器220中或安全元件或等同的硬件模块如安全包体或硬件安全模块(HSM)中。在图11的示出的实施方式中,SCM-设备-密钥私有密钥不被发送到其他系统组件。此外,在示出的实施方式中,SCM-设备-密钥公开密钥可以经由制造工具、通信链路或物理介质被发送到附接的设备140并且仅存储在附接的设备140中。
SCM-设备-密钥私有密钥可以由SCM 120用于对SCM 120发送给设备140的消息进行加密和/或签名,并且由SCM 12用于解密和验证从设备140发送到SCM 120的消息。SCM-设备-密钥公开密钥可以由设备140用于解密和/或验证源自特定SCM 120的消息,并且由设备140用于对意在用于特定SCM 120的消息进行加密和/或签名。
在一个实施方式中,SCM-设备-密钥公开密钥可以被安全地发送到除附接的设备140之外的系统组件——包括例如装置110、云130或SCM 120或其组合,并且SCM-设备-密钥公开密钥可以由除附接的设备140之外的系统组件——包括例如装置110、云130或SCM 120或其组合——安全地存储。
在一个实施方式中,SCM-设备-密钥公开密钥可以不被安全地发送到系统组件或由系统组件存储。
可以存在附接至特定SCM 120的一个或更多个设备140。这样,系统100可以限定每SCM多设备系统。在每SCM多设备系统中,装置110可以获得状态,向各个设备140发布命令以及/或者从各个设备140接收响应或者其任意组合。
可以根据一个实施方式实现在使用中的SCM的所有或子集中共享的SCM-设备-密钥密钥。
在一个实施方式中,当系统组件已经具有存储的设备-密钥公开密钥时,系统组件(例如,设备140)可以不接受SCM-设备-密钥公开密钥。
在一个实施方式中,在一个或更多个其他系统组件没有批准的情况下,SCM-设备-密钥公开密钥可以不被发送到设备140以及/或者由设备140使用。例如,在没有来自装置110、用户10或云130的批准的情况下,设备140可以不与特定SCM 120进行通信。另外地或可替选地,SCM 120可以不批准它自己。
在一个实施方式中,其中,代替使用SCM-设备-密钥,可以利用SCM-密钥密钥。在这样的情况下,各种标识的SCM-设备-密钥操作也可以应用于SCM-密钥。
在一个实施方式中,SCM-设备-密钥私有密钥不存储在安全存储器220或安全元件或等同的硬件模块中。SCM-设备-密钥私有密钥仍然可以被安全地存储。例如,可以在静止时加密SCM-设备-密钥私有密钥,可以实现基于软件的缓解和/或基于硬件的缓解以防止对这样的数据的访问,并且可以实现硬件和/或物理障碍或屏蔽。可以禁用JTAG和其他端口。可以实现硬化的软件接口以消除攻击向量。可以安装可信执行环境、硬件或软件,并且可以实现用于检测操作系统根访问或损害的检测系统。在可替选实施方式中,SCM-设备-密钥私有密钥不被安全地存储。
在一个实施方式中,SCM-设备-密钥公开密钥不由利用SCM-设备-密钥公开密钥的系统组件安全地存储。
根据本公开内容的一个实施方式,SCM-设备-密钥公开密钥/私有密钥可以由于密钥循环或恢复出厂设置而改变和/或生成。
多个系统组件(例如,设备140)可以与单个SCM 120进行通信,并且其中,可以利用多个SCM-设备-密钥公开密钥对/私有密钥对。
一个或更多个证书可以用于SCM-设备-密钥密钥。可替选地,SCM-设备-密钥密钥可以是对称密钥。在另一可替选实施方式中,SCM-设备-密钥密钥可以是OAuth2令牌。在再一可替选实施方式中,可以使用可替选认证密钥或令牌类型和/或质询/响应机制来代替SCM-设备-密钥密钥。
在可替选实施方式中,可以创建一个或更多个SCM-设备-密钥密钥,并将所述一个或更多个SCM-设备-密钥密钥存储在SCM 120上以供稍后使用。如果SCM 120不具有在正常操作期间生成这样的密钥的能力,则该方法可能是有用的。在一个实施方式中,可以利用多个密钥,使得SCM 120可以在恢复出厂设置之后支持密钥循环和/或不同的密钥。在该实施方式中,SCM 120可以管理哪些SCM-设备-密钥密钥可用但不在使用中、在使用中、或者被处置或退出。可替选地,SCM-设备-密钥密钥可以在正常操作期间由云130(或另一系统组件)生成并且被存储在SCM 120上,诸如按需(一次一个)或批量(如本文描述的,以供稍后使用)。
在一个实施方式中,不存在SCM-设备-密钥密钥,在这种情况下,其他装置可以用于设备与SCM 120进行通信以及/或者验证SCM 120的真实性。
D.装置-SCM-密钥、装置-ID以及装置-SCM-ID
装置-SCM-密钥密钥可以唯一地标识装置110与SCM 120之间的特定配对(装置/SCM对)。在示出的实施方式中的装置-SCM-密钥密钥是由装置110生成和存储的非对称私有密钥对/公开密钥对。当云130请求向装置110发布关于新SCM 120如尚未向装置110发布授权的SCM 120的授权时,可以生成装置-SCM-密钥密钥。当装置110请求变为恢复出厂设置SCM 120的所有者时,诸如在制造期间或者在转移所有权时,也可以生成装置-SCM-密钥密钥。
因为这种方法可以将对每个被破坏的装置-SCM-密钥密钥的暴露限制到单个SCM120,因此基本上唯一的装置-SCM-密钥密钥可以用于每个装置/SCM对。这与暴露于与特定装置110相关联的所有SCM 120——如同假若将单个密钥用于与特定装置110相关联的所有SCM 120(例如,使用装置-密钥)的情况——形成对比。
在一个实施方式中,装置-SCM-密钥私有密钥可以安全地存储在装置110上的安全存储器220或安全元件或等同的硬件模块如安全包体或硬件安全模块(HSM)中。装置-SCM-密钥私有密钥可以不被发送到其他系统组件;另一方面,装置-SCM-密钥公开密钥可以被安全地发送到利用该装置-SCM-密钥公开密钥的系统组件如云130并由利用该装置-SCM-密钥公开密钥的系统组件如云130存储。
装置-SCM-密钥私有密钥可以由装置110用于对用于相关联的SCM 120的消息进行加密和/或签名,并且可以由装置110用于解密和/或验证从相关联的SCM 120发送到装置110的消息。诸如在发布授权的过程期间,或者当所有者装置110对用于相关联的SCM 120的ACP 400进行签名并将签名的ACP 400发送到云130时,该消息可以或可以不直接发送到装置110。装置-SCM-密钥公开密钥可以由SCM 120用于解密和/或验证源自相关联的装置110的消息,并且可以SCM 120用于对来自SCM 120的意在用于相关联的装置110的消息进行加密和/或签名。
与装置-SCM-密钥密钥相比,装置-ID可以用于不同但相关的目的。装置-ID对于特定装置110(而不是对于特定装置/SCM对)可以基本上是唯一的并且可以由云130生成。装置-ID可以不直接参与系统100的安全模型。与装置-SCM-密钥密钥相比,装置-ID在存储和/或表示方面大小可能相对较小(例如,32位或64位对比256位)。装置-ID可以通过系统100被传输到其他系统组件(诸如云130、SCM 120和用户10)并由其他系统组件(诸如云130、SCM120和用户10)用于帮助标识装置110和启用装置特定服务。装置特定服务的示例包括SMS和推送通知。因此,可以努力确保装置-ID被安全地传输和存储。
尽管预期装置-ID不会改变,但一些系统组件能够将改变作为安全异常或产品故障报告给装置所有者10。安全异常可以是篡改、欺骗企图或协议违规的结果。即使它是同一物理装置110,但是给定装置110可以在其整个生命周期中通过许多唯一的装置-ID而循环,因此在应用被移除并被重新安装、存储器被除去记录或应用被升级时,由于存储器损坏会造成产品故障。
装置-ID可以是仅用于装置标识的随机生成的标识符。可替选地,装置-ID可以用于其他目的。这样的另一目的的示例是充当通信协议标识符,诸如媒体访问控制(MAC)地址、与包括例如蓝牙低功耗/BLE的其他服务共享的全局/通用唯一标识符(GUID/UUID)。装置-ID的另一示例目的是作为人/机器可读标识符,诸如序列号、制造商部件号(MPN)、通用产品代码(UPC)、国际/欧洲物品号(EAN)、车辆标识号码(VIN)、用户定义的字符串或者对于特定装置110而言可以唯一的任何其他标识符。
在可替选实施方式中,装置-ID对于特定装置110可以不唯一。非唯一类型的装置-ID的示例包括国际标准书号(ISBN)、USB装置标识符以及产品模型、类或者类型。
在一个实施方式中,装置-ID可能没有被安全地存储。例如,因为装置-ID仅用于日志记录或报告目的或者作为任何系统组件不依赖的附加标识信息,因此可以不利用安全存储。
应当理解,在一个或更多个实施方式中,可以不存在或利用装置-ID。
在可替选实施方式中,装置-ID可以由装置110生成。
在一个实施方式中,可以存在类似于装置-ID的多个标识符,其中,每个标识符对于特定装置110可以是或可以不是唯一的。例如,装置110可以包括随机和内部装置-ID、外部可见序列号、以太网MAC、BLE UUID、包括电子序列号(ESN)的蜂窝标识符、国际移动站设备标识(IMEI)、和/或移动设备标识符(MEID)、装置名称或用户标识符或其任意组合。
装置-SCM-ID可以类似于装置-ID,但是在示出的实施方式中,装置-SCM-ID意在用于与受约束的装置或受约束的带宽接口或者受约束的装置和受约束的带宽接口这两者一起使用。在一个实施方式中,装置-SCM-ID可以对特定装置/SCM对而言基本上唯一,装置-SCM-ID可以由云130生成,并且不直接参与系统100的安全模型。与装置-ID相比,装置-SCM-ID在存储和/或表示方面大小可能相对较小(例如,8位或16位对比32位或64位)。
装置-SCM-ID可以通过系统100被传输到其他系统组件如云130、装置110和SCM120并由其他系统组件如云130、装置110和SCM 120用于帮助在装置110与SCM 120之间建立安全通信信道。在一个实施方式中,装置-SCM-ID可以仅存储在云130中,使得装置-SCM-ID可以在ACP 400和/或ACP容器410中被递送。在一些情况下,装置-SCM-ID可以不被安全地传输或存储。
预期装置-SCM-ID不会改变。因此,一些系统组件能够将改变作为安全异常或产品故障报告给装置所有者10。安全异常可以是篡改、欺骗企图或协议违规的结果。即使它是同一物理装置110,但是给定装置110可以在其整个生命周期中通过许多唯一的装置-SCM-ID而循环,因此在应用被移除并被重新安装、存储器被除去记录或应用被升级时,由于存储器损坏会造成产品故障。
在一个实施方式中,装置-SCM-ID可以是仅用于装置标识的小的随机生成的标识符,并且可能仅在特定SCM 120的背景下是唯一的。可替选地,装置-SCM-ID可以不存在。
在一个实施方式中,装置-SCM-ID可以由装置110生成。在一些情况下,存在类似于装置-SCM-ID的多个标识符,其中,这些标识符中的每个对于特定装置110可以是或可以不是唯一的。例如,装置110可以包括其他小的随机标识符。
在一个实施方式中,代替装置-SCM-密钥密钥,装置-密钥密钥可以仅特定于使用中的特定装置110。在该实施方式中,装置-密钥可以在装置110注册过程期间生成。可替选地,可以在使用中的所有装置110之间共享装置-密钥密钥,而不是装置-SCM-密钥密钥。
在一个实施方式中,装置-SCM-密钥公开密钥可以不被安全地发送到利用装置-SCM-密钥公开密钥的系统组件以及/或者不由利用装置-SCM-密钥公开密钥的系统组件存储。
装置-SCM-密钥私有密钥可以不存储在安全存储器220或安全元件或等同的硬件模块中。然而,装置-SCM-密钥私有密钥仍然可以被安全地存储。例如,可以根据以下中的任何一个或更多个来实现不使用安全存储器220的安全存储:可以在静止时加密装置-SCM-密钥私有密钥,可以实现基于软件的缓解和/或基于硬件的缓解以防止对这样的数据的访问,并且可以实现硬件和/或物理障碍或屏蔽。可以禁用JTAG和其他端口。可以实现硬化的软件接口以消除攻击向量。可以安装可信执行环境、硬件或软件,并且可以实现用于检测操作系统根访问或损害的检测系统。在可替选实施方式中,装置-SCM-密钥私有密钥不被安全地存储。
在一个实施方式中,装置-SCM-密钥公开密钥/私有密钥可以由于密钥循环或恢复出厂设置而改变或生成或者改变和生成这两者。
在一个实施方式中,一个或更多个证书可以用于装置-SCM-密钥密钥。可替选地,装置-SCM-密钥密钥可以是对称密钥。在另一可替选实施方式中,装置-SCM-密钥密钥可以是OAuth2令牌。在再一可替选实施方式中,使用可替选认证密钥或令牌类型和/或质询/响应机制来代替装置-SCM-密钥密钥。
可以创建一个或更多个装置-SCM-密钥密钥,并将所述一个或更多个装置-SCM-密钥密钥存储在装置110上以供稍后使用。如果装置110不具有在正常操作期间生成这样的密钥的能力,则该方法可能是有用的。在一个实施方式中,可以利用多个密钥,使得装置110可以在恢复出厂设置之后支持密钥循环和/或不同的密钥。在该实施方式中,装置110可以管理哪些装置-SCM-密钥密钥可用但不在使用中、在使用中、或者被处置或退出。可替选地,装置-SCM-密钥密钥可以在正常操作期间由云130(或另一系统组件)生成并且被存储在装置110上,诸如按需(一次一个)或批量(如本文描述的,以供稍后使用)。
在一个实施方式中,装置-SCM-密钥密钥可以不存在,在这种情况下,其他装置可以用于系统组件与装置110进行通信以及/或者验证装置110的真实性。
E.用户-SCM-密钥和用户-SCM-ID
在一个实施方式中,用户-SCM-密钥密钥可以唯一地标识用户帐户与SCM 120之间的特定配对(用户帐户/SCM对)。在示出的实施方式中的的用户-SCM-密钥密钥是由云130中的用户帐户服务生成和存储的非对称私有密钥对/公开密钥对。当云130请求向与用户的用户帐户相关联的装置110发布关于新SCM 120如还没有向用户帐户发布授权的SCM 120的授权时,可以生成用户-SCM-密钥密钥。当与用户的用户帐户相关联的装置110请求变为恢复出厂设置SCM 120的所有者时,诸如在制造期间或者在转移所有权时,也可以生成用户-SCM-密钥密钥。用户-SCM-密钥至少由用户帐户服务用于对ACP 400进行签名(并且由SCM120用于解密和验证ACP容器410已经被批准)。
因为这种方法可以将对每个被破坏的用户-SCM-密钥密钥的暴露限制到单个SCM120,因此基本上唯一的用户-SCM-密钥密钥可以用于每个用户帐户/SCM对。这与暴露于与特定用户帐户相关联的所有SCM 120——如同假若将单个密钥用于与特定用户帐户相关联的所有SCM 120(例如,使用用户-密钥)的情况——形成对比。
在一个实施方式中,用户-SCM-密钥私有密钥可以由云130的用户帐户服务安全地存储。用户-SCM-密钥私有密钥可以不被发送到其他系统组件;另一方面,用户-SCM-密钥公开密钥可以被安全地发送到利用用户-SCM-密钥公开密钥的系统组件如SCM 120并由利用用户-SCM-密钥公开密钥的系统组件如SCM 120存储。
用户-SCM-密钥私有密钥可以由用户帐户服务用于对用于相关联的SCM 120的消息进行加密和/或签名,并且可以用于解密和/或验证从相关联的SCM 120发送到用户帐户服务的消息。用户-SCM-密钥公开密钥可以由SCM 120用于解密和/或验证源自用户帐户服务的消息,并且可以用于对来自SCM 120意在用于用户帐户服务的消息进行加密和/或签名。
在一个实施方式中,可以使用用户-SCM-密钥来代替装置-SCM-密钥。在该实施方式中,与用户帐户相关联的所有装置110可以使用同一用户-SCM-密钥(而不是单独的装置-SCM-密钥密钥)。
在一个实施方式中,使用用户-SCM-密钥密钥和装置-SCM-密钥密钥这两者。在该实施方式中,例如,可以使用用户-SCM密钥密钥对ACP 400的ACP外层2进行签名,而使用装置-SCM-密钥密钥对装置110进行单独认证。
在一个实施方式中,代替用户-SCM-密钥密钥,用户-密钥密钥可以仅特定于特定用户帐户。在该实施方式中,用户-密钥可以在用户帐户创建过程期间生成。可替选地,可以在与用户的用户帐户相关联的所有装置110之间共享用户-密钥密钥,而不是用户-SCM-密钥密钥。
在一个实施方式中,用户-SCM-密钥公开密钥可以不被安全地发送到利用用户-SCM-密钥公开密钥的系统组件以及/或者由利用用户-SCM-密钥公开密钥的系统组件存储。
用户-SCM-密钥私有密钥可以不存储在安全存储器220或安全元件或等同的硬件模块中。然而,用户-SCM-密钥私有密钥仍然可以被安全地存储。例如,可以根据以下中的任何一个或更多个来实现不使用安全存储器220的安全存储:可以在静止时加密用户-SCM-密钥私有密钥,可以实现基于软件的缓解和/或基于硬件的缓解以防止对这样的数据的访问,并且可以实现硬件和/或物理障碍或屏蔽。可以禁用JTAG和其他端口。可以实现硬化的软件接口以消除攻击向量。可以安装可信执行环境、硬件或软件,并且可以实现用于检测操作系统根访问或损害的检测系统。在可替选实施方式中,用户-SCM-密钥私有密钥不被安全地存储。
在一个实施方式中,用户-SCM-密钥公开密钥/私有密钥可以由于密钥循环或恢复出厂设置而改变或生成或者改变和生成这两者。
在一个实施方式中,一个或更多个证书可以用于用户-SCM-密钥密钥。可替选地,用户-SCM-密钥密钥可以是对称密钥。在另一可替选实施方式中,用户-SCM-密钥密钥可以是OAuth2令牌。在再一可替选实施方式中,使用可替选认证密钥或令牌类型和/或质询/响应机制来代替用户-SCM-密钥密钥。
在一个实施方式中,可以创建一个或更多个用户-SCM-密钥密钥,并由云130中关于特定SCM 120的用户帐户服务存储(或者关于所有SCM 120,作为全局密钥池)所述一个或更多个用户-SCM-密钥密钥以供稍后使用。该方法可以避免使云130的用户帐户服务在正常操作期间生成这样的密钥。可以利用多个密钥,使得云130的用户帐户服务可以支持密钥循环和/或多个SCM 120。在该实施方式中,云130的用户帐户服务可以管理哪些用户-SCM-密钥密钥可用但不在使用中、在使用中、或者被处置或退出。
在一个实施方式中,用户-SCM-密钥密钥可以不存在,在这种情况下,其他装置可以用于系统组件与用户帐户服务进行通信以及/或者验证用户帐户服务的真实性。
在一个实施方式中,可以使用与装置-SCM-ID类似的用户-SCM-ID。
F.云-SCM-密钥和云-SCM-批准-密钥
云-SCM-密钥密钥可以唯一地标识SCM 120与云130之间的特定配对(或云/SCM对)。在示出的实施方式中的云-SCM-密钥可以是由云130生成和存储的非对称私有密钥对/公开密钥对。当在恢复出厂设置之后为SCM 120建立第一所有者装置110时,诸如在制造期间或者在转移所有权时,可以生成云-SCM-密钥。
基本上唯一的云-SCM-密钥密钥可以用于每个云/SCM对。与和特定云130相关联的所有SCM 120相对比,这种方法可以基本上将对被破坏的云-SCM-密钥密钥的暴露限制到单个SCM 120。这与暴露于与特定云130相关联的所有SCM 120——如同假若将单个密钥用于与特定云130相关联的所有SCM 120(例如,使用云-密钥)的情况——形成对比。
云-SCM-密钥私有密钥可以安全地存储在云130中的安全存储器220上或安全元件或等同的硬件模块如安全包体或硬件安全模块(HSM)中。云-SCM-密钥私有密钥可以不被发送到其他系统组件;云-SCM-密钥公开密钥可以被安全地发送到利用云-SCM-密钥公开密钥的系统组件如云130、装置110或SCM 120并由利用云-SCM-密钥公开密钥的系统组件如云130、装置110或SCM 120存储。云-SCM-密钥私有密钥可以由云130用于对用于相关联的SCM120的消息进行加密和/或签名,并且可以由云130用于解密和/或验证从相关联的SCM 120发送到云130的消息。云-SCM-密钥公开密钥可以由SCM 120用于解密和/或验证源自云130的消息,并且可以由SCM 120用于对来自SCM 120意在用于云130的消息进行加密和/或签名。消息可以或可以不直接被发送到SCM 120。例如,在发布授权的过程期间,可以将签名的ACP 400发送到所有者装置110用于批准。在批准之后,云130可以对经由装置110被递送到SCM 120的完整的ACP容器410(包含先前签名的ACP 400)进行签名。
在一个实施方式中,可以利用多个云-SCM-密钥密钥,诸如用于云130内的不同服务的一个或更多个云-SCM-密钥密钥。例如,如前所述,可以存在用于云授权请求服务的一个云-SCM-密钥密钥和用于云授权批准服务的另一个云-SCM-批准-密钥密钥。
在一个实施方式中,可以存在用于每个云130和/或云服务的云-ID(类似于装置-ID)。
在一个实施方式中,代替云-SCM-密钥密钥,云-密钥密钥可以仅特定于特定云130和/或云服务。在该实施方式中,云-密钥可以在云130供应和/或初始设置期间生成。
在一个实施方式中,云-SCM-密钥公开密钥可以不被安全地发送到利用云-SCM-密钥公开密钥的系统组件以及/或者由利用云-SCM-密钥公开密钥的系统组件存储。
云-SCM-密钥私有密钥可以不存储在安全存储器220或安全元件或等同的硬件模块中。然而,云-SCM-密钥私有密钥仍然可以被安全地存储。例如,可以根据以下中的任何一个或更多个来实现不使用安全存储器220的安全存储:可以在静止时加密云-SCM-密钥私有密钥,可以实现基于软件的缓解和/或基于硬件的缓解以防止对这样的数据的访问,并且可以实现硬件和/或物理障碍或屏蔽。可以禁用JTAG和其他端口。可以实现硬化的软件接口以消除攻击向量。可以安装可信执行环境、硬件或软件,并且可以实现用于检测操作系统根访问或损害的检测系统。在可替选实施方式中,云-SCM-密钥私有密钥不被安全地存储。
在一个实施方式中,云-SCM-密钥公开密钥/私有密钥可以由于密钥循环而改变或生成或者改变和生成这两者。云-SCM-密钥公开密钥/私有密钥可以不由于恢复出厂设置而改变。
在一个实施方式中,一个或更多个证书可以用于云-SCM-密钥密钥。可替选地,云-SCM-密钥密钥可以是对称密钥。在另一可替选实施方式中,云-SCM-密钥密钥是OAuth2令牌。在再一可替选实施方式中,可以使用可替选认证密钥或令牌类型和/或质询/响应机制来代替云-SCM-密钥密钥。
在一个实施方式中,可以创建一个或更多个云-SCM-密钥密钥并将所述一个或更多个云-SCM-密钥密钥存储在关于特定SCM 120(或者关于所有SCM 120,作为全局密钥池)的云130中以供稍后使用。该方法可以避免使云130在正常操作期间生成这样的密钥。可以利用多个密钥,使得云130可以支持密钥循环和/或多个SCM 120。在该实施方式中,云130可以管理哪些云-SCM-密钥密钥可用但不在使用中、在使用中、或者被处置或退出。
在一个实施方式中,云-SCM-密钥密钥可以不存在,在这种情况下,其他装置可以用于系统组件与云130进行通信以及/或者验证云130的真实性。
G.根证书
根证书可以是根据一个实施方式的用于系统100的根证书。根证书可以是为系统100建立信任根的自签名证书。私有根证书可以安全地存储在离线或通常云130或其他系统组件不可访问的服务器上。公开根证书可以被分发给云130以及可以与云130进行通信的每个系统组件如装置110或OEM云135。
在一个实施方式中,根证书可以由证书颁发机构签名。
在一个实施方式中可以存在多个根证书。例如,可以存在用于系统100、云130、云服务、或装置110、以及OEM云135、或其任意组合的不同实例的根证书。多个根证书中的每个可以自签名或由证书颁发机构签名。在一个示例中,系统100可以配置有用于在线验证的一个信任根和用于离线验证的另一信任根。
在一个实施方式中,在一些情况下并非绝对需要离线存储根证书,所以根证书可以存储在在线的服务器上。
根证书的内容和/或创建过程可以随应用而变化。在一个实施方式中,根证书可以是非对称公开密钥对/私有密钥对,或者根证书可以是对称密钥。
H.云-节点-证书
在示出的实施方式中的云-节点-证书是已经由相应系统100的私有根证书签名的证书。因此,每个云-节点-证书可以形成信任链的一部分以验证特定云服务器130的身份。私有的云-节点-证书可以安全地存储在每个云服务器130上。公开的云-节点-证书可以被分发给云130以及可以与云130进行通信的每个系统组件,包括例如装置110和OEM云135。在其他加密密钥中的任意加密密钥被实施为证书而非加密密钥的情况下,那些证书可以由根证书或云-节点-证书或可替选的根信任证书签名。
在一个实施方式中,可以存在多个云-节点-证书层,诸如用于系统100、云130、云服务、装置110、或OEM云135、或其任意组合的不同实例和/或集群的层。每个子(或较低级别)云-节点-证书可以由其父级别或较高级别的私有云-节点-证书签名,从而形成较长的信任链。
云-节点-证书可以以各种方式被签名。例如,在一个实施方式中,云-节点-证书可以自签名,或者云-节点-证书可以由非父证书或非对称私有密钥/公开密钥签名。
在一个实施方式中,云-节点-证书是非对称公开密钥对/私有密钥对。可替选地,云-节点-证书可以是对称密钥。
I.装置-权利-密钥
对于云130的权利管理系统,装置-权利-密钥密钥可以唯一地标识特定装置110。装置-权利-密钥密钥可以是在装置110关于云130首次注册之前的某个时刻由装置110生成和存储的非对称私有密钥对/公开密钥对。装置-权利-密钥私有密钥可以安全地存储在装置110中的安全存储器220中或安全元件或等同的硬件模块如安全包体或硬件安全模块(HSM)中。装置-权利-密钥私有密钥可以不被发送到其他系统组件;另一方面,装置-权利-密钥公开密钥可以被安全地发送到利用装置-权利-密钥公开密钥的系统组件如云130并由利用装置-权利-密钥公开密钥的系统组件如云130存储。
装置-权利-密钥私有密钥可以由装置110用于对装置110发送到云130的权利管理系统的消息进行加密和/或签名,并且可以由装置110用于解密和/或验证从云130的权利管理系统发送到装置的消息。装置-权利-密钥公开密钥可以由云130的权利管理系统用于解密和/或验证源自特定装置110的消息,并且可以由云130的权利管理系统用于对意在用于特定装置110的消息进行加密和/或签名。
在一个实施方式中,装置-权利-密钥密钥对于每个装置110可以基本上不是唯一的。这样的配置的示例包括:装置-权利-密钥密钥对于每个帐户基本上是唯一的,用于帐户内的某些装置110,或者对于所有装置110全局相同或仅特定于云130的特定权利管理系统。装置-权利-密钥密钥对于每个装置基本上不是唯一的另一示例是装置-权利-密钥密钥用于由特定组织拥有的所有装置110。
在一个实施方式中,装置-权利-密钥密钥可以由云130生成并且作为装置110注册过程的一部分被递送到装置110。
在一个实施方式中,装置-权利-ID(类似于装置-ID)可以与每个装置110相关联,以与云130的权利管理系统一起使用。
在一个实施方式中,装置-权利-密钥公开密钥不被安全地发送到利用装置-权利-密钥公开密钥的系统组件以及/或者由利用装置-权利-密钥公开密钥的系统组件存储。
装置-权利-密钥私有密钥可以不存储在安全存储器220或安全元件或等同的硬件模块中。然而,装置-权利-密钥私有密钥仍然可以被安全地存储。例如,可以根据以下中的任何一个或更多个来实现不使用安全存储器220的安全存储:可以在静止时加密装置-权利-密钥私有密钥;可以实现基于软件的缓解和/或基于硬件的缓解以防止对这样的数据的访问;并且可以实现硬件和/或物理障碍或屏蔽。可以禁用JTAG和其他端口。可以实现硬化的软件接口以消除攻击向量。可以安装可信执行环境、硬件或软件,并且可以实现用于检测操作系统根访问或损害的检测系统。在可替选实施方式中,装置-权利-密钥私有密钥不被安全地存储。
在一个实施方式中,装置-权利-密钥公开密钥/私有密钥可以由于密钥循环而改变或生成或者改变和生成这两者。在一个实施方式中,装置-权利-密钥公开密钥/私有密钥可能不会由于恢复出厂设置而改变。
在一个实施方式中,一个或更多个证书可以用于装置-权利-密钥密钥。可替选地,装置-权利-密钥密钥可以是对称密钥。在另一可替选实施方式中,装置-权利-密钥密钥可以是OAuth2令牌。在再一可替选实施方式中,可以使用可替选认证密钥或令牌类型和/或质询/响应机制来代替装置-权利-密钥密钥。
可以创建一个或更多个装置-权利-密钥密钥,并将所述一个或更多个装置-权利-密钥密钥存储在装置110上以供稍后使用。如果装置110不具有在正常操作期间生成这样的密钥的能力,则该方法可能是有用的。在一个实施方式中,可以利用多个密钥,使得装置110可以在恢复出厂设置之后支持密钥循环和/或不同的密钥。在该实施方式中,装置110可以管理哪些装置-权利-密钥密钥可用但不在使用中、在使用中、或者被处置或退出。可替选地,装置-权利-密钥密钥可以在正常操作期间由云130(或另一系统组件)生成并且被存储在装置110上,诸如按需(一次一个)或批量(如本文描述的,以供稍后使用)。
在一个实施方式中,装置-权利-密钥密钥可以不存在,在这种情况下,授权类型或一些其他装置可以用来建立装置权利,或者一些其他装置可以用于装置110与云130的权利管理系统进行通信以及/或者验证云130的权利管理系统的真实性。
J.ACP-版本-密钥
ACP-版本-密钥密钥可以在ACP容器版本包412(包含ACP版本信息的安全包)的背景下使用,并且可以唯一地标识云130与SCM 120之间的特定配对(或云/SCM对)。当在恢复出厂设置之后为SCM 120建立第一所有者装置110时,诸如在制造期间或者在转移所有权时,在示出的实施方式中的ACP-版本-密钥密钥是由云130生成和存储的非对称私有密钥对/公开密钥对。在示出的实施方式中,ACP-版本-密钥公开密钥可以不被提供给装置110。
可能唯一的ACP-版本-密钥密钥可以用于每个云/SCM对。与和特定云130相关联的所有SCM 120相对比,该方法可以基本上将对每个被破坏的ACP-版本-密钥密钥的暴露限制到单个SCM 120。这与暴露于与特定云130相关联的所有SCM 120——如同假若将单个密钥用于与特定云130相关联的所有SCM(例如,使用ACP-密钥)的情况——形成对比。
ACP-版本-密钥私有密钥可以安全地存储在云130中的安全存储器220上、安全元件或等同的硬件模块如安全包体或硬件安全模块(HSM)中。ACP-版本-密钥私有密钥可以不被发送到其他系统组件;另一方面,ACP-版本-密钥公开密钥可以被安全地发送到利用ACP-版本-密钥公开密钥的系统组件如SCM 120并由利用ACP-版本-密钥公开密钥的系统组件如SCM 120存储。ACP-版本-密钥私有密钥可以由云130用于对用于相关联的SCM 120的消息进行加密和/或签名,并且可以由云130用于解密和/或验证从相关联的SCM 120发送到云130的消息。ACP-版本-密钥公开密钥可以由SCM 120用于解密和/或验证源自云的消息,并且可以由SCM 120用于对来自SCM 120意在用于云130的消息进行加密和/或签名。
在一个实施方式中,云-SCM-密钥密钥可以用于ACP-版本-密钥密钥。
在一个实施方式中,可以以与SCM-密钥类似的方式生成和管理ACP-版本-密钥私有密钥。例如,ACP-版本-密钥私有密钥可以驻留在SCM 120上,并且公开密钥可以驻留在云130中。
在可替选实施方式中,可以实现仅特定于特定云130的ACP-密钥密钥,而不是ACP-版本-密钥密钥。
在一个实施方式中,ACP-版本-密钥公开密钥可以不被安全地发送到利用ACP-版本-密钥公开密钥的系统组件以及/或者由利用ACP-版本-密钥公开密钥的系统组件存储。
在一个实施方式中,ACP-版本-密钥私有密钥可以不存储在安全存储器220或安全元件或等同的硬件模块中。然而,ACP-版本-密钥私有密钥仍然可以被安全地存储。例如,可以根据以下中的任何一个或更多个来实现不使用安全存储器220的安全存储:可以在静止时加密ACP-版本-密钥私有密钥;可以实现基于软件的缓解和/或基于硬件的缓解以防止对这样的数据的访问;并且可以实现硬件和/或物理障碍或屏蔽。可以禁用JTAG和其他端口。可以实现硬化的软件接口以消除攻击向量。可以安装可信执行环境、硬件或软件,并且可以实现用于检测操作系统根访问或损害的检测系统。在可替选实施方式中,ACP-版本-密钥私有密钥不被安全地存储。
在一个实施方式中,ACP-版本-密钥公开密钥/私有密钥可以由于密钥循环而改变或生成或改变和生成这两者。
在一个实施方式中,ACP-版本-密钥公开密钥/私有密钥可能不会由于恢复出厂设置而改变。
一个或更多个证书可以用于ACP-版本-密钥密钥。可替选地,ACP-版本-密钥密钥可以是对称密钥。在另一可替选实施方式中,ACP-版本-密钥密钥可以是OAuth2令牌。在再一可替选实施方式中,可以使用可替选认证密钥或令牌类型和/或质询/响应机制来代替ACP-版本-密钥密钥。
在一个实施方式中,可以创建一个或更多个ACP-版本-密钥密钥并将所述一个或更多个ACP-版本-密钥密钥存储在关于特定SCM 120(或者关于所有SCM 120,作为全局密钥池)的云130中以供稍后使用。该方法可以避免使云130在正常操作期间生成这样的密钥。可以利用多个密钥,使得云130可以支持密钥循环和/或多个SCM 120。在该实施方式中,云130可以管理哪些ACP-版本-密钥密钥可用但不在使用中、在使用中、或者被处置或退出。
在一个实施方式中,ACP-版本-密钥密钥可以不存在,在这种情况下,其他装置可以用于系统组件与ACP容器版本包412进行通信以及/或者验证ACP容器版本包412的真实性。在一个实施方式中,系统组件可以不验证ACP容器版本包412中的所有的真实性。
在一个实施方式中,可以存在多个ACP-版本-密钥密钥。例如,一种系统,其中,每个SCM 120可以存储和使用多于一个的ACP 400,照此,可以认为它对于给定SCM使用多个ACP-版本-密钥密钥接收多个ACP容器410和/或多个ACP容器版本包412和/或多个ACP容器集合414是必需的。
K.装置-SCM-会话-密钥
装置-SCM-会话-密钥密钥可以是用于保护在对中的至少一个对已经被认证诸如以类似于TLS主秘密的方式被认证之后在特定装置110与SCM 120之间定义的配对(或装置/SCM对)之间的通信的对称密钥。为了用受约束的系统组件来增强系统性能和响应性,装置-SCM-会话-密钥密钥可以在连接中存活(诸如以类似于TLS会话恢复的方式),并且可以如本文描述的那样被周期性地循环。
装置/SCM对中的装置的装置-SCM-ID可以用于在建立和/或恢复连接时识别和/或选择适当的装置-SCM-会话-密钥密钥。
在一个实施方式中,可以为每个装置/SCM对提供装置-SCM-会话-ID(类似于装置-SCM-ID),用于在建立和/或恢复连接时识别和/或选择适当的装置-SCM-会话-密钥密钥。这可以以类似于TLS会话ID或会话票证的方式来执行。
在一个实施方式中,装置-SCM-会话-密钥密钥是非对称密钥对。可替选地,装置-SCM-会话-密钥密钥可以是OAuth2令牌。在另一可替选实施方式中,可以使用可替选认证密钥或令牌类型和/或质询/响应机制来代替装置-SCM-会话-密钥密钥。
在一个实施方式中,装置-SCM-会话-密钥密钥可以不存在,在这种情况下,其他装置可以用于装置110和SCM 120安全地通信以及/或者装置110和SCM 120可以不安全地通信。
L.会话令牌
与云130和/或OEM云135通信的系统组件(诸如装置110)可以在OEM云登录过程期间获得OEM云会话令牌和/或云会话令牌以用作附加的安全措施。OEM云会话令牌可以伴随所有OEM云135消息以及到由OEM云135管理的其他数据项的任何内部映射。云会话令牌可以伴随所有云130消息,云会话令牌可以映射到特定云-用户-ID和OEM-ID并且可以使得云130能够限制对与特定云-用户-ID和OEM-ID相关联的数据的访问。OEM云135可以使用云-OEM-云会话令牌与云130进行通信。除了云-OEM-云会话令牌可能仅限制对与特定OEM-ID相关联的数据的访问之外,云-OEM-云会话令牌可以与云会话令牌类似。
云130和OEM云135可以周期性地循环会话令牌,使得令牌到期。循环可以在各种情况下发生或响应于事件,诸如,在每次登录时,或者当发生可疑活动或者消息验证失败时。
在一个实施方式中,OEM云会话令牌和云会话令牌可以相同。可替选地,可以不使用OEM云会话令牌。在可替选实施方式中,可以不使用云会话令牌。另外地或可替选地,可以不使用云-OEM-云会话令牌。
M.其他密钥
系统100中可以存在专用于目的和/或瞬态的其他密钥。示例专用目的是在特定消息集内使用的或者在内部用于特定系统组件的密钥。瞬态示例包括在标准安全协议如TLS或DTLS的背景下操作的其他系统组件之间使用的会话密钥。
N.用户
在一个实施方式中,用户10可以在系统中扮演类似于加密密钥的角色。用户10具有以下可能独特的特性/特征,所述特性/特征可以作为加密密钥被并入,用于认证(或双因素或多因素认证)机制,或者与系统100中的系统组件的批准门有关:
1)眼睛和/或面部(例如,视网膜/面部密钥/签名、收到的视觉确认)
2)指纹(例如,指纹密钥/签名、诸如苹果触摸ID的确认)
3)电子邮件访问(例如,表明对电子邮件帐户的访问)
4)SMS访问(例如,表明对SMS消息的访问)
5)推送通知访问(例如,表明对推送通知的访问)
6)屏幕访问或代码输入(例如,表明对装置屏幕的访问)
7)接近(例如,向系统组件接近,诸如基于微位置接近或基于IR检测接近)
8)访问(例如,表明对系统组件的物理访问,诸如按钮按压)
9)接近或访问其他装置(例如,其他用户装置,诸如手表或带子)
XIII.密钥循环
根据一个实施方式,也被称为密钥轮换或密钥更新的密钥循环是如下过程,通过该过程针对现有对象改变密钥而不向用户直接通知该改变或需要用户交互。可以针对对象改变密钥,对象包括例如授权、装置110、SCM 120、云130、设备组件130和OEM云135。
密钥可以周期性地诸如每几小时、每天、每周、每月、每6个月或每年或在检测到漏洞或异常时循环。改变可以自动或手动地发生,诸如通过管理动作或操作动作。
适当地支持密钥循环可以是系统100的密集任务。一个问题在于可能离线的系统组件,其中,密钥改变请求可能在再一密钥改变请求之前不被递送到目标系统组件。例如,背对背密钥循环操作可能导致密钥改变的未递送或延迟递送。依赖于密钥的任何配置改变(例如,ACP 400)还可能由于系统组件离线而导致未递送或延迟递送。对于许多系统组件,这不太可能发生,原因是密钥改变可以被快速地递送;然而,SCM 120可能在几天、几个月或几年内保持未使用,因此错过若干密钥循环事件,之后先前的所有者可能无法使用系统100将SCM 120递送到新的所有者。更具体地,在这种情况下,SCM 120可能无法解密更新的ACP400或更新的ACP容器410,以及/或者SCM 120可能无法认证循环装置110。在这种情况下,对SCM 120进行恢复出厂设置可能是可接受的。在不同的场景中,在超过若干小时的时间段的情况下,发生致使SCM 120无法使用(由所有者或客户)的多个密钥循环事件,从用户体验或可用性视角来看可能是不可接受的。
影响多个密钥的密钥循环事件也是可能的。多个密钥可能在各种情况下受到影响,诸如系统范围的密钥循环、在管理多个SCM 120的装置110中、或者具有多个授权帐户和/或装置110的SCM 120。下面示出了示例序列。
根据一个实施方式的循环密钥的方法在图12中描绘并且通常被指定为1200。云130请求装置110针对给定SCM 120循环其密钥,向装置110提供新的云-SCM-密钥密钥和其他云生成的密钥(例如,用户-SCM-密钥)和/或与云通信所必需的密钥(令牌等)。步骤1201。装置110响应于密钥循环请求而生成新的装置-SCM-密钥密钥并将该新的装置-SCM-密钥密钥发送到云130。步骤1202。
在某一时刻,在云130从与SCM 120相关联的所有装置110接收更新的装置-SCM-密钥(以及所需的任何其他输入密钥)之后,云130向装置110发送更新的ACP 400(“版本2”)以递送到SCM 120(例如,经由ACP容器410)。步骤1203。装置110将包含所有必需的更新的密钥的更新的ACP 400递送到SCM 120。步骤1204。SCM 120向装置110通知ACP 400更新成功。步骤1205。装置110向云130通知SCM 120已经应用了ACP 400的“版本2”。这使得云130能够为每个SCM 120保持适当版本的ACP 400的适当密钥集,使得在SCM 120或装置110(或其他系统组件)错过密钥更新的情况下,可以依次递送先前的更新,或者使用先前的密钥递送最近的更新,以进行恢复。步骤1206。
步骤1207至1211描绘了第二密钥循环事件。在某一时刻,云130循环用于SCM 120的云生成的密钥中的一个并且将更新的ACP 400(“版本3”)递送到装置110以递送到SCM120(例如,经由ACP容器410)。步骤1207和1208。步骤1209至1211类似于步骤1204至1206,导致云130被通知SCM 120已经应用了ACP 400的“版本3”。
为了在SCM 120上循环密钥,“新密钥”和“旧密钥”(先前已知密钥)两者都可以包括在ACP 400中用于目标SCM 120。每当SCM 120接受ACP 400时,收到确认可以在某一时刻经由在线系统组件如装置110被发送回到云130。通过保持跟踪特定SCM 120最后接受哪个ACP版本,云130可以防止为该SCM 120创建包含密钥改变的后续ACP容器410,直到SCM 120已经接受飞行中的ACP 400为止,其中,“旧密钥”字段可以与飞行中(先前的/未接受的)的ACP 400不同。
在可替选实施方式中,无论SCM 120已经接受哪些ACP 400,云130都可以照常发送用于该SCM 120的后续ACP容器410。在该实施方式中,可以将最小-在先-版本添加到ACP容器版本包412、ACP容器410、ACP 400和/或云API响应中。
如果SCM 120已经检测到其当前ACP版本未达到或高于最小-在先-版本(即,SCM120中的当前密钥集有效的最后版本),则SCM 120可以拒绝ACP更新并请求最小-在先-版本。这可能导致较旧的ACP容器410的一系列回溯,然后发送系统组件(例如,装置110)依次发送或执行更新的包。拒绝ACP更新还可以涉及云130为每个SCM 120保持先前最终确定的ACP容器410的副本,或者至少为还没有接收到最新ACP的SCM 120保持其副本。
另外地或可替选地,最小-先前-版本可以仅经由对云API的响应被传送到接收系统组件,接收系统组件然后可以请求适当的ACP容器410。另外地或可替选地,云130可以依次向SCM 120提供仅可行的ACP容器410——即,云可以不进行任何排序。
在一个实施方式中,如果飞行中的ACP 400可能还没有被特定SCM 120接受,则云130可以不发送用于该SCM的后续ACP容器410,直到该SCM已经接受飞行中的ACP 400为止。
在一个实施方式中,如果飞行中的ACP 400可能还没有被特定SCM 120接受,则云130可以将飞行中的密钥改变合并到新的ACP版本中。换言之,云130可以为每个系统组件保持一个或更多个先前密钥,然后基于目标SCM 120的最后已知状态使用适当的密钥。
在示出的实施方式中,因为ACP容器410针对特定SCM 120并且已经由一个或更多个系统组件或服务签名,所以ACP 400内包含的密钥之外的密钥如SCM-密钥和云-SCM-密钥以及包括标识符的其他非密钥属性也可以同时更新。
在没有向帐户发布授权(例如,授权改为被发布给特定装置110)的一个实施方式中,对于仅包含循环的密钥的ACP容器410,可以不要求所有者10批准更新的ACP 400,因此所有者装置110可以不对ACP外层2进行加密和签名。而是,所有者装置标识符可以被设置为指示所有者装置标识符是密钥循环ACP 400的值,然后ACP外层2可以用由另一层(例如,ACP外层1或ACP外层3)使用的密钥来加密。另外地或可替选地,密钥循环ACP 400可以不被加密,在这种情况下,签名和密钥字段可以用于进一步验证。
在可以向帐户发布授权的一个实施方式中,对于仅包含循环的密钥的ACP容器410,可以不要求所有者10批准更新的ACP 400,但是用户帐户服务仍然可以照常对ACP外层2进行加密和签名。
ACP 400可以具有可以被设置成进一步验证包是合法的的密钥循环属性。合法性可以指示ACP外层2的加密或缺少加密是有意的。在验证ACP容器410期间,SCM 120可以验证SCM 120的当前密钥(即,由SCM 120接收的先前ACP 400中标识的密钥)与新ACP中的“旧密钥”匹配。如果任意密钥不匹配,则可以拒绝ACP 400。
在可替选实施方式中,对于密钥循环ACP 400,SCM 120可以验证没有授权已经被更新(除了与授权相关联的密钥之外)。在另一可替选实施方式中,对于密钥循环ACP 400,可以仅更新密钥。
在可替选实施方式中,所有者装置110可以被配置成:在有或没有用户干预的情况下,批准并可能签名密钥改变ACP 400。在这种情况下,所有者装置110可以仅自动签名ACP400。在可替选实施方式中,所有者装置可以被配置成:在用户干预的情况下,批准并可能签名密钥改变ACP 400。可能需要用户10批准ACP 400,就像ACP 400是任何其他授权改变一样。
当循环密钥时,系统组件可以保持零个或更多个先前密钥一段时间,以帮助容纳错过的密钥循环ACP 400。如果较新的密钥失败,则系统组件可以尝试使用先前密钥。系统组件可以保持先前密钥直到确定不再需要这样做的某个时刻为止,诸如直到另一配置在没有新密钥而使用最近的密钥的情况下到达之后为止,或者直到已经经过一段时间为止。
在一个实施方式中,当密钥被循环时,与利用密钥的实体的连接可以被重新建立,或者至少被重新验证。这样的连接的示例包括装置/SCM对、云/装置对和设备/SCM对。尽管如果由于不良实现导致用户体验下降,则密钥循环在某些方面可能是妨害行为,但是密钥循环可以被认为是安全措施,而并不意味着是妨害行为。在一个实施方式中,可能的情况是,密钥被循环以防止漏洞使用被黑客攻击的装置,从而被用于使系统组件如SCM 120断开连接以强制重新连接。在被黑客攻击的装置的情况下,尝试重新连接可能会失败。
在可替选实施方式中,可以类似于可以在ACP容器410内如何递送密钥改变来递送关于SCM 120的密钥改变,但改为在有或没有由云130针对每个SCM 120跟踪的单独的KCP版本的情况下在单独的包如密钥改变包(KCP)内递送关于SCM 120的密钥改变。在使用这样的方法但不使用KCP版本的情况下,可以将KCP版本与ACP版本合并。
在一个实施方式中,SCM不是可以利用密钥循环的唯一系统组件——装置110、云服务器130、设备组件140、OEM云135,并且其他(如果存在)也可以被配置成用于响应于漏洞而更新密钥。
密钥循环请求可以源自云130,因此,每个系统组件可以验证循环密钥的请求是真实的。如本文描述的,每个系统组件可以拥有多个密钥——这些密钥中的零个或更多个可以由该系统组件生成,并且这些密钥中的零个或更多个可以从其他系统组件获得。因为每个系统组件可以生成这些密钥中的至少一个,所以密钥循环操作可以涉及多个系统组件的协作、协调和排序。
SCM 120可以不生成其自己的密钥,因此可以不请求SCM 120循环密钥。在这种情况下,SCM 120是密钥循环过程的接收者。不由SCM 120生成的密钥包括SCM-密钥和SCM-设备-密钥中的至少一个。
如果SCM不生成其自己的密钥,则当密钥不在云130的控制下时,云130可以发布对要循环的特定密钥的请求。例如,云130可以向装置110发布生成用于特定SCM 120的新装置-SCM-密钥的请求。如果被配置,那么更新的密钥(被认证为来自被请求的装置110)可以包括在ACP 400中并且被递送到与特定SCM 120相关联的一个或多个装置110。一个或多个装置110可以将ACP 400递送到SCM 120。
在可替选实施方式中,SCM 120可以生成其自己的密钥,从而可以请求SCM 120循环密钥。在可替选实施方式中,系统组件可以循环特定密钥,或启动密钥循环,并且向云130发布新密钥以用于分发。
在可替选实施方式中,代替经由ACP容器410将更新的密钥递送到SCM 120,可以向SCM 120发布各个密钥循环请求(从云130单独地或批量地获得),并且可以将状态报告给云130。在该实施方式的一种配置中,仅当已经处理了所有请求时,才认为完成了密钥循环操作。
在另一可替选实施方式中,系统100可以不直接支持密钥循环,而是利用系统100中的操作来执行以下中的一个或更多个:移除并重新发布授权;对SCM 120恢复出厂设置;对装置110恢复出厂设置以及/或者擦除或重新安装应用;以及启动新的云服务器。
XIV.安全连接建立
在图14的示出的实施方式中,装置/SCM通信信道可以采用分级的、懒惰的认证过程或方法、分级的、懒惰的认证过程和方法这两者,以改善用户体验(响应性)以及使实现与SCM 120从未见过的装置110的通信。安全连接过程可以在任何通信链路上发生,但是被配置成用于受约束的硬件之间的相对低速、不安全的无线通信链路,诸如蓝牙低功耗(BLE)通信链路。
在示出的实施方式中,安全连接建立过程或方法1400可以包括三(3)个不同阶段:(1)未知的——步骤1401;(2)安全的——步骤1402;以及(3)可信的——步骤1403。无论底层通信层是安全的还是不安全的,都可以在任何底层通信链路上使用作为结果的安全连接。该底层通信链路可以被描述为预先未知的通信链路;在已知预先未知的通信链路是安全的情况下(例如,已经建立了TLS或DTLS会话),于是可替选的实施方式可以除去冗余阶段(例如,未知的和/或安全的)。方法1400在某些方面可以类似于TLS/DTLS连接建立过程。
A.预先未知的通信链路
预先未知的通信链路初始化和连接顺序可以基于系统配置和底层物理介质以及协议栈(例如,以太网-IP-TCP、以太网-IP-UDP、以太网-IP-TCP-TLS、BLE、802.15.4-IPv6[6LoWPAN]等)而变化。照此,对于不同的底层技术,实际的消息内容、分组/成帧以及发送/接收连接/连接的协议排序/操作可以稍微不同。由于底层技术的差异,以下情况也是可以的:可以将一个或更多个协议步骤组合成单个步骤(或者相反,将单个步骤分解为许多较小的步骤以克服非常小的分组/消息限制可能是有用的或必要的)。然而,高级协议步骤可以保持相同。在示出的实施方式中,连接建立过程通过蓝牙低功耗(BLE)来实现——但应当理解,本公开内容不限于此。
到SCM 120和装置110已经到达未知阶段——步骤1401——的开始时,可能的是,可能已经付出了大量的努力来设置预先未知的通信链路。这种情况的一个这样的示例是该实施方式的结合于2015年2月12日提交的题为“SYSTEM AND METHOD FOR COMMUNICATINGWITH A VEHICLE”的J.Michael Ellis等人的美国非临时申请第14/620,959号以及于2017年4月14日提交的题为“SYSTEM AND METHOD FOR ESTABLISHING REAL-TIME LOCATION”的Raymond Michael Stitt的美国非临时申请第15/488,136号中描述的系统的应用——这两个申请的公开内容通过引用整体并入本文中,包括使用BLE的微位置系统。根据该系统的方法在图13的示出的实施方式中示出并且被指定为1300。方法1300可以使用如下连接策略,在该连接策略中,主装置(SCM 120)启动作为外围设备,而便携式装置(装置110)启动作为中心(初始连接)。步骤1301。在同意彼此通信之后,角色被切换,其中,主装置110变为中心,而便携式装置110变为作为微定位连接的一部分的外围设备。步骤1302。
在实施方式中,可以结合本文描述的系统和/或于2015年2月12日提交的题为“SYSTEM AND METHOD FOR COMMUNICATING WITH A VEHICLE”的J.Michael Ellis等人的美国非临时申请第14/620,959号以及于2017年4月14日提交的题为“SYSTEM AND METHOD FORESTABLISHING REAL-TIME LOCATION”的Raymond Michael Stitt的美国非临时申请第15/488,136号中描述的那些来应用本文描述的安全模型/系统——这两个申请的公开内容通过引用整体并入本文中。
1.预先未知的通信链路——初始连接
预先未知的通信链路可以是与方法1300相关的初始连接。换言之,装置110和SCM120尚未交换角色,因此,本文中关于方法1300描述的序列中的第一交换是从装置110→SCM120。
在该实施方式中,安全连接建立过程可以通过初始连接的情境下的安全阶段或可信阶段来完成。可以根据在未知阶段或安全阶段期间是否执行相互认证而通过安全阶段或可信阶段来完成该过程。
可以在切换到微定位连接(即,角色反转)之前验证和/或认证在该过程期间建立的会话密钥如装置-SCM-会话-密钥。无论如何,可以在微定位连接内使用(“移交给”)会话密钥以建立安全通信信道。在使用阶段降级的情况下,可以继续使用微定位连接。可以在诸如由于断开连接/重新连接、会话密钥循环或认证失败的各种情况下使用阶段降级。
该方法可以使得SCM 120能够在角色反转边界处将装置连接利索地分发给可替选的系统组件(例如,SCM 120或类似模块)。
2.预先未知的通信链路——微定位连接
在一个实施方式中,预先未知的通信链路可以是微定位连接。换言之,装置110和SCM 120可能已经交换了角色,因此,关于方法1400描述的序列中的第一交换被反转——装置110←SCM 120。
这是可替选实施方式,其中,在步骤1401处的未知连接建立阶段可能在方法1300中的初始连接期间没有完成。也就是说,整个连接建立过程1400可以在方法1300的步骤1320处建立的微定位连接的情境下完成。
3.建立预先未知的通信链路
在图14的示出的实施方式中,微位置系统中的初始连接的开始是装置110已经决定连接至特定SCM 120的时刻。为了提供示例,装置110可以决定连接至SCM 120,原因是SCM120被识别为装置110相信的系统组件:a)装置110被配置成通信,b)装置110想要变为SCM120的所有者,或者c)装置110是与SCM 120连接的奇怪(或恶意)装置。
装置110可以使用根据方法1300在步骤1301处建立的初始连接来询问SCM 120,诸如以确定SCM 120是否处于恢复出厂设置模式,以发送更新的ACP或者确定另一配置。当装置110和/或SCM 120开始其中建立会话密钥(装置-SCM-会话-密钥)的安全连接建立过程的一部分时,装置110可以通过根据步骤1302切换到微定位连接来执行角色反转。步骤1402。安全连接建立步骤可以在装置110已经共享装置110的装置-SCM-ID之后发生,因此,尽管可能不安全,但是SCM 120具有装置110可以是SCM 120应当连接至的装置110的一些证据。
利用这种方法,在决定是否切换到微定位连接并且尝试建立与装置110的安全通信信道之前,装置110可能无法认证SCM 120,以及/或者SCM 120可能无法认证装置110。
在图14的示出的实施方式中,消息定时信息可以并入到通信链路质询-响应协议中以帮助防止中继攻击。图14中描绘的应用实施方式集中于本文讨论的微位置系统并且通过引用并入本文中——但是应当理解,本公开内容不限于此,并且本文描述的系统100和通信方法可以便于任何类型的装置的系统或系统组件中的通信。
在一个实施方式中,因为一些装置平台/库不允许BLE外围设备在后台处理模式期间通告所有期望的信息,所以SCM 120和/或装置110可以存储BLE绑定信息以完成到微定位连接的转换。在可替选实施方式中,可以在代表用户的初始连接阶段期间完成BLE绑定。
B.安全连接建立
装置110可以根据图14的示出的实施方式启动与SCM 120的连接。SCM 120可以接受连接并且开始连接建立过程:步骤1401——第一(未知)阶段;步骤1402——第二(安全)阶段;以及步骤1403——第三(可信)阶段。
1.第一(未知)阶段
在示出的实施方式中,在第一(未知)阶段期间,不知道通信链路是否可以是安全的。
底层通信链路可能已经提供实际上可能安全或可能不安全的某种级别的加密和/或端-节点硬件认证。例如,底层通信链路可能遭受已知缺陷/弱点。因此,假设在该阶段期间通信链路是不安全的。
在该阶段或在步骤1401期间,装置110可以向SCM 120发送切换到安全通信信道的请求。步骤1410。该请求可以引起装置110向SCM 120发送其装置-SCM-ID和ACP容器版本包412。在可替选实施方式中,装置110的装置-SCM-ID可以包含在ACP容器版本包412内。装置-SCM-ID可以由SCM 120用于确定将哪个加密密钥集如装置-SCM-密钥、ACP-版本-密钥、或装置-SCM-会话-密钥或其组合用于后续消息。
如至少在ACP容器410章节(章节III)处描述的,如果要更新ACP 400,则SCM 120可能不允许转换到安全通信信道。如果确定应当更新SCM 120的ACP 400,则SCM 120可以将发送更新的ACP 400的请求发送回到装置110。
如果不需要更新SCM 120的ACP 400,则SCM 120可以将消息发送回到装置110,指示装置110可以继续进行,并且进一步,是否使用先前存储的会话密钥(装置-SCM-会话-密钥)。步骤1412。如果SCM 120指示装置110应当使用已经建立的会话密钥(会话密钥本身可能没有被公开),并且装置110拥有会话密钥(装置-SCM-会话-密钥),则该装置110和SCM120可以立即转换到安全阶段。如果SCM 120没有指示装置110应当使用已经建立的会话密钥(会话密钥本身可能没有被公开),则SCM 120和装置110可以开始建立新的会话密钥(装置-SCM-会话-密钥)。可以在装置110尝试根据以下步骤中的一个或更多个实现SCM 120的质询-响应认证期间建立装置-SCM-会话-密钥会话密钥:
1)装置110可以生成加密随机数(nonce)(N)。
2)装置110可以用装置-SCM-密钥(私有)密钥对N进行加密,创建ND。
3)装置110可以将ND发送到SCM 120。
4)SCM 120可以使用装置-SCM-密钥(公开)密钥来解密ND,创建NDS。
5)SCM 120可以生成加密随机数(M)。
6)SCM 120可以使用例如与M连结的NDS的加密散列来计算其会话密钥的副本——装置-SCM-会话-密钥。会话序列号(与会话密钥一起存储)可以被设置为0或随机数。
7)SCM 120可以用SCM-密钥(私有)密钥对NDS和M进行加密,创建NM。
8)SCM 120可以将NM发送到装置110。
9)装置110可以使用SCM-密钥(公开)密钥来解密NM,创建NDSD和MD。
10)装置可以验证N等于NDSD。如果不匹配,则不能认证SCM 120并且装置110断开连接。SCM 120和装置110可以丢弃任何先前计算的会话密钥。可以在该阶段处中止质询-响应认证过程。
11)装置110可以使用例如与MD连结的N的加密散列来计算其会话密钥的副本——装置-SCM-会话-密钥。与会话密钥一起存储的会话序列号可以被设置为0。
在该时刻,装置110和SCM 120两者都已经计算出新的会话密钥,但是都没有验证它们能够成功通信,这可以被认为是SCM 120的再一真实性度量。如果质询-响应认证过程成功完成,则装置和SCM可以在步骤1402处立即转换到安全阶段。
在一个实施方式中,除了在质询-响应认证过程中对消息进行加密之外,还可以对消息进行签名-然后-加密。在可替选实施方式中,由装置110生成的加密随机数(N)可以由SCM-密钥(公开)密钥而不是装置-SCM-密钥(私有)密钥来加密。在另一可替选实施方式中,由装置110生成的加密随机数(N)可以不被加密。在又一可替选实施方式中,当尚未建立会话密钥时,由SCM 120生成的加密随机数(M)可以与(在质询-响应认证过程之前被发送的)“继续进行”消息一起被发送。
在又一可替选实施方式中,可以通过另一方法来计算会话密钥(装置-SCM-会话-密钥)。在再一可替选实施方式中,可以利用可替选的质询-响应认证算法。在再一实施方式中,装置-ID可以用作装置-SCM-ID。在一个实施方式中,不利用会话序列号。
在一个实施方式中,当质询-响应认证过程成功(即,装置生成其会话密钥)时,装置110可以向SCM 120发送“会话密钥建立”消息。在一个实施方式中,当质询-响应认证过程中止时,装置110可以向SCM发送“认证失败”消息。
在一个实施方式中,SCM 120可以在该阶段或步骤1401期间验证装置110的真实性(而不是装置110验证SCM 120的真实性)。因此,在稍后的阶段处,当命令被发送时,装置110可以验证SCM 120的真实性。
在一个实施方式中,对本文描述的一个或更多个实施方式而言另外的或可替选的,装置110和SCM 120可以在步骤1401期间彼此相互认证;在这种情况下,如果成功,则装置110和SCM 120可以转换到可信阶段。
SCM 120可以被配置成在预定的不活动时段之后与装置110断开连接。SCM 120可以在任何时间或响应于任何事件而与装置110断开连接。例如,SCM 120可能由于SCM 120上的高系统资源利用、由于在预定时间段内没有响应请求、或者由于超过预定最大持续时间的连接持续时间而断开连接。
如在该章节XIV.B的开始处描述的,SCM 120可以请求装置110发送伴随ACP容器版本包412的ACP容器410。装置110可以在该阶段期间将ACP容器410发送到SCM 120。响应于ACP容器410的接收,SCM 120可以提供具有状态指示的响应,可能至少指示ACP容器410是否被接受、未被处理或被拒绝。接受可以指示ACP容器410被处理和存储,并且指示ACP容器410中包含的任何改变被成功应用。可能由ACP容器410是较旧版本或等同版本造成未被处理。拒绝可以指示验证失败。在可替选实施方式中,SCM 120可以不向装置110提供关于ACP容器410更新处理的状态指示。
为了支持恢复出厂设置状态,装置110可以在步骤1401期间经由新-所有者-发起请求从SCM 120请求SCM-密钥(公开)密钥和/或SCM-ID标识符。响应于该请求,如果处于恢复出厂设置模式,则SCM 120可以提供包含SCM-密钥(公开)密钥和/或SCM-ID标识符的响应,从而指示SCM 120实际上处于恢复出厂设置模式。
SCM 120可以将关于失败的认证尝试的信息记录到SCM系统日志。失败的认证尝试的示例包括进入或保持在安全阶段和/或可信阶段内失败。
2.第二(安全)阶段
在第二(安全)阶段或步骤1402期间,装置110和SCM 120两者都可以拥有可以用于创建安全通信信道的会话密钥(装置-SCM-会话-密钥)。也就是说,会话密钥可以使装置110和SCM 120能够执行以下中的一个或更多个:对数据进行加密;递增序列号;以及生成消息认证代码。
可以使用装置-SCM-会话-密钥会话密钥和递增序列号来发送来自装置110和SCM120使用安全通信信道的消息,以加密-然后-MAC(例如,使用装置-SCM-会话-密钥对消息进行加密,然后附加根据加密的消息计算的MAC[消息认证代码]),使得装置110和SCM 120能够验证和认证发送的/接收的消息。这种通信模式可能与TLS/DTLS的一些方面类似。应当注意,可以使用除加密-然后-MAC之外的方法(例如,MAC-然后-加密或加密-和-MAC);然而,它们可能不太安全。
在示出的实施方式中,会话密钥(装置-SCM-会话-密钥)可以在连接中存活;因此,为了限制会话密钥的持续时间或持久性,装置-SCM-会话-密钥会话密钥可以由SCM 120周期性地和/或在方便的时间循环(在任何阶段)。方便的时间可以是在其他事件期间,其中,用户体验已经受到影响,或者正在发生以任何方式导致新会话密钥的其他动作(密钥循环或ACP更新)。方便的时间也可以采用更传统的含义,其中,方便的时间被认为是用户体验不受影响或没有受到明显影响的时间,诸如在用户10没有主动使用SCM 120但是在SCM 120的范围内时,或者在用户进入/离开范围并且存在足够的时间来完成操作时。在范围内的示例包括坐在已经启动的汽车内、坐在桌子处或者在被锁的门内。
可以通过以下操作来循环会话密钥:在现有安全通信信道内执行会话密钥滚动算法,以及/或者相对于未知阶段和在未知阶段期间会话密钥的计算而使用质询-响应认证过程或在一些方面与本文描述的过程类似的另一过程来计算新会话密钥。另外地或可替选地,可以通过在未知阶段期间使存储的会话密钥无效并且然后断开连接并重新建立会话密钥来循环会话密钥。在一个实施方式中,装置110可以发起会话密钥循环。
在步骤1402的开始,装置110可以向SCM 120发送请求,以验证会话密钥(装置-SCM-会话-密钥)是有效的(验证信道是运转的)或者验证信道的有效性和SCM 120的真实性这两者。步骤1416、1418。如果使用现有会话密钥,例如先前阶段最近没有被执行,则可以验证SCM 120的有效性和真实性。步骤1418。
如果装置110最近验证了信道的运转或者验证了会话密钥有效,则装置110可以跳过该信道的验证步骤1418。在可替选实施方式中,装置可以不跳过验证步骤1418。
为了完成会话密钥验证步骤1418,装置110和SCM 120可以执行安全阶段质询-响应协议。该协议的主要目的是用于装置110在从未知阶段立即进入验证阶段时验证信道的运转,在未知阶段中,SCM 120的真实性已经被建立。然而,安全阶段质询-响应协议可以由装置110或SCM 120周期性地用作保持信道活跃或用于其他目的。下面提供了示例(简单)质询-响应协议:
1)装置110(或SCM 120)可以生成随机数(N)。
2)装置110可以将N发送到SCM。
3)SCM 120可以计算N+1(M)。
4)SCM 120可以将M发送到装置110。
5)装置110可以验证N+1等于M。如果它们不匹配,则验证失败——可能是因为没有正确地传送消息。
当装置110执行安全阶段质询-响应协议时,装置110可以验证通信信道是运转的。除了SCM 120拥有正确的会话密钥之外,装置110在该阶段可能还没有验证关于SCM 120的真实性的任何事物。因为SCM 120也可以发起安全阶段质询-响应协议以验证安全通信信道,因此SCM 120和以上装置110的角色可以反转。在可替选实施方式中,可以不利用安全阶段质询-响应协议。在这种情况下,可以始终使用认证协议,或者不存在认证协议。
在一个实施方式中,装置110可以使用安全阶段质询-响应认证协议以验证SCM120的真实性。当在已经经过预定义的时间段之后进入安全阶段时,或者当发生一些其他事件时,可以周期性地执行安全阶段质询-响应认证协议。示例事件包括SCM 120请求装置110执行安全阶段质询-响应认证协议以及由装置110接收更新的ACP 400。下面概述的安全阶段认证协议在许多方面与未知阶段认证协议类似;然而,因为利用了更少的非对称加密操作,因此本文概述的安全阶段认证协议可以利用明显更少的计算。示例安全阶段认证协议可以如下来执行(尽管可以使用可替选的质询-响应认证协议):
1)装置110可以生成加密随机数(N)。
2)装置110可以将N发送到SCM。
3)SCM 120可以计算N+1(M)的加密散列。
4)SCM 120可以用SCM-密钥(私有)密钥对M进行加密,创建MS。
5)SCM 120可以将MS发送到装置110。
6)装置110可以使用SCM-密钥(公开)密钥来解密MS,创建MSD。
7)装置110可以计算N+1(MD)的加密散列。
8)装置110可以验证MD等于MSD。如果它们不匹配,则认证已经失败,可能是因为SCM 120没有适当的加密密钥来证明其真实性。
在可替选实施方式中,代替SCM-密钥(私有)密钥,可以利用可替选加密密钥如装置-SCM-密钥(公开)密钥。在可替选实施方式中,可以利用附加加密密钥如装置-SCM-密钥密钥。
类似于在未知阶段中描述的操作,装置110可以使用安全通信信道向SCM 120发送ACP容器版本包412。例如,装置110可以响应于或基于装置接收的更新的ACP容器410来发送ACP容器版本包412。如果SCM 120确定需要或期望接收相应的ACP容器410,则SCM 120可以请求装置110发送伴随ACP容器版本包412的ACP容器410。SCM 120还可以请求装置110在周期性的基础上或响应于事件的发生而发送存储在装置110中的最新ACP容器版本包412。
如在先前阶段中描述的,装置110可以在该阶段期间使用安全通信信道将ACP容器410发送到SCM 120;作为响应,SCM 120可以提供具有状态指示的响应。在可替选实施方式中,可以不允许在安全阶段期间将ACP容器410和/或ACP容器版本包412发送到SCM 120。如本文描述的,可以存在使用与ACP容器410类似的语义/操作的其他配置包,因此,不应当推断ACP容器410是可以在该阶段或其他阶段中递送的系统100的唯一配置包。
在一个实施方式中,固件更新包(FUP)可以诸如在安全阶段或可信阶段期间仅经由安全通信信道从装置110被递送到SCM 120。装置110可以从云130获得FUP或者可以获得FUP作为存储在装置110上的可执行/可加载镜像的一部分。例如,可以获得FUP作为应用束(app bundle)的一部分,或者作为包括在较大装置固件镜像中的单独镜像。
在一个实施方式中,FUP可以通过任何通信信道从装置110被递送到SCM 120。在一个实施方式中,FUP可以诸如仅在可信阶段期间仅通过装置110已经被认证的安全通信信道从装置110被递送到SCM 120。在一个实施方式中,FUP可以仅由所有者装置110从装置110递送到SCM 120。在一个实施方式中,装置110可以不向SCM 120递送FUP。另外地或可替选地,固件更新配置和实施方式至少在章节XV处被描述,章节XV包括关于固件更新包本身的附加信息。
SCM 120可以使用安全通信信道向装置110发送在本文中至少在章节XXI处进一步详细讨论的黑名单包。装置110可以向黑名单包提供具有状态指示的响应。在一个实施方式中,装置110可以请求SCM 120向装置110发送黑名单包。如果没有列入黑名单的项,则SCM120可以什么都不做,或者SCM 120可以发送不存在列入黑名单的项的指示。
装置110和SCM 120可以在后台执行各种系统级操作,经由安全通信信道彼此通信。这些操作可能与利用认证和/或授权来启动或完成的命令的显式执行无关。出于公开的目的,由于装置110与SCM 120之间的通信或不存在通信而执行的任何操作被认为是命令;因此,这样的后台操作被认为是命令。可以执行的任何操作或动作可以被认为是命令。可以存在当没有连接时发生的一些操作或动作(例如,关灯),并且可以存在当连接有某些东西时发生的一些操作或动作(例如,跟踪装置,开灯等)。该命令可以涉及装置110或SCM 120或任何其他系统组件的动作或操作。
示例后台操作包括微位置服务、GPS/INS服务、状态信息、日志记录、后台/维护处理、电源模式改变以及配置更新。另外,从一个通信阶段到另一通信阶段的转换被认为是命令(例如,从未知转换到安全、从安全转换到可信、从可信转换到未知、转换到断开连接等)。例如,装置110关于SCM 120的授权可能需要转换到可信通信阶段(即,授权可以包含认证信息和授权标准这两者)。
还值得注意的是,虽然在该阶段——步骤1402中,SCM 120可能尚未明确地验证装置的真实性。最近或最初可能尚未执行明确的验证。然而,可以存在使得高度肯定装置110是真实的足够证据。在该阶段——步骤1402内的某个时刻,装置110和/或SCM 120可以引起、发布或接收命令,该命令可以封装发送/接收以下命令中的任何一个或更多个:
1)命令(例如,装置110可以指示SCM 120或其设备组件140做某事)
2)请求(例如,装置110可以请求SCM 120或其设备组件140发送数据)
3)更新(例如,SCM 120或其设备组件140可以提供周期性/非周期性数据)
4)响应(例如,SCM 120或其设备组件140可以提供对请求的响应)。
SCM 120可以基于装置110的存在、位置、认证状态或授权状态或其任意组合来执行包括列出的命令中的任何一个的操作。装置110可以基于SCM 120的存在、位置、认证状态或授权状态或其任意组合来执行包括列出的命令中的任何一个的操作。
可以值得注意的是,以上对各种类型的命令的描述以及被认为是命令的内容并非详尽或仅限于以上列表,命令的列表也不限于该通信阶段(例如,无论它是由哪个通信阶段引起、发布或接收,命令都是命令)。
如果SCM 120接收到命令而装置110尚未被认证,则可以在装置110被认证的同时对命令进行排队。如果装置110认证失败,则可以为每个被拒绝的命令提供适当的错误响应。
在一个实施方式中,在装置110被认证的同时可以对仅多达一个命令进行排队。另外地或可替选地,如果装置110尚未被认证,则可以拒绝命令。
在一个实施方式中,除非在可信阶段——步骤1403中,否则可能不允许系统级后台操作。
即使没有发送或接收命令,SCM 120也可以(先发制人地)认证装置110,以改善用户体验。在可替选实施方式中,SCM 120可以不先发制人地认证装置110。
在一个实施方式中,为了装置110向SCM 120发送命令或接收命令,SCM 120可以要求SCM 120对装置110进行认证。SCM 120可以在允许执行命令之前发起安全阶段质询-响应认证协议以验证装置110的真实性。步骤1420、1422。安全阶段质询-响应认证协议的示例可以包括以下步骤中的一个或更多个:
1)SCM 120可以生成加密随机数(N)。
2)SCM 120可以将N发送到装置。
3)装置110可以计算N+1(M)的加密散列。
4)装置110可以用装置-SCM-密钥(私有)密钥对M进行加密,创建MS。
5)装置110可以将MS发送到SCM。
6)SCM 120可以使用装置-SCM-密钥(公开)密钥来解密MS,创建MSD。
7)SCM 120可以计算N+1(MD)的加密散列。
8)SCM 120可以验证MD等于MSD。如果MD和MSD不匹配,则认证已经失败。换言之,如果MD和MSD不匹配,则装置110没有适当的加密密钥来证明装置110的真实性。
一旦装置110已经被认证,装置110就可能在预定时间段内以及/或者直到发生预定事件——诸如发生连接断开、对ACP容器410的更新以及来自设备组件140的认证请求、或其任意组合——不再再次被认证。
在一个实施方式中,如本文描述的,可以每个会话密钥循环仅执行一次装置110的真实性。在一个实施方式中,如果装置110的真实性的SCM验证失败,则装置110和SCM 120可以保持在安全阶段——步骤1402中。
在一个实施方式中,可以由SCM 120用从装置110发布并由装置110发送到SCM 120的每个命令来执行装置110的认证。在一个实施方式中,可以用从装置110发布的每个命令来执行装置110的认证。在一个实施方式中,可以用从SCM 120发布的每个命令来执行SCM120的认证。
如果质询-响应过程或质询-响应认证过程失败,则装置110和SCM 120可以立即断开连接以及/或者转换回到步骤1401处的未知阶段。
在SCM 120已经验证了装置10的真实性之后,装置110和SCM 120可以转换到可信阶段。
3.第三(可信)阶段
在第三(可信)阶段期间,装置110和SCM 120两者都可以拥有已经被验证的会话密钥(装置-SCM-会话-密钥),并且装置110和SCM 120两者都已经被确定为是真实的。步骤1403。
在该阶段——步骤1403期间,可以在安全通信信道上执行先前阶段的动作和结果的所有或子集,包括例如对ACP容器410的更新、固件更新、后台操作/其他操作以及装置110和SCM 120质询-响应认证协议。如果发生了在安全通信信道上认证失败,则装置110和SCM120可以立即断开连接以及/或者转换回到先前阶段(例如,未知阶段)。
在可信阶段期间,可以利用SCM 120和装置110两者的周期性认证,并且甚至可以认为SCM 120和装置110两者的周期性认证是必需的。可以通过命令的例行执行、通过关于SCM 120和装置110的真实性的周期性和/或触发的单独验证(经由适当的质询-响应认证协议)或者通过周期性和/或触发的相互认证质询-响应认证协议来完成周期性认证。在可替选实施方式中,SCM 120和装置110两者的周期性认证可能不是必需的或不被认为是必需的。
在一个实施方式中,可以实现相互认证质询-响应协议,其与上述质询-响应协议类似,但是有一个或更多个例外。一个差异可能在于:SCM 120和装置110两者在一个序列中被认证。该单个序列认证可以并入TLS/DTLS相互认证的一个或更多个方面。如果质询-响应认证过程失败,则装置110和SCM 120可以立即断开连接以及/或者转换回到未知阶段。
在可信阶段——步骤1403期间,可以使不透明数据信道(ODC)在SCM 120与装置110之间可用,以用于来回转移抽象的、用户定义的命令和/或数据。ODC可以使得SCM 120能够将命令和/或数据从一个系统组件(例如,装置110)安全地传递到另一系统组件(例如,设备组件140)/从另一系统组件(例如,设备组件140)安全地传递命令和/或数据,同时确保装置110被授权这样做,但可能没有利用API的细节或装置110的数据的知识。SCM 120可以不执行ODC内使用的命令和/或数据的授权、验证和确认中的一个或更多个。ACP 400还可以包含可以是与ODC结合有用的附加信息,诸如附加认证类型和标识符。
XV.固件升级
在一个实施方式中,系统100可以被配置成确保系统组件能够安全且鲁棒地升级固件。升级固件的能力可以使得安全隐患和固件缺陷能够被修补。固件更新可以经由如本文所讨论的固件更新包(FUP)被分发给SCM 120。
可以使用FUP版本包(在许多方面与ACP容器版本包412类似,但适于便于转移FUP而不是ACP 400)接收FUP。FUP(以及可以一起提供的FUP版本包)可以经由云130被递送到系统组件如设备组件140,并且然后可以以与ACP容器410类似的方式被分发给SCM 120。
如本文根据一个实施方式描述的,固件更新可以经由安全通信信道被递送到SCM120。不同的系统实例可以具有不同的可允许固件更新分发器。例如,一个系统可以允许经由装置110或直接从云130递送固件,而另一系统可以预期更新仅通过SCM 120上的物理介质或设备组件140发生。
FUP与ACP容器410的设计和本文描述的其他安全固件镜像/递送方法类似之处在于:FUP可以从任何系统组件被递送、存储和分发到特定SCM 120。然而,在一个实施方式中,系统100可以被配置成使得仅对一个或更多个特定系统组件实现递送。在另一实施方式中,固件更新可以经由任何类型的通信信道被递送到SCM 120。
与ACP容器410类似,可以对用于目标SCM 120的FUP和FUP版本包进行签名和/或加密,并且然后由云120对用于目标SCM 120的FUP和FUP版本包进行签名和/或加密,使得FUP和FUP版本包可以被验证成源自适当的云130并且仅目标SCM 120可以解密FUP和FUP版本包的内容。
如果FUP特定于目标SCM 120,则可以在包内标识目标SCM 120。可以在FUP和FUP版本包内提供云130的身份。
在一个实施方式中,FUP和FUP版本包可以仅由云130加密和/或签名。FUP和FUP版本包可以对许多SCM 120可见和/或适用于许多SCM 120或者仅适用于一个SCM 120,但FUP和FUP版本包的内容可以对所有许多SCM 120可见。在一个实施方式中,可以使用ACP-包-版本密钥对FUP版本包进行加密和/或签名。
在一个实施方式中,可以不加密FUP和FUP版本包。在另一实施方式中,可以另外用制造商提供的加密密钥(例如,固件-密钥)来签名和/或加密FUP,该加密密钥可以或可以不特定于特定行业、顾客、产品线和/或目标的数量(包括特定于单个目标),其他选项也在其中。在一个实施方式中,签名和/或加密的附加层可以用于FUP和/或FUP版本包,使得FUP版本包更类似于ACP容器410的配置。
FUP可以安全地存储在一个或多个系统组件(例如,装置110或云130)上的安全存储器220或安全元件或等同的硬件模块如安全包体或硬件安全模块(HSM)中。
在一个实施方式中,FUP可以不存储在安全元件(或等同的硬件模块)中。然而,FUP仍然可以被安全地存储。例如,可以根据以下中的任何一个或更多个来实现不使用安全存储器220的安全存储:可以在静止时加密FUP;可以实现基于软件的缓解和/或基于硬件的缓解以防止对这样的数据的访问;并且可以实现硬件和/或物理障碍或屏蔽。可以禁用JTAG和其他端口。可以实现硬化的软件接口以消除攻击向量。可以安装可信执行环境、硬件或软件,并且可以实现用于检测操作系统根访问或损害的检测系统。在可替选实施方式中,FUP不被安全地存储。
SCM 120和SCM 120的子组件可以在接收固件更新镜像的时继续正常操作。SCM120和SCM 120的子组件可以立即和/或在不使用时和/或在预定时间段如一天中的某个时间或一周中的某一天期间应用更新。在一个实施方式中,在固件被更新时,SCM 120和SCM120的子组件可以进入中断或禁用正常操作的更新模式。
如果SCM 120的当前操作固件被破坏或者未在预期或所需约束内操作,则SCM 120可以回滚到其自己固件和所有SCM子组件的先前版本。例如,如果在单位时间内发生太多例外,如果SCM 120无法连续运行足够长的时间以执行另一固件更新,如果SCM 120无法与另一系统组件(诸如装置110、云130或设备140组件)建立连接,或镜像散列/CRC校验在加载时失败,或其任意组合,则SCM 120可以发起回滚过程。可以将对操作的约束硬编码在引导选择器、引导加载器、固件/应用或其他可加载项内。
在一个实施方式中,对操作的约束可以在运行时配置。对评估对操作的约束有用的统计和/或其他信息可以存储在存在重置和/或功率损耗的存储器区域中。在一个实施方式中,对操作的约束可以包括运行时行为或统计分析、运行时性能(例如,定时或吞吐量)分析、使用机器学习的分类、或确定固件是否正常操作的其他动态分析器、或其任意组合。在一个实施方式中,当发生固件回滚时,可以通知SCM 120的子组件,并且可以选择是否回滚。在一个实施方式中,SCM 120和SCM 120的子组件可能由于各种原因而不回滚,所述各种原因包括例如因为这些组件中的一个或更多个不能执行回滚或者因为这些组件中的一个或更多个不跟踪足够的统计数据以确定是否降级。
在一个实施方式中,在请求FUP之前,可以针对适用性来验证固件版本、时间戳、最小兼容版本、以及关于如由FUP版本包标识的FUP内的固件镜像中的所有或子集的其他版本控制信息和约束、或该信息的任意组合。
如果确定FUP适用,则可以从目标请求FUP。可以基于一个或更多个标准——诸如固件更新镜像的版本是否比当前固件更新(或者是等同的,但是其时间戳更新),各种配置的最小兼容版本是否与新固件兼容,以及是否满足所有其他约束——将特定固件更新镜像确定为适用的。一旦获得完整的固件镜像(并且可能在写入ROM时再次获得),目标就可以验证镜像。验证可以涉及执行完整性散列、签名以及对可以被验证的任何其他属性的分析、或者其任意组合。
在一个实施方式中,可以以较小的块(以使得能够由受约束的组件进行处理)将固件镜像递送到目标系统组件,通过目标系统组件可以独立地验证较小的块。
SCM 120可以对用于SCM 120的子组件的固件更新进行认证、另外加密和/或签名、或保持不变、或其任意组合,并且将所述固件更新分发给那些子组件。SCM 120的子组件可以是从其他系统组件的视角共同表示SCM 120的SCM 120上的其他硬件模块和/或SCM 120上的其他传感器。
在一个实施方式中,可以跨子组件同步和/或排序固件更新到SCM 120的子组件的递送。SCM 120可以在更新它自己之前更新所有子组件,通过验证所加载的项的版本来验证每个子组件被成功更新。在一个实施方式中,SCM 120可以在子组件的更新之前更新它的固件。在一个实施方式中,系统100可以基于FUP内的数据、SCM 120是否首先更新子组件、SCM120首先被更新、或者要满足另一排序约束是可配置的。
SCM 120可以向所有SCM子组件广播固件更新,或者SCM可以向特定SCM子组件发送目标固件更新。
在一个实施方式中,可以使用增量更新来将FUP发送到SCM 120。可以使用压缩来将FUP发送到SCM 120。
在一个实施方式中,云130可以使用FUP格式或用于不同系统组件的可替选格式向除了SCM 120之外的系统组件如装置110和设备组件140提供固件更新包。在一个实施方式中,系统组件可以支持用于其他系统组件的固件更新的分发(和/或路由)。例如,装置110可以通过SCM 120分发设备固件更新。
在一个实施方式中,系统组件可以对固件更新进行认证、另外加密/签名、或保持不变、或其任意组合,并且将固件更新分发给其他组件。例如,装置110可以将固件更新包递送到SCM 120,SCM 120可以对固件更新包进行签名并且将固件更新包递送到另一SCM 120或附接的设备组件140。
在初始制造之后或者响应于被命令恢复出厂设置,SCM 120可以进入恢复出厂设置模式。响应于被命令恢复出厂设置,SCM 120可以丢弃其ACP 400、其他配置记录以及加密密钥以返回到出厂(初始制造)状态。以下标识符和加密密钥中的零个或更多个可能由于恢复出厂设置而无法被重置:
1)SCM-ID标识符。
2)SCM-密钥密钥。
3)设备-密钥密钥。
4)SCM-设备-密钥密钥。
在一个实施方式中,作为恢复出厂设置的结果,SCM-密钥密钥可以由SCM 120循环。改变SCM-密钥密钥可以使SCM 120作为新的SCM 120而呈现给系统100,使得具有旧SCM-密钥的任何系统组件不能加密或解密来自SCM 120的消息。尽管SCM 120看起来可能是新的,但是只要SCM 120的SCM-ID没有改变(或者可替选的标识符可以用于标识SCM 120保持不变),SCM 120就仍然可以被识别为同一SCM 120。
在一个实施方式中,如果SCM-密钥没有被循环,并且攻击者能够利用在攻击者控制下的装置110成功连接至云130并与云130进行认证,则攻击者可能能够收集信息以潜入系统的部件,然后提交新-所有者-注册请求。以这种方式,攻击者可能能够说服云130将SCM120的所有权转移到攻击者的装置110。然而,SCM 120将拒绝必须由云130签名的任何消息,包括将授权攻击者的装置110向SCM 120发送命令以及/或者从SCM 120接收命令的ACP400。在这种情况下,攻击者的动作可以是清楚地可标识和可反转的。
在恢复出厂设置时改变SCM-密钥可以使云130能够拒绝变为已经用同一SCM-密钥注册的SCM 120的第一所有者装置110的任何请求,提供防止攻击者试图使用新-所有者-注册请求来“接管”SCM 120的附加机制。在可替选实施方式中,云130可以生成要作为新-所有者-注册请求响应的一部分被递送到SCM 120的新SCM-密钥密钥。
在一个实施方式中,作为恢复出厂设置的结果,SCM-ID标识符可以由SCM 120循环。SCM-ID标识符可以意在是永久标识符;然而,特别是如果SCM-密钥也被改变,则改变SCM-ID标识符可以致使系统100不能将SCM 120识别为同一物理部件。在一个实施方式中,云130可以生成要作为新-所有者-注册请求响应的一部分被递送到SCM 120的新SCM-ID标识符。在一个实施方式中,可以循环SCM-ID,并且云130可以保持用于该SCM 120的SCM-ID的历史。
在一个实施方式中,作为恢复出厂设置的结果,SCM 120可以清除设备-密钥密钥。根据一个实施方式,作为恢复出厂设置的结果,SCM-设备-密钥密钥可以由SCM 120循环。清除和/或改变设备密钥可以致使SCM 120无法与耦接至或可能附接至SCM 120的设备组件140进行通信。在一个实施方式中,云130可以生成要作为新-所有者-注册请求响应的一部分被递送到SCM 120的新SCM-设备-密钥密钥。
与已经被恢复出厂设置的SCM 120相关联并且对该SCM 120具有授权的一个或更多个装置110可以不接收SCM 120已经被恢复出厂设置的任何通知。如果恢复出厂设置的SCM 120的SCM-ID标识符或SCM-密钥密钥中的至少一个没有被改变,则云130可以响应于对SCM 120的新-所有者-注册请求而自动撤销对用户10的授权。
SCM 120可以在恢复出厂设置模式下完成其制造过程——但是制造过程可以加载特定于特定目的地的配置,诸如设备-密钥密钥或其他配置数据。然后,SCM 120可以被包括在用于SCM 120耦接至的设备组件140的制造过程中。在设备制造过程期间,SCM 120可以退出恢复出厂设置模式,其中,制造设备可以被注册为关于SCM 120的所有者装置110。在设备制造过程结束时,SCM 120的所有权可以转移到另一装置110或者SCM可以被恢复出厂设置。其他装置110可以与OEM、转销商或租赁代理商相关联。
在该制造阶段,SCM 120可以在销售和交付过程期间被转移到其他装置110以及/或者被恢复出厂设置。可以通过其耦接至的设备组件140命令SCM 120恢复出厂设置。设备组件140可以确定对SCM 120进行恢复出厂设置的适当性的标准可能对OEM系统的整体安全性有用。例如,设备组件140可以验证:请求恢复出厂设置的用户10被授权这样做。授权可以基于一个或更多个因素,诸如设备组件140的所有权或设备组件140的物理拥有。
在一个实施方式中,可以由云130直接或间接地经由一个或更多个系统组件命令SCM 120恢复出厂设置。当SCM 120连接至云130时,可以接收恢复出厂设置的直接命令。可以类似于ACP 400经由一个或更多个系统组件——诸如云130到装置110到SCM 120、或者云130到设备组件140到SCM 120——接收恢复出厂设置的间接命令。
在一个实施方式中,所有者装置110可以命令SCM 120恢复出厂设置。可替选地,任何装置110可以命令SCM 120恢复出厂设置。另外地或可替选地,任何系统组件(包括SCM120本身)可以——诸如通过用户按下SCM 120上的按钮——命令SCM 120恢复出厂设置。
当SCM 120处于恢复出厂设置模式时,虽然对SCM 120而言不存在所有者装置110,但SCM 120可以接受新-所有者-发起请求。新-所有者-发起请求可以为SCM 120建立第一所有者装置110,这可以导致:生成和转移用于SCM 120的第一ACP 400,向SCM 120提供云密钥(例如,云-SCM-密钥密钥、云-SCM-批准-密钥以及ACP-版本-密钥密钥)和授权以及其他配置数据。可以根据以下步骤中的一个或更多个来执行SCM 120的注册和新所有者的建立:
1)装置110可以将新-所有者-发起请求发送到SCM 120。
2)SCM 120可以将其SCM-密钥(公开)密钥和SCM-ID标识符发送到装置110。
3)装置110可以生成新的装置-SCM-密钥公开密钥对/私有密钥对。
4)装置110可以将新-所有者-注册请求发送到云130。作为新-所有者-注册请求的一部分,装置110可以向云130发送以下中的一些或所有:
ο云-用户-ID标识符
ο装置-SCM-密钥(公开)密钥
οSCM-密钥(公开)密钥
οSCM-ID标识符
ο装置-ID标识符
ο装置-SCM-ID标识符
ο其他(例如,以太网MAC、BLE UUID或APNS/GCM令牌)5)云130可以注册装置110,并且生成以下中的一个或更多个:
ο生成新的云-SCM-密钥公开密钥/私有密钥(例如,云-SCM-密钥和云-SCM-批准-密钥)
ο生成新的ACP-版本-密钥公开密钥/私有密钥
ο生成新的用户-SCM-密钥公开密钥/私有密钥
ο生成所有者装置授权
ο生成初始ACP 400并且递送它
6)云130可以将云-SCM-密钥(公开)密钥发送到装置110。
7)云130可以将ACP容器410(包含初始ACP)发送到装置110。
8)装置110可以将ACP 400转移到SCM 120。
9)SCM 120可以接受ACP 400并且退出恢复出厂设置模式。
在SCM 120已经接受其第一ACP 400并且退出恢复出厂设置模式之后,可以正常添加对附加装置110的授权。
在一个实施方式中,可以不通过不安全连接获得SCM-ID,因此,SCM-密钥可以用于建立安全连接。安全连接的建立可以与装置/SCM连接建立过程类似,以未知阶段开始,然后装置110可以使用安全连接从SCM请求SCM-ID。
XVI.装置/云通信——服务器侧认证
在一个实施方式中,诸如通过使用具有基于证书和云会话令牌的服务器侧(云)认证的TLS 1.2或更高版本,可以保护装置110与云130之间的通信信道。
系统100中的应用层和/或应用编程接口可以基于诸如HTTPS、谷歌协议缓冲器、AMQP、MQQT、CoAP、TCP和UDP的相关标准技术的任意组合。在一个实施方式中,每个装置110可以具有其自己的唯一客户端证书,并且可以基于该唯一客户端证书来执行TLS相互认证。在一个实施方式中,可以利用DTLS代替TLS。在一个实施方式中,可以使用原始非对称加密代替TLS。在一个实施方式中,可以使用对称加密代替TLS。在一个实施方式中,不使用安全通信信道。装置110从云130接收的用于特定SCM的消息可以由SCM的相应的云-SCM-密钥密钥签名。
XVII.云/云通信——相互认证
在一个实施方式中,通过使用具有使用证书的相互认证的TLS 1.2或更高版本,在云130内(云内部)和/或云系统之间使用的通信信道可以是安全的。
应用层和/或应用编程接口可以基于诸如HTTPS、谷歌协议缓冲器、AMQP、MQQT、CoAP、TCP和UDP的相关标准技术的任意组合。在一个实施方式中,可以利用DTLS代替TLS。在一个实施方式中,可以使用原始非对称加密代替TLS。在一个实施方式中,可以使用对称加密代替TLS。在一个实施方式中,不使用安全通信信道。
XVIII.设备/SCM通信
设备组件140与SCM 120之间的通信信道可以使用原始非对称加密来保护通信。非对称加密可以基于SCM-设备-密钥和/或设备-密钥。
应用层和/或应用编程接口可以基于相关标准技术的任意组合,相关标准技术包括例如谷歌协议缓冲器、CoAP、TCP、UDP、CAN、UART(可能是定制的)、SPI以及I2C。在一个实施方式中,TLS可以与具有证书或非对称加密的相互或服务器侧认证一起使用。在一个实施方式中,DTLS可以与证书或非对称加密一起使用。在一个实施方式中,可以使用对称加密。在一个实施方式中,不使用安全通信信道。
如本文描述的,SCM 120可以是用于另一SCM 120的设备,每个SCM120建立一个或更多个SCM-SCM通信信道。这样的配置可以便于以下中 的一个或更多个:共享连接;授权;和/或SCM 120之间的认证活动;加载平衡(例如,通信连接或计算资源);装置或其他系统组件(例如,其他设备)的冗余/多因素验证/认证;冗余/锁步系统执行和验证(例如,交叉检查);以及扩展系统控制能力(例如,更多输入/输出端口或增大通信范围)。
XIX.时间分发
一个或更多个系统组件可以利用当前时间来建立安全连接或验证信息或者建立安全连接和验证信息这两者。照此,可以安全地并从可信源分发或获得当前时间。在一个实施方式中,SCM 120可以从SCM 120耦接至的设备组件140获得当前时间。在一个实施方式中,SCM 120可以从装置110获得当前时间(可能使用安全通信信道或可能不使用安全通信信道)。在一个实施方式中,SCM 120可以从云130获得当前时间。在一个实施方式中,装置110可以从云130获得当前时间。
XX.区块扇权利管理
在一个实施方式中,系统100可以利用基于区块扇的权利管理系统。与常规区块链(其中,每个节点可以具有多达一个父节点和多达一个子节点)相对比,区块扇(或区块扇)被标识为基于区块链的权利管理系统,其中,每个节点可以“扇”入树中。区块扇的树结构可以用于管理和验证经由父授予授予的对等权利。例如,装置110可以被授予访问SCM 120的权利(父授予),并且在该权利的背景下,授予发布多个命令的权利(对等授予)。
区块扇中的链结构可以用于随着时间的顺序授予。在一个实施方式中,梅克尔树(Merkle tree)可以用于验证区块扇的节点的散列和/或签名(包括授予节点的同属节点,以确保没有多次使用令牌授予)。因此,梅克尔树可以用于验证整个权利管理系统的完整性、有效性和正确性。基于区块扇的权利管理系统可以限定令牌授予,其中,授予单个使用权利用于稍后使用。例如,在将来的某个时刻,特定装置110可能想要获得特定SCM 120的所有权。区块扇可以形成分类账——换言之,权利永远不会被删除并且所有权利可以追溯到一个或更多个根授予。在权利无法追溯到根授予的情况下,认为这指示验证失败。
根据图15的示出的实施方式的权利管理系统中的权利可以被限定到三(3)个组件中:
1)做动作的权利,被指定为1501。
2)授予执动作作的权利的权利,被指定为1502。
3)授予授予执动作作的权利的权利的权利,被指定为1503。
ο注意,具有授予权利的权利并不一定意味着授予者能够自己采取动作。
ο该权利可能意味着有权将该权利授予其他人。
在一个实施方式中,授予者不能将权利分配给他们自己,已经被授予授予授予对权利的授予的权利的权利的授予者也不能授予对他们自己的授予。
例如,SCM 120所有者10可以授予另一用户10授予发布特定命令的权利的权利。该其他用户10现在可以向其他用户10授予发布特定命令的权利,但是该其他用户10不能授予另一用户授予其他用户10发布特定命令的权利。在示出的实施方式中,仅SCM 120所有者可以这样做。
在一个实施方式中,所有授予可以包括以下信息:
·动作
·背景
·被授予者
·被授予者公开密钥的副本
·授予
·开始日期
·截止日期
·父授予ID
·检查值
该信息集合可以用授予者的私有密钥进行加密并且可以包括授予者的ID、被授予者的ID、父授予的ID、动作、背景、授予、开始日期和结束日期。应当理解,本公开内容不限于具有标识的信息中的所有信息的授予——还可以包括附加信息,并且可以不存在标识的一条或更多条信息。
在一个实施方式中,经由针对撤销的权利表的联合,每个权利或授予还可以包括:
·撤销的父ID
·撤销的值
该集合可以用撤销者的私有密钥进行加密,并且可以包括撤销者的ID、撤销的ID、撤销授予的ID、动作、背景以及撤销的状态。
通过对授予的发布进行签名和注明日期,可以将每个权利的授予追溯到系统100的开始,在该过程中能够实现对系统100中的数据的验证。
根据本公开内容的一个实施方式,可以利用下面列出的权利类型。应当注意,授予可以按照动作具有不同的模型。
·依赖。当授予者的授予权利的权利到期时,依赖的权利可能也到期。这种类型的权利可以主要用于关于SCM 120的操作权利,使得当SCM 120被转移或者SCM 120所有者被除去时,可以撤销所有这样的依赖权利。
·独立。独立权利可能不要求在授予的时刻之后授予者的授予该授予的权利有效。仍然可以通过系统100实现跟踪以确保在授予的时刻授予者的权利是有效的。这种类型的权利可能在组织内对管理任务有用。
·令牌。在一个实施方式中,令牌授予仅可以使用一次。在一个实施方式中,令牌授予是系统100内唯一不能在没有副作用的情况下使用的权利。令牌权利的使用可以使令牌的同属无效。令牌权利可以用于SCM 120的转移。
·永久。可以在SCM 120的生命周期内授予永久权利,并且可以超越SCM 120所有权。虽然如此,永久权利可以仅授予OEM,并且表示可以在将总是为由永久权利引用的SCM120创建的每个配置中包括的权利。
在一个实施方式中,基于区块扇的权利管理系统可以用于在该系统100和安全模型内使用的云130中创建权利管理服务,其中,装置-权利-密钥引用区块扇中的相应节点。
XXI.黑名单
在一个实施方式中,可以认为系统100遭遇可能的隐患:如果无法传送更新,则可能无法递送更新。系统100的分布式性质可以致使系统100比其他系统100更能容忍缺少连接;然而,系统100可能不提供对该问题的基本上绝对的解决方案,没有在线系统可能会提供对该问题的基本上绝对的解决方案。
授权和配置更新可以经由其他系统组件(例如,装置110)被递送到SCM 120。如果系统组件不能与SCM 120进行通信,或者由于其自身缺少连接而不能获得更新,则系统组件可以不向SCM 120递送更新。关于授权撤销,由于无意或有意缺少连接而导致不能以及时的方式接收更新是特别令人关注的。
考虑以下场景:一个用户A撤销对属于用户B的装置110关于SCM 120的授权,但是用户B希望继续能够访问SCM 120附接至的设备组件140(即,“疯狂的示例”场景)。在这种场景下,如果用户B禁用其装置110上的无线电,则其装置110可能不会将撤销其授权的更新的ACP 400递送到SCM 120,因此,用户B可以继续使用与SCM 120相关联的设备组件140。因为具有关于SCM 120的授权的任何装置110可以递送更新的ACP 400,所以系统100的分布式性质可以帮助避免该序列。然而,在这种场景下,用户A具有唯一的在附近被授权的其他装置110,而他们的装置110离线,但是用户A能够访问SCM 120以及附接的设备组件140。
为了为设备组件140(以及通过代理、用户10)提供本地撤销授权的手段,SCM 120可以保持授权黑名单(SCM黑名单)。假设设备组件140具有合适的用户界面,设备组件140可以向用户A呈现有效授权的列表——使用用户界面,用户A可以将用户B的授权添加到SCM120的黑名单,此时,用户B的授权已经被本地撤销,并且用户B不能使用与用户B相关联的装置110访问设备组件140。
SCM 120黑名单中的每个条目可以是授权与唯一黑名单-项-ID的配对。在一个实施方式中,装置-ID或装置-SCM-ID可以用作黑名单-项-ID。
当装置110与SCM 120(至少在安全阶段中,每装置/SCM连接建立过程)建立安全通信链路时,SCM 120可以将黑名单包发送到装置110。在处理更新的ACP 400之后,在装置110连接之后的某个时刻,或者当SCM 120黑名单改变时,SCM 120可以将黑名单包发送到装置110。
黑名单包与ACP容器410的类似之处在于:黑名单包可以是多层加密的包——黑名单包可以包含SCM 120的当前ACP版本,可以用SCM-密钥(私有)密钥进行签名和加密,并且然后可以用云-SCM-密钥(公开)密钥进行签名和加密。在一个实施方式中,SCM 120可以经由任何通信链路将黑名单包发送到另一SCM 120或另一系统组件。在一个实施方式中,黑名单包还可以用ACP-包-版本(公开)密钥进行签名和加密。在一个实施方式中,除设备组件140之外的系统组件可以接收有效授权的列表并且将列入黑名单的授权发送到SCM 120。
当装置110接收黑名单包时,装置110可以将黑名单包发送到云130而没有修改(装置110可能无法解密黑名单包)。云130可以执行以下中的一个或更多个:验证黑名单包;应用黑名单包中表示的撤销;以及向SCM 120的所有者装置110通知更新的ACP 400可用于批准。ACP 400可以包含自从云130最后接收到配置被递送到SCM 120的确认以来已经被处理的黑名单-项-ID。例如,ACP黑名单可以增长直到接收到黑名单内容已经被处理的确认为止,此时,黑名单可能减少。如果更新的ACP 400对于所有者10而言是不可接受的,则所有者10可以修正ACP 400直到ACP 400满足批准为止。
当装置110将更新的ACP 400递送到SCM 120时,SCM 120可以处理ACP 400黑名单,除去存在于SCM 120黑名单和ACP 400黑名单两者中的黑名单-项-ID。在ACP 400黑名单中存在黑名单-项-ID可以表示所有者装置110在ACP 400中包括黑名单-项-ID的决定(无论所有者10决定保留还是撤销相应的授权)。
XXII.中央系统日志
在一个实施方式中,为了提供可以帮助检测和分析对系统100或特定系统组件(包括用10)的攻击的信息,或者在分析系统性能和操作时,云130可以保持被定义为中央系统日志的安全的集中式系统日志,该系统日志可以存储(即,记录)来自已经在系统100的组件中的所有或子集中发生的事件的信息。这样的事件可以包括在云130本身中发生的那些事件。
每个系统组件可以保持系统日志,该系统日志可以存储(即,记录)关于系统组件已经遇到的本地事件的信息。存储在组件的系统日志中以及存储系统日志的信息可以是可配置的(在构建时、配置时或运行时),并且可以由于系统状态而改变。诸如如果由另一系统组件命令这样做,则改变可以自动和/或手动地发生。
系统组件可以将事件实时、批量或经由可分发的系统日志包记录到中央系统日志、RAM、ROM、其他系统组件或一个或更多个通信链路、诊断/调试端口和/或物理介质。系统日志包可以被分发给其他系统组件(例如,装置110、设备140、SCM 120等),以递送到云130(例如,SCM 120可以将SCM 120系统日志包分发给装置以递送到云)。可替选地,系统日志包可以以类似于黑名单包的方式被直接递送到云130。由于系统日志包被加密的方式,系统日志包可以经由任何通信信道被分发;在一个实施方式中,实时和批量日志可以仅经由安全通信链路被发送到云130。在一个实施方式中,系统日志包可以仅经由安全通信信道被递送。
在一个实施方式中,中央系统日志不存在,改为每个系统组件可以创建和保持其自己的系统日志。
XXIII.示例用例
应当理解,本公开内容的一个或多个实施方式可以结合各种应用来实现,并且本公开内容不限于本文描述的特定应用。出于公开的目的,包括可以与微位置系统组合的用例的若干用例或应用被标识如下:
1)汽车
ο乘客/轻型卡车
ο公共汽车
ο长途
ο本地递送
ο效用/专门
ο娱乐车
ο共享乘车
ο租赁
ο经销权
ο共享访问。
2)重型设备(推土机)
3)农场设备(John Deere、Kubota)
4)摩托车(以及四轮车、三轮车和雪地车)
5)飞机
ο通用航空
ο商业
ο军事
6)船
ο个人船只
ο船(住宅)/游艇
ο商业
ο货船
7)门锁
ο住宅和商业
ο酒店/租赁
ο安全、受控制的访问
8)办公设备和自动化
ο会议室设备
ο安全按钮(即将到来的单独专利)
ο自动化
9)办公家具
ο空间利用
ο开放式办公台
ο空间定制
ο移动的设备
ο可调节椅子
ο布罗迪(Brody)椅子
ο显示器
10)会议/事件
ο允许进入会议(对比扫描标签)
ο我的座位在哪里/我在正确的座位上
11)主题公园(迪士尼、六旗(Six Flags))
12)医院
ο房间和设备访问
ο某人在哪个房间
οRTLS(实时定位系统)——跟踪事物
13)零售(商店)
14)工业设备/制造业自动化(大的昂贵的东西)
15)自动售货机
16)餐厅
ο服务员/经理
ο“哪张桌子订了哪种食物?”
ο来自任意桌子的订单,获取您的东西
17)计算机显示器/膝上型计算机
本文描述的一个或更多个实施方式提供超过常规系统的若干优点。
诸如“竖直”、“水平”、“顶部”、“底部”、“上部”、“下部”、“内部”、“向内”、“外部”和“向外”的方向术语用于帮助基于图示中示出的实施方式的取向描述本发明。方向术语的使用不应被解释为将本发明限制于任何特定取向。
以上描述是本发明的当前实施方式的描述。在不脱离如所附权利要求中限定的本发明的精神和更广泛的方面的情况下,可以进行各种变更和改变,将根据包括等同原则的专利法的原理来解释所附权利要求。出于说明性目的而呈现本公开内容,并且本公开内容不应被解释为对本发明的所有实施方式的详尽描述或者将权利要求的范围限制到结合这些实施方式示出或描述的特定要素。例如但不限于,所描述的发明的任何单个要素可以由提供基本相似的功能或以其他方式提供适当操作的可替选要素代替。例如,这包括目前已知的可替选要素,诸如本领域技术人员当前可能知道的那些要素以及可以在将来开发的可替选要素如本领域技术人员可以在开发时认为是可替选的那些要素。此外,公开的实施方式包括一致描述的并且可以协作地提供一些益处的多个特征。除了在发布的权利要求中另外明确阐述的范围之外,本发明不限于仅包括这些特征中的所有特征或提供所陈述益处中的所有益处的那些实施方式。以单数形式对要求保护的要素的任何引用,例如使用冠词“一个(a)”、“一个(an)”、“该”或“所述”,不应被解释为将该要素限制为单数。对要求保护的要素的如“X、Y和Z中的至少一个”的任何引用意味着单独包括X、Y或Z中的任何一个以及X、Y和Z的任意组合,例如,X、Y、Z;X、Y;X、Z;以及Y、Z。
Claims (20)
1.本发明的要求保护排他权或特权的实施方式被限定如下:
一种用于从第一装置到第二装置进行通信的系统,所述系统包括:
所述第一装置,其被配置成在在线模式下与网络服务器进行无线通信,所述第一装置被配置成从所述网络服务器获得授权配置信息,其中,所述授权配置信息涉及关于所述第一装置与所述第二装置通信的授权,其中,所述授权配置信息包括由与所述第二装置相关联的第一密钥加密的数据;
所述第二装置,其耦接至设备组件,所述第二装置被配置成与所述设备组件进行通信;
所述第二装置被配置成在离线模式下与所述第一装置进行无线通信,在所述离线模式下,所述第一装置和所述第二装置都不能与所述网络服务器有效地通信;
其中,所述第一装置和所述第二装置被配置成建立用于交换通信的通信链路,其中,在建立所述通信链路之前,所述第二装置没有接收到指示所述第一装置已经获得所述授权配置信息的信息,所述授权配置信息涉及所述第一装置的认证和所述第一装置关于所述第二装置的授权中的至少一个;并且
其中,所述第一装置被配置成经由所述通信链路将所述授权配置信息传送到所述第二装置,其中,所述第二装置基于所述授权配置信息来认证所述第一装置的身份并且确定所述第一装置是否关于所述第二装置被授权。
2.根据权利要求1所述的系统,其中,在所述第一装置与所述第二装置之间建立的所述通信链路涉及所述第二装置认证所述第一装置的所述身份的质询-响应认证过程。
3.根据权利要求1所述的系统,其中,所述第二装置至少部分地基于利用与所述第一密钥相关联的第二密钥对所述授权配置信息的所述数据的解密来认证从所述网络服务器发布的所述授权配置信息,其中,所述第一密钥是私有密钥,而所述第二密钥是公开密钥。
4.根据权利要求3所述的系统,其中,在所述第一装置与所述第二装置之间的通信之前,在所述网络服务器与所述第二装置之间建立所述私有密钥和所述公开密钥。
5.根据权利要求1所述的系统,其中,所述授权配置信息包括与所述第一装置相关联的公开密钥,其中,所述第一装置存储与所述公开密钥相关联的私有密钥,并且其中,所述第二装置至少部分地基于以下操作来认证所述第一装置的所述身份:用所述公开密钥对经由所述通信链路接收的数据进行解密。
6.根据5所述的系统,其中,所述第一装置基于以下操作来认证所述第二装置的身份:对经由所述通信链路从所述第二装置接收的数据进行解密。
7.根据权利要求1所述的系统,其中,所述授权配置信息包括涉及所述第一装置关于针对所述第二装置的一个或更多个命令的一个或更多个授权的授权数据,其中,所述授权数据被加密,并且仅所述第二装置能够解密所述授权数据。
8.根据权利要求1所述的系统,其中,所述授权配置信息是具有多个层的分层包,其中,每个层根据非对称密钥对中的一个密钥被加密。
9.根据权利要求8所述的系统,其中,所述授权配置信息包括认证信息。
10.根据权利要求8所述的系统,其中,所述授权配置信息的层包括涉及与所述第二装置的通信和操作中的至少一个相关联的一个或更多个授权的授权数据。
11.根据权利要求10所述的系统,其中,仅所述第二装置能够解密所述多个层中的所有层。
12.根据权利要求10所述的系统,其中,所述多个层中的所有者加密的层由与所述第二装置相关联的所有者装置加密,所述所有者装置被建立为对所述第二装置的操作的授权,并且其中,所述所有者加密的层的加密指示所述所有者装置已经授权包括在所述层中的所述授权数据。
13.一种用于与设备组件进行通信的控制单元,所述装置包括:
通信接口,其能够操作成与远程装置进行无线通信;
存储器,其被配置成存储涉及所述远程装置的认证和授权的一个或更多个加密密钥;
设备接口,其能够操作成与所述设备进行通信;
控制器,其被配置成建立经由所述通信接口与所述远程装置的通信链路,所述控制器被配置成从所述远程装置接收授权配置信息,其中,所述授权配置信息包括被加密的授权数据,其中,仅所述控制器能够解密来自所述授权配置信息的所述授权数据;并且
其中,至少部分地基于所述授权数据,所述控制器被配置成认证所述远程装置的身份并且确定所述远程装置是否被授权。
14.根据权利要求13所述的控制单元,其中,所述授权配置信息是具有多个层的分层包,其中,每个层根据非对称密钥对中的一个密钥被加密。
15.根据权利要求14所述的控制单元,其中,所述授权配置信息包括认证信息。
16.根据权利要求14所述的控制单元,其中,所述授权配置信息的层包括所述授权数据,其中,所述授权数据涉及与通信和操作中的至少一个相关联的一个或更多个授权。
17.根据权利要求14所述的控制单元,其中,仅所述控制单元能够解密所述多个层中的所有层。
18.根据权利要求14所述的控制单元,其中,所述多个层的所有者加密的层由与所述控制单元相关联的所有者装置加密,所述所有者装置被建立为对所述控制单元的操作的授权,并且其中,所述所有者加密的层的加密指示所述所有者装置已经授权包括在所述层中的所述授权数据。
19.一种在第一装置与第二装置之间通信的方法,所述方法包括:
在所述第一装置中获得来自网络服务器的授权配置信息,其中,所述授权配置信息包括由与所述第二装置相关联的第一密钥加密的数据;
建立用于在所述第一装置与所述第二装置之间交换通信的通信链路,其中,在建立所述通信链路之前,所述第二装置没有接收到指示所述第一装置已经获得所述授权配置信息的信息;
在所述第二装置中提供所述授权配置信息;
在所述第二装置中解密所述授权配置信息,以获得涉及关于所述第一装置与所述第二装置通信的一个或更多个授权的授权数据;
基于从所述授权配置信息获得的所述授权数据来认证所述第一装置的身份;以及
确定所述第一装置是否关于所述第二装置被授权。
20.根据权利要求19所述的方法,还包括利用在所述第二装置与所述网络服务器之间建立的第二密钥加密所述授权配置信息中的至少一部分,其中,所述授权确认信息包括认证信息。
Applications Claiming Priority (5)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US201662413966P | 2016-10-27 | 2016-10-27 | |
US201662413778P | 2016-10-27 | 2016-10-27 | |
US62/413,966 | 2016-10-27 | ||
US62/413,778 | 2016-10-27 | ||
PCT/US2017/058792 WO2018081583A1 (en) | 2016-10-27 | 2017-10-27 | System and method for authenticating and authorizing devices |
Publications (1)
Publication Number | Publication Date |
---|---|
CN109891416A true CN109891416A (zh) | 2019-06-14 |
Family
ID=62021981
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201780065045.9A Pending CN109891416A (zh) | 2016-10-27 | 2017-10-27 | 用于认证和授权装置的系统和方法 |
Country Status (5)
Country | Link |
---|---|
US (4) | US10313134B2 (zh) |
EP (1) | EP3532971A4 (zh) |
JP (4) | JP6888673B2 (zh) |
CN (1) | CN109891416A (zh) |
WO (1) | WO2018081583A1 (zh) |
Cited By (11)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN110784461A (zh) * | 2019-10-23 | 2020-02-11 | 北方工业大学 | 一种基于区块链的安全6LoWPAN通信方法及系统 |
CN110865608A (zh) * | 2019-11-21 | 2020-03-06 | 武夷学院 | 一种可重构制造系统 |
CN110991622A (zh) * | 2019-08-22 | 2020-04-10 | 腾讯科技(深圳)有限公司 | 基于区块链网络的机器学习模型处理方法及节点 |
CN111460499A (zh) * | 2020-03-31 | 2020-07-28 | 中国电子科技集团公司第三十研究所 | 一种保护隐私的基于Merkletree的区块链用户属性集核验方法 |
CN111639020A (zh) * | 2020-05-06 | 2020-09-08 | 贝壳技术有限公司 | 一种程序漏洞复现方法、系统、装置、电子设备及其存储介质 |
CN112187459A (zh) * | 2020-10-09 | 2021-01-05 | 安徽大学 | 一种智能网联车中模块间的可信认证方法及系统 |
CN112218279A (zh) * | 2020-10-14 | 2021-01-12 | 福建小飞科技有限公司 | 一种多协议的手持终端对展示终端的控制方法及设备 |
CN114152460A (zh) * | 2021-11-30 | 2022-03-08 | 四川虹美智能科技有限公司 | 智能空调的生产检测系统和方法 |
CN114730332A (zh) * | 2019-11-19 | 2022-07-08 | 美光科技公司 | 使用远程主机以认证装置 |
CN117093969A (zh) * | 2023-08-22 | 2023-11-21 | 上海合芯数字科技有限公司 | 调试授权方法及系统 |
CN119293775A (zh) * | 2024-12-10 | 2025-01-10 | 浙江吉利控股集团有限公司 | 设备的访问验证方法、车辆、电子设备及计算机存储介质 |
Families Citing this family (128)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US10852069B2 (en) | 2010-05-04 | 2020-12-01 | Fractal Heatsink Technologies, LLC | System and method for maintaining efficiency of a fractal heat sink |
US9417922B2 (en) | 2012-12-03 | 2016-08-16 | Cutting Edge Consulting Associates, Inc. | Systems and methods for protecting an identity in network communications |
US10277616B2 (en) | 2014-09-25 | 2019-04-30 | Vigilant Ip Holdings Llc | Secure digital traffic analysis |
US10169614B2 (en) | 2016-11-17 | 2019-01-01 | International Business Machines Corporation | Container update system |
EP3556119A4 (en) | 2016-12-14 | 2020-01-22 | Denso Corporation | METHOD AND SYSTEM FOR ESTABLISHING MICROLOCATION AREAS |
JP6766967B2 (ja) * | 2016-12-27 | 2020-10-14 | 株式会社デンソー | マイクロロケーションセンサ通信のためのシステムおよび方法 |
US20180198620A1 (en) * | 2017-01-11 | 2018-07-12 | Raptor Engineering, LLC | Systems and methods for assuring data on leased computing resources |
US11468439B2 (en) * | 2017-01-12 | 2022-10-11 | American Express Travel Related Services Company, Inc. | Systems and methods for blockchain based proof of payment |
WO2018140813A1 (en) * | 2017-01-27 | 2018-08-02 | Celitech Inc. | Systems and methods for enhanced mobile data roaming and connectivity |
US10425417B2 (en) * | 2017-03-08 | 2019-09-24 | Bank Of America Corporation | Certificate system for verifying authorized and unauthorized secure sessions |
US10560844B2 (en) * | 2017-03-15 | 2020-02-11 | International Business Machines Corporation | Authentication of users for securing remote controlled devices |
US11107048B2 (en) * | 2017-04-17 | 2021-08-31 | International Business Machines Corporation | Providing out-of-band verification for blockchain transactions |
US10358114B2 (en) * | 2017-04-25 | 2019-07-23 | Ford Global Technologies, Llc | Method and apparatus for dynamic vehicle key generation and handling |
US10554689B2 (en) * | 2017-04-28 | 2020-02-04 | Cisco Technology, Inc. | Secure communication session resumption in a service function chain |
US11194562B2 (en) * | 2017-05-19 | 2021-12-07 | Blackberry Limited | Method and system for hardware identification and software update control |
US11153076B2 (en) * | 2017-07-17 | 2021-10-19 | Thirdwayv, Inc. | Secure communication for medical devices |
US10805276B2 (en) * | 2017-09-05 | 2020-10-13 | Comodo Security Solutions, Inc. | Device and methods for safe control of vehicle equipment secured by encrypted channel |
US10516650B2 (en) * | 2017-09-13 | 2019-12-24 | Netabstraction, Inc. | Dynamic, user-configurable virtual private network |
US11251975B1 (en) * | 2017-09-27 | 2022-02-15 | Seagate Technology Llc | Block chain based trusted security infrastructure |
JP7242169B2 (ja) * | 2017-10-31 | 2023-03-20 | 株式会社小松製作所 | 通信監視装置、通信監視システム、および通信監視方法 |
US10904230B2 (en) * | 2017-11-29 | 2021-01-26 | Vmware, Inc. | Distributed encryption |
US10715610B2 (en) * | 2017-12-15 | 2020-07-14 | Slack Technologies, Inc. | System, method, and apparatus for generating a third party resource usage map in a group based communication system |
US10871952B2 (en) * | 2017-12-20 | 2020-12-22 | Nio Usa, Inc. | Method and system for providing secure over-the-air vehicle updates |
WO2019119408A1 (en) * | 2017-12-22 | 2019-06-27 | Intel Corporation | Manageability engine and automatic firmware validation |
US11606190B2 (en) * | 2017-12-26 | 2023-03-14 | Akamai Technologies, Inc. | High performance distributed system of record with cryptographic service support |
US11164172B2 (en) * | 2017-12-29 | 2021-11-02 | Square, Inc. | Application programming interfaces for structuring distributed systems |
US10868812B2 (en) * | 2017-12-29 | 2020-12-15 | ANI Technologies Private Limited | Method and system for device authentication |
US11010739B2 (en) | 2017-12-29 | 2021-05-18 | Square, Inc. | Application programming interfaces for structuring distributed systems |
US10437745B2 (en) * | 2018-01-05 | 2019-10-08 | Denso International America, Inc. | Mobile de-whitening |
US20190215163A1 (en) * | 2018-01-09 | 2019-07-11 | Ford Global Technologies, Llc | Electronic custody tracking |
JP2019133471A (ja) * | 2018-01-31 | 2019-08-08 | Dynabook株式会社 | 電子機器、及び電子機器の起動方法 |
US11277421B2 (en) * | 2018-02-20 | 2022-03-15 | Citrix Systems, Inc. | Systems and methods for detecting and thwarting attacks on an IT environment |
KR102511778B1 (ko) * | 2018-03-05 | 2023-03-21 | 삼성전자주식회사 | 전자 디바이스 및 전자 디바이스의 디지털 키 프로비저닝 수행 방법 |
JP7311245B2 (ja) | 2018-03-07 | 2023-07-19 | トヨタ自動車株式会社 | マスタ装置、マスタ、制御方法、プログラム及び車両 |
US10681020B2 (en) * | 2018-03-12 | 2020-06-09 | The Boeing Company | Blockchain fortified aircraft communications addressing and reporting system (ACARS) communication |
US11588878B2 (en) * | 2018-05-04 | 2023-02-21 | Bifrostconnect Aps | Remote support device |
EP3570578B1 (en) * | 2018-05-15 | 2021-12-22 | Volkswagen Aktiengesellschaft | Apparatus, method and computer program for determining information related to an authenticity of a wireless message in a wireless group communication among vehicles of a group of vehicles |
CN108777613A (zh) * | 2018-06-01 | 2018-11-09 | 杭州电子科技大学 | 物联网中传感信息虚拟服务的数据分块安全存储方法 |
CN111971984B (zh) * | 2018-06-13 | 2023-06-27 | 卧安科技(深圳)有限公司 | 低功耗蓝牙通信方法、电子设备、网络和存储介质 |
US11120137B2 (en) | 2018-06-19 | 2021-09-14 | Netgear, Inc. | Secure transfer of registered network access devices |
CN110659986B (zh) * | 2018-06-28 | 2022-07-19 | 本无链科技(深圳)有限公司 | 一种区块链的多账户协同打块的方法及系统 |
CN113393247A (zh) * | 2018-08-01 | 2021-09-14 | 北京洛必达科技有限公司 | 一种互联网区块链大数据处理系统 |
CN110798434B (zh) * | 2018-08-03 | 2022-04-08 | Emc Ip控股有限公司 | 计算机系统、计算装置所进行的方法和存储介质 |
US11100742B2 (en) * | 2018-08-23 | 2021-08-24 | Universal City Studios Llc | Unified access control system |
US10511443B1 (en) * | 2018-10-02 | 2019-12-17 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
EP3850510B1 (en) * | 2018-11-01 | 2023-12-27 | Hewlett-Packard Development Company, L.P. | Infrastructure device enrolment |
US10911899B2 (en) | 2018-11-07 | 2021-02-02 | Adero, Inc. | Providing indication to location of physical object using wireless tag |
US10945092B2 (en) | 2018-11-07 | 2021-03-09 | Adero, Inc. | Organizing physical objects using wireless tags |
US11138680B1 (en) | 2018-11-21 | 2021-10-05 | Square, Inc. | Updating menus based on predicted efficiencies |
US10938254B2 (en) * | 2018-12-18 | 2021-03-02 | Dell Products, L.P. | Secure wireless charging |
CN109474365A (zh) * | 2018-12-29 | 2019-03-15 | 深圳市柠檬互动科技有限公司 | 一种帧同步udp网络同步方法 |
EP3909276A1 (en) * | 2019-01-11 | 2021-11-17 | Telefonaktiebolaget Lm Ericsson (Publ) | 5g-4g authentication data coexistence |
CN109857101A (zh) * | 2019-01-11 | 2019-06-07 | 丰疆智慧农业股份有限公司 | 智能农机授权系统和方法 |
CN109687963B (zh) * | 2019-01-15 | 2021-06-22 | 如般量子科技有限公司 | 基于公钥池的抗量子计算联盟链交易方法和系统 |
US11295024B2 (en) | 2019-01-18 | 2022-04-05 | Red Hat, Inc. | Providing smart contracts including secrets encrypted with oracle-provided encryption keys using threshold cryptosystems |
US11593493B2 (en) | 2019-01-18 | 2023-02-28 | Red Hat, Inc. | Providing smart contracts including secrets encrypted with oracle-provided encryption keys |
US11177955B2 (en) * | 2019-01-23 | 2021-11-16 | Apple Inc. | Device-to-device messaging protocol |
US11316660B2 (en) * | 2019-02-21 | 2022-04-26 | Red Hat, Inc. | Multi-stage secure smart contracts |
US10666431B1 (en) * | 2019-03-11 | 2020-05-26 | Capital One Services, Llc | Systems and methods for enhancing web security |
US11329968B2 (en) * | 2019-03-18 | 2022-05-10 | Microsoft Technology Licensing, Llc | Authentication across decentralized and centralized identities |
US11341261B2 (en) * | 2019-04-05 | 2022-05-24 | Spideroak, Inc. | Integration of a block chain, managing group authority and access in an enterprise environment |
WO2020208913A1 (ja) * | 2019-04-11 | 2020-10-15 | 株式会社Nttドコモ | ネットワークノード |
CN110099065A (zh) | 2019-05-10 | 2019-08-06 | 北京百度网讯科技有限公司 | 物联网设备及认证方法、云服务器、处理设备、可读介质 |
US11956231B1 (en) * | 2019-05-30 | 2024-04-09 | Apple Inc. | Authority transfer for virtual objects in shared computer-generated reality environments |
US11677554B2 (en) * | 2019-06-01 | 2023-06-13 | Apple Inc. | Key registration transparency for secure messaging |
US20200403794A1 (en) * | 2019-06-21 | 2020-12-24 | Acton, Inc. | Electric vehicle with public and private keys pairs to cryptographically secure sensitive information relative to the electric vehicle |
CN114008972B (zh) * | 2019-06-27 | 2024-06-14 | 京瓷办公信息系统株式会社 | 图像形成装置、固件的篡改防止方法以及存储有篡改防止程序的计算机可读取的非瞬时性记录介质 |
US11451380B2 (en) | 2019-07-12 | 2022-09-20 | Red Hat, Inc. | Message decryption dependent on third-party confirmation of a condition precedent |
CN110620668B (zh) * | 2019-08-09 | 2022-11-15 | 如般量子科技有限公司 | 基于区块链的抗量子计算公钥池更新方法和系统 |
US12251201B2 (en) | 2019-08-16 | 2025-03-18 | Poltorak Technologies Llc | Device and method for medical diagnostics |
US20210067350A1 (en) * | 2019-09-04 | 2021-03-04 | Adero, Inc. | Presence and identity verification using wireless tags |
JP7318461B2 (ja) * | 2019-09-30 | 2023-08-01 | 株式会社リコー | 通信システム、通信端末、通信方法、通信端末のプログラムおよびアプリケーションプログラム |
US20220400019A1 (en) * | 2019-10-14 | 2022-12-15 | Vestas Wind Systems A/S | Secure data synchronization between offline and online systems |
CN110881026B (zh) * | 2019-10-15 | 2022-10-04 | 中国电力科学研究院有限公司 | 一种用于对信息采集终端用户进行身份认证的方法及系统 |
CN110765446B (zh) * | 2019-10-21 | 2023-09-12 | 深圳市神飞电子科技有限公司 | 一种电子设备授权许可分发方法 |
CA3160260A1 (en) * | 2019-12-06 | 2021-06-10 | Kapil Sachdeva | Methods & processes to securely update secure elements |
US20230198997A1 (en) * | 2019-12-09 | 2023-06-22 | Daniel Chien | Access control systems and methods |
KR102090911B1 (ko) | 2019-12-16 | 2020-03-19 | 주식회사 케이비시스 | 컨테이너 기반의 클라우드 서비스 제공 시스템 |
US11115819B2 (en) * | 2019-12-30 | 2021-09-07 | Itron, Inc. | Local authentication of communications device |
CN111193751B (zh) * | 2020-01-13 | 2022-02-08 | 临沂大学 | 一种恢复出厂设置的方法及设备 |
JP2021114116A (ja) * | 2020-01-17 | 2021-08-05 | パナソニックIpマネジメント株式会社 | 設備制御システム、制御方法、及びプログラム |
JP7331714B2 (ja) * | 2020-01-27 | 2023-08-23 | 富士通株式会社 | 情報処理装置、情報処理方法及びプログラム |
US11321489B2 (en) | 2020-03-03 | 2022-05-03 | The Prudential Insurance Company Of America | System for improving data security when storing data |
US11665159B2 (en) | 2020-04-22 | 2023-05-30 | Kyndryl, Inc. | Secure resource access by amalgamated identities and distributed ledger |
US11606349B2 (en) | 2020-06-02 | 2023-03-14 | Salesforce.Com, Inc. | Authentication token refresh |
US11394695B2 (en) * | 2020-07-02 | 2022-07-19 | Kpn Innovations, Llc. | Methods and systems for generating a secure communication channel interface for video streaming of sensitive content |
CN111541788B (zh) | 2020-07-08 | 2020-10-16 | 支付宝(杭州)信息技术有限公司 | 区块链一体机的哈希更新方法及装置 |
CN111541553B (zh) | 2020-07-08 | 2021-08-24 | 支付宝(杭州)信息技术有限公司 | 区块链一体机的可信启动方法及装置 |
CN111866000A (zh) * | 2020-07-24 | 2020-10-30 | 宁夏政安信息科技有限公司 | 计算机介质管理系统的账号密码管理方法 |
US11632244B2 (en) * | 2020-09-14 | 2023-04-18 | Paypal, Inc. | Techniques for single round multi-party computation for digital signatures |
US11522684B2 (en) | 2020-09-24 | 2022-12-06 | Capital One Services, Llc | Key rotation service |
CN112566119B (zh) * | 2020-11-30 | 2025-01-17 | 腾讯科技(深圳)有限公司 | 终端认证方法、装置、计算机设备及存储介质 |
US11533309B2 (en) * | 2020-12-28 | 2022-12-20 | Okta, Inc. | Digital signature injection for user authentication across multiple independent systems |
US12021861B2 (en) * | 2021-01-04 | 2024-06-25 | Bank Of America Corporation | Identity verification through multisystem cooperation |
US11503114B2 (en) | 2021-01-05 | 2022-11-15 | Toyota Motor North America, Inc. | Provisioning of event-based keys to transports |
US11438158B2 (en) | 2021-01-05 | 2022-09-06 | Toyota Motor North America, Inc. | Provisioning of external functionality to transports |
US11870557B2 (en) | 2021-01-05 | 2024-01-09 | Toyota Motor North America, Inc. | Process for generating transport keys for data communication based on actions performed by a transport |
US20220247576A1 (en) * | 2021-02-04 | 2022-08-04 | Fortanix, Inc. | Establishing provenance of applications in an offline environment |
US20220327003A1 (en) * | 2021-04-09 | 2022-10-13 | Oracle International Corporation | Cloud edge device virtualization |
US11831641B2 (en) | 2021-04-19 | 2023-11-28 | Capital One Services, Llc | Using tokens from push notification providers to enhance device fingerprinting |
US20220360568A1 (en) * | 2021-05-04 | 2022-11-10 | Facebook Technologies, Llc | Protecting real-time audio/visual communications end-to-end |
US12130953B2 (en) | 2021-08-05 | 2024-10-29 | International Business Machines Corporation | Secure guest image and metadata update |
US11943221B2 (en) | 2021-08-25 | 2024-03-26 | International Business Machines Corporation | Preventing masquerading service attacks |
US11405273B1 (en) * | 2021-09-22 | 2022-08-02 | Future Dial, Inc. | Network device data erasure |
US20230093749A1 (en) * | 2021-09-22 | 2023-03-23 | Apple Inc. | Secure Session Resumption |
JP7550124B2 (ja) | 2021-09-29 | 2024-09-12 | 株式会社デンソー | 車両用デジタルキーシステム、車両用デジタルキー管理方法、車両用装置、携帯端末 |
JP7605077B2 (ja) | 2021-09-29 | 2024-12-24 | 株式会社デンソー | 車両用デジタルキーシステム、車両用デジタルキー管理方法 |
JP7550125B2 (ja) | 2021-09-29 | 2024-09-12 | 株式会社デンソー | 車両用デジタルキーシステム、車両用デジタルキー管理方法、携帯端末 |
US11546358B1 (en) * | 2021-10-01 | 2023-01-03 | Netskope, Inc. | Authorization token confidence system |
CN116136913A (zh) * | 2021-11-18 | 2023-05-19 | 北京图森智途科技有限公司 | 一种服务发现方法、装置、计算设备和存储介质 |
US12015717B2 (en) | 2021-12-08 | 2024-06-18 | Bank Of America Corporation | System for processing offline digital resource transfers using a hardware device based cryptographic application |
US12231891B2 (en) * | 2022-01-12 | 2025-02-18 | T-Mobile Innovations Llc | Remote user device deauthentication |
CN114443304B (zh) * | 2022-01-28 | 2024-11-05 | 中国联合网络通信集团有限公司 | 云计算平台的安全认证方法、装置和计算机可读存储介质 |
US12225111B2 (en) * | 2022-03-08 | 2025-02-11 | SanDisk Technologies, Inc. | Authorization requests from a data storage device to multiple manager devices |
US20230297724A1 (en) * | 2022-03-15 | 2023-09-21 | Microsoft Technology Licensing, Llc | Hardware identity restoration post-device repair |
US11652696B1 (en) * | 2022-03-24 | 2023-05-16 | Red Hat, Inc. | Zoned mesh network isolation |
US12271478B2 (en) * | 2022-03-28 | 2025-04-08 | Lenovo Global Technology (United States) Inc. | Signed update package including a software update payload and compatibility data |
US20230354020A1 (en) * | 2022-04-27 | 2023-11-02 | Capital One Services, Llc | Systems and methods for context-switching authentication over short range wireless communication |
US11985124B2 (en) | 2022-06-02 | 2024-05-14 | Bank Of America Corporation | System for implementing multifactor authentication based on secure tokenization |
CN119422365A (zh) * | 2022-07-07 | 2025-02-11 | 高通股份有限公司 | 用于分配和使用特权以辅助交通工具的操纵和行驶的系统和方法 |
US11972300B2 (en) * | 2022-07-22 | 2024-04-30 | Oracle International Corporation | Techniques for managing edge device provisioning |
US12143492B2 (en) | 2022-08-04 | 2024-11-12 | Cisco Technology, Inc. | Method and apparatus for providing strong mutual authentication, encryption, and integrity for constraint devices without secure storage and PKI support |
CN115766130B (zh) * | 2022-11-02 | 2024-04-19 | 中国联合网络通信集团有限公司 | 一种会议加密方法、装置、电子设备及存储介质 |
CN116846575B (zh) * | 2022-11-30 | 2024-12-20 | 慧之安信息技术股份有限公司 | 一种基于区块链的物联网身份认证方法 |
US12107957B2 (en) | 2022-12-07 | 2024-10-01 | Credence ID, LLC | Point-of-service digital identity verification device |
US12013924B1 (en) * | 2022-12-07 | 2024-06-18 | Credence ID, LLC | Non-repudiable proof of digital identity verification |
US20250007730A1 (en) * | 2023-06-27 | 2025-01-02 | International Business Machines Corporation | Client-server response time based computer system geolocation |
CN117097570B (zh) * | 2023-10-19 | 2023-12-29 | 中国民航大学 | 一种基于云链融合的机载软件安全分发身份认证方法 |
Citations (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20040172396A1 (en) * | 2001-05-17 | 2004-09-02 | Marko Vanska | Remotely granting access to a smart environment |
US20060206709A1 (en) * | 2002-08-08 | 2006-09-14 | Fujitsu Limited | Authentication services using mobile device |
US20070106892A1 (en) * | 2003-10-08 | 2007-05-10 | Engberg Stephan J | Method and system for establishing a communication using privacy enhancing techniques |
US20120191242A1 (en) * | 2010-03-02 | 2012-07-26 | Christopher Scott Outwater | Method and apparatus for finding and accessing a vehicle fueling station, including an electric vehicle charging station |
CN102752298A (zh) * | 2012-06-29 | 2012-10-24 | 华为技术有限公司 | 安全通信方法、终端、服务器及系统 |
US20130179694A1 (en) * | 2012-01-05 | 2013-07-11 | Mohammed Alawi Geoffrey | System and method for electronic certification and authentication of data |
WO2016089846A1 (en) * | 2014-12-02 | 2016-06-09 | Carrier Corporation | Remote programming for access control system with virtual card data |
WO2016139301A1 (de) * | 2015-03-05 | 2016-09-09 | Volkswagen Aktiengesellschaft | Intelligenter elektronischer schlüssel mit mobilfunk-fähigkeit |
Family Cites Families (21)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6839759B2 (en) * | 1998-10-30 | 2005-01-04 | Science Applications International Corp. | Method for establishing secure communication link between computers of virtual private network without user entering any cryptographic information |
WO2001084761A1 (en) * | 2000-04-28 | 2001-11-08 | Swisscom Mobile Ag | Method for securing communications between a terminal and an additional user equipment |
FI20002255A (fi) | 2000-10-13 | 2002-04-14 | Nokia Corp | Menetelmä lukkojen hallintaan ja kontrollointiin |
JP2004140706A (ja) | 2002-10-18 | 2004-05-13 | Toshiba Corp | 車載用通信装置 |
ES2297338T3 (es) | 2004-04-30 | 2008-05-01 | Research In Motion Limited | Autentificacion criptografica de un dispositivo. |
JP2006083604A (ja) | 2004-09-16 | 2006-03-30 | Auto Network Gijutsu Kenkyusho:Kk | データ読取装置および車載機器無線制御システム |
JP2006321452A (ja) * | 2005-05-20 | 2006-11-30 | Yamaha Motor Co Ltd | 鞍乗型車両の車両制御装置 |
JP2007162309A (ja) | 2005-12-13 | 2007-06-28 | Tokai Rika Co Ltd | リモートコントロールキーシステム |
CN101051898B (zh) | 2006-04-05 | 2010-04-21 | 华为技术有限公司 | 无线网络端到端通信认证方法及其装置 |
JP4821837B2 (ja) | 2008-11-18 | 2011-11-24 | Necアクセステクニカ株式会社 | 無線通信装置、無線通信方法、無線通信プログラム |
EP2377267B1 (en) | 2008-12-04 | 2018-06-06 | Saab AB | Key issuer, key carrier, access unit and methods performed in said units |
JP2011012511A (ja) * | 2009-07-06 | 2011-01-20 | Kesaka System Inc | 電気錠制御システム |
US11042816B2 (en) | 2009-10-30 | 2021-06-22 | Getaround, Inc. | Vehicle access control services and platform |
EP2424185B1 (en) * | 2010-08-23 | 2014-10-22 | 3M Innovative Properties Co. | Method and device for challenge-response authentication |
JP2013257653A (ja) | 2012-06-11 | 2013-12-26 | Toyota Infotechnology Center Co Ltd | カーシェアリングシステム、通信端末、通信プログラムおよび通信方法 |
DE102012012389A1 (de) * | 2012-06-21 | 2013-01-24 | Daimler Ag | Vorrichtung und Verfahren zum Steuern einer Zugangsberechtigung und/oder Fahrberechtigung für ein Fahrzeug |
US20140064488A1 (en) * | 2012-08-30 | 2014-03-06 | Texas Instruments Incorporated | One-Way Key Fob and Vehicle Pairing |
JP6419588B2 (ja) * | 2015-01-19 | 2018-11-07 | 株式会社東海理化電機製作所 | 携帯端末追加登録システム |
JP2016184875A (ja) * | 2015-03-26 | 2016-10-20 | 美和ロック株式会社 | 鍵データ通信システム |
US10402792B2 (en) * | 2015-08-13 | 2019-09-03 | The Toronto-Dominion Bank | Systems and method for tracking enterprise events using hybrid public-private blockchain ledgers |
US10693658B2 (en) * | 2016-02-12 | 2020-06-23 | Visa International Service Association | Methods and systems for using digital signatures to create trusted digital asset transfers |
-
2017
- 2017-10-27 EP EP17866003.1A patent/EP3532971A4/en active Pending
- 2017-10-27 JP JP2019521454A patent/JP6888673B2/ja active Active
- 2017-10-27 CN CN201780065045.9A patent/CN109891416A/zh active Pending
- 2017-10-27 WO PCT/US2017/058792 patent/WO2018081583A1/en unknown
- 2017-10-27 US US15/796,180 patent/US10313134B2/en active Active
-
2019
- 2019-04-26 US US16/395,736 patent/US10771263B2/en active Active
-
2020
- 2020-09-02 US US17/010,315 patent/US11895247B2/en active Active
- 2020-11-18 JP JP2020191808A patent/JP2021040330A/ja active Pending
-
2022
- 2022-12-28 JP JP2022211220A patent/JP2023036897A/ja active Pending
-
2024
- 2024-01-08 US US18/406,758 patent/US20240205027A1/en active Pending
- 2024-11-27 JP JP2024206365A patent/JP2025028992A/ja active Pending
Patent Citations (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20040172396A1 (en) * | 2001-05-17 | 2004-09-02 | Marko Vanska | Remotely granting access to a smart environment |
US20060206709A1 (en) * | 2002-08-08 | 2006-09-14 | Fujitsu Limited | Authentication services using mobile device |
US20070106892A1 (en) * | 2003-10-08 | 2007-05-10 | Engberg Stephan J | Method and system for establishing a communication using privacy enhancing techniques |
US20120191242A1 (en) * | 2010-03-02 | 2012-07-26 | Christopher Scott Outwater | Method and apparatus for finding and accessing a vehicle fueling station, including an electric vehicle charging station |
US20130179694A1 (en) * | 2012-01-05 | 2013-07-11 | Mohammed Alawi Geoffrey | System and method for electronic certification and authentication of data |
CN102752298A (zh) * | 2012-06-29 | 2012-10-24 | 华为技术有限公司 | 安全通信方法、终端、服务器及系统 |
WO2016089846A1 (en) * | 2014-12-02 | 2016-06-09 | Carrier Corporation | Remote programming for access control system with virtual card data |
WO2016139301A1 (de) * | 2015-03-05 | 2016-09-09 | Volkswagen Aktiengesellschaft | Intelligenter elektronischer schlüssel mit mobilfunk-fähigkeit |
Cited By (18)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN110991622B (zh) * | 2019-08-22 | 2021-06-04 | 腾讯科技(深圳)有限公司 | 基于区块链网络的机器学习模型处理方法及节点 |
CN110991622A (zh) * | 2019-08-22 | 2020-04-10 | 腾讯科技(深圳)有限公司 | 基于区块链网络的机器学习模型处理方法及节点 |
CN110784461B (zh) * | 2019-10-23 | 2020-05-12 | 北方工业大学 | 一种基于区块链的安全6LoWPAN通信方法及系统 |
CN110784461A (zh) * | 2019-10-23 | 2020-02-11 | 北方工业大学 | 一种基于区块链的安全6LoWPAN通信方法及系统 |
US11847201B2 (en) | 2019-11-19 | 2023-12-19 | Micron Technology, Inc. | Authenticating a device using a remote host |
CN114730332B (zh) * | 2019-11-19 | 2023-10-20 | 美光科技公司 | 使用远程主机以认证装置 |
CN114730332A (zh) * | 2019-11-19 | 2022-07-08 | 美光科技公司 | 使用远程主机以认证装置 |
CN110865608A (zh) * | 2019-11-21 | 2020-03-06 | 武夷学院 | 一种可重构制造系统 |
CN111460499A (zh) * | 2020-03-31 | 2020-07-28 | 中国电子科技集团公司第三十研究所 | 一种保护隐私的基于Merkletree的区块链用户属性集核验方法 |
CN111639020A (zh) * | 2020-05-06 | 2020-09-08 | 贝壳技术有限公司 | 一种程序漏洞复现方法、系统、装置、电子设备及其存储介质 |
CN112187459B (zh) * | 2020-10-09 | 2022-08-16 | 安徽大学 | 一种智能网联车中模块间的可信认证方法及系统 |
CN112187459A (zh) * | 2020-10-09 | 2021-01-05 | 安徽大学 | 一种智能网联车中模块间的可信认证方法及系统 |
CN112218279A (zh) * | 2020-10-14 | 2021-01-12 | 福建小飞科技有限公司 | 一种多协议的手持终端对展示终端的控制方法及设备 |
CN114152460A (zh) * | 2021-11-30 | 2022-03-08 | 四川虹美智能科技有限公司 | 智能空调的生产检测系统和方法 |
CN114152460B (zh) * | 2021-11-30 | 2023-04-21 | 四川虹美智能科技有限公司 | 智能空调的生产检测系统和方法 |
CN117093969A (zh) * | 2023-08-22 | 2023-11-21 | 上海合芯数字科技有限公司 | 调试授权方法及系统 |
CN117093969B (zh) * | 2023-08-22 | 2024-06-04 | 上海合芯数字科技有限公司 | 调试授权方法及系统 |
CN119293775A (zh) * | 2024-12-10 | 2025-01-10 | 浙江吉利控股集团有限公司 | 设备的访问验证方法、车辆、电子设备及计算机存储介质 |
Also Published As
Publication number | Publication date |
---|---|
US20180123804A1 (en) | 2018-05-03 |
JP6888673B2 (ja) | 2021-06-16 |
US20200403808A1 (en) | 2020-12-24 |
US10771263B2 (en) | 2020-09-08 |
JP2023036897A (ja) | 2023-03-14 |
US10313134B2 (en) | 2019-06-04 |
JP2019536329A (ja) | 2019-12-12 |
US11895247B2 (en) | 2024-02-06 |
JP2025028992A (ja) | 2025-03-05 |
EP3532971A4 (en) | 2019-11-06 |
US20190253262A1 (en) | 2019-08-15 |
EP3532971A1 (en) | 2019-09-04 |
WO2018081583A1 (en) | 2018-05-03 |
US20240205027A1 (en) | 2024-06-20 |
JP2021040330A (ja) | 2021-03-11 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN109891416A (zh) | 用于认证和授权装置的系统和方法 | |
JP7436568B2 (ja) | ブロックチェーンにより実現される方法及びシステム | |
US12238224B2 (en) | Method, apparatus, and computer-readable medium for authentication and authorization of networked data transactions | |
EP3593482B1 (en) | Secure de-centralized domain name system | |
US11456879B2 (en) | Secure processing of an authorization verification request | |
US20190034919A1 (en) | Securing Electronic Wallet Transactions | |
CN110601858B (zh) | 证书管理方法及装置 | |
WO2020170976A1 (ja) | 認可システム、管理サーバおよび認可方法 | |
CN116980163A (zh) | 基于可信执行环境的数据处理方法、装置、设备及介质 | |
CN101321063A (zh) | 基于数字证书技术的系统用户访问管理系统及方法 | |
Arm et al. | Check for updates Offline Access to a Vehicle via PKI-Based Authentication | |
CN117220898A (zh) | 一种基于区块链的数据处理方法、设备以及可读存储介质 | |
JP2014045233A (ja) | 電子証明書発行方法 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination |