Patent ID: 12192380

DETAILED DESCRIPTION

Embodiments are described more fully below with reference to the accompanying drawings, which form a part hereof, and which show specific exemplary embodiments. However, embodiments may be implemented in many different forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope. Embodiments may be practiced as methods, systems or devices. Accordingly, embodiments may take the form of an entirely hardware implementation, an entirely software implementation or an implementation combining software and hardware aspects. The following detailed description is, therefore, not to be taken in a limiting sense.

The logical operations of the various embodiments are implemented (1) as interconnected machine modules within the computing system and/or (2) as a sequence of computer implemented steps running on a computing system. The implementation is a matter of choice dependent on the performance requirements of the computing system implementing the invention. Accordingly, the logical operations making up the embodiments described herein are referred to alternatively as operations, steps or modules.

Aspects of the disclosure pertains to computer systems and methods that enable trusted communications between two entities. More particularly, the present disclosure relates to computer systems and methods where a recipient of a communication may process the communication after receiving a confirmation that an entity other than the sender has deemed the communication to be trustworthy. Further, the disclosed systems and methods may be capable of controlling an entity's ability to communicate with other entities in real time. In embodiments that leverage public-key cryptography, the disclosed systems and methods may be capable of remotely adding, removing, revoking, or replacing one or more digital keys stored on, or accessible by, various entities. There are several potential applications for this technology, and the scope of this disclosure is not intended to be limited to any particular business concern.

FIG.1illustrates an example of a system100in which concepts consistent with the principles of the invention may be implemented. System100includes one or more clients110that are associated with at least one server group125. A server group125is a logical grouping of one or more servers120. System100further includes at least one central server130associated with server group125. Clients110, servers120in server group125, and central server130may be collectively referred to as a “project.” Clients110can connect to servers120in the associated server group125via network115. Servers120in server group125can connect to central server130via network135. Network115and/or network135may be or include, along or in conjunction, an intranet, the Internet, a local-area network (LAN), a wide-area network (WAN), or others. In system100, clients110are shown to be associated with a single server group125. However, in some embodiments, one or more clients110may be associated with, and can connect to, a plurality of server groups. Further in system100, central server130is shown to be associated with a single server group125. However, in some embodiments, central server130may be associated with a plurality of server groups, and/or a single server group125may be associated with a plurality of central servers.

Various resources may be shared among servers120in server group125. In system100ofFIG.1, for example, each server122may access a common data store142and a policy server144. Data store142may be, for example, a hardware security module (HSM), a database server, or a network-attached storage (NAS). Data store142may store, for example, digital keys that needs to be shared among servers120. A policy server144may include information relating to system100's policy. For example, policy server144may include information that can be used to determine which entities are authorized to communicate with other entities in system100. In another example, policy server144may include information that can be used to determine whether one or more entities are currently active, deactivated, or removed in system100. InFIG.1, the shared resources are shown to be shared among servers120in a single server group125; however, in some embodiments, the shared resources may be shared among servers across a plurality of server groups. Additionally, or alternatively, the resources may be further shared with one or more clients110and/or central server130.

An entity (e.g., client112, server122, or central server130) may be implemented on one or more physical or virtual machines having, or having access to, a processor, memory, and a storage device. Alternatively, or additionally, an entity may be implemented on a cloud platform, such as, but not limited to, Amazon Web Services (AWS), Google Cloud Platform, and Microsoft Azure. In some embodiments, a set of physical and/or virtual machines may implement two or more of clients110, servers120, and central server130. In some embodiments, server122, and/or central server130may be implemented on one or more gateways.

At least some of the communications between a client112and server122may be communicated as trusted communications that have been deemed trustworthy by at least one entity other than the client112and the server122, such as central server130. For example, upon receiving a communication from client112, server122may forward the communication to central server130and receive a confirmation that central server130has deemed the communication to be trustworthy. In this example, server122may process (or finish processing) the communication after receiving the confirmation. In another example, upon receiving a communication from server122, client112may process (or finish processing) the communication after confirming that central server130has deemed the received communication to be trustworthy.

These confirmations that central server130has deemed the communication trustworthy may add additional layers of security to system100that make the system more difficult for attackers to breach. For example, compared to conventional systems, attackers may need to gain access to more entities and/or coordinate a more complex attack to breach system100.

In some embodiments, all communications between client112and server122may be communicated as trusted communications. Alternatively, a subset of the communications between client112and server122may be communicated as trusted communications. In some embodiments, communications that include a predetermined type(s) of data (e.g., sensitive information) may be communicated as trusted communications. For example, communications to clients110that include firmware updates may be communicated as trusted communication.

In some embodiments, at least some of the communications between client112and server122may be trusted communications that have been independently deemed to be trustworthy by a plurality of central servers. In some embodiments, at least some of the communications between client112and server122may be trusted communications that have been independently deemed trustworthy by central server130and at least one other entity (e.g., another server). In some embodiments, at least some of the communications between client112and server122may be trusted communications that have been independently deemed trustworthy by central server130and the recipient of the communications.

Central server130may deem that a communication is trustworthy after verifying that at least a portion of information included in the communication is correct. For example, central server130may verify that the sender identified in the communication is indeed the sender of the communication. In some embodiments, central server130may deem that a communication is trustworthy based on a policy associated with system100. For example, central server130may verify, by accessing a policy server (e.g., policy server144or another policy server), that the sender of the communication is authorized to send a communication and/or that the recipient is authorized to receive a communication from the sender. In some embodiments, central server130may deem that a communication is trustworthy after inspecting the content of the communication. For example, central server130may verify that the communication does not include any known malicious software code or instructions. In another example where the communication includes a firmware and a checksum for the firmware, central server130may verify that the checksum for the firmware is correct. Moreover, central server130may deem that a communication is trustworthy after verifying that the sender and/or the recipient of the communication is not included in one or more blacklists. The blacklists may include server-group-wide blacklists, system-wide blacklists, and/or global blacklists.

Furthermore, central server130may deem that a communication is trustworthy after verifying that the sender and/or the recipient of the communication is an active entity in system100. For example, central server130may access a list identifying active entities to determine whether the sender and/or the recipient is an active entity. If client112and/or server122has been deactivated (i.e., identified in the list as being inactive) or removed from system100(i.e., missing from the list), central server130may not provide a confirmation to the recipient that the communication is trustworthy. Therefore, by simply listing client112or server122as being inactive or removing client112or server122from the list, client112or server122may be immediately prevented from communicating with other entities in system100. This capability of system100may be useful, for example, when a client112or server122is compromised, to be retired, or temporarily/permanently removed from system100.

In embodiments where the communication is forwarded to one or more entities other than central server130to be independently determined as being trustworthy, such entities may perform the same process or a different process as central server130before determining that the communication is trustworthy.

In some embodiments, a client112may directly connect to a specific server122in server group125. For example, client112may connect to a specific server122using an IP address or an identifier that is unique to the server122. In other embodiments, a gateway may be associated with server group125, and the gateway may dynamically assign one of servers120in server group125to receive and/or process the communication from client112. For example, client112, prior to sending a communication, may request an IP address or an identifier of an assigned server122from the gateway. Alternatively, or additionally, client112may transmit the communication to the gateway, and the gateway may forward the communication to a server122. The gateway may assign a server122based on variety of factors, including, but not limited to, the amount of resources available to servers120, network distance/cost between client112and servers120, whether a server120handled prior communications from client112, and whether a server120has access to the required resources. In some embodiments, client112may transmit a communication to a server in server group125, but receive a response from another server in server group125. Client112may or may not have access to the identity of server122that received the communication.

IoT Deployments

FIG.2illustrates an example of a system200in which additional concepts consistent with the principles of the invention may be implemented. System200is similar to system100ofFIG.1, except that system200illustrates various types of internet-of-things (IoT) clients (or devices)110that can be deployed in various environments, such as a home210, office building220, and vehicle230. For example, in home210ofFIG.2, clients110such as a smart appliance (e.g., refrigerator)112a, smart thermostat112b, and a portable electronic device112care deployed. Office building220may include clients110such as a door/gate control device, a coffee machine, and a parking spot sensor (not shown). In vehicle230, clients110such as an entertainment device112d, a smart tire-pressure sensor112e, or a vehicle diagnostic system (not shown) may be deployed.

InFIG.2, servers120in server group125and central server130are shown to be physically located away from clients110that are deployed in home210, office building220, and vehicle230. Therefore, clients110may connect to servers120via the Internet240, as shown, or via a private wide-area network (WAN). However, in some embodiments, one or more of servers120in server group125and/or central server130may be located nearby clients110and connected to each other via a local-area network (LAN), such as a Wi-Fi network. In these embodiments, servers120and/or central server130may be located in a secure area. For example, servers120and/or central server130may be located in an area of Office Building220that is not accessible to public. As shown inFIG.2, central server130may be deployed on a cloud platform as a service.

