Encrypting strings with Attribute Based Encryption[Pairing Home][Home]
Attributed Based Encryption (ABE) allows for the generation of a decryption key based on the definition of attributes in a policy. With this we will created a cipher policy and ciphertext. We will then read the policy and only decrypt if the attributes fit with the policy. The page uses AES encryption for the encryption process. Note that it may take a few seconds to process the policy [article][article][slides]:
|
Background
What’s The One Thing That Every Agrees Is Right In Computer Security, But Few Actually Do It?
Well, everyone knows that we should be encrypting data at its core level (or in the application layer), and not relying on tunnels or single encryption keys for our protection. In this way we can embed encryption into the actual data and then define the actual access rights (and without relying on domain/operating system rights). Few people still trust the security of user names and passwords to properly protect data, but we still blindly use it for our accesses to data.
Why can’t I give access to my daily step count to a cancer research company, but make sure that a tobacco company have no rights to it?
And, so, if Bob the patient wants to give Alice the GP access to his health record, he might provide the right encryption key to open it. But, what if Bob is not on-line for the access? Well, we typically define an access policy, and where we can define the rules for access. This access can then relate to the generation of the required encryption key. It thus doesn’t matter where the encrypted data is stored, as only the required encryption key will open-up the data.
Bob might then give his consent as part of his policy to Alice. Then when the policy is checked, Alice can then have rights to his data. But, at any time, if Bob thinks that Alice is using his data in an inappropriate way (such as selling it to Google), he could take away the consent, and she will not be able to generate the required encryption key. On an emergency, too, if Bob was to have a life threatening incident, we could add a policy statement that allowed any GP access to his record (but this would be logged, and check after the incident).
And so we need to move to a point where every single data element has some policy applied to it, and where the data is protected. For this we can turn to CP-ABE (Ciphertext Policy — Attributed Based Encryption), and where we bake the policy into the data, and encrypt it so that it cannot be accessed, unless we comply with the policy.
Let’s say we have some modules (csn09112, csn08102 and csn10101) and some roles (staff, admin, student, and root). These will become attributes in the system, so that all our users will gain (or verify) their rights to these attributes. Thus a student who is enrolled on csn09112 will have the attributes of “student” and “csn09112”. A staff member who teaches on “csn09112” and “csn08102” will have the attributes of “staff”, “csn09112”, and “csn08102”.
If we wanted to create a policy of access the marks for a student, we could define any two attributes of “staff”, “csn09112” and “admin” (left-hand side of Figure 1). In the diagram, ∧ is AND, and ∧ is OR. We could also define that “root” was added to the top of the tree (right-hand side of Figure 1). These sample policies would then be:
“staff csn09112 admin 2of3”. Any two of three attributes are required. “staff cns09112 admin 2of3 root 1of2”. Any two from “csn09112”, “admin” and “staff”, or “root”.
Figure 1: Policies
Now let’s try to access the CP-ATE data with a policy of “staff csn09112 admin 2of3” and with the attributes of “staff”, “csn09112” and “csn90101” [here]
And we can see that 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 existing an an open place — such as in the Cloud — and 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
.CP-ABE is brought to you with the wonder of elliptic curves and crypto-pairing, and does things in the way that things are meant to work in computer security. Within a blockchain world, citizens could store their CP-ABE policy on the blockchain, and define the attribute provides they trust. Any updates to the policy could then be achieved in almost real-time. The data, itself, will not be stored on the blockchain, and will simple contain a link to the encrypted data, and a smart contract would then be responsible for generating the right key for data access.
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.
Coding
The sample code is based on [code]:
package co.junwei.cpabe; import co.junwei.bswabe.Bswabe; import co.junwei.bswabe.BswabeCph; import co.junwei.bswabe.BswabeCphKey; import co.junwei.bswabe.BswabeElementBoolean; import co.junwei.bswabe.BswabeMsk; import co.junwei.bswabe.BswabePrv; import co.junwei.bswabe.BswabePub; import co.junwei.bswabe.SerializeUtils; import it.unisa.dia.gas.jpbc.Element; public class Demo { final static boolean DEBUG = true; static String[] attr = { "baf", "fim", "foo" }; static String policy = "foo bar fim 2of3 baf 1of2"; static String student_attr = "objectClass:inetOrgPerson objectClass:organizationalPerson " + "sn:student2 cn:student2 uid:student2 userPassword:student2 " + "ou:idp o:computer mail:[email protected] title:student"; static String student_policy = "sn:student2 cn:student2 uid:student2 3of3"; public static void main(String[] args) throws Exception { BswabeCph cph; BswabeCphKey keyCph; byte[] plt; byte[] cphBuf; byte[] aesBuf; String message="Hello"; Element m; String attr_str; BswabePrv prv; if (args.length==2) { message= args[0]; policy= args[1]; } // attr = attr_kevin; // attr = attr_sara; // policy = policy_kevin_or_sara; // attr_str = array2Str(attr); // attr_str = student_attr; // policy = student_policy; System.out.println("Running..."); BswabePub pub = new BswabePub(); BswabeMsk msk = new BswabeMsk(); //attr = attr_kevin; //attr = attr_sara; // policy = policy_kevin_or_sara; Bswabe.setup(pub, msk); prv = Bswabe.keygen(pub, msk, attr); for (int i=0;i<attr.length;i++) println("Attribute: "+attr[i]); println("Policy: "+policy); keyCph = Bswabe.enc(pub, policy); cph = keyCph.cph; m = keyCph.key; cphBuf = SerializeUtils.bswabeCphSerialize(cph); plt = message.getBytes(); aesBuf = AESCoder.encrypt(m.toBytes(), plt); // Decrypt cph = SerializeUtils.bswabeCphUnserialize(pub, cphBuf); BswabeElementBoolean beb = Bswabe.dec(pub, prv, cph); System.err.println("e = " + beb.e.toString()); if (beb.b) { plt = AESCoder.decrypt(beb.e.toBytes(), aesBuf); String s = new String(plt); println("Decrypt: "+s); } else { println("CANNOT DECRYPT!"); System.exit(0); } } /* connect element of array with blank */ public static String array2Str(String[] arr) { int len = arr.length; String str = arr[0]; for (int i = 1; i < len; i++) { str += " "; str += arr[i]; } return str; } private static void println(Object o) { if (DEBUG) System.out.println(o); } }
Presentation
The following is an outline presentation [slides]: