Method and apparatus for providing secure communication among constrained devices

METHOD AND APPARATUS FOR PROVIDING SECURE COMMUNICATION AMONG CONSTRAINED DEVICES

[0001] Continue to paragraph [0002].

BACKGROUND OF THE DISCLOSURE

[0002] The disclosure relates to methods and apparatus for providing secure communications among devices such as constrained devices in a network.

[0003] In proposed models for providing security for the Internet of Things, there are two proposed authentication infrastructures, either or both of which may use public key infrastructure (PKI) technology and certificates. For example, when connecting multiple devices to a network (or to each other), via the Internet, a first security infrastructure may install credentials in the devices that uniquely identify each device. These identification credentials may be unmanaged from a security perspective and are independent of the domain of use. For example, when a device that can be connected to a network is manufactured, such as temperature sensors and thermostats to be installed in multiple floors of a large building, the manufacturer may have a server or use a server of a third party as a root certificate server and generate identification certificates for each of the devices that are produced by the manufacturer. As such, during manufacture, a database may be created with an entry correlating a unique identifier of the device with a certificate that is signed by the root certificate authority. In this manner, when a device is turned on, it may authenticate via a network, to the root authority or to another certification authority.

[0004] However, a different security infrastructure may be used for managing the configuration of the device when it is installed. As such, generic devices need to be added as new devices in a system or network and then the device needs to be configured to operate in a particular manner consistent with the needs of the system or network. For example, another authorization infrastructure may be used for managing authorization such as which devices are authorized on a network, which devices are authorized to communication with certain other devices, which devices can send which commands to which interfaces of which other devices in a network and their configuration settings. With a growing number of devices having to be installed in larger networks such as building networks, roadside infrastructures,

Date Reçue/Date Received 2023-05-16

CA 02992736 2018-01-16

WO 2017/015436 PCT7US2016/043272 manufacturing facilities, and other environments, each device is enrolled in a database of the second infrastructure.

[0005] As cryptanalytic capabilities advance, and certain cryptographic algorithms cease to be adequately secure for their purpose, it is necessary to continuously update the cryptographic algorithms and keys in use, while continuing to support parts of the network that have yet to update their algorithms. This presents a problem because both parties to a communication must use the same algorithm, yet it is impractical to update all devices 102102n simultaneously. This problem is usually solved by supporting a range of algorithms in devices that accept connections and messages, even obsolete ones. Devices that originate connections and messages must only support any one of the algorithms supported by the other parties with which it communicates. The cost paid for this solution is that all parties that accept connections and messages must support multiple algorithms and have keys suitable for use with each. In a network of constrained devices this cost may be unacceptable. A constrained device as used herein is one that stores one cryptographic algorithm code module per cryptographic function in memory. A code module as used herein is stored executable instructions that when executed by one or more processors, causes the one or more processors to perform operations as dictated by the stored instructions of the code module.

[0006] Referring to FIG. 1, a system 100 is shown with a plurality of devices 102 and 102n, that are to be added in a network, such as a network that employs the Internet 104. The devices may be sensors, actuators, roadside infrastructure elements, or any other suitable device that can network with the Internet or other network. Enrolling the devices 102-102n may be typically done in a batch process at a central location and then shipped to be installed. An administrator would need to review a plan of an overall system and try to figure out how to configure the devices.

[0007] In this example, a security management device 106 or authorization server that is part of a security management infrastructure, in this case a PKI infrastructure, populates a database 108, through an administrator interface at a server or other computer as part of the device 106, with data needed to issue device configuration certificates that are then issued to the devices 102-102n to configure the devices to operate as required by the network. Networks of sensors and actuators may use the authorization server that controls the privileges of the devices of which the network is formed; dictating which devices are permitted to access which functions on which other devices.

CA 02992736 2018-01-16

WO 2017/015436 PCT/US2016/043272