InFIG.2, servers120and central server130are shown to be communicating via the Internet. In some embodiments, however, servers120and central server130may communicate via a private network. In some embodiments, servers120and central server130may be implemented on the same cloud platform.

In system200, clients110are shown to be implemented on devices/components that are interfacing with, or operating near, a user. In some embodiments, servers120may be implemented on a device or component that interfaces with, and/or or operates near, a user. One of ordinary skill in the art will appreciate that whether a device/component is functioning as a server or a client often depends on the specific application being implemented and the client-server relationship.

In some embodiments, central server130may be implemented to provide Identity as a Service (IDaaS) providing authentication and/or verification of device, server, and user identities in Internet-of-Things (IoT) applications. In addition, various interfaces (e.g., management portal and/or command-line interface) may be provided to identify breaches in system200and/or provide complete management of identities in IoT systems (e.g., provisioning, revocation, etc.).

In some embodiments, central server130and/or servers120may be implemented on one or more public cloud platforms that can be accessible over the Internet. Alternatively, there may be instances where the administrator wants to have direct control over central server130and/or servers120. In these embodiments, one or more of central server130and/or servers120may be implemented on a private cloud platform that may not be accessible by entities outside a private network that the private cloud platform is a part of.

For locations with no or limited connectivity, central server130and/or servers120may be implemented on a local network. For example, for a system used in an oil rig that is offshore with unstable network/Internet connections, central server130and server122may be implemented on one or more physical host deployed in a local network of the oil rig.

In instances where a low latency communication is needed, central server130and/or servers120may be implemented on gateways or servers that are close to the network edge while still having access to a cloud platform. In fog deployments where the cloud platform can extend into a private network, central server130and/or server120may be positioned in a network location to meet the latency requirements. A low latency may be needed, for example, for a system deployed in a “smart city.” An end point client such as a signal light in the “smart city” may need to respond very quickly to communications sent from various entities in the system. In some embodiments, central server130and/or server122may be implemented on a cloud platform, which may be replicated in part or in entirety to one or more physical hosts deployed on a local network with clients110.

FIG.3illustrates an example of a system300which is similar to system100ofFIG.1, except that system300leverages public-key cryptography to enable trusted communications between clients110and servers120.

In system300, public/private key pairs are generated for each entity using a public-key cryptography algorithm, such as an RSA. The generated private key is typically kept within the entity that generated the key pair, but the public key may be distributed throughout system300so that various entities may access them.FIG.3illustrates private and public keys that can be accessed by various entities in system300.

While public/private key pairs have many different uses, in system300, a private key may be used to generate a digital signature based on given data (i.e., to “sign the data”), and a corresponding public key (i.e., a public key that was generated with the private key using the public-key cryptography algorithm) may be used to verify that the generated digital signature is indeed generated by an entity that has access to the corresponding private key. Additionally, the corresponding public key may be used to further verify that the data has not been altered since the digital signature was generated.

A digital signature may be generated in numerous ways. In one example, a digital signature may be generated by encrypting a hash value of given data using a private key. In this example, a corresponding public key may be used to decrypt the digital signature and obtain the hash value of the original data. Thus, if the decrypted digital signature matches the hash value of the received data, it may prove that 1) the data was signed with a private key that corresponds to the public key, and 2) the data has not changed since it was signed. However, if the decrypted digital signature does not match the hash value of the received data, the data has been altered and/or the digital signature was created with a private key that does not correspond to the public key. In some embodiments, a digital signature may be generated by encrypting metadata (e.g., checksum) of given data using a private key.

In another example, a digital signature may also be generated by encrypting a portion or all of the given data using a private key. Here, a corresponding public key may be used to decrypt the digital signature to obtain the portion of, the data or the entire data. Subsequently, the decrypted digital signature may be compared to the received data to determine (1) that the data was signed with a private key that corresponds to the public key, and (2) that the data has not changed since it was signed. It may be advantageous in terms of performance, however, to generate a digital signature based on a hash value rather than a portion or all of the given data because the size of a hash value is typically smaller than the size of the data.

In system300ofFIG.3, each client112has access to its own private key312, a central server130's public key314, and server group125's public key316. While client112is shown to store these keys within client112inFIG.3, in some embodiments, client112may store at least some of the keys in a storage component separate from client112. For example, at least some of these keys may be stored in an HSM. In some embodiments, client112may not have direct access to at least some of the keys. Instead, client112may request a separate signature processor to generate and/or verify digital signatures using the keys that are accessible by the signature processor. For example, client112may send data to a signature processor, and the signature processor may return a signature that is generated using the private key associated with client112. In another example, client112may send data and a digital signature to a signature processor, and the signature processor may return a confirmation that the digital signature has been verified using one of the public keys accessible by the signature processor. A different signature processor may be used by each client112in system300. Alternatively, a signature processor may be shared by a plurality of clients110. In some embodiments, a signature processor may be a secure element or trusted platform module (TPM). For example, the signature processor may be a tamper-resistant chip integrated that may be used for secure data storage or running a trusted execution environment (TEE).

In some embodiments, client112's private key312and its corresponding public may be associated with software or hardware of client112. For example, private key312may be associated with the physical computer, the operating system, or the client software implementing client112's function. In these embodiments, private key312and its corresponding public key may be referred to as “device keys.” Device keys may be used to generate and verify digital signatures (i.e., asserting and verifying device's identity).

In some embodiments, client112's private key312and its corresponding public may be associated with a user that is currently using client112. In these embodiments, private key312and its corresponding public key may be referred to as “user keys.” User keys may be used to generate and verify digital signatures (i.e., asserting and verifying user's identity).

In some embodiments, client112may have access to a plurality of private keys. In some embodiments, the plurality of private keys may include a device private key and a user private key.

Further in system300, each server122in server group125may have access to its own private key322, central server130's public key314, and server group125's private key324. In some embodiments, each server122in server group125may further have access to public keys334of clients110. InFIG.2, these keys are shown to be stored within server122. However, in some embodiments, at least some of these keys may be stored in a storage component separate from server122. For example, at least some of these keys may be stored in data store142. Alternatively, or additionally, server122may not have direct access to at least some of the keys. Instead, server122may request a separate signature processor to generate or verify digital signatures using some of the keys that are stored in the signature processor. A separate signature processor may be used by each server122. Alternatively, a signature processor may be shared by a plurality of servers120.

As shown inFIG.3, each server122also has access to server group125's private key324, which is shown to be stored in data store142. However, in some embodiments, each server122may have a local copy of server group125's private key324. In some embodiments, servers120′ access to server group's private key324may be limited. For example, server122's access to private key324may be based on policies associated with system300. Policies may define, for example, a time period and frequency that a server122can access private key324. In another example, server122's access to private key324may be granted after verifying that server122is indeed associated with server group125. In yet another example, server122's access to server group125's private key324may be granted after verifying that server122is an active server in system300and/or that server122is not listed in any blacklist. Alternatively, or additionally, server122may not have direct access to private key324. Instead, server122may request a separate signature processor to generate or verify digital signatures using keys that are accessible by the signature processor.

Central server130may have access to its own private key332, public keys334of clients110, and public keys336of servers120. InFIG.3, the keys are shown to be stored within central server130. However, in some embodiments, at least some of these keys may be stored in a storage component separate from central server130. In some embodiments, at least some of the keys stored in the storage component may be shared with one or more of clients110and servers120. Alternatively, or additionally, central server130may not have direct access to at least some of the keys. Instead, central server130may request a separate signature processor to generate or verify digital signatures using some of the keys that are stored in the signature processor.

In embodiments where each client112has a plurality of private keys, public keys334of clients110may include public keys corresponding to each client112's plurality of private keys.

As shown inFIG.3, central server130is shown to have access to public keys334of all clients and public keys336of all servers in system300. However, in some embodiments, system300may include a plurality of central servers, each central server having access to public keys of a subset of clients110and servers120.

As discussed above, clients120, servers120in server group125, and central server130may be collectively referred to as a “project.” Further, server group125's private key324and public key316may also be referred to as a project private key and a project public key, respectively.

End-to-End Trust for Connected Devices

FIG.4is a flow diagram of an example process400for sending a trusted communication from a client112to a server122in which concepts consistent with the principles of the invention may be implemented. As shown inFIG.4, steps402,404, and406may be implemented by client112; steps408,410,420,422,424, and426by server122; and steps414,414,416, and418by central server130. However, in some embodiments, steps402,404, and406may be implemented by server122and steps408,410,420,422,424, and426may be implemented by client112. In some embodiments, steps402,404, and406may be implemented by client112and steps408,410,420,422,424, and426may be implemented by another client. In some embodiments, steps402,404, and406may be implemented by server122and steps408,410,420,422,424, and426may be implemented by another server.

