Licensing of software meant for the commons, and clauses for protecting user data

My current feeling is actually that this wouldn't be a good idea for us in Holo-REA. See https://twitter.com/pospigos/status/1232095550226354177

(PS love that this is a lurker causing another lurker to stop lurking lol)

"My current feeling is actually that this wouldn't be a good idea for us in Holo-REA"


Can you say more @pospi about what you see are the issues? I am just interested in the different takes out there on this CAL license. If you are willing to share, thanks!

See tweet. We've discovered some use-cases at the margins where holding cryptographic keys on network participants' behalf is actually a core requirement of the social context.

ahhhhhhhhhhhh thanks for this:

> holding cryptographic keys on network participants' behalf is actually a core requirement

That was sometihng I didn't gather from the tweet. So regularly losing your device translates into regularly losing your idewntity and data, is that correct? And what follows is that there's a need for storage that's a bit more resilient, while being accessible to non-technical users? I've got some thoughts on that, but it might be a bit off-topic for this thread. Long and short is that it may be possible while preserving the terms of the CAL -- after all, Holo Host has to struggle with this very issue.

That would be very cool if possible. I suspect it depends on the functionality offered by DPKI- you would basically need to have someone else able to revoke and re-issue keys on your behalf, correct?

To be clear, there are two issues here. Losing identity & data is one of them. But having an account reset that does not depend on the end-user and restores all previous data is another... I don't think we can really say that a paper key backup is workable in these situations. Paper may be a luxury item, and recording "seed words" locally could increase the possibility of acts of force being used to compromise people's identities.

We live in such a weird world, where paper might be a luxury item but phones are frequently replaced. I'm regularly surprised by the paradoxes that pop up in a global resource web with asymmetries everywhere.

So some details: whatever it was supposed to be in the past, DPKI is now exclusively for revocation and recreation of agent keys. The great thing about it is that it's not violating anyone's right to the data they've produced; it's merely agents sharing information with others. Sounds like paper backup isn't viable, which is fine -- that only covers you in the 'damaged phone' case and not the 'stolen phone' case. Depending on the strength of social connections, I'd suspect 'm of n signing' would be the best option -- that is, your old key is replaced with a new key that you produce on your new device and get m of your trusted n peers. But I feel like that's still vulnerable to acts of force, and now your friends and family are at risk too. You could expand n but that's a hassle because now you have to talk to more people if you ever get a new phone.

When you say an account reset that "does not depend on the end user", do you mean that it requires no interaction from them, or that it doesn't require them to be a crypto expert or actively maintain (paper/electronic) backpus?

Anyhow, momentarily disregarding the above concerns, DPKI + the planned source chain backup app should at least provide the resilience and decent UX that a community needs. Would love to hear your thoughts, especially if you feel I'm missing or dismissing important concerns.

