In the following presentation, I am going over the basic details of security tokenization starting from its definition.
I will be going over practical integration and deployment options for tokenization in another presentation. Please stay tuned!
Showing posts with label encryption. Show all posts
Showing posts with label encryption. Show all posts
Tuesday, September 2, 2014
Wednesday, July 23, 2014
Is Encryption a Silver Bullet?
You have probably heard that "encrypt all your data so that even if an attacker gets their hands on your data, they won't be able to see your plaintext data as they cannot decrypt it". So, encryption is a silver bullet that protects your enterprise data from attackers of all walks, isn't it? Not really! Encryption do help in certain scenarios but there are many other cases where it may not fully protect your data. For example, if your goal is to protect data against direct access to data from the physical media, then encryption works if the keys are stored elsewhere.
What most people forget is that most of the encrypted data is available in plaintext to database systems (if transparent encryption is used) and applications. If an attacker can get access to the database or application, they get access to plaintext data. The strongest encryption algorithm or the key for that matter won't help in that case.
So, if encryption won't fully help to protect your data, what can we do to improve protection? Obviously, we need to use defense in depth and we need to make it harder for attackers to gain access to application or database server. Application firewalls and database firewalls can help.
What if attackers penetrate the firewalls and gain access to application? One way to contain/control the damage is to always use a least privileged database user in the application so that the attacker has access only to limited objects in the database. Hence, the damage they can do is limited.
Another control mechanism is to make only the least information available for the application. For example, if the application requires two columns of a table, instead of using the full table, you can limit to the two columns only. That way, if the attacker does not have access to the database directly, they can only steal limited amount of data. One step further is to dynamically mask (redact) data before sending to the application if the full data is not necessary for the application functionality. For example, if the application just displays the credit card number, instead of sending the full 16 digit credit card number, masked number with the last four digit could be sent to the application.
Let me tell you one last, but not the least, brilliant idea. Delete or archive the data that you don't use. If there is no data, there is nothing to steal!
What about insiders who misuse the applications or databases .. and also targeted insiders (i.e. insiders whose credentials are stolen by attackers to avoid perimeter security)? Granting least privilege can help, but this where you need to have detection mechanisms (auditing and monitoring) in place. Behavioral anomaly detection could help to stop such attacks and remove the malicious or targeted insiders from the system.
The bottom line is encryption is not the cure for all your security threats. You've got to strengthen the security at the points where the plaintext is readily available. Always grant least privileges to application and database users. Deploy firewalls and detection systems. Extensively audit to make users accountable for what they do. Educate users how not be the target of phishing attacks which gives easy access to your systems to attackers. With all these sophisticated attacks we see day in and day out, defense in depth is the way to go!
Figure: Encryption works to prevent direct access to disk data
What most people forget is that most of the encrypted data is available in plaintext to database systems (if transparent encryption is used) and applications. If an attacker can get access to the database or application, they get access to plaintext data. The strongest encryption algorithm or the key for that matter won't help in that case.
Figure: Encryption fails as attacker hacked into the database server which has access to plaintext data
Figure: Encryption fails again as attacker gained access to the application server which sees plaintext data
So, if encryption won't fully help to protect your data, what can we do to improve protection? Obviously, we need to use defense in depth and we need to make it harder for attackers to gain access to application or database server. Application firewalls and database firewalls can help.
What if attackers penetrate the firewalls and gain access to application? One way to contain/control the damage is to always use a least privileged database user in the application so that the attacker has access only to limited objects in the database. Hence, the damage they can do is limited.
Another control mechanism is to make only the least information available for the application. For example, if the application requires two columns of a table, instead of using the full table, you can limit to the two columns only. That way, if the attacker does not have access to the database directly, they can only steal limited amount of data. One step further is to dynamically mask (redact) data before sending to the application if the full data is not necessary for the application functionality. For example, if the application just displays the credit card number, instead of sending the full 16 digit credit card number, masked number with the last four digit could be sent to the application.
Let me tell you one last, but not the least, brilliant idea. Delete or archive the data that you don't use. If there is no data, there is nothing to steal!
What about insiders who misuse the applications or databases .. and also targeted insiders (i.e. insiders whose credentials are stolen by attackers to avoid perimeter security)? Granting least privilege can help, but this where you need to have detection mechanisms (auditing and monitoring) in place. Behavioral anomaly detection could help to stop such attacks and remove the malicious or targeted insiders from the system.
The bottom line is encryption is not the cure for all your security threats. You've got to strengthen the security at the points where the plaintext is readily available. Always grant least privileges to application and database users. Deploy firewalls and detection systems. Extensively audit to make users accountable for what they do. Educate users how not be the target of phishing attacks which gives easy access to your systems to attackers. With all these sophisticated attacks we see day in and day out, defense in depth is the way to go!
Saturday, March 30, 2013
[ABE] How to re-encrypt without decrypting in the cloud?
ABE (Attribute Based Encryption) is a great invention by security researchers and allows to efficiently perform group based encryption. While it provides many benefits, revocation of users has been a key issue of utilizing ABE (FYI, another key issue is key escrow problem where one party knows all secret keys - as far as I know this is still an open problem. If you are looking for a ground breaking research topic, it could be this one; but be warned - it's hard, you may not find a solution ;) ). The most common way of revoking attributes in ABE is to periodically refresh secret keys given to users. (Another approach is to use short-lived attributes. For example, use a time based attribute which expires after a certain time in the future.) While this approach works, it does not scale: when there are many users, regenerating keys and sending them to users have a huge overhead. This also requires re-encrypting already encrypted documents to match the new keys. In this blog post, I am looking at an alternative approach that we can utilize. This blog post is inspired from the techniques presented in a recent paper by Sahai et al. [1] and the attribute delegation work done by Goyal et al. [2].
In a real life situation, revocation needs to handle two things:
(1) Make the policy under which data is encrypted is invalid for revoked user(s).
(2) Re-encrypt the affected data to reflect the revocation. (If we do not re-encrypt, a revoked user can use her old credentials to access the encrypted data.)
Let's get started using a simple example.
Bob shares an encrypted file in a public cloud with Alice, Ted and Tim. In order to make the encryption process efficient, Bob can a group encryption technique such as ABE (attribute based encryption) or BE (broadcast encryption) or even a simple symmetric key encryption. For this example, we focus only on ABE. I will devote a separate blog post for broadcast encryption.The beauty of the group based encryption technique is that Bob needs to do ONLY ONE encryption for all the people with whom he shares the file.
Some background information: In a modern group based encryption scheme, users are assigned attributes and the users having the same set of attributes belong to the same group. Let's say for this example, Bob has tagged Alice, Ted and Tim with the attributes "cool_friend" and "buddy", and is using ABE cryptosystem.
Bob has his own KGC (key generation center) to run the ABE cryptosystem. Bob generates the master secret key MK and public key PK. (Keygen(k) --> MK, PK)
Bob does not trust the public cloud, so Bob uses a client side encryption as shown above (Encrypt(SK, M, policy("cool_friend" AND "buddy")) --> C) and keeps the secret key secret from the public cloud.
After some time, Bob decides that he no longer wants Tim to access the encrypted file. Tim's credentials still allow him to decrypt the encrypted file. So, Bob needs to re-encrypt the file so that Tim can no longer decrypt the file.
In a typical ABE setting, how does Bob do this revocation?
a. Generate new secret keys for Ted and Alice for the attribute "cool_friend" and "buddy", and send these to them (this process results in a new master secret key SK' and public key PK' as well.)
b. Download the encrypted document from the cloud and decrypt it (Decrypt(SK, C) --> M) and re-encrypt (Encrypt(PK', M, policy("cool_friend" AND "buddy")) --> C') and upload back to the cloud.
Can we do better? Can we delegate the re-encryption to the cloud itself? (The subject of this post.)
Decrypt -> Re-encrypt is off the table since in order to do that, Bob needs to give SK to the cloud, which is what Bob does not want to do in the first place - Bob wants to hide the content from the cloud. So, is there a way out for this problem?
One possible approach is as follows:
- Execute step 1
- Ask the cloud to do an onion encryption over the current encryption
Problem: size of the onion gets bigger and bigger as we do more revocations.
Can we do better? Yes, we can incrementally change the ciphertext using the technique called ciphertext delegation [1]. I am showing you a simplified version of ciphertext delegation here. Please read [1] for more details.
The idea behind ciphertext delegation is to allow another party to re-encrypt a file under a more restrictive policy than the original policy without decrypting the file. That is, originally encrypted as Encrypt(PK, M, P) = C, then do the delegation: Delegate(PK, C, P') = Encrypt(PK, M, P'), where P' is a more restrictive policy than the original policy P.
How can we encrypt under a more restrictive policy? Recall that the policies we deal with have a linear structure. We can restrict such policies in many ways. Here are some possible approaches:
- increase node threshold (for example from OR to AND)
- add an additional attribute to the access tree
- remove a subtree from the access tree
For illustration purpose, I will be using the second option. I am introducing a new attribute called "time" to restrict the policy.
Bob uploads some public information to the cloud so that it can re-encrypt and also some additional public information to allow only Alice and Ted recover the secret components for the attribute "time". It is done in a way that Tim will not be able to recover the secret for the attribute "time". Hence, Tim will not be able to satisfy the new restrictive policy.
Bob can use several approaches to give this additional secret only to Alice and Ted. One approach is that Bob may give this secret directly to Alice or Ted. Another approach is to utilize a broadcast encryption technique to encrypt this secret for only Alice and Ted and upload to the cloud as public information.
The following equations shows how the cloud does the re-encryption:
Alice and Ted can generate the following value:
It is easy to see that using their other credentials and the above new value, Alice and Ted can decrypt the re-encrypted file. However, as Tim cannot generate the above value, he will not be able to access the re-encrypted file.
It should be noted that the above scheme fails if Alice or Ted collude with Tim. I leave the readers to figure out a collision resistant way to do the ciphertext delegation (hint: read [1] :) I hope this post gave you some idea about how to do re-encryption for ABE in the cloud itself without decrypting.
References:
[1] http://eprint.iacr.org/2012/437.pdf [CRYPTO 2012]
[2] http://research.microsoft.com/en-us/um/people/vipul/abe.pdf [CCS 2007]
[3] http://eprint.iacr.org/2004/086.pdf [CCS 2006]
In a real life situation, revocation needs to handle two things:
(1) Make the policy under which data is encrypted is invalid for revoked user(s).
(2) Re-encrypt the affected data to reflect the revocation. (If we do not re-encrypt, a revoked user can use her old credentials to access the encrypted data.)
Let's get started using a simple example.
Bob shares an encrypted file in a public cloud with Alice, Ted and Tim. In order to make the encryption process efficient, Bob can a group encryption technique such as ABE (attribute based encryption) or BE (broadcast encryption) or even a simple symmetric key encryption. For this example, we focus only on ABE. I will devote a separate blog post for broadcast encryption.The beauty of the group based encryption technique is that Bob needs to do ONLY ONE encryption for all the people with whom he shares the file.
Some background information: In a modern group based encryption scheme, users are assigned attributes and the users having the same set of attributes belong to the same group. Let's say for this example, Bob has tagged Alice, Ted and Tim with the attributes "cool_friend" and "buddy", and is using ABE cryptosystem.
Access control policy
Bob has his own KGC (key generation center) to run the ABE cryptosystem. Bob generates the master secret key MK and public key PK. (Keygen(k) --> MK, PK)
Keygen operations
Encrypt(SK, M, policy("cool_friend", "buddy") steps
Secret Key generation for Alice and Tim (Similarly for Ted - not shown above)
Secret keys for users are generated by Bob based on a linear secret sharing scheme. Shamir's secret sharing scheme is the most popular choice. For simplicity, for this example, I am using simple addition as the linear secret sharing scheme. (Notice that the secret keys given to Alice and Tim and generated using different sets of secret shares. This is to prevent collisions. Interested readers are encouraged to read [3] for more in-depth details on preventing collisions.) For complex monotonic policies, the typical approach is to build an access tree and internally use the Shamir's secret sharing scheme.
Now Alice, Ted and Tim can decrypt the document using their secret keys.
Alice decrypting Bob's message
In a typical ABE setting, how does Bob do this revocation?
a. Generate new secret keys for Ted and Alice for the attribute "cool_friend" and "buddy", and send these to them (this process results in a new master secret key SK' and public key PK' as well.)
b. Download the encrypted document from the cloud and decrypt it (Decrypt(SK, C) --> M) and re-encrypt (Encrypt(PK', M, policy("cool_friend" AND "buddy")) --> C') and upload back to the cloud.
Can we do better? Can we delegate the re-encryption to the cloud itself? (The subject of this post.)
Decrypt -> Re-encrypt is off the table since in order to do that, Bob needs to give SK to the cloud, which is what Bob does not want to do in the first place - Bob wants to hide the content from the cloud. So, is there a way out for this problem?
One possible approach is as follows:
- Execute step 1
- Ask the cloud to do an onion encryption over the current encryption
Problem: size of the onion gets bigger and bigger as we do more revocations.
Can we do better? Yes, we can incrementally change the ciphertext using the technique called ciphertext delegation [1]. I am showing you a simplified version of ciphertext delegation here. Please read [1] for more details.
The idea behind ciphertext delegation is to allow another party to re-encrypt a file under a more restrictive policy than the original policy without decrypting the file. That is, originally encrypted as Encrypt(PK, M, P) = C, then do the delegation: Delegate(PK, C, P') = Encrypt(PK, M, P'), where P' is a more restrictive policy than the original policy P.
How can we encrypt under a more restrictive policy? Recall that the policies we deal with have a linear structure. We can restrict such policies in many ways. Here are some possible approaches:
- increase node threshold (for example from OR to AND)
- add an additional attribute to the access tree
- remove a subtree from the access tree
For illustration purpose, I will be using the second option. I am introducing a new attribute called "time" to restrict the policy.
Restrictive policy
Bob uploads some public information to the cloud so that it can re-encrypt and also some additional public information to allow only Alice and Ted recover the secret components for the attribute "time". It is done in a way that Tim will not be able to recover the secret for the attribute "time". Hence, Tim will not be able to satisfy the new restrictive policy.
New public information given to the cloud to re-encrypt in the cloud
Additional secret given only to Alice and Ted
Bob can use several approaches to give this additional secret only to Alice and Ted. One approach is that Bob may give this secret directly to Alice or Ted. Another approach is to utilize a broadcast encryption technique to encrypt this secret for only Alice and Ted and upload to the cloud as public information.
The following equations shows how the cloud does the re-encryption:
It is easy to see that using their other credentials and the above new value, Alice and Ted can decrypt the re-encrypted file. However, as Tim cannot generate the above value, he will not be able to access the re-encrypted file.
It should be noted that the above scheme fails if Alice or Ted collude with Tim. I leave the readers to figure out a collision resistant way to do the ciphertext delegation (hint: read [1] :) I hope this post gave you some idea about how to do re-encryption for ABE in the cloud itself without decrypting.
References:
[1] http://eprint.iacr.org/2012/437.pdf [CRYPTO 2012]
[2] http://research.microsoft.com/en-us/um/people/vipul/abe.pdf [CCS 2007]
[3] http://eprint.iacr.org/2004/086.pdf [CCS 2006]
Wednesday, July 7, 2010
[Security/Privacy] Can we bridge the gap?
I was wondering how we may apply secure computing (e.g. computation over encrypted data) in real life scenarios where you have to interact with real objects as opposed to bits and bytes. It seems to me quite difficult, if not impossible, to achieve the same "invisibility" in the physical world; the very nature of the tangibility makes it hard to do so.
Consider the example where I want to mail my digital photos to Walgreens and get them printed. However, I want Walgreens to see neither the photos nor the printed copies. You see the similar privacy/security problems in getting something printed through a courier service such as UPS. I am not aware of any technology that we could use to solve this problem. One important thing is for the solution to be economical for me (the service requester), the amount of work I need to do (hence the cost) to recover the actual thing (actual photos from printed copies) should be cheaper than the service I want (getting the photos printed) in the long run. Otherwise, I might as well buy my own printing machine and do the printing myself which will eliminate the problem of privacy/security.
Consider the example where I want to mail my digital photos to Walgreens and get them printed. However, I want Walgreens to see neither the photos nor the printed copies. You see the similar privacy/security problems in getting something printed through a courier service such as UPS. I am not aware of any technology that we could use to solve this problem. One important thing is for the solution to be economical for me (the service requester), the amount of work I need to do (hence the cost) to recover the actual thing (actual photos from printed copies) should be cheaper than the service I want (getting the photos printed) in the long run. Otherwise, I might as well buy my own printing machine and do the printing myself which will eliminate the problem of privacy/security.
Wednesday, March 17, 2010
Computation over encrypted data [Crypto]
The following diagram shows the ideal situation:
The objective is to perform a general computation over encrypted data so that the party that performs the computation learns neither the input values nor the result of the computation (over a finite field). The computation to be performed (e.g. eigenvalue computation, null space computation, Gaussian elimination, etc.) is public (i.e. known to everyone). Theoretically speaking, one can achieve the above objective using a SMC (Secure Multiparty Computation) protocols by evaluating a scrambled Boolean circuit. However, it is not practical.
Two popular practical techniques that we can use:
1. Commutative encryption (Pohlig-Hellman)
2. Homomorphic encryption (Paillier, Damgard, Unpadded RSA, Benaloh, ElGamal, etc.)
Since I am interested in one off computation, IMO, homomorphic encryption is the most suitable here. Computations over finite fields, in general, involves two binary operations (e.g. addition and multiplication). However, all the practical homomorphic crypto systems are homomorphic to only one operation. (E.g.: addition - Paillier, Damgard, Benaloh; multiplication - Unpadded RSA, Elgamal). It should be noted that mid last year, IBM published a paper on a fully homomorphic encryption using ideal lattices, but it is computationally intensive and thus not suitable for real applications. So, it is still an open problem to invent a practical fully homomorphic encryption. Until such an invention, we need to rely on specialized protocols to solve the afore mentioned problem.
The objective is to perform a general computation over encrypted data so that the party that performs the computation learns neither the input values nor the result of the computation (over a finite field). The computation to be performed (e.g. eigenvalue computation, null space computation, Gaussian elimination, etc.) is public (i.e. known to everyone). Theoretically speaking, one can achieve the above objective using a SMC (Secure Multiparty Computation) protocols by evaluating a scrambled Boolean circuit. However, it is not practical.Two popular practical techniques that we can use:
1. Commutative encryption (Pohlig-Hellman)
2. Homomorphic encryption (Paillier, Damgard, Unpadded RSA, Benaloh, ElGamal, etc.)
Since I am interested in one off computation, IMO, homomorphic encryption is the most suitable here. Computations over finite fields, in general, involves two binary operations (e.g. addition and multiplication). However, all the practical homomorphic crypto systems are homomorphic to only one operation. (E.g.: addition - Paillier, Damgard, Benaloh; multiplication - Unpadded RSA, Elgamal). It should be noted that mid last year, IBM published a paper on a fully homomorphic encryption using ideal lattices, but it is computationally intensive and thus not suitable for real applications. So, it is still an open problem to invent a practical fully homomorphic encryption. Until such an invention, we need to rely on specialized protocols to solve the afore mentioned problem.
Subscribe to:
Posts (Atom)