At a step402, client112may obtain data to be sent to server122. In some embodiments, the data may be generated by client112. Alternatively, or additionally, client112may retrieve or receive the data that was obtained or generated by one or more devices or components that are associated with, and/or connected to, client112. For example, client112may retrieve or receive sensor data from a sensor component connected to client112.

The data may be any data that client112can access. For example, in system200ofFIG.2, smart refrigerator112amay obtain data that includes a current temperature inside the refrigerator and/or the number of times the door has been opened per hour. Smart thermostat112bmay obtain data that includes, for example, the current room temperature and/or the configuration data, such as a heating/AC schedule. In another example, tire pressure sensor112emay obtain data that includes raw sensor data.

In some embodiments, the data may be provided by a user. For example, a user may provide data directly to client112via a user interface connected to client112. Alternatively, or additionally, a user may provide data indirectly to client112, for example, by causing the data to be transmitted to client112or by causing client112to retrieve the user-generated data from another entity.

In some embodiments, the data may include information identifying the sender (i.e., client112) and/or the intended recipient(s). In some embodiments, the data may include a set of data. Further, the set of data may include data obtained from a plurality of sources or generated by a plurality of entities.

In some embodiments, the obtained data may be encrypted. For example, the obtained data may be encrypted using Elliptic Curve Diffie-Hellman (ECDH) algorithm, and only intended recipient or a plurality of recipients may decrypt the data.

In some embodiments, the obtained data may include expiration date/time associated with the data and/or unique nonce data.

At a step404, client112may obtain a client signature. In some embodiments, the client signature may be generated based on at least a portion of the obtained data using client112's private key312. For example, client112may generate the client signature by generating a hash value of the obtained data and encrypting the generated hash with client112's private key312. In some embodiments, client112may generate the client signature by encrypting a portion or all of the data to be sent to server120using client112's private key312.

A client signature may be a digital signature generated using client112's private key312. However, in some embodiments, the client signature may be any information that can be used by servers120and/or central server130to verify that the data is indeed sent by client112and/or that the data has not been altered after the data was transmitted by client112. For example, the client signature may be a passcode associated with client112. A digital signature, however, is preferable over the passcode as the passcode may be compromised, for example, when the data is intercepted. In another example, the client signature may be a hash value of the obtained data. The digital signature may be generated by client112. Alternatively, client112may obtain the digital signature from another component such as a signature processor.

In embodiments where client112has access to a plurality of private keys, client112may generate a client signature based on the plurality of private keys. Alternatively, client112may generate a plurality of client signatures based on the plurality of private keys.

At a step406, client112may transmit a communication. The communication may be destined for server122. Further, the communication may include the generated client signature and/or the obtained data. In embodiments where the client signature is an encrypted version of the entire data, the communication may include the generated client signature without the data. As discussed above in reference toFIG.1, the communication may be transmitted directly to a specific server122, for example, by using a identifier or an electronic address (e.g., IP address) associated with server122. Alternatively, also as discussed above, the communication may be sent to a gateway associated with server group125, and the gateway may forward the communication to one of the servers120in server group120. In some embodiments, the communication may include additional data other than the obtained data and the generated client signature. For example, the communication may include, in addition to the obtained data and the generated client signature, identification of the algorithm used to generate the client signature.

In embodiments where client112generated a plurality of client signatures, the communication may include the plurality of client signatures.

At a step408, server122may receive the communication.

At a step410, server122may transmit the client signature to central server130. In some embodiments, server122may further transmit the data to central server130. In some embodiments, server122may transmit the entire communication that was received from client112to central server130.

In some embodiments, server122may further transmit the client signature, the data, and/or the remaining portion of the communication to at least one other server and/or at least one other central server.

At a step412, central server130may receive the client signature. In some embodiments, central server130may further receive the data. In some embodiments, server112may receive the entire communication that server122received form client112.

At a step414, central server130may verify the client signature. In some embodiments, central server130may verify the client signature by generating a hash value of the received data, decrypting the client signature using client112's public key334, and comparing the decrypted signature with the generated hash value of the received data. A match between the decrypted client signature and the generated hash value of the received data may indicate to central server130that 1) the sender of the data had access to client112's private key312, and 2) the data has not been altered since the data was signed by the sender. If only client112is assumed to have access to client112's private key312, the match may further indicate to central server130that client112is indeed the sender of the data. If the decrypted client signature and the generated hash value of the received data do not match, central server130may halt process400. That is, the communication may “die on the vine.” In some embodiments, if the decrypted client signature and the generated hash value of the received data do not match, central sever130may notify server122that the communication from client112is not deemed trustworthy. Alternatively, central server130may not notify server122. In some embodiments, central server130may save the client signature and/or the data for further examination, for example, by a system administrator or a security analysis software.

In embodiments where the client signature is an encrypted version of a portion or the entire data, central server130may verify the client signature by decrypting the client signature using client112's public key334and comparing the decrypted client signature with a portion or all of the received data.

In embodiments where a plurality of client signatures is received, central server130may verify at least one client signature. In some embodiments, central server130may verify all of the plurality of client signatures.

At a step416, central server130may obtain a central-server signature generated based on at least a portion of the data using central server130's private key332. For example, the central-server signature may be generated by generating a hash value of the data and encrypting the hash value with central server130's private key332. In some embodiments, central server130may generate a central-server signature based on both the data and the client signature. In embodiments where the entire communication was transmitted to central server130, central server130may generate a central-server signature based the entire communication. In embodiments where the client signature is an encrypted version of a portion or the entire data, the central-server signature may be generated based on a portion or all of the decrypted client signature.

In system300, a central-server signature is a digital signature generated using central server130's private key332. However, in some embodiments, the central-server signature may be any information that can be used by servers120and clients110to confirm that central server130has deemed the communication as being trustworthy. For example, the central-server signature may be a passcode associated with central server130. In some embodiments, the central-server signature may simply be an identifier of central server130. A digital signature, however, is preferable over a passcode or an identifier because the passcode and identifier may be compromised or already known by public.

In some embodiments, central server130may log that the central-server signature has been generated. The log may include at least a portion of the data and/or the client signature.

At a step418, central server130may transmit the central-server signature to server122. In some embodiments, central server130may further transmit the data and/or the client signature. In some embodiments, central server130may further transmit the entire communication sent by client112.

In some embodiments, central server130may transmit the central-server signature after determining that the received data is in accordance with policies associated with system300. For example, central server130may verify, by accessing a policy server (e.g., policy server344), that client112is authorized to send a communication to server122and/or that server122is authorized to receive a communication from client130. A policy may also define, for example, a time period and frequency at which client112and server122may communicate. If central server130determines that the received data is not in accordance with the policies associated with system300, central server130may halt process400and/or notify server122.

In some embodiments, central server130may transmit the central-server signature after inspecting the content of the communication or the received data. For example, central server130may verify that the communication does not include any known malicious software code or instructions. If malicious software code or instructions are detected, central server130may halt process400and/or notify server122.

In some embodiments, central server130may have access to a list of active entities in system300and may transmit the central-server signature after verifying that client112and/or server122is listed as being active. If one or both of client112and server122are listed as being inactive or missing from the list, central server130may halt process400and/or notify server122. Therefore, in these embodiments, by simply listing client112or server122as being inactive or removing client112or server122from the list, client112or server122may be immediately prevented from communicating with other entities. In some embodiments, a user, an administrator, and/or an owner of a system (or a project) may use a management portal to manipulate the list of active entities and immediately prevent an entity from communicating.

In embodiments where server122transmitted the client signature, the data, and/or the remaining portion of the communication to at least one server other than122, each server that receives the client signature, the data, and/or the remaining portion of the communication may verify the receive client signature. In some embodiments, each server may verify the client signature using its own copy of client112's public key. Further, each server may transmit a digital signature generated using each server's private key to central server130. In these embodiments, central server130may transmit the central-server signature after verifying each of the digital signature received.

At a step420, server122may receive the central-server signature. In some embodiments, server122may further receive the data and/or the client signature. In some embodiments, central server130may further receive the entire communication. In embodiments where server122transmitted the client signature, the data, and/or the remaining portion of the communication to at least one central server other than central server130, server122may receive additional central-server signatures from the other central server(s).

At a step422, server122may verify the central-server signature. Server122may verify the central-server signature, for example, using central server130's public key314. In one example, server122may verify the central-server signature by generating a hash value of the received data, decrypting the central-server signature using central server130's public key314, and comparing the decrypted signature with the generated hash value of the received data. A match between the decrypted central-server signature and the generated hash value of the data is a confirmation to server122that central server130has deemed the communication from client112to be trustworthy. More particularly, the match is a confirmation to server122that central server130has verified that 1) client112is indeed the sender of the communication, and 2) the data has not been altered since the data was signed by client112.

