BACKGROUND

[0001] Blockchain distributed ledgers may be used to cryptographically sign transactions. Each transaction may be cryptographically signed with a hash of the preceding transaction. Adding a new record to the block chain involves verification and approval of multiple nodes within the blockchain service.

BRIEF DESCRIPTION OF THE DRAWINGS

[0002] FIG. 1 illustrates an authorization device, according to an example;

[0003] FIG. 2 is a block diagram of an authorization system, according to an example;

[0004] FIG. 3 is an activity diagram showing interactions within an authorization system according to an example; and

[0005] FIG. 4 is a computing device for supporting instructions for an authorization system, according to an example.

DETAILED DESCRIPTION

[0006]Blockchains services are distributed cryptographic ledgers. In some implementations, blockchains may utilize smart contracts to establish a set of rules that are applied and enforced when adding records to the ledger. The rule associated with the smart contract may be enforced without requiring human intervention or approval. A blockchain service that implements smart contracts may be a private or permissioned blockchain. In private or permissioned blockchains, access control is applied as to what entities are allowed to participate in the blockchain service network, submit transactions, view information within the transaction as well as who can execute the consensus protocol and maintain the distributed cryptographic ledger. [0007]As described herein, is an authorization service that utilizes blockchain technology to provision or bootstrap device identities with the context of the blockchain service smart contract. The provisioned device identities may then be used to authorize subsequent access to the resources of the blockchain service and network.

[0008] In some implementations, the authorization service may correspond to the initialization of a computing device within a factory or a place of manufacture for the computing device. The enrolling device may correspond to a computing device, not limited by form factor. For example, the enrolling device may be a personal computer, a mobile device such as a mobile phone, or an internet of things (loT) device. The authorization service may correspond to a system within the factory or place of manufacture that identifies and authorizes an enrolling device. For example, the authorization service may be an authorization device existing within the factory or place of manufacture that is networked with the enrolling device. The networking in this example, may correspond to a limited local area network, where the enrolling device and the authorization device exist on the same subnet. The authorization device may have information in the form of a database corresponding to each enrolling device being produced in the factor or place of manufacture. For example, the authorization device may incorporate serial and part numbers within the aforementioned database. The authorization device may tie those serial and part numbers to subscribed services purchased and provisioned by a customer.

[0009] In another implementation, the authorization service may correspond to a non-factory-based server to authorize enrolling devices post manufacture. The authorization service may correspond to an internet enabled authorization system. The authorization service may incorporate a database of authorized devices based on subscriber information to be authorized. The enrolled device may be blockchain enabled. The enrolled device may incorporate interfaces to allow it to communicate with the authorization service and the blockchain service. The interfaces may be installed as software or firmware packages during the lifetime of the device, including post-manufacture and at the request of a user. [0010] In one example, an authorization device may include a processor and memory. The memory may include computer readable instructions that cause the processor to receive a secure enrollment request, validate the secure enrollment request, and export the secure enrollment request to a blockchain service.

[0011] In another example, a system may include an enrolling device, an authorization service, and a blockchain service. The authorization service may be communicatively coupled to the enrolling device. The authorization service may receive a first blockchain transaction request (BTR) from the enrolling device. The authorization service may validate the first BTR against a known authorization credential. The authorization service generates a second BTR and creates a blockchain batch. The blockchain service receives the blockchain batch from the authorization service. The blockchain service validates the blockchain batch, the first BTR and the second BTR. Upon validation, the blockchain service creates a blockchain ledger record.

[0012] In another example, a non-transitory computer readable medium may include instructions executable by a processor. The instruction may cause the processor to recreate a first BTR. The processor may send the first BTR to an authorization service. The processor may receive the first BTR confirmation from the authorization service. The processor may validate the first BTR confirmation. The processor may delete the first BTR and related data corresponding to the first BTR. The processor may schedule a registration validation when a blockchain service is available. The processor may execute a query corresponding to the blockchain service.

[0013] FIG. 1 illustrates an authorization device 100, according to an example. The processor 102 of the device 100 may be implemented as dedicated hardware circuitry or a virtualized logical processor. The dedicated hardware circuitry may be implemented as a central processing unit (CPU). A dedicated hardware CPU may be implemented as a single to many-core general purpose processor. A dedicated hardware CPU may also be implemented as a multi-chip solution, where more than one CPU are linked through a bus and schedule processing tasks across the more than one CPU. [0014]A virtualized logical processor may be implemented across a distributed computing environment. A virtualized logical processor may not have a dedicated piece of hardware supporting it. Instead, the virtualized logical processor may have a pool of resources supporting the task for which it was provisioned. In this implementation, the virtualized logical processor may be executed on hardware circuitry; however, the hardware circuitry is not dedicated. The hardware circuitry may be in a shared environment where utilization is time sliced. In some implementations the virtualized logical processor includes a software layer between any executing application and the hardware circuitry to handle any abstraction which also monitors and save the application state. Virtual machines (VMs) may be implementations of virtualized logical processors.

