Attendance of ownership of private keys for remote devices

Abstract

A certification of ownership (POP) of a private key by a device is verified. The computer system generates a pre-provisioning package for the device directory. The pre-provisioning packet includes a POP challenge. After generating the provisioning packet, the computer system receives a device activation request for the device. The device activation request includes a public key, a device identifier, and a signature. The computer system verifies the POP of the private key corresponding to the public key, including cryptographically verifying the signature using the public key, the device identifier, and the POP challenge. The computer system establishes a trust relationship with the device, including registering a public key and a device identifier into a device directory.

Description

Background Art

[0001] Computer systems are coupled to each other and to other electronic devices to form both wired and wireless computer networks, through which computer systems and other electronic devices can transmit electronic data. Therefore, the execution of many computing tasks is distributed across multiple different computer systems and / or multiple different computing environments. In some computing environments, one or more computing devices are provisioned by a centralized service. For example, in a cloud computing environment, it is common for IoT devices to be provisioned into a device catalog of a service operating at a server computer system. Once an IoT device is provisioned by a service, the service communicates and potentially consumes data generated by the IoT device.

[0002] Provisioning IoT devices to a service's device catalog typically involves the service obtaining and registering identity parameters associated with the IoT device. The identity parameters can be used to subsequently verify the identity of the IoT device. As an example, asymmetric cryptography (also known as public key cryptography) uses a related key pair - a public encryption key (public key) and a private encryption key (private key) - to encrypt and decrypt data. In general, the public key of an asymmetric key pair can be shared freely, while the private key of the key pair is held as a secret key by the owner of the key pair. The public key can be used by anyone to encrypt a message, which can then only be decrypted by the corresponding private key. If the sender encrypts a message using its private key, the message can only be decrypted using the sender's public key, thus authenticating that the message originated from the sender. Therefore, a service can use the public key of a registered IoT device as an identity parameter for the IoT device, and verify that the message received from the IoT device is generated using the corresponding private key.

[0003] The subject matter claimed herein is not limited to embodiments that solve any disadvantages or that operate only in environments such as described above.Rather, this background is provided merely to illustrate one exemplary technology area where some embodiments described herein may be practiced. Summary of the invention

[0004] In some aspects, the technology described herein relates to a method for verifying proof of possession (POP) of a private key by a device, the method being implemented at a computer system including a processing system, the method comprising: generating a provisioning package including a POP challenge; receiving a device activation request for a device, the device activation request including a public key, a device identifier, and a signature; verifying the POP of a private key corresponding to the public key, including cryptographically verifying the signature using the public key, the device identifier, and the POP challenge; and establishing a trust relationship with the device, including registering the public key and the device identifier in a device directory.

[0005] In some aspects, the technology described herein relates to a computer system for verifying a POP of a device to a private key, the computer system comprising: a processing system; and a computer storage medium storing computer executable instructions executable by the processing system to cause the computer system to at least: generate a provisioning package including a POP challenge; receive a device activation request for a device, the device activation request including a public key, a device identifier, and a signature; verify the POP of a private key corresponding to the public key, including cryptographically verifying the signature using the public key, the device identifier, and the POP challenge; and establish a trust relationship with the device, including registering the public key and the device identifier in a device directory.

[0006] In some aspects, the technology described herein relates to a computer program product that includes a computer storage medium storing computer-executable instructions that are executable by a processing system to cause the computer system to verify a POP of a device to a private key, the computer-executable instructions including instructions that are executable by the processing system to cause the computer system to at least: generate a provisioning package including a POP challenge; receive a device activation request for a device, the device activation request including a public key, a device identifier, and a signature; verify the POP of a private key corresponding to the public key, including cryptographically verifying the signature using the public key, the device identifier, and the POP challenge; and establish a trust relationship with the device, including registering the public key and the device identifier in a device directory.

[0007] This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter. BRIEF DESCRIPTION OF THE DRAWINGS

[0008] In order to describe the manner in which the advantages and features of the systems and methods described herein can be obtained, a more particular description of the embodiments briefly described above will be presented by reference to specific embodiments thereof illustrated in the accompanying drawings. It should be understood that these drawings depict only typical embodiments of the systems and methods described herein and are therefore not to be considered limiting of the scope of the systems and methods, and the specific systems and methods will be described and explained with additional specificity and detail through the use of the accompanying drawings, in which:

