Advanced Development Projects

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...

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...

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 ...

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...

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...

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...

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...

I would like to elaborate on why sidetree has a batch size limit and how the proof of payment works to combat a denial of service attack to the network. Each sidetree node (at least a full node) maintains a mongodb database to store all valid DID operations that are confirmed in the Bitcoin blockchain and written into IPFS. DID operations are basically json documents that contains a DID document and a sidetree operation type. When you think about it the mongodb store acts as a DID and DID document cache that improves the performance of sidetree fetch services. When resolving a DID Document given a DID, sidetree would just read a local database instead of a fetching data from Bitcoin network and IPFS every time. The mongodb store is also known as DID cache. Suppose a malicious sidetree node wants to harm the network and tries to flood 100M protocol-adherent but bogus DID documents into sidetree network by sending 1M DID operations. Those operations gets queued in a single batch. The ...

Current mechanism to secure communication between services and devices is to install X.509 certificates to each devices. During the manufacturing flow, a hardware security module generates a private public key pair for each device. A. X.509 certificate is created from the public key and device id, and is signed by a certificate authority (CA) or intermediate CAs known to the IoT Hub. Both the certificate and the private key is installed in the device. The private key is kept secured and hidden and may be installed in a more secure area inside the device. Manufacturer also upload the certificate to the IoT Hub. Devices are registered and provisioned in the IoT Hub. In this process, upon connection of device to the IoT Hub, IoT Hub sends a challenge that asks for proof of ownership of the message that will be sent by the device. Device signs a reply message with its private key, along with the certificate. IoT Hub verifies using the public key of device's certificate. This establish...

In bitcoin, you usually use new key pairs for every transaction you make. It becomes unmanageable when your keys grow over time, as you need to store each private key in your wallet. A Hierarchical Deterministic wallet or HD wallet helps users by just deriving key pairs from a single seed instead of randomly generating it. This way you only need to store the seed or sometimes called the master key. Keys used in bitcoin are elliptic curve key pairs. The private key is used to sign a transaction and is kept hidden safe in a crypto wallet. This key is a hash of a 32bit seed generated randomly and is not human readable. Basically you can derive all of your key pairs and addresses from the seed so its really important if you have a really have a backup of it. Even its string representation in either base64 or hex is not human friendly and is hard to memorize. Backing it up by writing it on a piece of paper or memorizing it is not a good thing to do since it is very prone to human error...

Cryptowallets can be categorized into 7 forms. The first one is Web Based wallets. They are also called server side wallets. Users entirely trust their keys to these websites. An advantage of this is users do not need to manage everything by themselves. But if the websites are compromised by either an employee or a hacker, all of the users coins are lost. This is the most popular type of wallets as most users are not techie and are willing to pay to manage their keys and coins by trusted companies. Desktop and Browser are client side wallets. Desktop wallets are implemented as a standalone application running on a user's local machine while Browser is implemented as a plugin of a web browser. They are typically more secure than web based wallets. They are cold wallets, meaning keys are stored locally and never leaves the client. Cryptographic operations are executed only on the user side, making it more secure. Browser rely on the security of the plugin as well as on the secur...

DID Authentication allows two parties to establish a secure communication between each other directly, with no third party federation getting involved. The first step is for the user to ask for permission to authenticate to the relying party. This is done typically by user clicking a button from the relying party website or any agent form. The relying party in turn generate a challenge, typically a jwt token made from its DID, a request saying to share the user's DID, and some random string. Most of the time, this is done by the relying party generating a QR code, made up of the jwt and a callback url that will be accessed by the user. User then usually open its digital wallet to take a picture of the QR code to receive it. The user receiving the challenge validates the token message by resolving the relying party's DID Document from a Universal Resolver and then using the public key inside the DID Document to verify the signature of the jwt token. Upon verification, user...

Blockchain scalability is a non-trivial problem, but there is now a promising strategy for scaling blockchain-based systems known as ‘Layer 2’ protocols, or L2s, for short (example: Bitcoin’s Lightning Network). L2s achieve scalability through deterministic processing and transaction schemes that take place ‘above’ the blockchain, with zero or minimal consensus requirements beyond small points of interaction with the underlying chain. For decentralized identity to become a reality, it requires a system that operates at massive scale, while still delivering on important features, such as deterministic state resolution and differential persistence. Using blockchains for anchoring and tracking unique, non-transferable, digital entities is a useful primitive, but the current strategies for doing so suffer from severely limited transactional performance constraints. Sidetree Entities is a Layer 2 protocol for anchoring and tracking entities across blockchains. Sidetree Enities, and nod...

Public key certificates are digital certificates to prove the ownership of a public key. Certificates are typically signed by a certificate authority (CA). Upon receipt of the cert from a site, CA will sign the cert, saying the public key in the cert is tied to the domain or the ip address of the site. CA will then send the cert to the site. When you access a secured website from your browser, let us say https://www.google.com, your browser will establish a secure communication channel. It will ask for a certificate from the site. The site will share its certificate signed by a trusted certificate authority. The browser has all the list of public keys of the major certificate authorities. This way the browser easily verifies the signed certificate using the public key of the certificate authority who signed the certificate. If the certificate is valid, Browser will generate a symmetric key that will be used to encrypt the communication traffic. Browser will then encrypt the symmetric...

In the United States, a person's identity is tied to his/her social security number. It is a unique number issued to each citizen of the country and is maintained by an independent agency of the government. One major issue is that given a social security number, one cannot prove its ownership alone, without going to the agency that issued it. Social security number is often kept private since anybody who will have access to it can easily misuse it. Decentralized Identifiers or DIDs solve this by incorporating public key cryptography to achieve verifiability. A DID is associated with a public private key pair, where the private key is kept hidden by the owner and the public key is stored in a global and persistent database, typically implemented using blockchains. Normally, DIDs and their corresponding private key are secured in a digital wallet in a mobile phone. Wallets enable you to have a lifetime secured connection to another person, organization or even a device. They also al...

Today I am going to talk about Decentralized Identifiers or DIDs. The standard model of what we started before is the siloed or centralized identity. Here, you are not really you. You do not own your identity. You only had accounts on different organizations or companies. And how you use your identity, your username and password, need to have some security and standards. That is SSL/TLS. But management of several accounts had become complex over time. This has led to a more efficient model. And that is the third party IDP or federated identity. Federated identity solves the problem by putting a service provider in the middle. You have an account in the service provider and it gets confederated to different organizations. We know this on the web as social login, using twitter or google or facebook. So despite the advantage of being able to simplify authentication by using an intermediate service, a lot of challenges still exist. It inserts somewhat an intermediary into your relationshi...