BLOCKCHAIN BASED DISTRIBUTION CHANNEL FOR CA CERTIFICATES
FIELD OF INVENTION
Embodiments of the present application illustrates a blockchain based distribution channel for certification authority (CA) certificates, specifically, the present application illustrates a blockchain based distribution channel for CA certificates that involves a method that uses decentralized identifiers (DID) for distributing the CA public key in a flexible and efficient way.
BACKGROUND OF THE INVENTION
Secure connections between entities allow safe communication of data by maintaining the confidentiality and integrity of data. To achieve this feat, multiple methodologies have been deployed and used, public key cryptography or 'asymmetric cryptography' being one of them. The core idea of asymmetric cryptography is to use a pair of keys per device, one of which would be used for encryption and the other for decryption. The encryption key is made public and is called the 'Public Key', whereas the decryption key is kept private and is called the 'Private key'. Anybody having the public key of another entity can use it to encrypt a message and send, which can only be decrypted by the corresponding entity who has the private (decryption) key.
As it becomes evident, the next big task would be to distribute the public keys in a trustworthy manner; so that when an entity gets the public key of 'X', it can be rest assured that the public key belongs to 'X'. The prevalent method to achieve this key distribution is the PKI (Public Key Infrastructure), which embeds public keys into digitally signed certificates. The certificates are authenticated based on a hierarchal trust model, whereby each digital signature is verified using a higher level certifying authority. The trust in this case is endowed in a top-level certificate signing authority (henceforth referred to as CA), which prima facie is the sole entity which everybody else in the PKI ecosystem trusts. The CA acts as the 'Root of Trust', pivoting the whole PKI ecosystem on it.
In the current scenario associated with general arrangement of PKI hierarchy, the verification of the presented certificates can only be done if the complete certificate chain starting from root

certificate down to the end certificate is available. The root certificate provides the 'Root of Trust' for the verification process. The distribution of root certificates is typically done by pre-provisioning it into applications and/or devices. For example, all the web browsers are provided with a pre-provisioned 'Trust Store' that provides the root of trust for the browsers. The number of certificates in the trust stores runs close to hundred, for e.g. Chrome and Internet Explorer (IE 10) both have around 70 root certificates in their store.
Similarly, IoT devices are pre-provisioned with root certificates. Since memory is a costly resource in IoT devices, the devices typically hold only the certificate for the CA which is used to issue the device certificates. As such any other certificate with a different root of trust will not be considered a valid certificate for the devices. The problem arises when changes are to be made to the root CA. Eventually, we will need to change the 'Trust Store' of the applications/devices by updating/deleting the root certificates for the related CA. Although change in the root CA information will lead to updating/deleting of all the derived certificates in the trust chain, there are established ways to carry out the update/deletion of the derived certificates. The challenge stays with the update/deletion of the root CA. The root CA information changes under, but not limited to, the following cases:
The keys of the CA got compromised, hence needs to be revoked
There is a change of ownership for the application/device and the new owner wants to transition the trust chain to a different CA
Many a times organizations use a private CA (local to their organization), instead of globally available public CAs. To increase the level of assurance, it would be a good practice to change the keys of the private CA at regular intervals.
In classical PKI, the update regarding a root CA is announced via an out-of-band mechanism, such as an independent web page, an official legal announcement, or some other publicly available and trusted channel. Responsible vendors and IT administrators are then requested to act accordingly. An IOT device, being in the field, typically has no second mechanism to verify the changed status of root certificates. Also, there are likely to be billions of IoT devices in the field with limited energy budgets and updating a CA certificate will consume precious battery life. All devices need to be re-provisioned with the new root of trust. The re-provisioning is

typically done through firmware update (new certificate embedded in the firmware), which is a much involved and tricky process. In view of the above, there is a need for a method and a system that executes the method to effectively re-provision all devices with the new root of trust.
SUMMARY OF THE INVENTION
The following presents a simplified summary of the subject matter in order to provide a basic understanding of some of the aspects of subject matter embodiments. This summary is not an extensive overview of the subject matter. It is not intended to identify key/critical elements of the embodiments or to delineate the scope of the subject matter. Its sole purpose to present some concepts of the subject matter in a simplified form as a prelude to the more detailed description that is presented later.
The present invention describes an architecture of blockchain based distribution channel for distributing the CA certificate (root of trust) in the IoT ecosystem. As against the existing methodologies of distribution which involves out-of-band distribution channels, the proposed approach allows to leverage blockchain allowing the distribution through an in-band channel, in a flexible manner.
The blockchain based distribution channel and corresponding method that involves the usage of decentralized identifiers (DID)s for distributing the CA public key in a flexible and efficient way is disclosed herein. The method that involves multiple steps. Initially, the DID of CA is embedded onto the device at the time of manufacturing the device. The CA authority is responsible for maintaining the Design and Delivery Obligation (DDO) corresponding to the DID on blockchain, where DDO contains the public key for the CA. When the device boots up, it resolves the DID of the CA from the blockchain, which results in a DDO that contains the public key of the CA. It has to be noted that the resolution should occur over an integrity protected channel. The device now creates a symbolic CA certificate, by embedding the CA public key from the DDO into a certificate template and sign it with a locally generated key. This symbolic certificate is equivalent to a X.509 CA certificate in all respects, leaving apart the signature which differs; because of a different key (locally generated) being used to sign the certificate, rather than the private key of the CA itself. Since this certificate is root CA certificate, the