[0009] Figure 1 An example computer architecture is illustrated that facilitates a POP for verifying a private key against a remote device;

[0010] Figure 2 An example process flow for generating device registration information for a POP providing a device private key is illustrated;

[0011] Figure 3 illustrates an example timing diagram for verifying a POP for a private key of a remote device; and

[0012] Figure 4 A flow chart of an example method for authenticating a device's POP to a private key is illustrated. DETAILED DESCRIPTION

[0013] When provisioning a remote device (such as an IoT device) into a service's device catalog, there are challenges around developing a trust relationship with the remote device's identity parameters. In particular, there are challenges around verifying that the identity parameters (such as a public key) presented for a given device actually correspond to a private key owned by the party registering the device. This is because, when a service receives a public key as an identity parameter for a remote device to be provisioned into a service's device catalog, possession of the public key does not provide any proof that the party registering the device actually possesses the device itself (or the private key corresponding to the device). As a result, a party may obtain a public key for a device that they do not have physical possession or control of (e.g., another party's device), provision the device into a device catalog for a service that they can access or control, and then capture communications between the service and the device and / or control the device. Additionally, traditional device provisioning is prone to error because if there is a mismatch between the public key registered for a device and the actual public key of the device during provisioning, a user may provision a device that will not be able to communicate later.

[0014] Traditionally, this challenge has been handled by separately verifying the authenticity of the device's public key during provisioning, such as based on a query to a certification authority (CA). However, separately verifying the authenticity of the device's public key requires communication with the CA, and therefore prevents remote devices from being provisioned to a service in an offline or asynchronous manner (e.g., where the service and remote device do not communicate directly during the provisioning process). Additionally, separately verifying the authenticity of the device's public key requires communication with the CA, which requires establishing a trust relationship with the CA.

[0015] The embodiments described herein provide for POP of a remote device's private key during provisioning of the remote device to a service's device catalog in a manner that does not require a separate public key verification mechanism (such as verification with a CA). Thus, the embodiments enforce that only those devices that have proven possession of their private key can be provisioned to a service's device catalog using their public key. Additionally, by not requiring a separate key verification mechanism, the embodiments enable remote devices to be reliably provisioned to a service in an offline or asynchronous manner.

[0016] Figure 1 An example computer architecture 100 is illustrated that facilitates verifying a POP of a private key for a remote device. As shown, the computer architecture 100 includes a computer system 101 that includes a processing system(s) 102 (e.g., a single processor, or multiple processors), a memory 103 (e.g., a system or main memory), a storage medium 104 (e.g., a single computer-readable storage medium, or multiple computer-readable storage media), and a network interface 105 (e.g., one or more network interface cards), all interconnected via a bus 106. Additionally, the computer system 101 communicates with one or other computer systems, such as a provisioning system 108, a device to be provisioned 109 (or multiple devices to be provisioned), and / or an admin system 110, via a network 107.

[0017] Storage medium 104 is illustrated as storing computer-executable instructions that implement at least directory service 111, and is illustrated as storing directory instance 112 (e.g., a device directory for a service such as a cloud service provided by computer system 101 or by some other computer system). In general, directory service 111 operates to provision a device 109 (e.g., an IoT device), including registering the device 109 into directory instance 112 as an activated device 114.

[0018] In embodiments, computer architecture 100 enables device 109 to be provisioned by directory instance 112 in a direct manner, wherein directory service 111 communicates directly with device 109 via network 107. In embodiments, computer architecture 100 additionally or alternatively enables device 109 to be provisioned by directory instance 112 in an indirect (e.g., offline) manner, wherein directory service 111 communicates directly with provisioning system 108 via network 107, and wherein provisioning system 108 then communicates with device 109. In these latter embodiments, use of provisioning system 108 enables device 109 to be activated into directory instance 112 even in environments (such as a factory floor, warehouse, secure location, etc.) where device 109 lacks wide area network (e.g., Internet) communication capabilities.

[0019] Figure 1 Pictured Figure 1 An example of internal components of directory service 111. Figure 1 Each internal component of the directory service 111 depicted in the 10 ...

