The End of Role-based Security and the Rise of Attribute-based Security

The Internet is over five decades old, and still, we have data breaches and cybersecurity compromises. One of the problems in this relates to the usage of role-based security, so let’s look at an alternative: Attribute-based encryption (ABE). Basically, we started with role-based security as it matched well with the operating system, but we have scaled this up to work at the corporate level. Unfortunately, the rights of the operating system do not match well with the things that are defined within organisations. Our role-based approaches can be seen as a legacy of the past, and where we just found it easier to scale the roles rather than secure our data properly.

The problem with role-based security

In cybersecurity, most of our systems are based on role-based security, and which is often flawed, as simple security has a few roles, such as staff and student. For this every person in the staff role gets the same rights (even if they need them or not). Then we often add in other roles, such as Admin, Production, and so on, and then more roles on top of that. As we scale up with more and more roles, the whole thing becomes confusing to manage, and where an adversary can just pick off a user with enough rights to achieve their mission.

These days, many companies who take cybersecurity seriously now focus on zero-trust environments, and where you do not automatically gain access to a resource just because you have a certain role. Overall, you have to prove then that you have the right to access a role, such as that you are in a certain place and at a certain time. This approach stops users at the gate and before they even have any rights to access a service.

In a perfect cybersecurity world, every single piece of data has an access policy associated with it, such as “Bob and Alice can change, Carol can delete, and Dave can view. Only access from Edinburgh or Glasgow, and only between 9am and 5pm”. Then, users would have to prove that they have the right to access the data. We would implement access to this data without secure enclaves for data.

Attribute-based Encryption

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

There are two main types of ABE. The first is Key-policy attribute-based encryption (KP-ABE) and the other is ciphertext-policy attribute-based encryption (CP-ABE). In KP-ABE, we generate the key based on a policy that contains attributes. For CP-ABE, we use a tree structure with different keys in order to access given attributes.

This page provides a basic demo of BWS CP-ABE and where we use the JB for pairing-based encryption [1]. 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) and which 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˜).

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.

Coding

The sample code is based on [code][here]:

package co.junwei.bswabe.demo;
import co.junwei.bswabe.*;
public class Demo {
 final static boolean DEBUG = true;
 
 public static void main(String[] args) throws Exception {
   String[] attr = { "baf", "fim1", "fim", "foo" };
   String[] attr_delegate_ok = {"fim", "foo"};
   String[] attr_delegate_ko = {"fim"};
   String[] attr_delegate_ko2 = {"foo"};
   
  String policy = "foo bar fim 2of3 baf 1of2";
   
     if (args.length==1) {
      policy= args[0];
     }
     
  System.out.println("Running...");
  BswabePub pub = new BswabePub();
  BswabeMsk msk = new BswabeMsk(); 
  BswabePrv prv, prv_delegate_ok, prv_delegate_ko,prv_delegate_ko2;
  BswabeCph cph;
  BswabeElementBoolean result;
  //attr = attr_kevin;
  //attr = attr_sara;
  //policy = policy_kevin_or_sara;
  Bswabe.setup(pub, msk);
  
  System.out.println("\n=====Keygen");
  prv = Bswabe.keygen(pub, msk, attr);
  System.out.println("Public Key (g)"+pub.g.toString());
  
  prv_delegate_ok = Bswabe.delegate(pub, prv, attr_delegate_ok);
  prv_delegate_ko = Bswabe.delegate(pub, prv, attr_delegate_ko);
  prv_delegate_ko2 = Bswabe.delegate(pub, prv, attr_delegate_ko2);
  System.out.println("Mask (beta): "+msk.beta.toString());
  System.out.println("Mask (g_alpha): "+msk.g_alpha.toString());
  System.out.println("Private Key (prv): "+prv.hashCode());
  System.out.println("Policy:"+policy.toString());
  
  println("\n====Encrypting");
  BswabeCphKey crypted = Bswabe.enc(pub, policy);
  cph = crypted.cph;
  
  println("Encrypted: "+cph.toString());
  println("\n=====Decrypting");
  result = Bswabe.dec(pub, prv, cph);
  
  if ((result.b == true) && (result.e.equals(crypted.key) == true))
   System.out.println("Success");
  else
   System.err.println("Failure!!!");
  
  
  println("\n=====Trying for policy ('fim','foo')");
  result = Bswabe.dec(pub, prv_delegate_ok, cph);
  if ((result.b == true) && (result.e.equals(crypted.key) == true))
      System.out.println("Success");
  else
      System.err.println("Failure");
  
  println("\n=====Trying for policy ('fim')");
  result = Bswabe.dec(pub, prv_delegate_ko, cph);
  if ((result.b == true) && (result.e.equals(crypted.key) == true))
      System.out.println("Success");
  else
      System.err.println("Failure");
  
  println("\n=====Trying for policy ('foo')");
  result = Bswabe.dec(pub, prv_delegate_ko2, cph);
  if ((result.b == true) && (result.e.equals(crypted.key) == true))
      System.out.println("Success");
  else
      System.err.println("Failure");
 }
 private static void println(Object o) {
  if (DEBUG)
   System.out.println(o);
 }
}

You will find more examples here:

Attributed-Based Encryption (ABE)

Conclusions

I do appreciate that we will not get rid of role-based security, but we need to match it with other attributes, as role alone is typically not enough. Location, time and biometrics are often required for access to sensitive data. In a true Cloud system, we do not see the underlying rights of the operating system, and we should thus try to separate these and work at a higher level.

References

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