Last year, at the annual SMPTE Technical Conference, I presented a paper “Is the Future of Content Protection Cloud(y)?” I explained that the trust model of public cloud was theoretically inherently weaker than the trust model of private cloud or private data center. The audience argued that at the opposite, the security of public cloud may be better than the security of most private implementations. As usual in security, the answer is never Manichean.
Metaphors are often good tools to introduce complex concepts. Analogy with the real world helps to build proper mental models. The pizza as a service metaphor that explains the IaaS, PaaS and SaaS is a good example. In preparation of the panel on cloud security at the next Content Protection Summit, I was looking for a metaphor to illustrate the difference between the two trust models. I may have found one.
On one side, when using a private cloud (or a private data center), we can likened the trust model to your residential house. You control whom you invite into your home and what your guests are allowed to do. You are the only person (with your family) to have the keys. Furthermore, you may have planted a high hedge to enforce some privacy so that your neighbors cannot easily eavesdrop.
On the other side, the trust model of the public cloud is like a hotel. You book a room at the hotel. The concierge decides who enters the hotel and what the hosts are allowed to do. The concierge provides you with the key to your room. Nevertheless, the concierge has a passkey (or can generate a duplicate of this key). You have to trust the concierge as you have to trust your cloud provider.
The metaphor of the hotel can be extended to different aspects of security. You are responsible for the access to your room. If you do not lock the room, a thief may enter easily regardless of the vigilance of the hotel staff. Similarly, if your cloud application is not secured, hackers will penetrate irrespective of the security of your cloud provider. The hotel may provide a vault in your room. Nevertheless, the hotel manager has access to its key. Once more, you will have to trust the concierge. The same situation occurs when your cloud provider manages the encryption keys of your data at rest. The hotel is a good illustration of the risks associated to multi-tenancy. If you forget valuable assets in your room when leaving the hotel, the next visitor of the room may get them. Similarly, if you do not clean the RAM and the temporary files before leaving your cloud applications, the next user of the server may retrieve them. This is not just a theoretical attack. Multi-tenancy may enable it. Clean your space behind you, the cloud provider will not do it on your behalf. The person in the room next to your room may eavesdrop your conversation. You do not control who is in the contiguous rooms. Similarly, in the public cloud, if another user is co-located on the same server than your application, this service may extract information from your space. Several attacks based on side channels have been demonstrated recently on co-located server. They enabled the exfiltration or detection of sensitive data such as secret keys. Adjacent hotel rooms have sometimes connecting doors. They are locked. Nevertheless, they are potential weaknesses. A good thief may intrude your room without passing through the common corridor. Similarly, an hypervisor may have some weaknesses or even trapdoors. The detection of colocation is a hot topic that interests the academic community (and of course, the hacking community). My blog will follow carefully these new attacks.
Back to the question whether the public cloud is more secure than the private cloud, the previous metaphor helps to answer. Let us look more carefully at the house of the first figure. Let us imagine that the house is as the following illustration.
The windows are wide open. The door is not shut. Furthermore, the door has cracks and a weak lock. Evidently, the owner does not care about security. Yes, in that case, the owner’s assets would be more secure in the room of a hotel than in his house. If your security team cannot secure properly your private cloud (lack of money, lack of time, or lack of expertise), then you would be better on a public cloud.
If the house is like the one of the next image, then it is another story.
The windows have armored grids to protect their access. The steal door is reinforced. The lock requires a strong password and is protected against physical attacks. Cameras monitor the access to the house. The owner of this house cares about security. In that case, the owner’s assets would be less secure in the room of a hotel than in his house. If your security team is well trained and has sufficient resources (time, fund), then you may be better in your private cloud.
Now, if you are rich enough to afford to book an entire floor of the hotel for your usage, and put some access control to filter who can enter this level, then you mitigate the risks inherent to multi-tenancy as you will have no neighbors. Similarly, if you take the option to have the servers of the public cloud uniquely dedicated to your own applications, then you are in a similar situation.
This house versus hotel metaphor is an interesting metaphor to introduce the trust model of private cloud versus the trust model of public cloud. I believe that it may be a good educational tool. Can we extend it even more? Your opinion is welcome.
A cautionary note is mandatory: a metaphor has always limitation and should never be pushed too far.
The illustrations are from my son Chadi.
The team of David NACCACHE recently published an interesting paper disclosing an exemplary work on a real attack exploiting this vulnerability: “when organized crime applies academic results.” The team performed a non-destructive forensic analysis of forged smart cards that exploited this weakness. The attacker combined in a plastic smart card the chip of a stolen EMV card (in green on the picture) and an other smart card chip FUN. The FUN chip acted like a man in the middle attack. It intercepted the communication between the Point of Sales (PoS) and the actual EMV chip. The FUN chip filtered out the VerifyPIN commands. The EMV card did not verify the PIN and thus was not blocked in case of the presentation of wrong PINs. On the other side, the FUN chip acknowledged the PIN for the PoS which continues the fraudulent transaction.