[0020] exist Figure 1 In the embodiment, the directory service 111 includes a directory management component 121. In an embodiment, the directory management component 121 enables the directory service 111 to create, delete, and manage multiple directory instances. Figure 1 , storage medium 104 is shown as storing multiple catalog instances, including catalog instance 112. In an embodiment, catalog management component 121 interacts with management system 110 (or multiple management systems) to manage one or more catalog instances per customer, one or more catalog instances per tenant, one or more catalog instances per service, and so on.

[0021] Directory service 111 also includes a provisioning package generation component 118. In an embodiment, provisioning package generation component 118 generates one or more provisioning packages for each directory instance, such as provisioning package 113 for directory instance 112. As shown, provisioning package generation component 118 includes a POP challenge component 119 that generates a POP challenge for each provisioning package, and a directory identifier component 120 that inserts a directory identifier (e.g., identifying directory instance 112) into each provisioning package generated. Thus, in an embodiment, the provisioning packages include at least a POP challenge and a directory identifier - although they may also include additional information. In an embodiment, each POP challenge is a unique value generated for each provisioning package, such as a globally unique identifier (GUID) or a universally unique identifier (UUID).

[0022] Directory service 111 also includes device provisioning component 122. In an embodiment, device provisioning component 122 handles provisioning of a device based on communication with the device, such as device 109, and / or based on communication with a separate provisioning service, such as provisioning system 108. In general, device provisioning involves communicating a provisioning package to the device, which then uses at least a POP challenge within the provisioning package to generate a signature that proves that the device possesses a private key used to sign the POP challenge.

[0023] To illustrate the process, Figure 2 An example process flow 200 for generating device registration information for a POP providing a device private key is illustrated. The process flow 200 illustrates an example of a provisioning package 201 (e.g., generated by a provisioning package generation component 118), a device activation file 202 (e.g., generated by a device 109), and an activation package 203 (e.g., generated by a provisioning system 108). Of note, Figure 2 The various data fields illustrated in FIG. 1 are for illustrative purposes only, and one of ordinary skill in the art should understand that some data fields may be modified or even omitted without departing from the principles described herein.

[0024] Will combine Figure 3 To describe Figure 2 Processing flow 200, Figure 3 An example timing diagram 300 for verifying a POP for a private key of a remote device is illustrated. The timing diagram 300 includes management 301 (e.g., management system 110), directory server 302 (e.g., computer system 101), provisioner 303 (e.g., provisioning system 108), and device 304 (e.g., device 109). It is noted that while the timing diagram 300 includes management 301 and provisioner 303 for completeness, it should be understood that embodiments consistent with the disclosure herein may operate with only directory server 302 and device 304.

[0025] refer to Figure 3 At time T1, management 301 sends message 305 to directory server 302 requesting creation of a provisioning package for the identified device directory (e.g., directory instance 112). In response, at time T2, directory server 302 returns message 306 to management 301 confirming the request, and uses provisioning package generation component 118 to create the requested provisioning package for the device directory.

[0026] Figure 2 In the embodiment shown, provisioning package 201 includes a package identifier (ID) 204 , which is a unique identifier for provisioning package 201 . Figure 2Also shown, in an embodiment, provisioning package 201 also includes a catalog name 205 identifying the device catalog (eg, catalog instance 112) for which the provisioning package is created and to which devices consuming provisioning package 201 will be provisioned and activated. Figure 2 It is also shown that, in an embodiment, provisioning package 201 also includes endpoint 206 that specifies an endpoint uniform resource identifier (URI) for a service that is provided to a device activated using provisioning package 201 . Figure 2 Also shown, in an embodiment, provisioning package 201 also includes a POP challenge 207 (such as a random GUID value) that is used during device provisioning to verify possession of a private key in the device being provisioned. Figure 2 It is also shown that, in an embodiment, provisioning package 201 also includes expiration 208, which specifies an expiration date for the provisioning package and after which the provisioning package 201 cannot be used to activate a new device.

[0027] Figure 2 It is also shown that, in at least some embodiments, provisioning package 201 also includes a digest 209, such as a cryptographic hash (e.g., SHA1, SHA256, etc.) of one or more of package ID 204, directory name 205, endpoint 206, POP challenge 207, and expiration 208. In embodiments where digest 209 is included, digest 209 enables a recipient to verify the consistency of the data included within provisioning package 201. However, one of ordinary skill in the art will appreciate that digest 209 may be omitted from provisioning package 201.

