Is your data more (or less) secure in the cloud?

The basic concept behind public cloud computing is to consolidate traditional behind the firewall services, data, and applications into an elastic on-demand multi-tenant third-party hosted environment. So, is your data more secure in the cloud compared to in the enterprise? One could argue both ways.

Less secure:
- cloud is more attractive and a lucrative target for hackers - higher RoI - if hacked, they get access to consolidated data of all customers.
- virtualization/multi-tenancy creates more attack surface compared to traditional computing model
- you loose control of your data

More secure:
- cloud may protect your data with the very latest security technologies by an expert security team while enterprises may not have that luxury.
- security patches/updates may be updated timely and in a consistent manner across all resources (better security management).
- easier to protected centralized consolidated resources than distributed resources.
- have the ability to correlate audit information from multiple customers to provide better detection and mitigation of attacks.

Explaining public cloud computing to my kid

Subway - Public Cloud Computing

Bob is living in a very busy city. In order for him to go to work, either he could take the subway train or drive his own car. Bob is a recent college graduate. He neither has  a lot of money nor a good credit score. Therefore, buying a car is somewhat out of his options. Besides, it is really time consuming to drive in the city to commute. So, Bob opts to take the subway to work. This is exactly how cloud computing works. Instead of Bob buying his own vehicle, he is using the public transportation to commute. In cloud computing, companies, without having to invest on computer hardware, rent hardware or software in the cloud.

When Bob takes the subway, he shares the ride with many other commuters. Similarly, many organizations share the computing infrastructure made available through cloud computing.

Bob pays for his subway ride everyday. He pays only when he takes it and only for the distance he travels. For example, Alice, who is also a subway commuter, has to pay more than Bob as she travels longer distance than Bob. Likewise, with cloud computing, companies pay only for the resources they use. If a company uses more resources than another, they have to pay more for the cloud provider.

Subway trains are available 24x7. Bob can catch a train virtually any time he wants. Similarly, cloud is available 24x7.

Trains have more compartments during peak hours than the normal hours. So, Bob does not have to worry about getting on-board anytime he wants to take a train. Subway accommodates all passengers catering for varying demands through out the day. The cloud is also like that. The resources in the cloud can expand or shirk based on the demand. We call it elasticity. Elasticity is a very useful property that lets businesses to timely respond to their customers for varying amounts of demand through out the year.

If Bob used his own vehicle, he needs to regularly maintain his car on his own and repair any damages. Since Bob is using the public transport, he does not have to worry about any of that. Similarly, companies can have the peace of mind that they don't have to worry about maintaining computer hardware and having a dedicated staff to look after them.

When Bob boards in to the train, he gets a seat to sit and travel peacefully. Usually, everyone respects each other and does not invade others' space. Bob can browse his smart phone or read a book without getting unnecessary peaking from others. Similarly, even though the cloud is public, companies get their own bounded space to do their business so that their data is not mixed with other companies.

Usually subways have one or more train operators and ticket security officers. They make sure that Bob and other passengers travel safely as well as catch bad people who misuse it. Similarly, the cloud provides a several security measure to make sure that your business is safe and secure.

In summary, a public cloud is a shared resource, paid-per-usage, elastic, 24x7 available, transparent, virtually isolated, and secure.

[Cloud] Cloud Computing Definition

Since the term cloud computing is a relatively new term compared to other technologies in the IT field, different people/organizations have come up with different definitions. Out of all of them, in my opinion, NIST definition is by far the best in terms of clarity and completeness.

NIST definition of cloud computing is quite simple and upto the point:

• Essential characteristics
• On-demand self-service - provisioning of computing capabilities without any human intervention
• Broad network access - capabilities are available over the network/any device
• Resource pooling - multi-tenant model to serve multiple customers from pooled resources
• Rapid elasticity - capabilities can be elastically provisioned or released based on demand
• Measured service - resource usage can be monitored to provide metering capability
• Service models
• Software as a Service - consumers have access to applications running on provider's cloud - zero software installation; e.g. Salesforce, Oracle CRM
• Platform as a Service - consumers have control over deployed apps - consumers are provided middleware running in provider's cloud
• Infrastructure as a Service - consumers have control over OS, storage and deployed apps - consumers are provided virtual machines

