Posts

On IoT Exchange

There are several benefits of using IoT Exchange instead of just directly using AWS or Azure. First one is presence. First is presence. In some regions, there are more Equinix IBXs than Azure IBXs, so if the customer is lucky enough and is in close proximity to an Equinix IBX, it means its connectivity will have lower delay, thus higher throughput in general. This has an assumption that all Equinix IBXs have an IoT Exchange service deployed. Next is the nature of Equinix being cloud neutral. If you are an Equinix customer, you can create a private connection between your machines and big cloud service providers such as Azure, AWS, and Google Cloud. Private means fast and secure connection that does not go through the public internet. If you are only in Azure, you cannot have direct communication to AWS and Google Cloud services. IoT Exchange customers are instantly Equinix customers, which entitles them to have private connectivity not only to cloud service providers, but to other Equ...
Post a Comment
Read more

Smartkey Overview

Whenever we write applications, we need to keep our _secrets_ in a single central secure place. These secrets can be your password to your database, your api key, or your cryptographic keys used for signing messages. There are two major reasons why we want to do this. The first one is we want these secrets to be fetched by multiple instances of the application from a single place, instead of duplicating or hardcoding them in the application. This secure place may be a keystore stored in a directory in a file server, but making it reachable across different environments, specially when dealing with software development in the cloud, ultimately becomes a challenge. Nowadays, this is implemented as a service, where it expose endpoints easily accessible to applications for fetching the secrets themselves. Aside from key access, these type of services often offer key management solutions such as key rotation and key revocation. These solutions are sometimes referred as key management servi...
Post a Comment
Read more

Is the DID Document instantly resolvable after successful DID operation creation?

One of the challenges when dealing with the Bitcoin network is it takes a while to confirm a transaction to the blockchain. Bitcoin writes a block of transactions at an average of every 10 minutes. And what goes to that block depends on the transaction fee that a user paid. The larger the fee the faster the transaction is included in a block. At the time of this writing, 16 US cents is the fee paid to get a transaction to go into the next block, 15 cents to make sure it goes in the next 3 blocks, and 5 cents into the next 6 blocks.  Sidetree processes DID operations every 10 minutes as the default configuration. Syncing the DID Cache from blockchain happens every 5 mins This in turn would make the process to persist a DID into the blockchain take about 10 mins best case to around 25 minutes worst case. Why 25 minutes? Because if you are unlucky, it can take 10 minutes to run operation processor, plus 10 minutes for Bitcoin to persist the block, and an additional 5 minutes for ...
Post a Comment
Read more

How Multisignatures would work on Verifiable Credentials

State of the art multisignature implementations are based on Naive Schnorr signatures with mechanisms against rogue-key attack, where a participant could claim a false public key, and eventually control the multi-signature. An example of this is Musig, where it extended the BN-scheme to make it more efficient for the Bitcoin network. Musig not only aggregates the signature, but the public keys as well. The aggregated public key will look no other like a normal non-aggregated public key. It cannot be determined that the public key is from an aggregated public key or not.  Verifiable Credentials or VC can be signed by multiple entities. Here is how multisignatures would work on VC. Let us say we have 3 departments: d1, d2, d3 and each of them have their own DID: did1, did2, did3. d1 wants to issue a VC, but it also needs to secure d2 and d3 signature. d1 will first acquire did2 and did3, and create a new did called did4 from aggregated public keys from did1, did2, and did3. d4 is...
Post a Comment
Read more

Using Proof to Verify the Controller of a Decentralized Identifier

In Sidetree, the owner of the DID is the only . Concretely, only the public keys of the DID Document being processed can verify who can perform operations on the DID Document, such as DID Document modification or revocation. But the DID specs defines that we can delegate another entity that can do DID Document operations on behalf of the owner, by adding a _controller_ attribute. Furthermore, we can also add an optional _proof_, a signature generated by either the owner or a controller! A controller signing the proof means that a third party entity (the controller) is attesting the integrity of the DID Document. Below is a sample of a DID Document persisted to the Sidetree network. The proof is signed not by the owner but by a controller whose DID is did:example:bcehfew7h32f32h7af3.   {   "@context": "https://www.w3.org/2019/did/v1",   "id": "did:example:123456789abcdefghi",   "controller": "did:example:bcehfew7h32f32h7af3...
Post a Comment
Read more

Verifiable Credentials for Fine Grained Access Control

If you are familiar with public key certificates, you would probably understand Verifiable Credentials (VC). VCs are json formatted credentials that are cryptographically verifiable by itself. It consists of 3 major attributes: an issuer, a claim called credential subject, and a proof. The issuer is the entity which creates and signs the VC. The credential subject is a claim, for example, stating that this entity is over a certain age, or that this entity graduated from a certain university. The proof is the signature saying the credential subject holds true and is cryptographically verifiable. One interesting application of this credential format is to use it for access control. Suppose there is a service named Telemetry Gateway or TG that accepts billions of incoming messages of devices from an insecure network. If all messages of the devices hold cryptographic proof saying that "this message is authorized to get consumed by TG", TG does not need to maintain its own ac...
Post a Comment
Read more

On the IoT Exchange - DID integration

One of the challenges of introducing Decentralized Identifiers (DID) into Internet of Things (IoT) is the proprietary nature of the IoT ecosystem. Most IoT devices use proprietary technology. The ideal way of integrating DIDs is to put the keys and some cryptographic operations directly into the device. The assumption here is (1.) the manufacturer themselves can either generate and embed the keys from a secure or "offline" environment or (2.) manufacturer can embed cryptographic logic into the device and the device would generate the keys themselves, given that the device has enough power to execute the operations. If we are going create a service from DIDs and we do not have any access to the device manufacturing process, we may need to generate and maintain the keys elsewhere, but we need to make sure the pathway from that "elsewhere" to the device is _secure_, and how that secured pathway is implemented is *out* of the scope of this post. That "elsewher...
Post a Comment
Read more