[0028] In an example, the provisioning package is a file in JavaScript Object Notation (JSON) format, although a variety of formats may be used. In an example, the provisioning package file includes two blocks—a "provisioning" block that includes specific provisioning information and activation information, and a "hash" block that defines a hash value of the "provisioning" block.

[0029] Back to Figure 3 At time T3, provisioner 303 sends a message 307 to directory server 302 requesting a provisioning package. In response, at time T4, directory server 302 sends a message 308 with the requested provisioning package to provisioner 303. As indicated, in the example, message 308 may include a combination of Figure 2 The provisioning package 201 in question. At time T5, step 309 represents the provisioner 303 distributing the provisioning package 201 to one or more devices (such as IoT devices on a factory floor) for provisioning of the devices.

[0030] At time T6 , provisioner 303 sends message 310 to device 304 , requesting the device to generate device activation information (eg, device activation file 202 ) based on provisioning package 201 . Figure 2 As shown, in an embodiment, the device activation file 202 includes a network device ID 211 (e.g., the network device ID 115 of the device 109), which uniquely identifies the device 304 in the directory instance 112. In some embodiments, the network device ID 211 is a combination of the directory name 205 and a device hardware identifier (e.g., a media access control (MAC) address, a unique firmware-based identifier). Figure 2 Also shown, in an embodiment, device activation file 202 includes a public key 212 (e.g., authentication key (AK) 116 of device 109) associated with a private key owned by device 304. In an embodiment, public key 212 is a public AK and the associated private key is a private AK. Figure 2 Also shown, in an embodiment, the device activation file 202 includes a device type 213 that identifies the type (eg, model) of the device being provisioned. Figure 2 It is also shown that, in an embodiment, the device activation file 202 includes a signature 210 (e.g., the signature 117 of the device 109), and the signature 210 includes the signature of the POP challenge 207. In an embodiment, the content signed to generate the signature 210 follows the format of "network device ID + POP challenge". In an embodiment, the signed content also includes a prefix, which is a known constant value, so that the signature 210 follows the format of "prefix + network device ID + POP challenge".

[0031] Back to Figure 3 As a result of receiving message 310, device 304 performs step 311 of generating a device identifier (e.g., network device ID 211) at time T7, step 312 of generating an AK pair at time T8, and step 313 of generating a signature (e.g., signature 210) at time T9. It is worth noting that steps 311 and 312 may be reversed or performed in parallel. Additionally, in an embodiment, step 312 may be optional because device 304 may already have an AK pair. At time T10, device 304 sends message 314 with device activation information to provisioner 303. As indicated, in the example, message 314 may include a combination of Figure 2 The device activation file 202 in question.

[0032] At time T11, step 315 represents that provisioner 303 collects device activation information from one or more devices (such as IoT devices on the factory floor). At time T12, provisioner 303 sends message 316 to directory server 302, message 316 including device activation information for one or more devices (including device 304).

[0033] In some embodiments, the device activation information includes one or more device activation files, such as device activation file 202 (e.g., as a compressed (zip) file of different device activation files, plus the original provisioning package). In other embodiments, the device activation information is an activation package that includes device activation information for one or more devices in a single file. Figure 2 As shown, in an embodiment, activation package 203 includes package ID 204 from provisioning package 201 and one or more registrations (e.g., registrations 214a through 214n). As shown, in an embodiment, each registration includes information from a corresponding device activation file. Similar to provisioning package 201, device activation file 202 may include a digest that enables a recipient to verify the consistency of the data included in activation package 203.

[0034] Back to Figure 3 As a result of receiving message 316, at time T13, directory server 302 verifies the device activation information obtained in message 316 at step 317. Then, at time T14, directory server 302 sends message 318 to provisioner 303, which acknowledges and / or confirms the provisioning of the device(s) identified in message 316.

[0035] In an embodiment, at step 317, the device provisioning component 122 uses the public key (e.g., public key 212) and the network device ID (e.g., network device ID 211) received as part of the device activation information (device activation file 202) for each device to verify the signature (e.g., signature 210) generated by the device. If the signature is valid, the device provisioning component 122 registers the device as an activated device 114.