The following diagram illustrate the above three service models:

(Source: Wikipedia)

• Deployment models
• Private cloud - provisioned for exclusively used by one organization
• Community cloud - provisioned for used by one community with similar interest
• Public cloud - provisioned for open use by general public - e.g. Amazon cloud service
• Hybrid cloud - any combination of the above three

The following diagram from Microsoft provide some more information on the deployment models:

(Source: Microsoft.com)

[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.

 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

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.

 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

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.

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:

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]

My PhD defense presentation

Privacy Preserving Access Control for Third Party Data Management Systems

View more presentations from Nabeel Mohamed.

What holds you from moving to the cloud?

The following list of concerns are from 2008. Has it changed in 2011 or still the same??

What is the top use of cloud computing?

Remote storage is the top use of cloud computing for small and medium businesses!


Reference: Source

Cost is the #1 barrier for cloud security

Cost is the #1 barrier affecting customer deployment of new security solution:


Reference: Source

Grid vs. Cloud computing

In today's group meeting, we were discussing the security issues in the cloud computing paradigm. At the end of the meeting, I was confused about the difference between grid vs. cloud computing. Are they both refer to the same thing? Or Are they different? Or Are they have things in common? If it is the last case, what is common and what is different? So, I decided to look for the answer.

I am not familiar with grid computing, but Ian Foster et.al.'s 2008 paper titled "Cloud computing and grid computing 360-degree compared" helped to resolve some of the confusions I had in mind. This blog post is based on the material in that paper.

The following diagram shows the big picture of grid vs. cloud computing.

The following discussion is based on projects such as TeraGrid (grid computing) vs. commercially available Amazon EC2, Microsoft Azure (cloud computing).

How the resources are distributed?
To me both are the same from the distributed system point of view; both try to reduce the computing cost by using distributed cluster of computers. However, the main difference appear to be how the two approaches work. It is safe to say that, from a user's point of view, cloud computing is a centralized model whereas grid computing is a decentralized model where the computation could occur over many administrative domains.

Who controls?
In cloud computing (at least from what I have seen so far), one party has the control over the cluster of computers, whereas in grid computing, there is no one controller that can control all the nodes in the cluster. In other words, cloud computing allows a user/organization to build a virtual organization on a third party infrastructure where as grid computing tries to build a collaborative virtual organization that does not belong to one single entity.

How the on demand computation works?
Both have the notion of on demand computation. However, grid computing is more of an incentive model (e.g. if you provide computation resources, you also get computation resources from others who have already joined the grid/cluster), whereas in cloud computing there is no notion of incentive model. Cloud computing is more of a utility model like electricity consumption where you pay for what you use. One could argue that both have some kind of a utility model; in grid computing you trade your idle computation cycles, unused space, etc. with some other (same or different) resources available in the virtual network and in cloud computing, you trade your money for the resources available with a cloud provider.


I don't claim that the above description is fully correct. I may have looked at the topic from a narrow point of view. Please feel free to voice your opinion.

Starting a sub sandwitch business applying MapReduce :)

Here's the simplified process:


Input map to the mapper:
item1 -> bread, item2 -> cucumber, item3 -> green pepper, item4 -> tomato, item5 -> lettuce, item6 -> onion

Output map of the mapper:
item1 -> sliced bread, , item2 -> sliced cucumber, item3 -> chopped green pepper, item4 -> sliced tomato, item5 -> chopped lettuce, item6 -> sliced onion

Output map of the reducer:
vegi subs

That's the start-up. It is self-explanatory to see how easy it is to parallelize these tasks and make subs quickly on the fly. As the business grows, adding different varieties of breads, toppings, meats, etc. is quite easy too.

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.

Another great presentation

"Cloud computing - why it matters?" by Simon Wardley (OSCON '09). I like the presentation style and the presentation itself.