Protecting Sensitive Parts of Credentials with Cryptographically Enforceable Policies

Another example is from the Dutch government, which has a law that says that the ‘Burger Service Number (BSN)’, i.e. the number that the government uses to identify its citizens and other registered residents, may only be used within the government itself, within the healthcare domain, and for onboarding by banks and other financial institutions. It is realistic to expect that citizens can be easily coerced^[3] to provide this number to parties that are not eligible to see it if it were to appear in a ‘regular’ verifiable credential.^[4]

Limiting access to data by using traditional public key encryption methods is not a solution, as it requires knowledge of the public key of the decryptors, and does not cater for more complex access control policies that are resistant to collusion attacks.

Around 2007, various articles have been published that introduced and refined what they called Attribute-Based Encryption (ABE), which is a mechanism that allows

• one party to express a policy in terms of attributes and encrypt a plaintext ‘under that policy’ to produce a ciphertext, and
• other parties to acquire decryption keys in which their actual attributes are embedded, in such a way that this key can only successfully decrypt the ciphertext if the attributes embedded in the key satisfy the policy under which the ciphertext was encrypted.

To apply this in an SSI context, we first require that services exist where parties can obtain decryption keys in which their actual attributes are embedded. These must be trusted services, meaning that they need to do strong authentication and validation of the attributes that such parties offer. Secondly, we enable issuers to replace the plaintext value(s) of one or more attributes in their credentials with a ciphertext that embeds the policy for recovering the plaintext again. This idea also applies to so-called presentations, i.e. sets of data derived from one or more credentials (from possibly different issuers) that are typically constructed by holders. Thus, while issuers can author the policies under which (parts of) credentials are encrypted, holders can do this for encrypting (parts of) presentations.

In the case of the medical trial, if the issuer would issue a credential that has an attribute “placebo” which could be true or false, it could encrypt just this value under a policy that requires the decrypting party to be a member of the project team that conducts this trial. Arbitrary verifiers would then be able to see all fields, except the ‘placebo’-field, which can only be decrypted by a member of the project team.

Similarly, the Dutch government could issue citizen identity data as a credential, encrypting the BSN of the holder under the policy that ensures the legal requirements are fulfilled.

Combining SSI and ABE

Before discussing how SSI and ABE can be combined, we postulate three ABE-roles: ‘KeySmith’, ‘encryptor’ and ‘decryptor’. An encryptor is a party that uses an encryption key and a policy to encrypt some plaintext and produce a cryptogram. A decryptor is a party that uses a decryption key to decipher the cryptogram, which it can only do successfully if the attributes that are embedded in its decryption key satisfy the policy that is embedded in the cryptogram. The KeySmith will be doing all key generation and distribution. Here is how it works:

KeySmiths provide offerings that consist of a (public) key that is intended for encrypting plaintexts with. They key is associated with attribute types, which an encryptor can use to specify a policy with, and decryptors must provide values for when requesting a decryption key. We expect to see various KeySmiths, each of which may provide multiple such offerings.

Encryptors thus need to choose which KeySmith offering to use so that it can create a policy under which it can then encrypt plaintexts. Typically, the encryptor will assess the KeySmith to ensure that it will only embed decryptor attributes in the decryption keys it generates after having ascertained that they are in fact valid attributes for these decryptors.

Decryptors will need to go to the decryption-key provisioning service (DKPS) of that KeySmith to obtain a decryption key. The KeySmith will request the attributes it has specified it will encode in the decryption key, validates them, and returns the decryption key. This allows decryptors to decrypt ciphertexts with an embedded policy that is satisfied by the attributes embedded in the decryption key.

There are various ways in which SSI roles (issuer, holder, and verifier) can be combined with ABE roles. The most obvious are combinations such as (issuer,encryptor), (holder,decryptor) and (verifier,decryptor). This allows issuers to create credentials parts of which may be hidden from holders and/or verifiers. However, (holder,encryptor) might be useful as it enables a holder to encrypt (parts of) presentations that it sends to the verifier which the latter can only read if it complies with the holder’s policy.