[0036] Notably, in timing diagram 300, directory server 302 could have communicated directly with device 304, eliminating provisioner 303. However, the inclusion of provisioner 303 makes the process asynchronous, enabling device 304 to be provisioned even if it is offline (e.g., unable to communicate with directory server 302).

[0037] Now combine Figure 4 Describe the embodiments, Figure 4A flow chart of an example 400 of a method for verifying a device's POP to a private key is illustrated. As shown, example 400 includes method 400a (e.g., actions 401 to 404) performed at a server (e.g., computer system 101), and method 400b (e.g., actions 405 to 409) performed at a device (e.g., device 109). In some embodiments, method 400a and method 400b are independent methods. In other embodiments, method 400a and method 400b are each part of a single method.

[0038] In an embodiment, instructions for implementing method 400a and method 400b are encoded as computer executable instructions stored on a computer storage medium (e.g., directory service 111), which can be executed by a processing system to cause a computer system (e.g., computer system 101, device 109) to perform the method. The following discussion now refers to multiple methods and method actions. Although method actions can be discussed in a certain order, or can be shown in a flowchart as appearing in a specific order, unless specifically stated or because an action depends on another action being completed before performing the action, a specific order is not required.

[0039] Referring first to the directory service 111, the method 400a includes an act 401 of generating a POP challenge. In some embodiments, the act 401 includes generating a provisioning package including the POP challenge. In an example, the provisioning package generation component 118 generates the provisioning package 201, including using the POP challenge component 119 to generate the POP challenge 207. By generating the POP challenge 207, the act 401 has the effect of generating information that can be used by a remote device to prove that it possesses a private key corresponding to a public key that is used to identify the remote device.

[0040] In some embodiments of method 400a, the provisioning package also includes a catalog identifier. In an example, provisioning package generation component 118 uses catalog identifier component 120 to insert catalog name 205 (e.g., of catalog instance 112) into provisioning package 201. In an example, provisioning package generation component 118 generates package ID 204 and inserts package ID 204 into provisioning package 201.

[0041] In some embodiments, directory service 111 sends the provisioning package (including the POP challenge generated in act 401) to a provisioning system (such as provisioning system 108). Thus, in some embodiments, method 400a further includes sending the provisioning package to the provisioning system. In other embodiments, directory service 111 sends the provisioning package (including the POP challenge generated in act 401) to a device to be provisioned (such as device 109). Thus, in some embodiments, method 400a further includes sending the provisioning package to the remote device to be provisioned.

[0042] Method 400a also includes an act 402 of receiving an activation request for a device. In some embodiments, act 402 includes receiving a device activation request for a device after generating a provisioning package, the device activation request including a public key, a device identifier, and a signature. In an example, device provisioning component 122 receives the information shown in device activation file 202 as part of the device activation request.

[0043] In some embodiments, such as when directory service 111 sends a provisioning package to a provisioning system, method 400a includes receiving an activation package (e.g., activation package 203) from the provisioning system. In an embodiment, the activation package includes multiple device activation requests for multiple devices (e.g., registrations 214a to 214n), and the device activation requests include a device activation request for a device (e.g., registration 214a). In other embodiments, such as when directory service 111 sends a provisioning package to a device to be provisioned, method 400a includes receiving a device activation request (e.g., device activation file 202) directly from the device.

[0044] Method 400a also includes an act 403 of verifying the POP of the device private key using the POP challenge. In some embodiments, act 403 includes verifying the POP of the private key corresponding to the public key, including cryptographically verifying the signature using at least the public key and the POP challenge. In an example, the device provisioning component 122 verifies that the signature 210 received in the device activation request (e.g., device activation file 202) is (1) encrypted by the private key corresponding to the public key 212 received in the device activation (e.g., by obtaining a first digest based on decrypting the signature using the public key), and (2) is generated based on the POP challenge 207 generated in act 401 (e.g., by calculating a second digest of at least the POP challenge, and determining that the first digest and the second digest are equal). In some embodiments, act 403 also includes cryptographically verifying the signature using the device identifier. For example, the device provisioning component 122 verifies that the signature 210 received in the device activation request is generated based on a combination of at least the device identifier and the POP challenge.

[0045] As mentioned, in some embodiments, the provisioning package also includes a catalog identifier (e.g., catalog name 205). In this embodiment, the device identifier (e.g., network device ID 211) includes a combination of at least the catalog identifier and a device-specific identifier (e.g., a device hardware identifier such as a MAC address or a unique firmware-based identifier).