[0008] Each device has a suitable network interface to communicate with the network and with each other, and in this example, includes an IP address or URL. In one example, the security management device 106 may generate device configuration certificates in a capability certificate model shown as certificate 110 and/or device configuration certificates based on a device permission certificate model, shown as certificate 112. The device configuration certificates may be stored in a certificate database 114 as known in the art. An example of a device configuration certificate based on a capability certificate model would be a certificate, for example, signed by the security management device 106 or other suitable certification authority. The device configuration certificate that is based on a device capability certificate would include, for example, the device ID, such as a serial number, IP address, URL or other identifier, as well as data representing the commands the particular device can emit and which devices are authorized to communicate with other devices in the network. A device configuration certificate that is based on a device permission certificate 112 through a permission model may generate a certificate that includes the same type of device ID information and data identifying what commands a device can accept. The database 108 may include, for example, the device ID for each device in the network and a per device location such as the position of the device within the system. For example if the device is a sensor in a one of many pipes, its position within a particular pipe with respect to a particular junction of pipes or other location information has to be determined by an administrator. The database 108 may also include other device information such as the model number and serial number of the device as well as capabilities of the device set by an administrator that may set the parameters through a suitable user interface of the security management device 106. Alternatively, permissions or rules may be stored for a particular set of devices if a permission model is used. The issued device configuration certificates, whether they be based on a capability model or permission model, after generated or issued, are then sent to each respective device so that their configuration is securely administered through a public key infrastructure based security system. As such, a device 102-102n, will only accept a certificate if it can verify that it was signed by a trusted root authority, and changes can only be made to the configuration of the device via the security management device 106.

[0009] There is a need for systems that employ constrained devices to maintain secure communication around the devices.

CA 02992736 2018-01-16

WO 2017/015436 PCT/US2016/043272

BRIEF DESCRIPTION OF THE DRAWINGS

[0010] The embodiments will be more readily understood in view of the following description when accompanied by the below figures and wherein like reference numerals represent like elements, wherein:

[0011] FIG. 1 is a block diagram illustrating one example of a prior art system;

[0012] FIG. 2 is a block diagram illustrating one example of a system in accordance with one example set forth in the disclosure;

[0013] FIG. 3 is a flowchart illustrating one example of a method for secure communication between constraint devices in accordance with one example set forth in the disclosure;

[0014] FIG. 4 is a diagram illustrating one example of a method for secure communication between constraint devices in accordance with one example set forth in the disclosure;

[0015] FIG. 5 is a diagram illustrating one example of issued cryptographic communication rights in the form of digital certificates or tokens for a plurality of constrained devices in accordance with one example set forth in the disclosure;

[0016] FIG. 6 is a block diagram illustrating one example of an authorization server in accordance with one example set forth in the disclosure; and

[0017] FIG. 7 is a block diagram illustrating one example of a constrained device in accordance with one example set forth in the disclosure.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0018] Generally, an apparatus such as an authorization server and method for secure communication between constrained devices issues cryptographic communication rights among a plurality of constrained devices. Each of the plurality of constrained devices comprises no more than one cryptographic algorithm code module per cryptographic function. The method includes receiving a cryptographic communication rights request associated with at least a first of the plurality of constrained devices in response to a cryptographic algorithm update request, and includes providing a response including an identification of a subset of the plurality of constrained devices that have cryptographic communication rights with the identified first of the plurality of constrained devices. A software update server then updates the cryptographic code modules in the sub-set of the plurality of constrained devices.

CA 02992736 2018-01-16

WO 2017/015436 PCT/US2016/043272

[0019] In one example, the apparatus and method may also provide the response including the identification of the subset of the plurality of constrained devices that have cryptographic communication rights by determining which of the plurality of constrained devices have cryptographic communication rights with the identified first constrained device based on authorized communication rights authorized by the authorization server.

[0020] The method may also include provisioning, by a software update server, a replacement cryptographic code module, in response to the cryptographic algorithm update request, to the subset of the plurality of constrained devices that have cryptographic communication rights in common with the identified first of the plurality of constrained devices, wherein the replacement cryptographic code module includes at least one of: a data encryption code module, a key encryption code module, a data signature code module, a key agreement code module and a data digest code module. A data digest code module may, for example, carry out an SHA-1 or an SHA-2 cryptographic operation as known in the art, or any other suitable data digest operation as known in the art.

[0021] The apparatus and method may also issue cryptographic communication rights among the plurality of constrained devices by issuing asymmetric key based configuration certificates or symmetric key based tickets to the plurality of constrained devices wherein the configuration certificates assign communication rights to each of the plurality of constrained devices to allow the plurality of constrained devices to cryptographically exchange information between the plurality of constrained devices.