At an optional step424, server122may verify the client signature using client112's public key, which may be stored locally at server122or retrieved from a separate data store (e.g., data store142). It may be preferable that server122's source of client112's public key is different from central server130's source of client112's public key so as to avoid a single point of failure (e.g., when the source is compromised to an attack). In system300, for example, server122may verify the client signature by decrypting the client signature using client112's public key and comparing the decrypted client signature with a hash value of the received data. A match between the decrypted client signature and the hash value of the received data indicates to server122that 1) the sender of the data had access to client112's private key312, and 2) the data has not been altered since the data was signed by the sender. If only client112is assumed to have access to client112's private key312, the match may further indicate to server122that client112is indeed the sender of the data. If the decrypted client signature and the generated hash value of the received data do not match, server122may halt process400. In some embodiments, if the decrypted client signature and the generated hash value of the received data do not match, server122may save the client signature and/or the data for further examination, for example, by a system administrator or a security analysis software.

Server122's verification of the client signature may be performed independently from central server130's verification of the client signature at step414so as to prevent a single point of failure in system300. For example, server122may independently generate a hash value of the received data without sharing the hash value with central server130or vice versa. Further, server122may retrieve client112's public key from a source is not shared with central server130.

The optional step424may be performed any time after the communication is received from client112at step408and before the communication is processed (or finished being processed) at step406. For example, the optional step424may be performed in parallel with one or more of steps410-422. In another example, the optional step424may be performed after verifying the central-server signature422or before transmitting the client signature and the data to central server130at step410.

In some embodiments, server122may further verify that the received data (or the content of the communication) is in accordance with policies associated with system300. For example, server122may perform one or more verifications that are similar to the verifications performed by central server130at step416. In embodiments where server122verifies that client112and/or server122are listed as being active in a list of active entities accessible by central server130, the list of active entities may be the same list or a different list from the list that can be accessed by central server130. In embodiments where the list is different from the list accessible by central server130, client112or server122may be immediately prevented from communicating with other entities in system100simply by altering either the list accessible to server122or the list accessible to central server130.

In embodiments where a plurality of client signatures is received, server122may verify at least one client signature. Additionally, the client signature verified by server122may be different from the client signature verified by central server130. In some embodiments, server122may verify all of the plurality of client signatures.

At step426, server122may process the communication. For example, server122may process the communication after step422and/or step424. In some embodiments, server122may partially process the communication before step422and/or step424, and server122may finish processing the communication after step422and/or step424. In some embodiments, server122may send an indication to client112that the communication has been processed.

In embodiments where the data included in the communication includes an expiration date/time associated with the data and/or unique nonce data, server122may determine whether the data has expired and/or whether server122has received data with the same nonce data prior to processing the communication. If the data is determined to be expired based on the expiration date/time the same nonce data has been received previously, process400may be halted (i.e., communication may not be processed).

FIG.5is a flow diagram of a process500for sending a trusted communication from server122to client112in system300ofFIG.3in which concepts consistent with the principles of the invention may be implemented. As shown inFIG.5, steps502,504,506,516,518, and520may be implemented by server122; steps508,510,512, and514by central server130; and steps522,524, and526by client112. In some embodiments, however, steps502,504,506,516,518, and520may be implemented by client112and steps522,524, and526may be implemented by server122. In some embodiments, steps502,504,506,516,518, and520may be implemented by client112and steps522,524, and526may be implemented by another client. In some embodiments, however, steps502,504,506,516,518, and520may be implemented by server122and steps522,524, and526may be implemented by another server.

At a step502, server122may obtain data to be sent to client112. In some embodiments, the data may be generated by server122. In some embodiments, the data may be obtained by one or more devices or components that are associated with server122. For example, the data may be obtained from an instant messaging system that is in communication with server122and may include a message destined for client112. In some embodiments, the data may be provided by a user of system300. For example, a user may provide data directly to server122, for example, via a user interface of server122. Alternatively, or additionally, a user may provide data indirectly to server122, for example, by causing the data to be transmitted to server122or by causing server122to retrieve a user-generated data.

The data may be any data that server122has access to. For example, in system200ofFIG.2, server122may obtain data that includes instructions on how to configure smart thermostat112bor a new firmware to be installed in vehicle230's entertainment system112d. In another example, the data may include data for software running on the portable device112c.

In some embodiments, the data may include information identifying the sender (i.e., client112) and/or the intended recipient(s). In some embodiments, the data may include a set of data. Further, the set of data may include data obtained from a plurality of sources or generated by a plurality of entities.

In some embodiments, the obtained data may be encrypted. For example, the obtained data may be encrypted using Elliptic Curve Diffie-Hellman (ECDH) algorithm, and only intended recipient or a plurality of recipients may decrypt the data.

In some embodiments, the obtained data may include expiration date/time associated with the data and/or unique nonce data.

At a step504, server122may obtain a server signature. In some embodiments, the server signature may be generated based on at least a portion of the obtained data using server122's private key322. For example, server122may generate the server signature by generating a hash value of the data to be sent to client112and encrypting the generated hash with server122's private key322. In some embodiments, server122may generate the server signature by encrypting some or all of the data to be sent to client112.

In system300, a server signature is a digital signature generated using server122's private key322. However, in some embodiments, the server signature may be any information that can be used by client112and central server130to verify that the communication is indeed sent by server122. For example, the server signature may be a passcode associated with server122. As discussed above, however, a digital signature is preferable over the passcode as the passcode may be compromised, for example, when the communication is intercepted. The server signature may be generated by server122. Alternatively, server122may obtain the server signature from another component such as a signature processor.

At a step506, server122may transmit the server signature to central server130. In some embodiments, server122may further transmit the data.

At a step508, central server130may receive the server signature. In some embodiments, central server130may further receive the data.

At a step510, central server130may verify the server signature. In some embodiments, central server130may verify the server signature using server122's public key336. In one example, central server130may verify the server signature by generating a hash value of the received data, decrypting the server signature using server122's public key336, comparing the decrypted signature with the generated hash value of the received data. A match between the decrypted server signature and the generated hash value of the received data indicates to central server130that 1) the sender of the data had access to server122's private key322, and 2) the data has not been altered since the data was signed by the sender. If only server122is assumed to have access to server122's private key322, the match may further indicate to central server130that server122is indeed the sender of the data. If the decrypted server signature and the generated hash value of the received data do not match, central server130may halt process400. In some embodiments, if the decrypted server signature and the generated hash value of the received data do not match, central sever130notify server122. Alternatively, central server130may not notify server122. In some embodiments, central server130may save the server signature and/or the data for further examination, for example, by a system administrator or a security analysis software.

At a step512, central server130may obtain a central-server signature generated based on at least a portion of the data. In some embodiments, the central-server signature may be generate using central server130's private key332. For example, the central-server signature may be generated by generating a hash value of the data and encrypting the hash value with central server130's private key332. In some embodiments, server122may generate the server signature by encrypting some or all of the data to be sent to client112.

In system300, as discussed above, a central-server signature is a digital signature generated using central server130's private key. However, in some embodiments, the central-server signature may be any information that can be used by clients110to confirm that central server130has deemed the data as being trustworthy. For example, as discussed above, the central-server signature may be a passcode associated with central server130.

In some embodiments, central server130may log that the central-server signature has been generated. The log may include at least a portion of the data and/or the server signature.

At a step514, central server130may transmit the central-server signature to server122. In some embodiments, central server130may further transmit the data and/or the server signature to server122.

In some embodiments, central server130may transmit the central-server signature after determining that the received data (or the content of the communication) is in accordance with policies associated with system300. For example, central server130may verify, by accessing a policy server (e.g., policy server344), that server122is authorized to send a communication to client112and/or that client112is authorized to receive a communication from server122. In another example, central server130may verify, by accessing a policy server (e.g., policy server344), that client112and/or server122is not in any system-wide or global blacklist. A policy may also define, for example, a time period and frequency at which client112and server122may communicate. If central server130determines that the received data is not in accordance with the policies associated with system300, central server130may halt process500.

In some embodiments, central server130may transmit the central-server signature after inspecting the data. For example, central server130may verify that the data does not include any known malicious software code or instructions. If malicious software code or instructions are detected, central server130may halt process500in one example.

In some embodiments, central server130may have access to a list of active entities in system300and may transmit the central-server signature after verifying that client112and/or server122are listed as being active. If one or both of client112and server122are listed as being inactive or missing from the list, central server130may halt process500. Therefore, by simply listing client112or server122as being inactive or removing client112or server122from the list, client112or server122may be immediately prevented from communicating with other entities in system100.