Sam Smith did come good work on his Mnemonic seed game. (Found a ref here: https://iiw.idcommons.net/index.php?title=Seed_Quest_%2B_Didery_%E2%80%93_3-D_Game_Mnemonic_DID_Keystore&oldid=21861)

Also I filmed his talk at IIW the other year so you can view that on the youtubes here: https://www.youtube.com/watch?v=JB_o7Y67CY4

You could also potentially run pattern recognition (computer vision etc) on the way we write, brush our teeth or play a midi instrument to feed a key generator and then use the same interpretor to restore your keys. Just food for thought!

Hey, that is a very clever/fun way of embedding seeds in our brains. I also like his background info and comments in the slideshow, although I suspect I'd get more out of it if I were actually at the talk. Thanks for sharing, Josh!

Thanks for continuing to unpack this! Seems like Art has echoed the same thing on Twatter. FWIW I'm thinking the issues with paper may be more about durability (and compromisability) than availability. Having stayed in one or two bamboo-wall shacks during monsoon season... they're not what you'd call "waterproof".

We now have a second use-case incoming who need centralised control over issuing, revoking and re-issuing user identities (also in the "global south"); so this seems like it could be a common requirement.

Is it feasible to set up m of n signing such that a trusted identity providing entity can do revocations & recoveries on others' behalf? Seems like that would work, but I wanted to be sure. Are there lower limits on m and n or could you feasibly set it up like a single "master" key that can reissue others? I get that this would be "bad security design", but want to be prepared for all possible contexts.

In terms of social pressure, compromising of friends & relatives is certainly a possible issue. IIRC the Dark Crystal team did a fair bit of threat modelling on this, but I'm not sure where to find it. May be worth reaching out to them.

Private source chain backups are another thing entirely. If they only work between your own trusted devices (ie. devices which store your keys and act as you), then it won't be relevant here- most people in these ecosystems can only afford a single Android device. But if source chain backups can be configured more like a "cloud backup", where a third-party service provider can hold the backup for you, then that's definitely useful. Otherwise, to create the durability we need it may simply be that no users have an actual "private" chain; instead storing all "private" entries into a shared network space to which only they and the service provider have access.

I think at some point we are going to need a clear description of the process that the end-users have to progress through to do a full key recovery, in order to determine whether it fits the constraints of the environment. If there's a way we can start that exploration now, I'd be indebted!

Attached is $1m of research from Evernym and the department of homeland security.

Here are my "quick notes" made quite a while back. I must admit all this is hazy!

With DKMS, the initial “root of trust” for all participants is any distributed ledger that supports a new form of root identity record called a DID (decentralized identifier).

Each DID points to a DID document, a JSON or JSON-LD object containing the associated public verification key(s) and addresses of off-ledger agent(s) supporting secure peer-to-peer interactions with the identity owner.

Since no third party is involved in the initial registration of a DID and DID document, it begins as “trustless”. From this starting point, trust between DID-identified peers can be built up through the exchange of verifiable claims. These proofs can be verified by reference to the issuer’s DID and DID

document.

As a general rule, DKMS requirements are a derivation of CKMS requirements, adjusted for the lack of centralized authorities or systems for key management operations.

Global DKMS infrastructure must achieve interoperability organically based on a shared set of specifications, just like the Internet. Note that the need to maintain decentralization is most acute when it comes to key recovery: the advantages of decentralization are nullified if key recovery mechanisms reintroduce centralization.

Conventional PKI and CKMS rarely have anti-correlation as a primary requirement. DKMS should ensure that participants will have more, not less, control over their privacy as well as their security. 

The DKMS needs to be able to support a broad spectrum of applications, with both manual and automatic key management,in order to satisfy the numerous security and usability requirements of those applications.

In DKMS design it is NOT RECOMMENDED to copy private keys directly between wallets, even over encrypted connections. It is RECOMMENDED to use derived keys whenever possible to enable agent-specific and device-specific revocation.

The DKMS design MUST enable key management to be delegated by one identity owner to another, including the DID concept of guardianship.

The DKMS design SHOULD be capable of being extended to support new cryptographic algorithms, keys, data structures, and modules, as well as new distributed ledger technologies and other security and privacy innovations.

Although the DKMS specifications will not themselves include a trust framework; rather, one or more trust frameworks can be layered over them to formalize certain types of extensions. This provides a flexible and adaptable method of extending DKMS to meet the needs of specific communities.

The DKMS specification should NOT try to do everything, e.g.,enumerate every possible type of key or role of user or application, but let those be defined locally in a way that is interoperable with the rest of the system.

The DKMS design MUST be an open system based on open, royalty-free standards.

Each DID method specification defines:

1. The specific distributed ledger against which the DID method operates;

2. The format of the method-specific identifier;

3. The CRUD operations (create, read, update, delete) for DIDs and DID documents on

that ledger.

From a digital identity perspective, the primary problem that DIDs and DID documents solve is the need for a universally available, decentralized root of trust that any application or system can rely upon to discover and verify claims about the DID subject.

3.2. The Cloud Layer: Cloud Agents and Cloud Wallets

While the DID specification covers the bottom layer of a decentralized public key infrastructure, the DKMS spec will concentrate on the two layers above it. The first of these, the cloud layer, is the server-side infrastructure that mediates between the ultimate peers—the edge devices used directly by identity owners—and the DID layer.    

While not strictly necessary from a pure logical point-of-view, in practice this server-side DKMS layer plays a similar role in DID infrastructure as email servers play in SMTP email infrastructure or Web servers play in Web infrastructure. Like email or web servers, cloud agents and cloud wallets are designed to be available 24 x 7 to send and receive communications on behalf of their identity owners. They are also designed to perform communications, encryption, key management, data management, and data storage and backup processes that are not typically feasible for edge devices given their typical computational power, bandwidth, storage capacity, reliability and/or availability. Cloud agents and wallets will typically be hosted by a service provider called an agency — while any identity owner can also host their own cloud agents. It is critical that the cloud layer be designed so that it does not “recentralize” any aspect of DKMS.

Another feature of the cloud layer is that cloud agents can use DIDs and DID documents to automatically negotiate mutually authenticated secure connections with each other using DID TLS, a protocol being designed for this purpose.

3.3. The Edge Layer: Edge Agents and Edge Wallets

The edge layer is vital to DKMS because it is where identity owners interact directly with computing devices, operating systems, and applications and have direct control over DKMS edge agents and edge wallets. When designed and implemented correctly, edge devices, agents, and wallets are also the safest place to store private keys and other cryptographic material.

The edge layer is where most DKMS private keys and link secrets are generated and where most key operations and storage are performed. To meet the security and privacy requirements, DKMS architecture makes the following two assumptions:

1. A DKMS agent is always installed in an environment that includes a secure element or Trusted Platform Module (for simplicity, this document will use the term “secure element” or “SE” for this module).

2. Private keys used by the agent never leave the secure element.

By default edge agents are always paired with a corresponding cloud agent due to the many DKMS operations that a cloud agent enables, including communications via the DKMS protocol to other edge and cloud agents. However this is not strictly necessary. As shown in Figure 1, edge agents could also communicate directly, peer-to-peer, via a protocol such as Bluetooth, NFC, or another mesh network protocol. Edge agents may also establish secure connections with cloud agents or with other using DID TLS.

3.4. Verifiable Claims

By themselves, DIDs are “trustless”, i.e., they carry no more inherent trust than an IP address. The primary difference is that they provide a mechanism for resolving the DID to a DID document containing the necessary cryptographic keys and endpoints to bootstrap secure communications with the associated agent.

To achieve a higher level of trust, DKMS agents may exchange digitally signed credentials called verifiable claims. What is being verified in a verifiable claim is the signature of the claim issuer. The strength of the actual claim depends on the degree of trust the verifier has in the issuer.

Different digital signature formats require different cryptographic key material. For example, claims that use a zero-knowledge signature format such as Camenisch-Lysyanskaya (CL) signatures require a “master secret” or “link secret” that enables the prover (the identity owner) to make proofs about the claim without revealing the underlying data or signatures in the claim (or the provers DID with respect to the claim issuer). This allows for "claim presentations" that are unlinkable to each other. Link secrets are another type of cryptographic key material that must be stored in DKMS wallets.

4. Ledger Architecture

It is a fundamental feature of DIDs and DKMS that it will work with any modern blockchain, distributed ledger, distributed database, or distributed file system capable of supporting a DID method. Permissioned ledgers restrict who can run a validator node, and thus can typically operate at a higher transaction rate. 

For decentralized identity management, a core requirement of DIDs and DKMS is that they can

interoperate with any of these ledgers. However for privacy and scalability reasons, certain

types of ledgers play specific roles in DKMS architecture.

4.1. Public Ledgers

Public ledgers, whether permissionless or permissioned, are crucial to DKMS infrastructure

because they provide an open global root of trust.

Such a publicly available root of trust is particularly important for:

1. Public DIDs that need to be recognized as trust anchors by a large number of verifiers.

2. Schema and claim definitions needed for broad semantic interoperability of verifiable claims.

3. Revocation registries needed for zero-knowledge revocation of verifiable claims that use zero-knowledge proofs.

4. Policy registries needed for authorization and revocation of DKMS agents (see section 7.2).

5. Anchoring transactions posted for verification or coordination purposes by smart contracts or other ledgers, including microledgers (below).

4.2. Private Ledgers

Although public ledgers may also be used for private DIDs—DIDs that are intended for use only by a restricted audience—this requires that their DID documents be carefully provisioned and managed to avoid any information that can be use for attack or correlation. This threat is lessened if private DIDs are registered and managed on a private ledger that has restricted access. However the larger the ledger, the more it will require the same precautions as a public ledger.

4.3. Microledgers

From a privacy perspective—and particularly for compliance with privacy regulations such as the EU General Data Protection Regulation (GDPR)—the ideal identifier is a pairwise pseudonymous DID. This DID (and its corresponding DID document) is only known to the two parties to a relationship.

Because pairwise pseudonymous DID documents contain the public keys and service endpoints necessary for the respective DKMS agents to connect and send encrypted, signed messages to each other, there is no need for pairwise pseudonymous DIDs to be registered on a public ledger or even a conventional private ledger. Rather they can use microledgers. 

A microledger is essentially identical to a conventional private ledger except it has only as many nodes as it has parties to the relationship. The same cryptographic steps are used:

1. Transactions are digitally signed by authorized private key(s).

2. Transactions are cryptographically ordered and tamper evident.

3. Transactions are replicated efficiently across agents using a simple consensus protocol.

Microledgers are effectively permissionless because anyone can operate one in cooperation with anyone else—only the parties to the microledger relationship need to agree. If there is a danger of the parties to the microledger getting “out of sync” (e.g., if both of them needed to move to different agencies at the same time, so that neither is able to push a change-of-endpoint to the other), the party’s agents can register a dead drop point on a public ledger. This is an encrypted value both parties can read to negotiate a temporary location where they can re-sync their microledgers to restore their connection.

Microledgers play a special role in DKMS architecture because they are used to maintain pairwise pseudonymous connections between DKMS agents. The use of microledgers also helps enormously with the problems of scale—they can significantly reduce the load on public ledgers by moving management of pairwise pseudonymous DIDs and DID documents directly to DKMS agents.

5.1. Key Types and Key Descriptions

NIST 800-130 framework requirement 6.1 requires a CKMS to specify and define each key type

used. The following key layering and policies can be applied.

1. Master keys:

• a. Keys at the highest level in the hierarchy, in that they themselves are not cryptographically protected. They are distributed manually or initially installed and protected by procedural controls and physical or electronic isolation.

• b. MAY be used for deriving other keys;

• c. MUST NOT ever be stored in cleartext.

• d. SHOULD never be stored in a single encrypted form, but only:

• i. Saved in secure offline storage;

  • ii. Saved in a highly secure encrypted vault, such as a secure element, TPM, or TEE.

  • iii. Sharded using a technique such as Shamir secret sharing;

  • iv. Derived from secure multiparty computation.

  • v. Saved somewhere that requires secure interactions to access (which could mean slower retrieval times).

• e. SHOULD be used only for creating signatures as proof of delegation for other keys.

• f. MUST be forgotten immediately after use.

2. Key encrypting keys

• a. Symmetric or public keys used for key transport or storage of other keys.

• b. MAY themselves be secured under other keys.

• c. If they are not ephemeral, they SHOULD be stored in secure access-controlled devices, used in those devices and never exposed.

3. Data keys

• a. Used to provide cryptographic operations on user data (e.g., encryption, authentication). These are generally short-term symmetric keys; however, asymmetric signature private keys may also be considered data keys, and these are usually longer-term keys.

• b. SHOULD be dedicated to specific roles, such as authentication, securing communications, protecting storage, proving authorized delegation, constructing claims, or generating proofs.

The keys at one layer are used to protect items at a lower level. This constraint is intended to make attacks more difficult, and to limit exposure resulting from compromise of a specific key. For example, compromise of a key-encrypting-key (of which a master key is a special case) affects all keys protected thereunder. Consequently, special measures are used to protect master keys, including severely limiting access and use, hardware protection, and providing access to the key only under shared control.

In addition to key layering hierarchy, keys may be classified based on temporal considerations:

• 1. Long-term keys. These include master keys, often key-encrypting keys, and keys used to facilitate key agreement.

• 2. Short-term keys. These include keys established by key transport or key agreement, often used as data keys or session keys for a single communications session.

The following policies apply to key descriptions:

• 1. Any DKMS-compliant key SHOULD use a DID-compliant key description.

• 2. This key description MUST be published at least in the governing DID method specification.

• 3. This key description SHOULD be aggregated in the Key Description Registry maintained by the W3C Credentials Community Group.

DKMS key management must encompass the keys needed by different DID methods as well as different verifiable claims exchange protocols and signature formats. The following list includes the initial key types required by the Sovrin DID Method Spec and the Sovrin protocol for verifiable claims exchange:

1. Link secret: (one per entity) A high-entropy 256-bit integer included in every claim in blinded form. Used for proving claims were issued to the same logical identity. A logical identity only has one link secret. The first DKMS agent provisioned by an identity owner creates this value and stores it in an encrypted wallet or in a secure element if available. Agents that receive claims and present proofs must know this value. It can be transferred over secure channels between agents as necessary. If the link secret is changed, claims issued with the new link secret value cannot be correlated with claims using the old link secret value.

2. DID keys: (one per relationship per agent) Ed25519 keys used for non-repudiation signing and verification for DIDs. Each agent manages their own set of DID keys.

3. Agent policy keys: (one per agent) Ed25519 key pairs used with the agent policy registry. See section 7.2. The public key is stored with the agent policy registry. Transactions made to the policy registry are signed by the private key. The keys are used in zero-knowledge during proof presentation to show the agent is authorized by the identity owner to present the proof. Unauthorized agents MUST NOT be trusted by verifiers.

4. Agent recovery keys: (a fraction per recovery buddy) Ed25519 keys. A public key is stored by the agent and used for encrypting backups. The private key is saved to an offline medium or split into shares and given to recovery buddies. To encrypt a backup, an ephemeral X25519 key pair is created where the ephemeral private key is used to perform a Diffie-Hellman agreement with the public recovery key to create a wallet encryption key. The private ephemeral key is forgotten and the ephemeral public key is stored with the encrypted wallet backup. To decrypt a backup, the private recovery key performs a Diffie-Hellman agreement with the ephemeral public key to create the same wallet encryption key.

5. Wallet encryption keys: (one per wallet segment) 256 bit symmetric keys for encrypting wallets and backups.

5.2. Key Generation

NIST 800-130 framework requirement 6.19 requires that a CKMS design shall specify the key-generation methods to be used in the CKMS for each type of key. The following policies can be applied.

1. For any key represented in a DID document, the generation method MUST be included in the key description specification.

2. Any parameters necessary to understand the generated key MUST be included in the key description.

3. The key description SHOULD NOT include any metadata that enables correlation across key pairs.

4. DKMS key types SHOULD use derivation functions that simplify and standardize key recovery.

If KDFs or PRNGs are used, a passphrase, biometric input, or social data from multiple users combined with random salt SHOULD be used as the input to create the seed. Alternately a QR code or words from a list such as the PGP word list can be used. In either case, the input MUST NOT be stored anywhere connected to the Internet. 

5.3. Multi-Device Management

Each device hosts an edge agent and edge wallet. All keys except for the link secret are unique per device. This allows for fine-grained (e.g., per relationship) control of authorized devices, as well as remote revocation.

It is recommended that private keys never be reused across agents. If a secret is shared across agents, then there must be a way to remotely revoke the agent using a distributed ledger such that the secret is rendered useless on that agent. An agent policy registry located on a ledger allows an owner to define agent authorizations and control over those authorizations. (See 9.2 Policy Registries). Agents must notify each other when a new agent is added to an authorized pool or removed in order to warn identity owners of potential threats.

8. Recovery From Key Compromise

Key compromise means that private keys and/or master keys have become or can become known either passively or actively. To protect from either, there are techniques available: rotation, revocation, and quick recovery. Rotation helps to limit a passive compromise, while revocation and quick recovery help to limit an active one.

8.1. Key Rotation

Keys SHOULD be changed periodically to limit tampering. When keys are rotated, the previous

keys are revoked and new ones are added. It is RECOMMENDED for keys to expire for the

following reasons:

• Technology advances. Encryption (and encryption breaking) technologies are constantly advancing. Expiring keys helps enforce migrating to better technologies.

• Mitigation of compromises. Keys that change often prevent attackers from using them even if they are able to steal them. Expiring keys spreads this immunity.

• Changing needs. Key owners may only use certain secrets while performing a specific task. The task may end after a certain date and all secrets tied to that task should also be terminated. Expiring keys helps enforce this this policy.

8.3. Agent Policy Key Compromise

Compromise of an agent’s policy key means an attacker can use the agent to impersonate the owner for proof presentation and make changes to the agent policy registry. Identity owners SHOULD have backup agent policy keys that are authorized to revoke the compromised key from the agent policy registry and issue a new agent policy key to the replacement agent.

8.4. DID Key Compromise

Compromise of a DID key means an attacker can use the channel to impersonate the owner as well as potentially lock the owner out from further use if the attacker rotates the key before the owner realizes what has happened. This attack surface is minimized if keys are rotated on a regular basis. An identity owner MUST also be able to trigger a rotation manually upon discovery of a compromise. Owners SHOULD implement a diffuse trust model among multiple agents where a single compromised agent is not able to revoke a key because more than one agent is required to approve the action.

8.5. Link Secret Compromise

Compromise of the owner link secret means an attacker may impersonate the owner when

receiving verifiable claims or use existing claims for proof presentation. Note that unless the

attacker is also able to use an agent that has “PROVE” authorization, the verifier will be able to

detect an unauthorized agent. At this point the owner SHOULD revoke her claims and request

for them to be reissued with a new link secret.

8.6. Claim Compromise

Compromise of a verifiable claim means an attacker has learned the attributes of the claim. Unless the attacker also manages to compromise the link secret and an authorized agent, he is not able to assert the claim, so the only loss is control of the underlying data.

Most technical parts that were beyond me at the time follows, please see the orignial document attached.