[0022] FIG. 2 illustrates one example of a system 200 that includes an authorization server 202, a network management device 204 (such as a server), a software update server 206 and constrained devices 209-210 that are in communication with one another through a network such as the Internet 104 or any other suitable communication network or networks. A gateway may be employed as shown and as known in the art if desired. The authorization server 202 may include the functionality of the security management device 106 (FIG. 1) and/or may also include additional logic as described herein. The authorization server 202 in this example, includes a database 214 similar to database 114 except additional information may be incorporated as digital certificates such as cryptographic communication rights among a plurality of constrained devices. For example, a certificate may indicate that constrained device 209 may communicate with other specified constrained devices 210 or unconstrained devices (not shown) in the network. Each constrained device 209-210 has a corresponding certificate or token indicating its cryptographic communication rights.

CA 0299273« 2018-01-16

WO 2017/015436 PCT/US2016/043272

[0023] Cryptographic communication rights, for example, indicate which cryptographic fonctions may be employed by a particular device. Differing cryptographic functions may include by way of example, and not limitation, a data encryption fonction, a key encryption function, a data signature function, a key agreement function, and a data digest function. The stored software modules corresponding to each of the cryptographic functions are referred to herein as cryptographic code modules. The single cryptographic code modules may be stored for each cryptographic function in each constrained device. As such, each of the plurality of constrained devices 209-210 include no more than one cryptographic algorithm code module per cryptographic function. The function may employ any suitable cryptographic format such as Elliptic Curve Cryptography (ECC), RSA or any other suitable format. The devices 209 and 210 are constrained such that they do not store more than a single cryptographic algorithm code module per cryptographic function.

[0024] The database 214 may be any suitable distributed database or local database stored in any suitable memory such as DRAM, ROM, RAM, or any other suitable storage medium that stores digital information. The authorization server 202 checks that all constrained devices that are permitted to communicate with each are programmed with compatible cryptographic algorithms and corresponding keys. If a particular cryptographic algorithm has to be updated for various reasons such as the algorithm is no longer strong enough for a particular application, or for any other reason, the network management device can suspend sub-sets of the constrained devices 209-210 and the software update server can update their respective cryptographic algorithms and keys and then the network management device can lift the suspension. In this way, all communicating parties are ensured at all times that they have compatible cryptographic algorithms and keys.

[0025] Referring also to FIGs. 3 and 5, a method for secure communication between constrained devices includes as shown in block 302, issuing by the authorization server 202 cryptographic communication rights such as certificates or tickets or other cryptographic token, among a plurality of constrained devices 209-210 where each of the plurality of constrained devices includes no more than one cryptographic algorithm code module per cryptographic function. An example of a certificate for constrained device 209 is shown as certificate 500 where it includes data representing cryptographic communication rights showing that constrained device A is authorized to communicate with constrained device B as well as unconstrained device 1. The cryptographic communication rights 500 also include, in this example, an authentication public key for device A along with the cryptographic algorithm identifier that device A is able to use. Similarly, cryptographic communication

CA 02992736 2018-01-16

WO 2017/015436 PCT/US2016/043272 rights 502, 504, 506 and 508 are provided for other constrained devices such as device B, device D, device G and device H (these devices are not shown in FIG. 2 for simplicity purposes). As such, the authorization server 202 issues in this example, public key certificates, signed by the authorization server or other root authenticator, expressing the subject constrained device’s public key and its capabilities. The subject in this case is an identifier for the constrained device to whom the certificate is issued. An object, such as other devices with whom the subject is permitted to communicate and if desired, an action the subject is permitted to perform on the object. Although this example employs public key cryptography techniques, symmetric key techniques may also be employed if desired.

[0026] Cryptographic communication rights can also be expressed as certificates with permissions in which the certificate identifies the object and the permissions identify the subjects and the action the subject is permitted to perform. The constrained devices may be identified by name such as a DNS name or an address such as an IPv6 address, or any other suitable identifier. The authorization server 202 certifies the assigned rights and as such, knows which constrained devices (and unconstrained devices if they are in a network) are permitted to talk to with each other in the network. The authorization server 202 is then able to identify which cryptography communication links would break should any of the identities replace its cryptographic algorithm code module.