At a step516, server122may receive the central-server signature. In some embodiments, server122may further receive the data and/or the server signature.

At a step518, server122may obtain a server-group signature generated based at least on a portion of the data. In some embodiments, the server-group signature may be generated using server group125's private key324. For example, the server-group signature may be generated by generating a hash value of the data and encrypting the hash value with server-group125's private key324. In some embodiments, server122may generate a server-group signature based at least on the data and the central-server signature.

In system300, a server-group signature is a digital signature generated using server-group125's private key324. However, in some embodiments, the server-group signature may be any information that can be used by clients110to verify that the communication is indeed sent by one of the servers120in server group125. For example, the server-group signature may be a passcode associated with server-group125. As discussed above, however, a digital signature is preferable over the passcode as the passcode may be compromised, for example, when the communication is intercepted.

As discussed above in reference toFIG.3, server group125's private key324may be stored in data store142that may be accessible by each of the server120in server group125. Therefore, prior to generating the server-group signature, server122may retrieve server group125's private key324from data store142. In some embodiments, server122may store a local copy of server group125's private key324. In these embodiments, server122may periodically update the local copy with the version stored in data store142. Alternatively, server122may generate a server-group signature by sending the data and/or the central-server signature to a signature component and receiving a server-group signature generated by the signature component using server group125's private key324accessible by the signature component. In some embodiments, the signature component and the gateway associated with server group125may implemented on the same entity.

InFIG.5, step518is shown to be performed after step516. However, in some embodiments, step518may be performed any time after step502and before step520.

At a step520, server122may transmit a communication to client112. The communication may include the server-group signature and the central-server signature. In embodiments where neither of the server-group signature and the central-server signature is an encrypted version on the entire obtained data, the communication may further include the obtained data.

In some embodiments, server122may verify that the data is in accordance with policies associated with system300prior to transmitting the communication. For example, server122may verify, by accessing a policy server (e.g., policy server344and/or another policy server), that client112is authorized to send a communication to server122and/or that server122is authorized to receive a communication from client130. A policy may also define, for example, a time period and frequency at which client112and server122may communicate. In another example, server122may verify, by accessing a policy server (e.g., policy server344and/or another policy server), that client112and/or server122is not in any system-wide or global blacklist. A policy may also define, for example, a time period and frequency at which client112and server122may communicate. If server122determines that the received data is not in accordance with the policies associated with system300, server122may halt process500. In some embodiments, server122may further verify that the communication does not include any known malicious software code or instructions. If malicious software code or instructions are detected, server122may halt process500in one example. In some embodiments, server122may verify that client112and/or server122are listed as being active in a list of active entities accessible by server122. If one or both of client112and server122are listed as being inactive or missing from the list, server122may halt process500. Therefore, by simply listing client112or server122as being inactive or removing client112or server122from the list, client112or server122may be immediately prevented from communicating with other entities in system100. The list of active entities may be the same or different list that can be accessed by central server130.

At a step522, client112may receive the communication.

At a step524, client112may verify the server-group signature and the central-server signature. In some embodiments, client112may verify the central-server signature using central server130's public key314. In one example, client112may verify the central-server signature by generating a hash value of the data included in the communication, decrypting the central-server signature using central server130's public key314, comparing the decrypted signature with the generated hash value of the data. A match between the decrypted central-server signature and the generated hash value of the data indicates to client112that central server130has deemed the data included in the communication to be trustworthy. More particularly, the match indicates to client112that central server130has verified that 1) one of the servers120in server group125is indeed the sender of the communication, and 2) the data has not been altered since the data was signed by server122. If the decrypted central-server signature and the generated hash value of the data do not match, client112may halt process500.

Client112may verify the server-group signature using server group125's public key324. In one example, client112may verify the server-group signature by generating a hash value of the data included in the communication, decrypting the server-group signature using server group125's public key324, comparing the decrypted signature with the generated hash value of the data. A match between the decrypted server-group signature and the generated hash value of the data may provide a confirmation to client112that 1) the data included in the communication is from one of the servers120in server group125, and 2) the data has not been altered since the data was signed by server122. If the decrypted server-group signature and the generated hash value of the data do not match, client112may halt process500.

