Towards Zero Trust and Attribute-Based Encryption

Overall, in cybersecurity, we need to realise that role-based access security (RBAC) is often not a sensible solution for protecting data and services. While it simplifies things, it does not efficiently scale across multiple domains and can end up being a rats-nest of access rights.

The way it works is that users get rights of access to data or services based on the role(s) they have been granted. These tend to be fairly large-ranging roles, such as where a GP role would get access to all the things that a GP needs, even though they might only need access to specific things at a specific time. One GP might actually need more rights than another one, and so typically add another role for the specific additional tasks. It then all becomes a tangled mesh of roles, and where if someone gains access to someone’s account, they inherit all of the rights of the roles assigned.

An improved approach would be to define a zero-trust environment, where every user must provide that they have the correct attributes to access a service or data. For example, we might define that access to a specific patient requires that there must be proof that someone is in a certain location, has authenticated themself with a wearable device, and that the time is between 9am and 5pm. For this, we need Attribute-Based Access Control (ABCL), and where a user must gain the right set of attributes/claims to gain access to a service/data.

We then end up with two main classifications of access control (Figure 1):

• Role-Based Access Control (RBAC). Define the role for the access to data, eg Policy = Subject (AND/OR) Role –> Permissions.
• Attribute-Based Access Control (ABCL). Define attributes eg Policy = User (role, nationality) AND/OR Resource (department, owner) AND/OR Action AND/OR Context (time, IP, location) -> Permissions.

Figure 1

As we will see, there are two main Attributed-Based Encryption methods:

• Key-policy attribute-based encryption (KP-ABE) and the other is In KP-ABE we generate the key based on a policy that contains attributes.
• Ciphertext-policy attribute-based encryption (CP-ABE). In CP-ABE, we use a tree structure with different keys in order to access given attributes.

And, so, yesterday, I was privileged to speak to the co-inventor of ABE, and a world leader in the area:

Apple [here]

A Matter of Rights

We are generally poor at properly integrating security and often use overlay models to overcome our lack of embedded security. Our models of security often, too, come from our legacy operating systems, and which fail to protect data (as they were designed to protect files and directories rather than data). We thus often fail to encrypt data properly, and we fall back to the operating system to provide rights to files. Our overall policies thus focus on documents and not on data.

We have thus created a data world which is open, and then, to protect it, we put up perimeters. But we find out that there are insiders who sit behind the firewall and can access our data. We then encrypt with an encryption key, but this is often applied on a fairly large scale basis. So how do we control access to sensitive data when we use cloud-based storage? Well, we need to look at better ways of protecting our data while still being able to process it.

The systems we have created have grown up through operating system security and apply role-based security. In a Linux system, we can have:

User: bob
Group: gp

and we have access rights as:

User=rwx Group=rwx Everyone=rwx

In this case, Bob will have access rights based on his ownership of a file or on the group he is in — and is defined as role-based security. In an Active Directory infrastructure, Bob can also be part of multiple groups, and this will gain him rights. However, being part of a group is not properly applying security, and we thus have to normally overlay a security model to check Bob’s rights to access a given file. What we really want is to be able to define that the access is based on other things, such as his location, or whether he is the clinician associated with a patient. These are defined as attributes for his access rights and define attributed-based security.

One of the best methods of embedding security into data is ABE (Attributed-based Encryption), where we can define fine-grained control of the decryption process. For example, we might define that some sensitive health information is only accessible when the patient and the clinician have both authenticated themselves and are in a provable location. Thus during the encryption process, we apply a policy:

Policy = ((user=GP and location=Edinburgh) or 
    (user=Patient and location=Scotland)

In this case, we would allow access to a file based on a user who is a GP in Edinburgh or a Scottish patient. In this way, we can base our accesses on real attributes rather than operating system rights.

Implementation

The following provides a basic demo of ABE, and where we use pairing-based encryption [1]:

Attribute Based Encryption

With CP-ABE, we would define a policy that was based on attributed such as time and location (Figure 2). These attributes would then be used to create a public key and which when added to the policy, would encrypt the data. When the attributes were generated for access, they would then generate an associated private key which would decrypt the data.

The policy encodes a postorder traversal of the threshold tree. For “foo bar fim 2of3 baf 1of2” we get two threshold gates and four leaves. Examples [here]:

• “fim bar baf 2of3 foo 1of2” Try!
• “foo bar baf 2of3 fim 1of2” Try!

The coding for this is:

CP-ABE (Cipher Policy - Attributed-Based Encryption) with Kryptology

In this case, we have several stages for the encryption process:

• Setup. This stage generates the public parameters (PK) and a master key (MK).
• Encrypt(PK,M, A). In this stage, we take PK and a message (M), along with an access structure for all the attributes (A). The output will be some ciphertext (CT) that embeds A so that when a user satisfies the required attributes, they will be able to decrypt the ciphertext.
• Key Generation(MK,S). In this stage we take the master key (MK) and a number of attributes that define the key (S), and output a private key (SK).
• Decrypt(PK, CT, SK). In this stage we take the public parameters (PK), the cipher text (CT — and which contains the access policy), and the secret key (for a given set of attributes S), and try to decrypt the ciphertext. If successful, we will get our message (M) back again.
• Delegate(SK, S˜). If required, we can use a delegate who will take the secret key (SK) and return a secret key (SK) for a given set of attributes (S˜).

Example

Now let’s try to access the CP-ABE data with a policy of “staff csn09112 admin 2of3” and with the attributes of “staff”, “csn09112” and “csn90101” [here]:

As we can see we can decrypt the encrypted data. But now let’s say we are a student who is studying “csn09112” and “csn09101” [here]:

Now we see we do not have enough attributes to match the policy. And now, we login as “root” and with a policy of “staff csn09112 csn09110 2of3 root 1of2” [here] and we get:

So, we can now create a system which can dynamically encrypt data based on a policy. The access to the data will not be controlled by the operating system any more, but is embedded into the data. In this way, our data can exist in an open place — such as in the Cloud — where we have trusted attribute providers.

If we were to start again with our data infrastructure, we certainly wouldn’t start from where we are. Most of the systems we have created — our spreadsheets, word documents, databases, and so on — have little in the way of embedded security, and we must thus overlay our security models. This makes the infrastructure complex and where is becomes difficult to manage. CP-ABE provides a much simpler solution and allows us to make sure our data is properly protected

Conclusions

Our security models are old, and where we have had to use overlay methods, and then spanned these across hybrid systems. This has created complex security policies, and which rely often on operating systems and domain controllers making judgments on access rights to files. In a world of Cloud computing, we must assume that our data can be accessed by anyone, so we increasingly need to embed security into our data.

Our future must be built by embedding policies into our data and supporting users by providing various attributes to define the claims they have to access the data.

Here is Brent talking about his invention:

References

[1] Bethencourt, J., Sahai, A., & Waters, B. (2007, May). Ciphertext-policy attribute-based encryption. In Security and Privacy, 2007. SP’07. IEEE Symposium on (pp. 321–334). IEEE.