[0046] The method 400a also includes an act 404 of establishing a trust relationship with the device. In some embodiments, act 404 includes establishing a trust relationship with the device, including registering at least a public key and a device identifier in a device directory. In an example, based on the POP verifying the device private key in act 403, the device provisioning component 122 establishes a trust relationship with the device 109 by registering the device 109 as an activated device 114 within the directory instance 112. In one example, the device provisioning component 122 stores the device activation file 202, or a portion thereof, in the directory instance 112.

[0047] like Figure 2 As shown in , in an embodiment, the activation package 203 includes a package ID 204, which is a unique identifier for the provisioning package 201. In this embodiment, the device provisioning component 122 associates the network device ID 211 with the package ID 204 within the directory instance 112. Therefore, in an embodiment, the provisioning package also includes the provisioning package identifier, and registering the public key and the device identifier in the device directory includes associating the device identifier with the provisioning package identifier. Notably, this association enables the directory maintainer to manage all devices registered under a specific package ID 204 as a group, such as to revoke all devices if it is discovered that the provisioning system to which the package ID 204 was sent is compromised or malicious.

[0048] Referring now to device 109, method 400b includes an act 405 of generating a key pair. In some embodiments, act 405 includes generating an asymmetric key pair, including a public key and a private key. In an embodiment, the asymmetric key pair is an AK pair, including a public AK and a private AK.

[0049] Method 400b also includes an act 406 of generating a device identifier. In some embodiments, act 406 includes generating a device identifier by combining at least a directory identifier and a device-specific identifier based at least on receiving a provisioning package. In an example, device 109 receives provisioning package 201 directly from computer system 101 or via provisioning system 108. Device 109 then generates network device ID 211 using directory name 205 together with a device-specific identifier (e.g., a device hardware identifier such as a MAC address or a unique firmware-based identifier).

[0050] The method 400b also includes an act of receiving a POP challenge 407. In an example, the device 109 receives the provisioning package 201 from the computer system 101 directly or via the provisioning system 108, the provisioning package 201 including the POP challenge 207.

[0051] It is worth noting that no specific order is illustrated between action 405, action 406, and action 407. Therefore, in various embodiments, these actions are performed in a different order or in parallel.

[0052] Method 400b also includes an act 408 of generating a signature. In some embodiments, act 408 includes generating a signature using a private key based at least on receiving the provisioning package. In an example, the device uses at least the POP challenge 207 received in act 407 to create a message, generates a digest for the message, and encrypts the digest using the device's private key (e.g., generated in act 405) to create a signature. Thus, in an embodiment, act 408 includes generating a signature by generating a first digest for at least the POP challenge and encrypting the first digest using the private key based at least on receiving the provisioning package. This has the effect of proving to a party (e.g., computer system 101) that receives the message and possesses the POP challenge 207 that the device 109 possesses the private key used to generate the signature.

[0053] In some embodiments, when creating the message, device 109 also uses at least the network device ID 211 generated in action 406. Thus, in an embodiment, action 408 includes generating a signature based at least on receiving the provisioning packet by generating a first digest for a combination of at least the POP challenge and the device identifier and encrypting the first digest using the private key. Since the device identifier is based on the directory identifier, this has the additional effect of tying the activation of the device to a particular directory (such as directory instance 112).

[0054] Method 400b also includes an act of generating a device activation file 409. In an example, device 109 generates device activation file 202 and sends the file to provisioning system 108 (which uses the file to generate activation package 203) or directly to computer system 101.

[0055] Embodiments of the present disclosure may include or utilize a specific or general-purpose computer system (e.g., computer system 101) that includes computer hardware, such as, for example, one or more processors (e.g., processing system 102) and system memory (e.g., memory 103), as discussed in more detail below. Embodiments within the scope of the present disclosure also include physical computer-readable media and other computer-readable media for carrying or storing computer-executable instructions and / or data structures. Such computer-readable media can be any available media that can be accessed by a general or specific computer system. Computer-readable media that store computer-executable instructions and / or data structures are computer storage media (e.g., storage media 104). Computer-readable media that carry computer-executable instructions and / or data structures are transmission media. Therefore, by way of example, embodiments of the present disclosure may include at least two distinct types of computer-readable media: computer storage media and transmission media.