In some embodiments, instead of the server-group signature, server122may have transmitted the server signature to client112at step520instead of the server-group signature. In these embodiments, client112may have access to public keys of servers120and verify the received server signature using server122's public key. However, it is preferable that server122generate and transmit a server-group signature, as opposed to a server signature, because each client112only needs to have access to and/or manage a single server group125's public key316(in addition to its own private key and central server130's public key). In embodiments where a server signature is transmitted to client112, instead of a server-group key, each client may need to manage public keys of all servers120that client112can communicate with. In some systems, however, clients110may not have the capability to store and/or manage a large number of keys. For example, in an IoT system (e.g., system200), clients110may be implemented on low-power and small devices (e.g., smart thermostat112b) that does not have sufficient storage capacity and/or processing power to store and/or manage a large number of keys.

In some embodiments, if client112halts process500because the verification of one or both of the signatures has failed, the signatures and/or the data may be stored for future examination, for example, by a system administrator or a security analysis software.

At step526, client112may process the communication. In some embodiments, client112may partially process the communication before step524, and server122may finish processing the communication after step524. In some embodiments, client112may send an indication to server122that the communication has been processed.

In some embodiments after obtaining data at502, server122may transmit the data and/or the server122's signature generated at step504to at least one entity other than central server130(e.g., another server or central server). In these embodiments, each of these entities, after verifying that the data is trustworthy using its own verification process, may generate a digital signature using each its own private key and transmit the digital signature to server122. Server122, at step506, may transmit these digital signatures to central server130. Alternatively, these digital signature may be transmitted to central server130directly. Further, at step510, central server130may further verify these digital signatures before transmitting the central-server signature to server122.

In embodiments where the data included in the communication includes an expiration date/time associated with the data and/or unique nonce data, server122may determine whether the data has expired and/or whether client112has received data with the same nonce data prior to processing the communication. If the data is determined to be expired based on the expiration date/time the same nonce data has been received previously, process500may be halted (i.e., communication may not be processed).

Automated Mutual Authentication

FIG.6is a flow diagram of a process600for transmitting an approval request from client112to be approved by server122and central server130in which concepts consistent with the principles of the invention may be implemented. As shown inFIG.6, steps602,604,606,630,632, and634may be implemented by client112, steps608,610,620,622,624,626, and628by server122, and steps612,614,616,618by central server130. In some embodiments, steps602,604,606,630,632, and634may be implemented by server122, steps608,610,620,622,624,626, and628by client112. In some embodiments, steps602,604,606,630,632, and634may be implemented by server122, steps608,610,620,622,624,626, and628by another server. In some embodiments, steps602,604,606,630,632, and634may be implemented by client112, steps608,610,620,622,624,626, and628by another client.

At a step602, client112may prepare an approval request. An approval request may be prepared by client112when client112needs an approval from server122before taking an action. For example, the approval request may be a user authentication request when a user is attempting to login to client112; the user authentication request may include authentication information of a user such as user identifying information, password (encrypted or in clear text), login date and time, and requested duration of the approval.

Steps604-624are similar to steps404-424ofFIG.4, except that the data in steps602-610is a request. Steps626-632are similar to steps518-524ofFIG.5, except that the data in steps626and628is the request prepared at step602.

Furthermore, at one or both of steps614and624, server122and/or central server130may independently determine whether the request should be approved. In some embodiments, the determination on whether the request should be approved may include accessing one or more policy servers (e.g., policy server144). For example, if the request is an authentication request for a user to login to client112, the determination on whether the request should be approved may include querying one or more policy servers to determine whether the user is an authorized user of client112, server-group125, and/or system300.

At a step634, client112may determine that the request is approved. In some embodiments, the determination that the request is approved may cause another process to be started. For example, in if the request was an authentication request for a user to login to client112, a process for logging in the user to client112may begin.

Process600may enable automated communications between client112and server122. In an IoT systems, for example, it may be necessary for entities to establish trust automatically, without human intervention such as entering usernames or passwords. Process600may enable client112and server122to digitally sign requests using their private key as discussed above, and assert and verify each other's identity without the need for usernames, passwords, or other human-assisted methods of establishing trust.

In some embodiments, as discussed above, process600may also provide two-factor (or multi-factor) authentication. That is, in some embodiments, a request may be verified by two or more entities (e.g., server122and central server130) before the request is approved. Since it is more difficult for an attacker to breach multiple entities (e.g., to obtain their private keys) than breaching a single entity, two-factor authentication may improve the overall security of the system.

Adding, Removing, Replacing, or Revoking Keys using Reset Keys (Backup Authentication)

FIG.7illustrates an exemplary system700in which concepts consistent with the principles of the invention may be implemented. System700is similar to system300ofFIG.3, except that system700is capable of remotely adding, removing, revoking, and/or replacing the keys that can be accessed by clients110, servers120, and/or central server130. Further, entities in system700may have access to (or a copy of) at least one reset public key702. In some embodiments, a single copy of reset public key702may be shared by a plurality of entities. Alternatively, each entity may have access to its own copy of reset public key702. In some embodiments, entities in system700may have access to (or a copy of) a plurality of reset public keys. In some embodiments, entities in system700may have access to (or a copy of) three reset public keys. In system700, an entity that receives a communication that is encrypted or signed with a reset private key(s) corresponding to the reset public key702may store one or more keys included in the communication so that the keys can be accessed by the entity. Further, the communication may cause one or more keys that are currently accessible by the entity to be revoked and/or removed. In some embodiments, the communication may cause one or more keys that are currently accessible by the entity to be replaced with the keys that are included in the communication. For example, the communication may cause server group125's public key, central server130's public key, and/or reset public key702to be replaced with the keys included in the communication.

In some embodiments, such a communication may be used to replace server group125's public key and/or central server130's public key periodically or when requested by a user (e.g., system administrator). In some embodiments, such a communication may be used to replace server group125's public key and/or central server130's public key when a server122and/or central server130is determined to be compromised. In some embodiments, such a communication may be used to replace server group125's public key and/or central server130's public key when server group125's private key and/or central server130's private key are determined to be compromised (e.g., a backup file containing the private keys is lost). In some embodiments, such a communication may be used to replace server group125's public key and/or central server130's public key when an entity is retired, replaced, moved, or altered. For example, such a communication may be used to replace server group125's public key and/or central server130's public key when a server122and/or central server130is updated with a new hardware or software.

FIG.8is a flow diagram of a process800for adding, removing, revoking, and/or replacing digital keys accessible by various entities in system700in which concepts consistent with the principles of the invention may be implemented.

At a step802, an entity (e.g., client112, server122, or central server130) of system700may receive a communication. The communication may include at least one digital signature generated using at least one private key and at least one new key. In some embodiments, the communication may include a digital signature that is generated using a plurality of reset private keys. For example, an intermediate digital signature may be generated using a first reset private key, and a final digital signature may be generated using a second reset private key based on the intermediate digital signature. In some embodiments, the communication may include a plurality of digital signatures generated using a plurality of reset private keys. The communication may be transmitted from any one of clients110, servers120, and central server130. Alternatively, the communication may be transmitted from another entity in or outside system700.

The new keys included in the communication may include, for example, at least one of reset public keys, central server130's public key313, server group125's public key316, client122's private key, and server122's private key. One or more of the new keys (e.g., private keys) may be encrypted before being included in the communication. In some embodiments, new keys included in the communication may include a plurality of reset public keys. In some embodiments, new keys included in the communication may include three reset public keys.

At a step804, the entity may verify the digital signature using at least one reset public key702accessible by the entity. Verifying the digital signature may include verifying that the digital signature was generated by a reset private key that corresponds to the reset public key702. In embodiments where the digital signature is generated using a plurality of reset private keys, the digital signature may be verified using a plurality of public keys that correspond to the plurality of reset private keys in an order that was signed using the plurality of reset private keys. In the above example where an intermediate digital signature is generated using a first reset private key and a final digital signature is generated using a second reset private key based on the intermediate digital signature, the final digital signature may be first decrypted using a second public key corresponding to the second reset private key and the subsequently decrypted using a first public key corresponding to the first reset private key. In embodiments where a plurality of digital signatures are received, a plurality of reset public keys702may be used to verify the plurality of digital signatures.

At a step806, the entity may store the new key(s) included in the communication so that the new key(s) may be accessible by the entity. In some embodiments, the new key(s) may be stored in the entity or in a separate storage component accessible by the entity. In some embodiments, the entity may load the new key to a signature processor accessible by the entity. In some embodiments, the new key(s) may replace the keys that are currently accessible by the entity. At an optional step, the entity may revoke or remove one or more keys that are accessible by the entity. In some embodiments, the entity may prevent future access to the revoked keys. In some embodiments, the communication may further include a reset instruction that identifies the new keys included in the communication as wells the keys to be revoked, removed, or replaced.

In some embodiments, at step804, the entity may receive a communication that includes at least one digital signature generated using at least one private key without any new keys. In these embodiments, after verifying the digital signature at step804, the entity may remove or revoke one or more keys that are accessible by the entity without adding new keys. The communication may include a reset instruction that identifies the keys to be removed or revoked.

In some embodiments, the entity's ability to add, remove, replace, or revoke keys may depend on the private key that was used to generate the digital signature. For example, when the entity receives a digital signature generated using a first private key, the entity may be allowed to add new keys. However, if the entity receives a digital signature generated using a second private key, the entity may be allowed to add new keys and remove the keys that are currently accessible to the entity. In another example, if the entity receives a digital signature generated using a third private key, the entity may only be allowed to add public keys, but not private keys.

At an optional step, the entity may notify the sender of the communication that the new keys have been added.

Identity Abstraction

FIG.9illustrates a system900in which concepts consistent with principles of the invention may be implemented. System900includes a group of clients910that includes, for example, clients912and914, and a group of servers920that includes, for example, servers922and924. At least some of the communications between clients in group of clients910and servers in group of servers920may be signed communications that include digital signatures.

In conventional systems, a client that can receive signed communications from a plurality of servers requires a public key for each server in the plurality of servers. For example, if a client communicates with a group of servers that includes thousands of servers, the client would need to have access to the thousands of server public keys. In some systems, however, clients may not have the capability to store and/or manage a large number of keys. For example, in an IoT system, clients may be implemented on low-power and small devices that do not have sufficient storage capacity and/or processing power to store and/or manage a large number of keys.

In contrast, clients910in system900may require a single public key associated with group of servers920. For example, in system900, servers in group of servers920(e.g., servers922and924) may send communications to clients in group of clients910that includes a digital signature generated using a common private key (i.e., server group's private key942) that can be accessed by the servers in group of servers920. Thus, clients910require a single public key that corresponding to the common private key (i.e., server group's public key944) to verify the included digital signature signed by servers in group of server920. Server group's private key942may be stored in each server. Alternatively, server group's private key942may be stored in a shared storage.

FIG.10is a flow diagram of a process1000for transmitting digitally signed communications by a server922in a group of servers920in system900ofFIG.9.

At a step1002, server922may obtain access to a private key942associated with server group920. In some embodiments, server922may obtain access to private key942by being authenticated by another entity. For example, server922may obtain access to private key942by sending a digital signature generated using server922's private key to an authentication server. In this example, the authentication, after verifying the digital signature, may authorize server922to access private key942.

At a step1004, server922may generate a digital signature using private key942. The digital signature may be based on data to be transmitted to client912. Client912may be one of a plurality of clients (e.g., clients in group of clients910) that may communicate with servers in group of servers920, including server922.

At a step1006, server922may transmit a communication to client912. The communication may include the data to be transmitted to client912and the generated digital signature.

At a step1008, client912, after receiving the communication from server922, may verify the digital signature included in the communication using a public key944that corresponds to the private key942. In some embodiments, clients in group of clients910may have access to the public key.

At a step1010, client912may verify the digital signature.

At a step1012, client912, after verifying the digital signature, may process the communication. In some embodiments, client912, after verifying the digital signature, may finish processing the communication.

Trusted Communications Between Components within a Single Device

FIG.11illustrates an example of a vehicle1100in accordance with the disclosed embodiments. Vehicle1100includes a device1180, and device1180is similar to system300ofFIG.3, except that clients110and servers120are implemented as various controllers (e.g., electronic control units (ECUs) and motor control units (MCUs)) within device1180and central server130is implemented as a gateway1110also within device1180. In some embodiments, vehicle1100may be, for example, a car, motorcycle, boat, or aircraft.

As shown inFIG.11, device1180may include one or more controllers, a bus system (e.g., controller-area network (CAN) bus1120or local interconnect network (LIN) bus), and a gateway1110. In the example ofFIG.11, controllers included in device1180may include, for example, crash avoidance controller1130, brake controller1140, lock controller1150, and navigational controller1160. Further, vehicle1100may include hundreds of additional ECUs and MCUs (not shown) that are connected to each other via CAN bus1120. In some embodiments, device1180may include a plurality of bus systems (e.g., a plurality of CAN buses) connected to each other via gateway1110.

In device1180, due to complexity for example, the controllers in device1180may be designed and/or manufactured by multiple suppliers, and subsequently assembled and/or integrated by a vehicle manufacturer as a single device for use in vehicle1100. For example, CAN bus1120may be manufactured by a first supplier, crash avoidance controller1130by a second supplier, brake controller1140by a third supplier, and navigation controller1160by a fourth supplier. Subsequently, a vehicle manufacturer may assemble the controllers into a single device1180, and connect device1180to various parts of vehicle1100(e.g., brakes, entertainment systems, locks, etc.).

Despite the controllers being designed and/or manufactured by different suppliers, the controllers may need to communicate with each other to provide various functionalities of vehicle1100. In one example, crash avoidance controller1130may be configured to detect when a vehicle in front of vehicle1100is braking abruptly and transmit an instruction to brake controller1140requesting brakes in vehicle1100to be engaged. In another example, navigation controller1160may detect that vehicle1100is traveling above a predetermined speed and transmit an instruction to lock controller1150requesting locks in vehicle1100to be locked. To that end, CAN bus1120may enable hundreds of controllers in vehicle1100to communicate with each other using only a few wires (i.e., bus lines).

However, the flexibility of CAN bus1120may cause device1180to become vulnerable to malicious attacks. For example, an unauthorized controller may be connected to device1180via CAN bus1120, and such a controller may be programmed to give an attacker with control of various parts of vehicle1100. Accordingly, to prevent such attacks, the controllers may use trusted communications to communicate with each to other via CAN bus1120. For example, a controller receiving a communication (e.g., containing instructions) may verify that the communication was indeed transmitted by an authorized controller. To that end, as described below with respect toFIG.12, the controllers may use a process1200similar to process400ofFIG.4and/or process500ofFIG.5to communicate with each other. Gateway1110may implement the functions of central server130.

As further shown inFIG.11, gateway1110may communicate with an external entity1170. For example, gateway1110may be capable of connecting to the Internet (e.g., via Wi-Fi or cellular network) and may communicate with external entity1170via the Internet. In another example, gateway1110may communicate with external entity1170via vehicle1100's ODB-II interface. In some embodiments, gateway1110may receive data destined for one or more controllers and/or gateway1110from external entity1170. For example, gateway1110may receive a new firmware for one of the controllers.

To ensure that data received by gateway1110is from an authorized external entity (e.g., a server associated with one of the suppliers of the controllers or the vehicle manufacturer), the communications between external entity1170and gateway1110may be trusted communications. In some embodiments, external entity1170and gateway1110may use process400and/or500ofFIGS.4and5to communicate with each other. In these embodiments, external entity1170may be implemented as a server122of system300and gateway1110as a client112of system300. Further, gateway1110may implement functions of central server130. Alternatively, or additionally, another external entity may implement functions of central server130.

In some embodiments, device1180may include a plurality of gateways. For example, device1180may include an in-vehicle gateway connecting one or more controllers and an external gateway connecting one or more external entities. In this example, the in-vehicle gateway may be connected to the external gateway such that one or more controllers can communicate with one or more external entities. A firewall may be implemented between in-vehicle gateway and the external gateway, regulating the communications between them. In these embodiments, the in-vehicle gateway may implement functions of central server130for communications between the controllers of device1180. Further, the external gateway may implement functions of central server130for communications between one or more controllers and one or more external entities.

In some embodiments, external entity1170may communicate with gateway1110via a command-line interface.

FIG.12illustrates an example of a process1200for transmitting a trusted communication from a first controller1250to second controller1260in accordance with the disclosed embodiments. In one example, first controller1250may be crash avoidance controller1130and second controller may be brake controller1140in device1180.

At a step1202, first controller1250may obtain data to be sent to second controller1260. In some embodiments, the data may be generated by first controller1250. Alternatively, or additionally, first controller1250may retrieve or receive the data that was obtained or generated by one or more devices or components that are associated with, and/or connected to, first controller1250. For example, first controller1250may retrieve or receive sensor data from a sensor component connected to first controller1250.

The data may be any data that first controller1250can access. For example, in system1100ofFIG.11, crash avoidance controller1130may obtain data that includes a distance between vehicle1100and a vehicle in front of vehicle1100. In another example, brake controller1140may obtain data that includes the current status of the brakes (e.g., whether the brakes are engaged or not). In yet another example, navigation controller1160may include a current location and/or current speed of vehicle1100.

In some embodiments, the data may be provided by a user. For example, a user may provide data directly to first controller1250via a user interface connected to first controller1250or via a smartphone. The user interface may be implemented on, for example, vehicle1100's entertainment system. Alternatively, or additionally, a user may provide data indirectly to first controller1250, for example, by causing the data to be transmitted to first controller1250or by causing first controller1250to retrieve the user-generated data from another component or controller.

In some embodiments, the data may include information identifying the sender (i.e., first controller1250) and/or the intended recipient(s). In some embodiments, the data may include a set of data. Further, the set of data may include data obtained from a plurality of sources or generated by a plurality of components or controllers.

At a step1204, first controller1250may obtain a first controller signature. In some embodiments, the first controller signature may be generated based on at least a portion of the obtained data using first controller1250's private key. For example, first controller1250may generate the first controller signature by generating a hash value of the obtained data and encrypting the generated hash with first controller1250's private key. In some embodiments, first controller1250may generate the first controller signature by encrypting a portion or all of the data to be sent to server120using first controller1250's private key. In some embodiments, first controller1250's private key may be stored on a secure element associated with first controller1250.

A first controller signature may be a digital signature generated using first controller1250's private key. However, in some embodiments, the client signature may be any information that can be used by second controller1260and/or gateway1110to verify that the data is indeed sent by first controller1250and/or that the data has not been altered after the data was transmitted by first controller1250. For example, the first controller signature may be a passcode associated with first controller1250. A digital signature, however, is preferable over the passcode as the passcode may be compromised, for example, when the data is intercepted. In another example, the first controller signature may be a hash value of the obtained data. The digital signature may be generated by first controller1250. Alternatively, first controller1250may obtain the digital signature from another component such as a signature processor.

In embodiments where first controller1250has access to a plurality of private keys, first controller1250may generate a first controller signature based on the plurality of private keys. Alternatively, first controller1250may generate a plurality of first controller signatures based on the plurality of private keys.

At a step1206, first controller1250may transmit a communication. The communication may be destined for second controller1260and/or via one or more bus systems (e.g., CAN bus1120). Further, the communication may include the generated first controller signature and/or the obtained data. In embodiments where the first controller signature is an encrypted version of the entire data, the communication may include the generated first controller signature without the data. In some embodiments, the communication may include additional data other than the obtained data and the generated first controller signature. For example, the communication may include, in addition to the obtained data and the generated first controller signature, identification of the algorithm used to generate the first controller signature. In embodiments where first controller1250generated a plurality of first controller signatures, the communication may include the plurality of client signatures.

In some embodiments, first controller1250may transmit the communication via a plurality of bus systems and one or more gateways. For example, first controller1250, which may be connected to a first bus system, may transmit the communication via an in-vehicle gateway to a controller on a second bus system. The first and second bus system may be based on different protocols and/or standards. For example, the first bus system may be a CAN bus system while the second bus system may be a LIN bus system.

In some embodiments, first controller125may transmit the communication destined for an external entity. In these embodiments, first controller125may transmit the communication via a plurality of gateways. For example, first controller125may transmit the communication via an in-vehicle gateway and an external gateway. As described above, the in-vehicle gateway may be connected to the external gateway, and the gateways, as a collective, may connect one or more controllers connected to the in-vehicle gateway with one or more external entities connected to the external gateway.

At a step1208, second controller1260may receive the communication. In some embodiments, second controller1260may receive the communication via a bus system (e.g., CAN bus1120).

At a step1210, second controller1260may transmit the first controller signature to gateway1110. In some embodiments, second controller1260may further transmit the data to gateway1110. In some embodiments, second controller1260may transmit the first controller signature and/or the data to gateway1110via CAN bus1120. In some embodiments, second controller1260may transmit the entire communication that was received from first controller1250to gateway1110.

At a step1212, gateway1110may receive the first controller signature. In some embodiments, gateway1110may further receive the data. In some embodiments, server112may receive the entire communication that second controller1260received from first controller1250.

At a step1214, gateway1110may verify the first controller signature. In some embodiments, gateway1110may verify the first controller signature by generating a hash value of the received data, decrypting the first controller signature using first controller1250's public key, and comparing the decrypted signature with the generated hash value of the received data. A match between the decrypted first controller signature and the generated hash value of the received data may indicate to gateway1110that 1) the sender of the data had access to first controller1250's private key, and 2) the data has not been altered since the data was signed by the sender. If only first controller1250is assumed to have access to first controller1250's private key, the match may further indicate to gateway1110that first controller1250is indeed the sender of the data. If the decrypted first controller signature and the generated hash value of the received data do not match, gateway1110may halt process1200. That is, the communication may “die on the vine.” In some embodiments, if the decrypted first controller signature and the generated hash value of the received data do not match, central sever130may notify second controller1260that the communication from first controller1250is not deemed trustworthy. Alternatively, gateway1110may not notify second controller1260. In some embodiments, gateway1110may save the first controller signature and/or the data for further examination, for example, by a system administrator or a security analysis software.