[0015] A memory 104 may be implemented in the device 100. The memory 104 may be dedicated hardware circuitry to host instructions for the processor 102 to execute. In another implementation, the memory 104 may be virtualized logical memory. Analogous to the processor 102, dedicated hardware circuitry may be implemented with dynamic random-access memory (DRAM) or other hardware implementations for storing processor instructions. Additionally, the virtualized logical memory may be implemented in a software abstraction which allows the instructions 106 to be executed on a virtualized logical processor, independent of any dedicated hardware implementation.

[0016] The device 100 may also include instructions 106. The instructions 106 may be implemented in a platform specific language that the processor 102 may decode and execute. The instructions 106 may be stored in the memory 104 during execution. The instructions may include operations executable by the processor to effectuate the authorization service. The instructions when executed may enable the processor to receive a secure enrollment request 108, validate the secure enrollment request 110, and export the secure enrollment request to a blockchain service 112.

[0017] The authorization device 100 may receive a secure enrollment request 108. The secure enrollment request may correspond to a standardized or non- standardized request to access the blockchain service. A standardized request may correspond to a blockchain transaction request (BTR) where the structure of the request is dictated by the blockchain service. A non-standardized request may correspond to a request that is not specific to a blockchain service, but instead is targeted to an interface of the authorization service. Thus, a non-standardized request may have a defined structure so the authorization service may decode and parse the request, however, the request is not structured in a way to interface directly with the blockchain service. Examples of standardized BTRs may include javascript object notation (JSON) formatted requests or Google Protocol Buffer (protobuf) formatted request, where the request includes a blockchain service verifiable payload that is digitally signed.

[0018] The authentication device 100 may also validate the secure enrollment request 110. The authentication device 100 may use a database to validate the secure enrollment request 110. The authentication device 100 may decode and parse the secure enrollment request. Within the secure enrollment request may be included unique identifiers corresponding to the enrolling device transmitting the request. In some implementations, the identifiers may correspond to a serial number or part number or a combination of identifiers. The identifiers may provide a mechanism for the authenticating device 100 to uniquely identify the enrolling device. The secure enrollment request may include a digital signature from the enrolling device. The digital signature may be generated by a pair of private and public keys associated with the enrolling device. In one implementation, the private and public keys may be generated by a Trusted Platform Module (TPM). The secure enrollment request may be signed by the private key of the enrolling device. The authentication device 100 may compare the identifiers encoded in a payload of the secure enrollment request to a database corresponding to subscribing devices which should be authorized to interface with the blockchain service.

[0019] The authentication device 100 may also export the secure enrollment request to a blockchain service 112. The authentication device 100 upon validating the secure enrollment request 110 may transmit the secure enrollment request to the blockchain service. In some implementations, where the secure enrollment request is properly formatted for reception to the blockchain service, the secure enrollment request may be directly forwarded. In another implementation, where the secure enrollment request is not formatted in a blockchain service accessible manner, the authentication device 100 may reformat the secure enrollment request to a format more appropriate for the blockchain service to process. In another implementation, the authentication device 100 may utilize a properly formatted secure enrollment request, such as a BTR, and submit the first BTR, of the secure enrollment request, and a second BTR, corresponding to the authentication device 100, to the blockchain service. The second BTR indicates the authentication device 100 has validated the enrolling device of the first BTR and that the first BTR may be included in a blockchain transaction. In another implementation, the first and second BTRs may be incorporated to a blockchain batch to be communicated to the blockchain service.

[0020] FIG. 2 is a block diagram of an authorization system 200, according to an example. The authorization system 200 may include one or more enrolling device 202, an authorization service 204, and a blockchain service 208. The authorization service 204 may be hosted on an authorization device 100 as described in reference to FIG. 1. The functionality described in reference to the authorization device 100 may be incorporated into the authorization service 204.

[0021]An enrolling device 202 may be a computing device. As described above, the enrolling device 202 may be a device within a factory floor being produced for sale. The enrolling device 202 may be communicatively coupled to an authorization service 204. The enrolling device 202 may be coupled via a networking protocol. In some implementations, the networking may be implemented by wired or wireless technology as a physical medium. In one implementation the enrolling device 202 may communicate with the authorization service 204 via a wireless WiFi connection. In another implementation, the enrolling device 202 may communicate through a near field communication (NFC) or Bluetooth® connection. Plainly speaking, the networking connection may be capable of carrying a secure enrollment request from the enrolling device 202 to the authentication service 204.