[0056] Computer storage media are physical storage media that store computer executable instructions and / or data structures. Physical storage media include computer hardware, such as random access memory (RAM), read-only memory (ROM), electrically erasable programmable ROM (EEPROM), solid-state drive (SSD), flash memory, phase change memory (PCM), optical disk storage, magnetic disk storage or other magnetic storage devices, or any other (multiple) hardware storage devices that can be used to store program code in the form of computer executable instructions or data structures, which can be accessed and executed by a general or specific computer system to implement the disclosed functions.

[0057] Transmission medium can comprise network and / or data link, and it can be used for carrying program code with computer executable instruction or data structure form, and it can be accessed by general or specific computer system." network " is defined as one or more data links that enable the transmission of electronic data between computer system and / or module and / or other electronic equipment.When transmitting or providing information to computer system by network or another communication connection (hardwire, wireless or hardwire or wireless combination), computer system can be considered as transmission medium by this connection.Above-mentioned combination also should be included in the scope of computer-readable medium.

[0058] In addition, upon reaching various computer system components, program code in the form of computer executable instructions or data structures can be automatically transferred from the transmission medium to the computer storage medium (or vice versa). For example, computer executable instructions or data structures received over a network or data link can be cached in RAM within a network interface module (e.g., network interface 105), and then ultimately transferred to the computer system RAM and / or less volatile computer storage media at the computer system. Therefore, it should be understood that computer storage media can be included in computer system components that also (or even primarily) utilize transmission media.

[0059] Computer executable instructions include, for example, instructions and data that, when executed at one or more processors (processing systems), cause a general purpose computer system, a specific computer system, or a specific processing device to perform a certain function or group of functions. Computer executable instructions may be, for example, binary code, intermediate format instructions such as assembly language, or even source code.

[0060] It should be understood that the disclosed system and method can be practiced in a network computing environment with many types of computer system configurations, including personal computers, desktop computers, laptop computers, message processors, handheld devices, multiprocessor systems, microprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframe computers, mobile phones, PDAs, tablet computers, pagers, routers, switches, etc. The embodiments of the present disclosure can also be practiced in a distributed system environment, where a local computer system and a remote computer system that are linked (by a hardwired data link, a wireless data link, or by a combination of a hardwired data link and a wireless data link) through a network perform tasks. Thus, in a distributed system environment, a computer system can include multiple component computer systems. In a distributed system environment, a program module can be located in a local memory storage device and a remote memory storage device.

[0061] It should also be understood that embodiments of the present disclosure can be practiced in a cloud computing environment. The cloud computing environment can be distributed, although this is not required. When distributed, the cloud computing environment can be distributed internationally within an organization and / or have components owned across multiple organizations. In this specification and the appended claims, "cloud computing" is defined as a model for enabling on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services). The cloud computing model can be composed of various features, such as on-demand self-service, extensive network access, resource pools, rapid elasticity, measurement services, etc. The cloud computing model can also appear in the form of various service models, such as, for example, software as a service (SaaS), platform as a service (PaaS), and infrastructure as a service (IaaS). The cloud computing model can also be deployed using different deployment models (such as private cloud, community cloud, public cloud, hybrid cloud, etc.).

[0062] Some embodiments, such as a cloud computing environment, may include a system that includes one or more hosts that are each capable of running one or more virtual machines. During operation, the virtual machines emulate an operational computing system, supporting an operating system and possibly one or more other applications. In some embodiments, each host includes a hypervisor that emulates virtual resources for the virtual machines using physical resources abstracted from the virtual machine's view. The hypervisor also provides appropriate isolation between virtual machines. Thus, from the perspective of any given virtual machine, the hypervisor provides the illusion that the virtual machine is interfacing with physical resources, even though the virtual machine is only interfacing with the appearance of physical resources (e.g., virtual resources). Examples of physical resources include processing power, memory, disk space, network bandwidth, media drives, and the like.

[0063] Although the subject matter has been described in language specific to structural features and / or method actions, it should be understood that the subject matter defined in the appended claims is not necessarily limited to the described features or the actions described above, or the order of the actions described above. Instead, the described features and actions are disclosed as example forms of implementing the claims.