In embodiments where the first controller signature is an encrypted version of a portion or the entire data, gateway1110may verify the first controller signature by decrypting the first controller signature using first controller1250's public key and comparing the decrypted first controller signature with a portion or all of the received data.

In embodiments where a plurality of first controller signatures is received, gateway1110may verify at least one first controller signature. In some embodiments, gateway1110may verify all of the plurality of first controller signatures.

Second controller1260may obtain first controller1250's public key numerous ways. In some embodiments, each controller in device1280may be preprogrammed at the time of manufacture with all public keys of device1280. In some embodiments, public keys of each controller in device1280may be provided to each other during an initialization of device1280. In some embodiments, public keys of each controller in device1280may be provided to each other during an initialization of device1280via gateway1110.

At a step1216, gateway1110may obtain a gateway signature generated based on at least a portion of the data using gateway1110's private key. For example, the gateway signature may be generated by generating a hash value of the data and encrypting the hash value with gateway1110's private key. In some embodiments, gateway1110may generate a gateway signature based on both the data and the first controller signature. In embodiments where the entire communication was transmitted to gateway1110, gateway1110may generate a gateway signature based the entire communication. In embodiments where the first controller signature is an encrypted version of a portion or the entire data, the gateway signature may be generated based on a portion or all of the decrypted first controller signature.

