“Go” And Do Security Access Control Properly

One of our major problems in security is that we have build systems which use role-based security, and it is flawed. Increasingly we need…
Photo by Markus Spiske on Unsplash

“Go” And Do Security Access Control Properly: Attribute-Based Encryption (ABE)

One of our major problems in security is that we have build systems which use role-based security, and it is flawed. Increasingly we need attributes, such as location, and time, to properly authenticate a user.

Introduction

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 we 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’s 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 will this 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 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), and where we can define fine-grained control on 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 into order to access given attributes.

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 will take the secret key (SK) and return a secret key (SK) for a given set of attributes (S˜).

Coding

So let’s keep it simple. Let’s say we have six attributes (0 1 2 3 4 5), and then define a policy based on these. The following is the Golang code to implement a basic demo [here]:

A sample run is [here]:

Message: Danger, danger!!
Policy: ((0 AND 1) OR (2 AND 3)) AND 5
Attributes: [0 1 3 5]

Decrypted Message: Danger, danger!!

and for a failure [here]:

Message: Danger, danger!!
Policy: ((0 AND 1) OR (2 AND 3)) AND 5
Attributes: [1 3 5]
You do not have rights!!

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 providing various attributes to define the claims they have to access the data.

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.