Towards Complete Encryption within Cloud-based Systems: Attributed-based Encryption

Towards Complete Encryption within Cloud-based Systems: Attribute-based Encryption

In a world of GDPR…

• Why we still have databases with non-encrypted values?
• Why do we store data on public cloud systems in a non-encrypted format?
• Why does anyone who has access to a spreadsheet, is able to see the values that are used?
• Why can’t we restrict data access to those users who provide the right attributes?

In public key encryption, we use the public key of a recipient to encrypt data, and they then use their private key to decrypt it. But we have to discover the public key in some way. This normally involves reading the key from a digital certificate. This is a rather complex system where, if you were sending an email to person, you need to get their public key, and then add that onto your key ring.

With IBE (identity-based encryption), we use something about the identity of a person, such as their email address, to generate the public key for the recipient. In this way we can easily encrypt data by only knowing the email address of the person:

With ABE (Attribute-based Encryption) we can use any set of attributes such as a roles or country, to encrypt messages. This can be subsets of attributes (key-policy ABE — KP-ABE) or can be policies over a set of attributes (ciphertext-policy ABE — CP-ABE). The decryption is then achieved using by an entity which has the key for the matching attributes.

Within CP-ABE, we associate a private key with a set of attributes. We can then define the required attributes to be owned, and where we use a thresholding system (such as k out of n attributes have to be present). For example, we might have four attributes of {academic, student, java_module, crypto_module}, and where we have roles of an academic and student, and registrations of access to crypto_module and java_module. Bob is a student and is studying the Java module and has keys for the attributes of {student, java_module}. Alice is an academic who has the key for the attribute of {academic}. The policy might for encrypting the data is for someone who is a student and registered for crypto_module, or be an academic:

(student and crypto_module) or academic

In other form this is: (student ∧ crypto_module) ∨ academic

Then Alice will be able to decrypt it, while Bob cannot. An advantage of this method is that Victor, who encrypts the data, does not need to know the list of users who can decrypt the data (implicit authorization). The encryption keys for the related attributes can be generated after the data has been encrypted. In this case, Alice will have to prove that she has the attribute of “academic” in order to get the encryption key. With KP-ABE the access policy is encoded into the users secret key, and the ciphertext is then computed with against a set of attributes.

One of the most important aspects with ABE is collusion resistance, and where entities should not be able to collude to generate the required key. In the example above, it should not be possible for someone with the {student} attribute and another person with the {crypto_module} attribute, to bring their attributes together to generate the decryption key.

Conclusions

As we increasingly move towards Cloud-based systems, we must increasingly encrypt ALL our data. Using ABE allows us to carefully control who is allowed access to our data, and where we can setup a trust infrastructure where we use multiple attributes that users must prove. We can then quickly lock out access, if required.