In system1100, a gateway signature is a digital signature generated using gateway1110's private key. However, in some embodiments, the gateway signature may be any information that can be used by second controller1260to confirm that gateway1110has deemed the communication as being trustworthy. For example, the gateway signature may be a passcode associated with gateway1110. In some embodiments, the gateway signature may simply be an identifier of gateway1110. A digital signature, however, is preferable over a passcode or an identifier because the passcode and identifier may be compromised or already known by public.

In some embodiments, gateway1110's private key may be stored on a secure element associated with gateway1110.

At a step1218, gateway1110may transmit the gateway signature to second controller1260. In some embodiments, the gateway signature may be transmitted via CAN bus1120. In some embodiments, gateway1110may further transmit the data and/or the first controller signature. In some embodiments, gateway1110may further transmit the entire communication sent by first controller1250.

In some embodiments, gateway1110may transmit the gateway signature after determining that the received data is in accordance with policies associated with vehicle1100and/or device1180. For example, gateway1110may verify, by accessing a policy controller (not shown), that first controller1250is authorized to send a communication to second controller1260and/or that second controller1260is authorized to receive a communication from first controller1250. A policy may also define, for example, a time period and frequency at which first controller1250and second controller1260may communicate. If gateway1110determines that the received data is not in accordance with the policies associated with system300, gateway1110may halt process1200and/or notify second controller1260. As an example, a policy of device1180may define that only crash avoidance controller1130may communicate with brake controller1140; that is, lock controller1150should not be able to engage brakes by sending instructions to brake controller1140.

In some embodiments, gateway1110may transmit the gateway signature after inspecting the content of the communication or the received data. For example, gateway1110may verify that the communication does not include any known malicious software code or instructions. If malicious software code or instructions are detected, gateway1110may halt process1200and/or notify second controller1260.

In some embodiments, gateway1110may have access to a list of active controllers in device1280and may transmit the gateway signature after verifying that first controller1250and/or second controller1260is listed as being active. If one or both of first controller1250and second controller1260are listed as being inactive or missing from the list, gateway1110may halt process1200and/or notify second controller1260. Therefore, in these embodiments, by simply listing first controller1250or second controller1260as being inactive or removing first controller1250or second controller1260from the list, first controller1250or second controller1260may be immediately prevented from communicating with other controllers via CAN bus1120.

The list of active controller may be updated, for example, by external entity1170. For example, an authorized external entity1170may send a trusted communication containing an updated active controller list to gateway1110. After verifying that the communication is indeed from an authorized external entity1170, gateway1110may update the list of active controllers.

At a step1220, second controller1260may receive the gateway signature. In some embodiments, second controller1260may further receive the data and/or the first controller signature. In some embodiments, gateway1110may further receive the entire communication. In some embodiments, second controller1260may receive the gateway signature via CAN bus1120.

At a step1222, second controller1260may verify the gateway signature. Second controller1260may verify the gateway signature, for example, using gateway1110's public key. In one example, second controller1260may verify the gateway signature by generating a hash value of the received data, decrypting the gateway signature using gateway1110's public key, and comparing the decrypted signature with the generated hash value of the received data. A match between the decrypted gateway signature and the generated hash value of the data is a confirmation to second controller1260that gateway1110has deemed the communication from first controller1250to be trustworthy. More particularly, the match is a confirmation to second controller1260that gateway1110has verified that 1) first controller1250is indeed the sender of the communication, and 2) the data has not been altered since the data was signed by first controller1250.

At an optional step1224, second controller1260may verify the first controller signature using first controller1250's public key. In system1100, for example, second controller1260may verify the first controller signature by decrypting the first controller signature using first controller1250's public key and comparing the decrypted first controller signature with a hash value of the received data. A match between the decrypted first controller signature and the hash value of the received data indicates to second controller1260that 1) the sender of the data had access to first controller1250's private key, and 2) the data has not been altered since the data was signed by the sender. If only first controller1250is assumed to have access to first controller1250's private key, the match may further indicate to second controller1260that first controller1250is indeed the sender of the data. If the decrypted first controller signature and the generated hash value of the received data do not match, second controller1260may halt process1200. In some embodiments, if the decrypted first controller signature and the generated hash value of the received data do not match, second controller1260may save the first controller signature and/or the data for further examination, for example, by a security analysis software or vehicle1100manufacturer.

Second controller1260's verification of the first controller signature may be performed independently from gateway1110's verification of the first controller signature at step1214so as to prevent a single point of failure in system1100. For example, second controller1260may independently generate a hash value of the received data without sharing the hash value with gateway1110or vice versa. Further, second controller1260may retrieve first controller1250's public key from a source is not shared with gateway1110.

The optional step1224may be performed any time after the communication is received from first controller1250at step1208and before the communication is processed (or finished being processed) at step1206. For example, the optional step1224may be performed in parallel with one or more of steps1210-1222. In another example, the optional step1224may be performed after verifying the central-server signature1222or before transmitting the first controller signature and the data to gateway1110at step1210.

In some embodiments, second controller1260may further verify that the received data (or the content of the communication) is in accordance with policies associated with vehicle1100and/or device1180. For example, second controller1260may perform one or more verifications that are similar to the verifications performed by gateway1110at step1216. In embodiments where second controller1260verifies that first controller1250and/or second controller1260are listed as being active in a list of active entities accessible by gateway1110, the list of active entities may be the same list or a different list from the list that can be accessed by gateway1110. In embodiments where the list is different from the list accessible by gateway1110, first controller1250or second controller1260may be immediately prevented from communicating with other controllers simply by altering either the list accessible to second controller1260or the list accessible to gateway1110.

In embodiments where a plurality of first controller signatures is received, second controller1260may verify at least one first controller signature. Additionally, the first controller signature verified by second controller1260may be different from the first controller signature verified by gateway1110. In some embodiments, second controller1260may verify all of the plurality of first controller signatures.

At step1226, second controller1260may process the communication. For example, second controller1260may process the communication after step1222and/or step1224. In some embodiments, second controller1260may partially process the communication before step1222and/or step1224, and second controller1260may finish processing the communication after step1222and/or step1224. In some embodiments, second controller1260may send an indication to first controller1250that the communication has been processed. For example, in embodiments where the data includes instructions, second controller1260may execute the instructions.

While illustrative embodiments have been described herein, the scope of any and all embodiments having equivalent elements, modifications, omissions, combinations (e.g., of aspects across various embodiments), adaptations and/or alterations as would be appreciated by those skilled in the art based on the present disclosure. The limitations in the claims are to be interpreted broadly based on the language employed in the claims and not limited to examples described in the present specification or during the prosecution of the application. The examples are to be construed as non-exclusive. Furthermore, the steps of the disclosed routines may be modified in any manner, including by reordering steps and/or inserting or deleting steps. It is intended, therefore, that the specification and examples be considered as illustrative only, with a true scope and spirit being indicated by the following claims and their full scope of equivalents.