[0027] In the example shown in FIG. 5, a cryptographic communication rights chain is determined by the authorization server 202 by looking at each of the certificates based on the subject (Device ID) that are included in any certificate. By way of example, device A is authorized to cryptographically communicate with device B (meaning that they both have the same cryptographic code modules for respective cryptographic functions) and device B is authorized to communicate cryptographically with constrained devices D, G and H and constrained devices D, G and H are each authorized to communicate with constrained device A. As such, having to update a cryptographic code module for device A would require updating the same cryptographic code module resident in constrained devices B, D, G and H for these devices to communicate properly with one another from a cryptographic perspective. As such, the authorization server 202 utilizes a method for identifying incompatible cryptographic algorithm provisioning based on cryptographic communication rights for constrained devices. As noted above, each cryptographic code module implements no more than one algorithm per key usage or per cryptographic function in order to minimize the amount of memory required to store the cryptographic codes. Key uses also referred to as

CA 02992736 2018-01-16

WO 2017/015436 PCT/US2016/043272 cryptographic fonctions include without limitation data encryption, key encryption, data signature generation, key agreement and data digests as noted above.

[0028] Referring back to FIG. 3, the method as shown in block 304 includes receiving, by the authorization server 202, a cryptographic communication rights request 220 which seeks a list of constrained devices that require common cryptographic code modules to communicate. In this example, the network management device 204 sends the request 220. As noted, this request 220 asks the authorization server 202 to provide the list of the devices that are affected by a necessary update to a cryptographic code module. A cryptographic algorithm update request 222 may be used to initiate a cryptographic code module update (i.e., software update). This cryptographic algorithm update request 222 may be received by the software update server, or the network management device 204. By way of example, the update request 222 may come through an administrator terminal requiring an improved level of security and hence, an upgrade in a key size or differing cryptographic algorithm such as an RSA to elliptic curve algorithm. The cryptographic algorithm update request 222 may also be generated automatically from another server or another process as desired. As such, as one example, issuing the cryptographic communication rights request can be done by the software update server in response to the software update server receiving the cryptographic algorithm update request. Likewise, as another example, issuing the cryptographic communication rights request can be done by the network management device in response to the network management device receiving the cryptographic algorithm update request.

[0029] As shown in block 306, the method include providing by the authorization server 202, a response 224 including an identification of a sub-set of the plurality of constrained devices that have cryptographic communication rights in common with the identified first of the plurality of constrained devices. For example, if the first device was device A, a response 224 from the authorization server 202 would send the response for device A listing the other constrained devices and unconstrained devices for which device A has the cryptographic communication right to communicate with using the same cryptographic code modules. In this example, it would include device B, device D, device G and device H (see FIG. 5). This list of devices may be, for example, a list of device IDs as part of the response 224 to the network management device. This is shown in block 306.

[0030] Referring to FIGs. 2 and 4, the communications described are diagrammed in both figures. Once the response with the device list 224 is sent to the network management device 204, the network management device 204 may send a command 400 to the software update server 206 instructing the software update server 206 to update the respective

CA 02992736 2018-01-16

WO 2017/015436 PCT/US2016/043272 cryptographic code modules in each of the constrained devices listed in the device list. The software update server 206 then provisions the cryptographic code modules shown by communication 402 to each of the constrained devices listed in the device list. These constrained devices are a sub-set of the total number of constrained devices in the network. As previously noted, this may include suspending these devices until the software update is complete and then allow the constrained devices to reassert themselves in a network. The device can be placed in “silent” mode by a command from the network management device, in which the device neither initiates nor accepts messages from devices other than the network management device. It will be recognized that the operations described herein may be suitably distributed among the various devices in the network depending upon the desired topology of the network.

[0031] Also illustrated in FIG. 4 are dashed lines 404 and 406 illustrating operations that may occur periodically between the constrained device and the software update server. The constrained device may initiate a software update request 404 to the software update server and, if the network management device 204 has sent a command 400 to the software update server 206 instructing the software update server 206 to update the respective cryptographic code module, then the software update server may then send a response 406 with the new cryptographic code module to the requesting device.