differing signature is not a problem, as long as the public key (of the CA) embedded in the certificate is correct. Almost all the applications check the signatures of the derived certificates rather than signature of CA certificate itself. In that sense, the CA certificate enjoys absolute trust.
BRIEF DESCRIPTION OF THE ACCOMPANYING DRAWINGS
The following drawings are illustrative of particular examples for enabling systems and methods of the present disclosure, are descriptive of some of the methods and mechanism, and are not intended to limit the scope of the invention. The drawings are not to scale (unless so stated) and are intended for use in conjunction with the explanations in the following detailed description.
FIG. 1A shows a typical hierarchy in the PKI ecosystem.
FIG. IB shows a chain of trust based on the hierarchy in the PKI ecosystem, based on the Figure 1A
Figure 2A shows a method that involves the usage of decentralized identifiers for distributing the CA public key, in a flexible and efficient way.
Figure 2B shows a schematic system drawing associated with the method described in Figure 2A, which involves the usage of decentralized identifiers for distributing the CA public key.
Persons skilled in the art will appreciate that elements in the figures are illustrated for simplicity and clarity and may represent both hardware and software components of the system. Further, the dimensions of some of the elements in the figure may be exaggerated relative to other elements to help to improve understanding of various exemplary embodiments of the present disclosure. Throughout the drawings, it should be noted that like reference numbers are used to depict the same or similar elements, features, and structures.
DETAILED DESCRIPTION

Exemplary embodiments now will be described. The disclosure may, however, be embodied in many different forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey its scope to those skilled in the art. The terminology used in the detailed description of the particular exemplary embodiments illustrated in the accompanying drawings is not intended to be limiting. In the drawings, like numbers refer to like elements.
Figures 1A and IB refer to the general arrangement of a typical PKI ecosystem in the prior art. FIG. 1A shows a typical hierarchy in the PKI ecosystem and FIG. IB shows a chain of trust based on the hierarchy in the PKI ecosystem, based on the Figure 1A. Based on the typical hierarchy in the PKI ecosystem in Figure 1A, at the base of the trust chain is the CA, which is then followed by the (optional) intermediate CA. Intermediate CAs add an extra level, shielding the root CA and helps distribute the load across multiple instances. The PKI uses certificates (typically X.509 standard) for distributing the public keys. As shown in Figures 2A and 2B, when a secure connection is established between two parties, certificates are exchanged between them. For verifying the presented certificates, the relying party needs to have a chain of trust.
In order to address the issue of chain of trust for secure connection and to re-provision all the devices with a new Root of Trust, the proposed approach is using "Decentralized Identifiers", for distributing the CA public key, in a flexible and efficient way, in an IoT ecosystem. The key terminology of elements used in the approach are Decentralized Identifier, Universal resolver, and Certificate pinning. The decentralized identifier, hereinafter referred to as DID, according to the w3c, is "a globally unique identifier that does not require a centralized registration authority because it is registered with distributed ledger technology or other form of decentralized network." The decentralized identifier is denoted for example, "did:example:123456789abcdefghijk", which is derived from the public key of the entity.
The decentralized identifier corresponding to the document holding the CA public key, is created on the blockchain and can be updated only by the owner of the decentralized identifier. The universal resolver is a service that utilizes a collection of DID Drivers to provide a standard means of lookup and resolution for DIDs across implementations and decentralized systems and

that returns the DID Document Object (DDO) that encapsulates metadata associated with a DID. As referenced herein, the DDO is created on the blockchain by the entity who owns the private key corresponding to the DID. Due to the nature of blockchain, changes in DID document cannot be done by anybody other than the owner of the DID. The standard also allows to cryptographically prove the relation between the DID and its owner and allows auditing the modifications done to the DID, in a trusted manner. Finally, certificate pinning is the process of associating a host with their expected X.509 certificate or public key. Once a certificate or public key is known or seen for a host, the certificate or public key is associated or 'pinned' to the host.
Figures 2A and 2B shows a method and a system 300 associated with the method that involves the usage of DIDs for distributing the CA public key, in a flexible and efficient way. The method involves multiple steps. Initially, the DID 308 of CA is embedded 200 onto the device 302 at the time of manufacturing the device 302. A processor 310 is installed within a device 302 and a memory 312 coupled with the processor, wherein the processor 310 executes programmed instructions stored in the memory 312 to execute the method steps 200-260, as mentioned in Figure 2A. The CA authority is responsible for maintaining the Design and Delivery Obligation (DDO) corresponding to the DID 308 on blockchain, where DDO contains the public key for the CA. Now, the device 302 sends 210 a CA DID resolution request to a DID resolver 304. When the device 300 boots up, the DID resolver 304 resolves 220 the DID 308 of the CA from the blockchain, which results in a DDO that contains the public key of the CA. It has to be noted that the resolution should occur over an integrity protected channel. The DID resolver 304 then retrieves 230 DDO from the blockchain, corresponding to the requested DID, which is stored in a blockchain DID registry 306.
The device 302 now creates 240 a symbolic CA certificate, by embedding the CA public key from the DDO into a certificate template and sign 250 the embedded CA public key from the DDO with a locally generated key. And finally, the device 302 installs 260 the CA certificate into the trusted list of CAs, wherein the device 302 can start using the new CA for secure communication. This symbolic certificate is equivalent to a X.509 CA certificate in all respects, leaving apart the signature which differs; because of a different key (locally generated) being used to sign the certificate, rather than the private key of the CA itself. Since this certificate is