[0022] The enrolling device 202 may also incorporate functionality for generating cryptographic key pairs where the key pairs consist of a private key and a public key. In some implementations, the enrolling device 202 may utilize a Trusted Platform Module (TPM) to generate the key pairs. In other implementations, the key pair may be generated in software or firmware, whereby the enrolling device 202 protects the confidentiality of the private key, as well as the integrity of both keys. As mentioned previously, the enrolling device 202 may also have installed software or firmware to interface with the blockchain service 208. The software or firmware may be an blockchain client application, or a blockchain client interface wherein libraries utilized for generating, sending, receiving and parsing are available to a client application.

[0023]An authorization service 204 may be communicatively connected to both the enrolling device 202 and the blockchain service 208. The connection to the blockchain service 208 may be virtualized as any connection to one or more blockchain nodes 206A, 206B, 206N may constitute a connection to the blockchain service 208. As mentioned previously the authentication service 204 may be implemented as an authentication device 100. The authentication service 204 may also be implemented virtually, wherein the authentication service 204 may be implemented as a system across multiple devices. For efficient use of computing resources, the authentication service 204 may be collocated with other services operating in the same virtualized environment or on the same physical authentication device 100. The authentication service 204 may be configured to receive a first BTR from the at least one enrolling device. The first BTR corresponds to the enrolling device, carries a payload of identifiers of the enrolling device, and incorporates a signature from the private key of the enrolling device. The authorization service 204 validates the payload of the first BTR as an authorized enrolling device by comparing the identifiers in the payload (e.g. serial numbers, part numbers, etc.) against a database of the authorization service 204 which incorporates known authorized devices. The authorization service 204 also validates timestamps associated with the first BTR to detect and avoid security issues with the reception first BTR. If a generated timestamp within the first BTR payload is compared to a receipt timestamp at the authorization service 204 and exceeds a threshold, the first BTR may be discarded. If the difference between timestamps does not exceed a threshold, the authorization service 204 may process the first BTR.

[0024] Upon validation of the first BTR, in some implementations, the authorization service 204 may generate a second BTR. The second BTR may incorporate a payload corresponding to the identifiers inclusive to the first BTR, as well as the timestamp receipts, and other metadata. In the factory floor implementation, the metadata may include a factory facility identifier, and additional information about the enrolling unit as described in the database of the authentication service 204. The second BTR may be signed by private key associated with the authentication service 204.

[0025] In another implementation, the authentication service 204 may create a blockchain batch including the first BTR and the second BTR. The blockchain batch may be signed by the batcher (in this example, the authentication service 204). All transaction requests submitted within the batch may be committed together, or not at all. In this implementation, if the blockchain batch is accepted by the blockchain service 208, then the first BTR and the second BTR are also accepted. As submitted in a batch, the first BTR nor the second BTR may be accepted or committed without the other BTR.

[0026]A blockchain service 208 may provide the interface to receive, validate, and store any BTRs. The blockchain service 208 may implement smart contracts to facilitate the verification of the enrolled devices. Smart contract rules allow for enrolled devices to participate in the blockchain service. The smart contract rules may perform the validation on individual blockchain transaction requests after registration as well as validating any blockchain batches from the authentication service 204.

[0027] The blockchain service 208 may be implemented in blockchain nodes 206A, 206B, 206N. Each of the blockchain nodes 206A, 206B and 206N may store copies of the digital cryptographic ledger and may enforce the rules of the smart contracts against any received BTRs. The blockchain nodes 206A, 206B and 206N are illustrated here as one implementation of the blockchain service 208.

[0028] FIG. 3 is an activity diagram 300 showing interactions within an authorization system 200 according to an example. In one example, the enrolling device 202, the authorization service 204 and the blockchain service 208 may be implemented as the examples described in reference to FIG. 2. As described above, the enrollment may take place in a factory in an example. Likewise, the process illustrated in FIG.

3, may take place after the point of sale, utilizing a client software (or firmware) package to enroll a device into a blockchain service 208. [0029] Enrolling device 202 may generate a key pair at block 302. As described above the enrolling device 202 may utilize a TPM to generate and secure a private and public key, according to an example. Likewise, the enrolling device 202 may additionally package a request. The request may be of a BTR format or may take a different form such that the authentication service 204 may parse and interpret any payload encoded within the request. The enrolling device 202 may transmit the request 304 to the authorization service 204.

[0030] The authorization service 204 may receive the request as a BTR or another format. The authorization service 204 may decode and verify the payload of the received request at block 306. The payload may be verified as to the access level of the enrolling device 202 within the blockchain service 208. The payload may also be verified based on timestamp indicating that the request was received within a set period of time. The authorization service 204 may create a second BTR request at block 306 as described in reference to FIG. 2. Likewise, in another example, the authorization service 204 may create a blockchain batch at block 306 including the first request (in BTR format) and the second BTR. The authorization service 204 then transmits 308, the request, the first BTR, the second BTR or the blockchain batch to the blockchain service 208.