Regarding the KeySmith role, there are cases where it is appropriate to combine it with the issuer role (e.g. for a government), who can then ensure that the validation of the attributes that are embedded in decryption keys is done using criteria that the issuer itself can specify. There are other cases, e.g. when it is important that the issuer has no clue whatsoever about the identity (attributes) of possible verifiers, where it is appropriate to have an independent (‘trusted’) party (such as a notary public) fulfill this role.

The potence of all this heavily depends on the expressiveness that ABE allows for the policies it can use, and the kinds of use that can be made of it. Bethencourt et. al^[6]. present an ABE system that works for complex policies (access structures), that consist of a logical expression (using ANDs and ORs) of attributes. This allows for policies such as “[role]=’ceo’ AND ([residence]=’EU’ or [residence]=’UK’)”, which should suffice for many applications.

Discussion

There are various conditions that must be met for this to work properly:

1. Attribute-types must ‘semantically match’. An issuer should express its policy using attribute types in the same meaning as the KeySmith. Otherwise, the phrase ‘decryption key DK satisfies the policy’ is evaluated in a different way than the issuer had foreseen and may therefore have undesired consequences.
2. A KeySmith should only generate a decryption key using ‘valid attribute values’, i.e. attributes that pertain to the party that requests such a key. In the case of the medical trial, the KeySmith must be certain that a party that claims to be a member of the project team is in fact such a member. If the KeySmith does not check that (properly), parties may be able to obtain keys with which they can see the hidden trial information causing the trial to become invalid.
3. Issuers should have a mechanism that enables decryptors to find out when/which attributes of the credentials that it issues will be encrypted under a policy, and where it can request for a decryption key.

All this isn’t difficult per se, but it is something that needs to be done.

There are, however, some things that need more careful consideration. One example is that decryptors could share their decryption keys with others, which could then decrypt ciphertexts they might not be entitled to. Keeping keys secret is nothing new: in public key cryptography, private (signing) keys are to remain secret as well. But the consequences of sharing do differ. If you share your signing key, you run the risk of the other party misusing it. However, if you share your ABE decryption key, the risk of misuse is not you (the decryptor), but the encryptor that may now need to face the situation that a party can decipher a cryptogram that it should not be able to. Encryptors should take care to construct their policy in such a way that this risk is sufficiently mitigated.

To sum it up: properly combining SSI and ABE provides parties with capabilities that are necessary for supporting use-cases that cannot be supported by SSI alone. However, combining them properly requires more engineering, e.g., to ensure the correct functioning and the mitigation of (encryptor) risks. We are eager to learn where this will go.

1. There is no consensus as to what SSI is (not). Preukschat and Reed put together a comprehensive book about SSI. We assume the reader is familiar with the basic building blocks. Van Deventer wrote a blog showing what’s good, bad, and ugly.
2. This is principle #2 of SSI in Christopher Allen’s blog “The Path to Self-Sovereign Identity” (2016).
3. Other ways of coercion and suggestions and means to counter them have been proposed, e.g. in another blog by Van Deventer.
4. Selective disclosure doesn’t help here, as the user controls what is (not) selectively disclosed.
5. Ostrovsky, Sahai, Waters, “Attribute-Based Encryption with Non-Monotonic Access Structures” CCS’07, October 29–November 2, 2007, Alexandria, Virginia, USA.
   ACM_CCS2007.pdf (ucla.edu)
6. John Bethencourt, Amit Sahai, Brent Waters. Ciphertext-Policy Attribute-Based Encryption. 2007IEEE Symposium on Security and Privacy (SP ’07), May 2007, Berkeley, France. ff10.1109/SP.2007.11ff.ffhal-01788815.
   Online: Ciphertext-Policy Attribute-Based Encryption (archives-ouvertes.fr)