root CA certificate, the differing signature is not a problem, as long as the public key (of the CA) embedded in the certificate is correct. Almost all the applications check the signatures of the derived certificates rather than signature of CA certificate itself. In that sense, the CA certificate enjoys absolute trust.
When considering IoT applications a common methodology is to include trusted CA certificates is 'certificate pinning', which allows the applications to trust some organization and/or service based on pre-existing relationships. The symbolic certificate that was created based on the CA relation, is then pinned to applications and used to create TLS connections with other services under the same CA domain. Since the device creates the symbolic CA certificate at run time, any changes in the CA key would be seamlessly communicated to the devices in almost real time through the blockchain interface. For example, consider a case of transitioning to a new CA as a result of change in ownership of the devices. This can be easily achieved by changing the 'DID Controller', defined in the standard (https://www.w3.Org/TR/did-core/#dfn-did-controllers) to point to the DID of the new owner.
As will be appreciated by one of skill in the art, the present disclosure may be embodied as a method and system. Accordingly, the present disclosure may take the form of an entirely hardware embodiment, a software embodiment or an embodiment combining software and hardware aspects.
It will be understood that the functions of any of the units as described above can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts performed by any of the units as described above.
Instructions may also be stored in a computer- readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the

instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function/act performed by any of the units as described above.
Instructions may also be loaded onto a computer or other programmable data processing apparatus like a scanner/check scanner to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions/acts performed by any of the units as described above.
In the specification, there has been disclosed exemplary embodiments of the invention. Although specific terms are employed, they are used in a generic and descriptive sense only and not for purposes of limitation of the scope of the invention.

WE Claim:

1. A method to distribute a certificate authority (CA) public key for a secure communication in a
blockchain, comprising:
embedding, via a processor, a decentralized identifier (DID) of a certificate authority (CA) within a device;
sending, via the processor, a CA DID resolution request to a DID resolver in communication with the device;
resolving, via a processor, the DID of the CA from the blockchain after booting up of the device, which results in a Design and Delivery Obligation (DDO) that contains a public key of the CA;
retrieving, via the DID resolver, the DDO from the blockchain, corresponding to the requested DID, which is stored in a blockchain DID registry;
creating, via the processor, a symbolic CA certificate, by embedding the CA public key from the DDO into a certificate template;
signing, via the processor, the embedded CA public key from the DDO with a locally generated key; and
installing, via the processor, the CA certificate into the trusted list of CAs, wherein the device starts using the new CA for the secure communication.
2. The method as claimed in claim 1, wherein the CA authority maintains Design and Delivery Obligation (DDO) corresponding to the DID on a blockchain, where DDO contains the public key for the CA.
3. The method as claimed in claim 1, wherein the CA authority maintains Design and Delivery Obligation (DDO) corresponding to the DID on a blockchain, where DDO contains the public key for the CA.
4. The method as claimed in claim 1, wherein the resolution occurs over an integrity protected channel.

5. The method as claimed in claim 1, wherein the symbolic certificate is equivalent to a X.509 CA certificate, which has a different signature since a different locally generated key is used to sign the symbolic certificate.
6. A system to distribute a certificate authority (CA) public key for a secure communication, comprising:
a processor; and
a memory coupled with the processor, wherein the processor executes programmed instructions stored in the memory to:
embed a decentralized identifier (DID) of a certificate authority (CA) within a device;
send a CA DID resolution request to a DID resolver in communication with the device;
resolve the DID of the CA from the blockchain after booting up of the device, which results in a Design and Delivery Obligation (DDO) that contains a public key of the CA;
retrieve, via the DID resolver, the DDO from the blockchain, corresponding to the requested DID, which is stored in a blockchain DID registry;
create a symbolic CA certificate, by embedding the CA public key from the DDO into a certificate template;
sign the embedded CA public key from the DDO with a locally generated key; and
install the CA certificate into the trusted list of CAs, wherein the device starts using the new CA for the secure communication.