[0031]The blockchain service 310 validates and accepts the received request from the authorization service 204 at block 310. In one implementation, the blockchain service 208 may validate the blockchain batch, the first BTR and the second BTR. The blockchain service 208 utilizes a rules-based approach implemented in smart contract form to determine whether to accept the transaction from the authorization service 206. The received request from the authentication service 204 may be in a format and may include acceptable criteria to pass the rules of the applicable smart contract. Upon validation, the blockchain service 208 may add any transactions received from the authentication service 204 to the distributed cryptographic ledger. The blockchain 208 transmits a confirmation message 312 to the authorization service 204. The confirmation message includes information corresponding to the request sent. The confirmation message indicates to the authentication service 204 that the request was accepted into by the blockchain service 208. The authorization service 204 validates the confirmation message at block 314. The validation may include verifying an identifier from the confirmation message and correlating the identifier to the correspond sent request.

[0032] Upon receipt and validation of the confirmation message, the authorization service 204 sends a confirmation message316 to the enrolling device. Similar to the confirmation received at the authorization service 204, the enrolling device 202 validates the confirmation message received at block 318. In one example, the enrolling device 202 may receive a confirmation message corresponding to the first BTR transmitted to the authorization service 204. Upon validating the confirmation message corresponds to the first request, the enrolling device 202 may clean up references to the first request (or first BTR) as well as any information related to the creation of the first BTR. The enrolling device may schedule a validation of the overall transaction when direct communication to the blockchain service 208 may be established. In one implementation, the direct communication channel may be the internet. The now enrolled device (enrolling device 202) upon leaving the factory and may be utilized to interact directly with the blockchain service 208. As such, the now enrolled device (enrolling device 202) may query the blockchain service 208 utilizing tools provided by the blockchain service 208 to examine contents of the ledger.

[0033] FIG. 4 is a computing device 400 for supporting instructions for an authorization system, according to an example. The computing device 400 depicts a processor 102 and a storage medium 404 and, as an example of the computing device 400 performing its operations, the storage medium 404 may include instructions 406-418 that are executable by the processor 102. The processor 102 may be synonymous with the processor 102 referenced in FIG. 1. Additionally, the processor 102 may include but is not limited to central processing units (CPUs). The storage medium 404 can be said to store program instructions that, when executed by processor 102, implement the components of the computing device 400.

[0034] The executable program instructions stored in the storage medium 404 include, as an example, instructions to create a first blockchain transaction record 406, instructions to send the first BTR to an authorization service 408, instructions to receive the first BTR confirmation from the authorization service 410, instructions to validate the first BTR confirmation 412, instructions to delete the first BTR and related data corresponding to the first BTR 414, instructions to schedule a registration validation when a blockchain service is available 416, and instructions to execute a query corresponding to the blockchain service 418.

[0035] Storage medium 404 represents generally any number of memory components capable of storing instructions that can be executed by processor 102. Storage medium 404 is non-transitory in the sense that it does not encompass a transitory signal but instead is made up of at least one memory component configured to store the relevant instructions. As a result, the storage medium 404 may be a non-transitory computer-readable storage medium. Storage medium 404 may be implemented in a single device or distributed across devices. Likewise, processor 102 represents any number of processors capable of executing instructions stored by storage medium 404. Processor 102 may be integrated in a single device or distributed across devices. Further, storage medium 404 may be fully or partially integrated in the same device as processor 102, or it may be separate but accessible to that computing device 400 and the processor 102.

[0036] In one example, the program instructions 406-418 may be part of an installation package that, when installed, can be executed by processor 102 to implement the components of the computing device 400. In this case, storage medium 404 may be a portable medium such as a CD, DVD, or flash drive, or a memory maintained by a server from which the installation package can be downloaded and installed. In another example, the program instructions may be part of an application or applications already installed. Here, storage medium 404 can include integrated memory such as a hard drive, solid state drive, or the like.

[0037] It is appreciated that examples described may include various components and features. It is also appreciated that numerous specific details are set forth to provide a thorough understanding of the examples. However, it is appreciated that the examples may be practiced without limitations to these specific details. In other instances, well known methods and structures may not be described in detail to avoid unnecessarily obscuring the description of the examples. Also, the examples may be used in combination with each other. [0038] Reference in the specification to “an example” or similar language means that a particular feature, structure, or characteristic described in connection with the example is included in at least one example, but not necessarily in other examples. The various instances of the phrase “in one example” or similar phrases in various places in the specification are not necessarily all referring to the same example.

[0039] It is appreciated that the previous description of the disclosed examples is provided to enable any person skilled in the art to make or use the present disclosure. Various modifications to these examples will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other examples without departing from the scope of the disclosure. Thus, the present disclosure is not intended to be limited to the examples shown herein but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.