This note discusses the ability to take existing certificate authority based systems and anchor them in DIDs, in order to have a self-sovereign identity that forms a root of trust. The user can have devices be sub-CAs, and use different keys for different services. We may be able to leverage existing technologies for this.
One design element in self-sovereign identity which is becoming common is the idea of decentralized identifiers (DIDs). The ideas is to have an identifier, called a DID, which maps to a descriptor object (DDO) which contains a public key. This mapping can be done in a decentralized way using a blockchain, but other ways could be used as well. The point is that if the root of trust exists in a blockchain, this forms a decentralized PKI (or DPKI). A service interacting with a user would verify a signed message by looking up the DID of the user, mapping this DID to a corresponding key and verifying that the key matches the key that signed the message.
In a certificate authority based identity system the root of trust is a root key held by a certificate authority (CA). The CA signs certificates containing the keys of sub-CAs which in turn signs keys used by end-users. Thus a service interacting with an end-user can receive a signed message, check the public key that signed the message and follow the certificate chain back to the root CA.
Suppose the users DID resolves to a DDO with a single master/root key. This could be a key stored securely in something like a yubikey, smart card or the secure enclave of a mobile device.
The user may want to have several devices with which she would like to interact with several services.
One way to achieve this is to set up a system where the user acts as their own root CA, the users devices are provisioned as sub-CAs, and each service gets its own key signed by the sub-CA. This way the user only needs to use their root key occasionally, and their day-to-day use could be via other devices.
If the user wants to use the same identity on a service from two different devices she can do this by revealing to the service the certificate chains leading back to their main DID, and request that the two keys from the two devices are treated as the same identity. This leads to some loss of privacy, but it may be possible to prove the existence of these certificate chains in a zero-knowledge way.
If the user loses a device she can issue a revocation certificate for that device that could be associated with the DDO until the certificate expires.
If the user loses her master key and obtains a new one through for instance delegated recovery, she would need to reprovision her devices with the new master key, and reenroll in services with certificates generated by the new device sub-CAs. To reenroll the devices again the user would need to go through a step where they send the old certificate chain as well as the new certificate chain to the service to allow the service to update.
The Sovrin project has done much work in thinking about the privacy aspects of decentralized identity, especially how to protect against correlation between services. This involves using new keys for each interaction, described in the documents The Technical foundations of Sovrin and How Sovrin works.
Blockstack uses a scheme of generating child keys of a master key in order to obtain different keys to use with different services. More info in this repository.
In the Swedish identity system BankId, a hardware token device (for instance digipass at SEB ) is given to the user by their bank. This hardware token device is then used as a root of trust to enroll keys generated by a mobile app (Known as "Mobile BankId"). This mobile app is then used for day-to-day banking activities and interactions with government services.
- Is this a good way to gain privacy by using different keys for different services (in unlinkable fashion)? Or are privacy benefits negated by the need to reveal certificate chains when enrolling a new device to interact with a service? Can zero-knowledge proofs be used, as Sovrin is doing?
- Is using certificate chains a good way to handle key management of multiple devices and/or multiple services, or is it better to just list all the relevant keys in a flat structure in the DDO?
- Should there be one root key/root of trust per user, or should each device have its own root of trust, anchored in the DID?
- If using certificate chains, how much of current software packages, data models and best practices can be reused? Do we gain anything by the reuse, or is it better to start fresh with new models?
- Can a method like this be used to introduce hierarchies of keys, ranked by the security of the device that holds them, so that an ephemeral key in the browser has a lower security rank than a key generated on a smart card or secure enclave?