[0032] Referring again to FIG. 5, the response 224 includes the identification of the sub-set of the plurality of constrained devices that have cryptographic communication rights in common. The method includes determining which of the plurality of constrained devices have cryptographic communication rights in common with the identified first constrained device based on authorized communication rights that are authorized by the authorization server. This is done by, for example, evaluating the chain of certificates that identify common constrained devices as illustrated in FIG. 5. Examples of standard format for key certificates include X.509, PGP, PEM, PKIX, PKCS&7, Publickeyinfo, and SHA-1 and other suitable formats known in the art.

[0033] The method also includes, for example as noted above, provisioning, by the software update server, a replacement cryptographic code module in response to the cryptographic algorithm update request 222 such that the provisioning is to the sub-set of the plurality of constrained devices that have cryptographic communication rights in common with the identified first of the plurality of constrained devices.

[0034] The authorization server issues the cryptographic communication rights (certificates, tickets or other tokens) among the plurality of constrained devices by, in one

CA 02992736 2018-01-16

WO 2017/015436 PCT/US2016/043272 example, issuing asymmetric key based configuration certificates or symmetric key based tickets to the plurality of constrained devices. The configuration certificates or symmetric key tickets assign communication rights to each of the plurality of constrained devices to allow the plurality of constrained devices to cryptographically exchange information between the plurality of constrained devices and are cryptographically signed by the authorization server.

[0035] FIG. 6 illustrates a block diagram of an authorization server 202 which may include logic such as one or more processors 600 such as CPUs, DSPs, or any other suitable processor(s) and memory 602 that may be accessible by the processor 600 through any suitable bus structure 604 as known in the art. The memory 602 may be any suitable memory including memory distributed through the network and/or local memory in the form of RAM, DRAM, ROM, EPROM or any other suitable memory. In this example, the memory 602 contains instructions that when executed cause the processor 600 to carry out the operations described herein. The processor 600 serves as logic that is operative to perform the functions when executing the stored code. The logic may also be implemented in any other suitable from such as application specific integrated circuits, state machines, or any suitable combination of hardware and stored software. The authorization server also includes, as known in the art, suitable interfaces 606 to provide interfaces to the network, user interfaces, or any other suitable interfaces that are needed by the authorization server. The software update server and network management server may include one or more processors, memory and interfaces to communicate with each other as known in the art. However, it will be recognized that the functions carried out by each of the servers can be combined onto or distributed amongst one or more servers as desired.

[0036] FIG. 7 illustrates a block diagram of a constrained device 202 including a controller 700, such as a microprocessor, state machine, digital signal processor or any other suitable logic, a radio frequency transceiver 702 to communicate with other constrained devices, and in this example a sensor 704 such as a temperature sensor, pressure sensor or other sensor provides sensor information 706 to the controller which may then provide the information through the RF transceiver to the network as desired and as known in the art. A cryptographic engine 708 may be part of the controller 700 or its own hardware if desired and performs the cryptographic operations needed by the constrained device such as the cryptographic functions described herein. The cryptographic engine in this example executes the cryptographic code modules stored in memory 710 and is a programmable processor. However, any suitable logic may also be employed as noted above. A code updater 712

CA 02992736 2018-01-16

WO 2017/015436 PCT7US2016/043272 which may be, for example, executing software on the controller 700 changes or overwrites the current cryptographic code modules with a provisioned cryptographic code module to update the cryptographic code modules on the constrained device. Any suitable software update application or operation may be employed.

[0037] Among other advantages, a sub-set of constrained devices may be identified that require a common cryptographic code module software update. The constrained devices may be low cost devices with single cryptographic function operation to improve network costs. The system effectively checks that all devices permitted to communicate with each other are programmed with compatible cryptographic algorithms and keys. When deprecating a particular cryptographic algorithm from a constrained device, the authorization server suspends sub-sets of the constrained devices in the network causes update of the subsets of cryptographic algorithms and keys, then lifts the suspension. In this way, the authorization server can ensure that all communicating parties, at all times, have compatible cryptographic algorithms and keys.

[0038] The above detailed description of the invention and the examples described therein have been presented for the purposes of illustration and description only and not by limitation. It is therefore contemplated that the present invention cover any and all modifications, variations or equivalents that fall within the spirit and scope of the basic underlying principles disclosed above and claimed herein.