[0064] The present disclosure may be embodied in other specific forms without departing from its essential features. The described embodiments are considered in all respects to be illustrative only and not restrictive. All changes that appear within the meaning and scope of the equivalence of the claims should be included within their scope.

[0065] When introducing an element in the appended claims, the articles "a", "an", "the", and "said" are intended to mean that there are one or more of the elements. The terms "comprise", "comprising", and "having" are intended to be inclusive, and mean that there may be additional elements in addition to the listed elements. Unless otherwise specified, the terms "set", "superset", and "subset" are intended to exclude empty sets, and therefore "set" is defined as a non-empty set, "superset" is defined as a non-empty superset, and "subset" is defined as a non-empty subset. Unless otherwise specified, the term "subset" excludes its entire superset (that is, the superset includes at least one item that is not included in the subset). Unless otherwise specified, a "superset" may include at least one additional element, and a "subset" may exclude at least one element.

Claims

1. A method for verifying proof of possession (POP) of a private key by a device, the method being implemented at a computer system including a processor, the method comprising: Generate a provisioning package including the POP challenge; receiving a device activation request for a device, the device activation request comprising a public key, a device identifier, and a signature; verifying the POP of the private key corresponding to the public key, comprising: cryptographically verifying the signature using the public key, the device identifier, and the POP challenge; and Establishing a trust relationship with the device includes registering the public key and the device identifier in a device directory.

2. The method of claim 1, wherein the provisioning package further comprises a catalog identifier, and wherein the device identifier comprises a combination of at least the catalog identifier and a device-specific identifier.

3. The method of claim 1 , wherein the provisioning package further comprises a provisioning package identifier, and wherein registering the public key and the device identifier in the device directory comprises: The device identifier is associated with the provisioning package identifier.

4. The method of claim 1, wherein based at least on receiving the provisioning package, the device generates the device identifier by combining at least a catalog identifier and a device-specific identifier.

5. The method of claim 1, wherein based at least on receiving the provisioning package, the device generates the signature using the private key.

6. The method of claim 1 , wherein cryptographically verifying the signature using the public key, the device identifier, and the POP challenge comprises: obtaining a first digest by decrypting the signature using the public key; calculating a second digest of at least the combination of the POP challenge and the device identifier; as well as It is determined that the first digest and the second digest are equal.

7. The method of claim 6, wherein based at least on receiving the provisioning package, the device generates the signature by: generating the first digest for a combination of at least the POP challenge and the device identifier; and The first digest is encrypted using the private key.

8. The method according to claim 1, further comprising: sending the provisioning package to a provisioning system; as well as An activation package is received from the provisioning system, the activation package comprising a plurality of device activation requests for a plurality of devices, the plurality of device activation requests including the device activation request for the device.

9. The method according to claim 1, further comprising: sending the provisioning package to the device; as well as The device activation request is received from the device.

10. A computer system for verifying proof of possession (POP) of a private key by a device, comprising: Processing systems; as well as A computer storage medium storing computer executable instructions executable by the processing system to cause the processing system to at least: Generate a provisioning package including the POP challenge; receiving a device activation request for a device, the device activation request comprising a public key, a device identifier, and a signature; verifying a POP of a private key corresponding to the public key, including cryptographically verifying the signature using the public key, the device identifier, and the POP challenge; as well as Establishing a trust relationship with the device includes registering the public key and the device identifier in a device directory.

11. The computer system of claim 10, wherein the provisioning package further comprises a catalog identifier, and wherein the device identifier comprises a combination of at least the catalog identifier and a device-specific identifier.

12. The computer system of claim 10, wherein the provisioning package further comprises a provisioning package identifier, and wherein registering the public key and the device identifier in the device directory comprises associating the device identifier with the provisioning package identifier.

13. The computer system of claim 10, wherein based at least on receiving the provisioning package, the device generates the device identifier by combining at least a catalog identifier and a device-specific identifier.

14. The computer system of claim 10, wherein based at least on receiving the provisioning package, the device generates the signature using the private key.

15. The computer system of claim 10, wherein cryptographically verifying the signature using the public key, the device identifier, and the POP challenge comprises: obtaining a first digest by decrypting the signature using the public key; calculating a second digest of at least the combination of the POP challenge and the device identifier; as well as It is determined that the first digest and the second digest are equal.

Images