Śūnyatā: The World of Zeroness in Cloud Security

The word Śūnyatā means zeroness, voidness, or emptiness. In both Buddhism and Hinduism the word means attributeless of self or Brahman. In security, zeroness is “attributeless of the security triad”. This self is self contained. It cannot be modified by other selves. Think of the self as providing the “security” for the body and mind.

Security is the self or soul of the cloud computing. The main security objectives are the security triads: confidentiality, integrity, and availability. There are other objectives that are also important, such as non-repudiation, attestation, authentication, etc.

In the world of zeroness of security let us focus on two of the objectives: confidentiality and integrity. What does it to say “zeroness of confidentiality”? It means that confidential information should be “processed in void, empty, or isolation” by an entity such that no other entity can observe the confidential information, including intermediate information or states that are generated. The only information that is observed is “what is expected or released” from the confidential processing unit.

What does “zeroness of integrity” mean? It means that the information should be “processed in void or empty” by an entity such that no other entity can modify the information or generate “misinformation”. Integrity should also ensure that the entity processing the information cannot be tampered by other entities.

In security we identify three main types of zeroness: (1) Zero Trust, (2) Zero Confidential, and (3) Zero Knowledge. In zero trust only a small portion of the system is trusted to behave with goodness property. In zero knowledge no information is leaked other than what is exchanged between two parties or entities. In zero confidential only a small portion of the system is relied on for processing confidential data; the confidential data is fully encrypted everywhere else. It is important to note that all three zeroness concepts are related with key differences.

Principle of Zeroness: Do not trust anything, do not reveal anything except what is minimally needed, and isolate, encrypt, verify and automate the processing of (sensitive) data.

The Principle of Zeroness prevents many types of attacks including lateral threat movements, advanced persistent threats, etc. Mitre ATT&CK and CAPEC provides a comprehensive set of different types of threat and attack patterns.

We look at zeroness of cloud security as a set of three steps, depicted in the following figure.

Step 1: Build Trust essentially consists of building trust among entities that want to interact with each, based on zero trust model. Building trust is like building the body (of a human being) such that the body is not easily compromised by other living beings.
Step 2: Process Confidentially consists of processing the (sensitive) data confidentially and in isolation, based on zero confidential model. Processing confidentially is like the mind (of a human being) such that the mind is not easily read by other living beings.
Step 3: Share Essential Knowledge consists of sharing only essential information or knowledge between entities that is needed for that interaction, based on zero knowledge model. Sharing essential knowledge like the sensors of a human being that shares only what is needed to be shared.

Notes: We assume a perfect human being that can control its mind, body and sensors.

Security Players

• Alice and Bob who interact with each other and exchange messages and information
• Trent is a trusted 3rd party that both Alice and Bob trust
• Oscar is an evil man-in-the-middle attacker

The above players can be both humans and non-humans or system players.

Build Trust: Zero Trust

In zero trust model Alice and Bob do not trust each other. In traditional network-based security model, Alice and Bob trust each other if they belong to the same network perimeter or zone, for instance, part of the same company and all message exchanges travel only with in the company. Unfortunately network perimeter model can easily be attacked. For instance, Oscar can be another employee of the company and he can masquerade either as Alice or Bob and intercept communication between Alice and Bob. Also, especially due to COVID-19 pandemic Alice and Bob have to interact over the Internet. Well, they could use VPN (virtual private network) to ensure they are on the same network perimeter. In some sense, VPN is like Trent that both Alice and Bob trust.

There is another model where, instead of using network perimeter, one can use identity as the new perimeter. Identity-based zero trust model relies on making identity at the center of security. Alice and Bob first needs to establish their identity. They need to authenticate the identities, and finally appropriate access control is established based on authorization policies. Keep in mind Alice and Bob need not be human identities; they can be end-point services identities. Identity-based perimeter then requires creating unique identities for every entities on the Internet. These identities can have a life time that is as short as a microsecond to as long as a year or more. So when Alice and Bob communicate with each other they need to first establish each others identity. One can use X.509 certificate as a specification of identity. SPIFFE and its implementation SPIRE provides one such identity framework. For establishing authorization policies we can use OPA model and engine.

It is important to keep in mind that zero trust does not mean we do not trust anything. There are a few things we have to trust. This includes the cryptographic algorithms and protocols, hardware/software that processes, transmits and stores cryptographic keys and algorithms, and system administrators or operators. We call these entities as trusted base. We must keep this trust based to be as small as possible (aka trusted computing base).

We need both identity-based and network-based perimeter. Also, transition to a zero-trust model is a journey rather than a switch. The network-based perimeter should be shrunk to a micro-segmented network perimeter. At the lowest level, each end-point becomes its own micro-segmented perimeter. Each end-point should be uniquely identifiable, leading to an identity-based perimeter. The communication between each micro-segmented perimeter should be encrypted and authenticated.

In summary, building a zero trust model is a journey and consists of the following steps:

1. Identify a network-based perimeter P and uniquely identify all the end-points within the network perimeter.
2. Any communication between two end-points such that one of the end-points is within the perimeter and the other is outside the perimeter should authenticated, admission-controlled and encrypted.
3. Further segment the network perimeter P into sub-network perimeter P1, P2, …, PN. For each Pi’s do steps 1 and 2. The segmentation should be done in stages and hierarchically.

NIST 800–207 is a good starting point for understanding zero trust architecture. Another comprehensive document is from DoD Zero Trust Architecture. The BeyondCorp, a Google company, is one of the first to build a zero trust solution.

Process Confidentially: Zero Confidential

Once a right-sized set of micro-segmented perimeter is created we then move to processing information confidentially. Each micro-segmented perimeter contains confidential information that should not be observed outside of the micro-segmented perimeter. One way to do this is to use a combination of hardware and software stack. Security enclave is one such hardware/software solution that provides an isolated trusted execution environment (TEE) with strong security guarantees (such as confidentiality, integrity, and attestation). Apple iPhone 5S and later version provides security enclave processor (SEP). SEP is not the only type of solution for zero confidential model;

Zero confidential module (ZCM) or TEE should satisfy three properties to be effective:

1. Modularity: ZCM should behave like truly modular function, which means that everything that is needed for execution are within the ZCM. Two different ZCMs can be “composed if their input-output behavior conform”.
2. Flexibility: ZCMs should be able to adapt to the needs of confidential computations where ever they are needed, which means that the confidential computation strategy should happen only with in TEE instead of spreading them throughout the network, software, or application.
3. Isolation : Zero confidential module should be isolated from the rest of the network, hardware, and software modules. This means that even the side-effects of confidential computation should not be observable from outside the TEE. Also, ZCM should not be affected even when the rest of the system is compromised. On the other hand, if ZCM is compromised, then the rest of the system is also compromised.

Notes: We will use the term zero confidential module ZCM and trust execution environment (TEE) interchangeably.

The above properties of ZCM is similar to properties we find in Monads, a construct used in functional programming languages to model side effects.

Zero confidential computing follows the classical trusted computing base (TCB) principle that includes smallest possible hardware and software that is trusted, and also the zero confidential module should continue to operate and provide security despite other parts of the system are compromised. What makes zero confidential computing model is the breadth of application that it should handle.There is a spectrum of zero confidential modules, depending on the need and the size of the micro-segmentation. At one end of the spectrum is something like HSM (hardware secure module) that performs encryption and decryption functions in secure, tamper-proof, isolated trusted execution environment. At the other end of the spectrum is a solution called Cloud-Based Internet Isolation (CBII).

Hardware Security Module

Hardware security module is a specialized hardware and software module that provides tamper-resistant protection of cryptographic keys used for encryption and decryption of data and other keys. Many vendors provide a combination of PKCS#11 and KMIP for interacting with HSM and the associated key management functions. FIPS 140–2 and FIPS 140–3 provides specifies the security requirements that should be satisfied by a cryptographic modules.

FIPS 140–2/3 provides four levels of increasing security requirements, from level 1 to level 4. Level 1 requires production grade baseline security requirements that includes passing security testing, does not contain known vulnerabilities, etc. Level 1 does not require physical tamper evidence logging and tamper-resistant modules. Most cryptographic software vendors provides Level 1 certification. Level 2 adds physical tampering evidences and logging to the Level 1 requirements, and also requires role-based authentication and authorization for security operators of the module. Level 3 adds physical tamper-resistance requirements to Level 2 requirements and also adds identity-based authentication. Level 3 also requires physical/virtual separation of how critical security parameters enters and leaves the security module. Most HSM vendors provide Level 3 certification. Level 4 adds protection against environmental attacks. Currently only highly sensitive military grade security modules satisfy Level 4 requirements. Typically HSM are in secure area such as a data center and assembled a rack and has plugin card that supports PKCS#11 interface.

Security Enclave

Security enclave is an extension to the core processor with special instructions set that allow user and operating system code to define private regions of memory, called enclaves. The enclaves are isolated and protected against reads and writes from process outside the enclaves. Intel Software Guard Extension (SGX) consists of encrypting a portion of memory by the CPU (central processing unit). The decryption is done only within the CPU for code and data running within the enclave. The protection and isolation is effected by encryption/decryption within the CPU for the enclaved portion of the memory. The rest of the system processes and components only seeing encrypted data and code. The SGX does not protect the enclaves against side-channel attacks since the processing within the CPU for enclaved data and code is in plaintext.

There are many cloud provider that provide enclave services. For instance, IBM Data Shield solution can run containerized application in a secure enclave on an IBM Cloud Kubernetes Service host, providing data-in-use protection.

Air-Gapped Solution and Cloud Based Internet Isolation

Cloud based internet isolation (CBII) is a approach that isolates Internet browsing from traditional desktop browsers to a secure, isolated cloud-platform.The basic idea behind CBII is to shift the Internet browsing from the desktop and to the Internet ‘cloud’, creating an air gap between the internet and DoD (Department of Defense) networks. The CBII ensures that all downloads happens in a remotely secured server and not on the end user’s computer. CBII prevents many of common malicious code from the Internet reaching into the DoD network.

Many cloud providers such IBM are targeting workloads of regulated industry, such as financial services. The financial services companies have stringent security requirements, similar to FedRAMP high security requirements. Many of these companies want air-gapped data centers where payloads do not flow into or from the Internet. These air-gapped data centers provides almost the same set of services available other services on public cloud. Interesting, things like CI/CD for continuous integration and continuous delivery needs to redesigned since air-gapped production data center are physically isolated. This means software feature enhancements and patching cannot be done automatically and frequently. Typically, software will have to downloaded into the air-gapped environment manually or a bridge computer needs to be established by physically connecting the “wires”, and software loaded, and once the loaded, the bridge computer is physically disconnected.

Zero confidential computing would not be complete if I do mention Fully homomorphic encryption (FHE). FHE are a class of encryption methods originally proposed in 1978 by Rivest, Adleman, and Dertouzos and first constructed by Craig Gentry in 2009. FHE allows one to compute on encrypted data without the need for secret/private key. FHE was originally used for privacy-preserving computations, but now there are many applications, especially cloud computing.

Share Essential Knowledge: Zero Knowledge

Alice goes to a supermarket to purchase beer. Bob cannot sell beer to Alice unless she is 21 years or older. Typically, she produces her driver license or other trusted-identity card (such as passport, aadhaar car in India, etc.) to Bob. Bob verifies her age but looking at the date of birth on the card, or scanning the card on to a reader. Using zero knowledge proof method Alice does not need to share her private date of birth but instead prove to Bob that she is older than 21 years. Zero-knowledge proof method was originally proposed by Shafi Goldwasser, Silvio Micali, and Charles Rackoff.

One of the best explanation of zero knowledge proof (ZKP) is by Michael Rabin. The basic idea behind ZKP is illustrated using the children puzzle “Where’s Wally?”. Where’s Wally? (titled Where’s Waldo? in North America) is a picture book where the reader is challenged to find a small character called Wally hidden somewhere on a double-spread page that is filled with many other characters. The pictures are designed so that it is hard to find Wally.

Alice is an expert at finding Waldo. Bob comes to Alice with a large picture poster and asks to find Waldo. Alice and Bob do not trust each other. Bob got the picture poster and if he finds Waldo, he gets $1000. Alice wants a share of the money, and she does want to show exactly where is Waldo to Bob. She asks Bob to turn around. She then cuts a large square cardboard with a hole at center of the cardboard. Alice covers the entire picture poster with the cardboard with the hole showing the character Waldo. She then asks Bob to turn around. Bob can see Waldo, but cannot see the rest of the picture poster that is covered by the large cardboard. Alice knows where is Waldo and Bob knows that Alice knows where is Waldo. Given that Alice and Bob do not trust each other how can Bob know there is his picture poster behind the cardboard. Alice can simple remove the cardboard unveiling the picture poster. Now if Alice and Bob trust Trent, then Alice can prove that the hole through which Waldo is seen is indeed Waldo. All she has to do is put a little toothpick or stick, and slows lift the cardboard; the stick will be pointing to Waldo on the picture poster.

There are many applications of ZKP, especially in cloud computing, blockchain, e-commerce, authentication system, etc. Please see an excellent survey article of ZKP by Morais, Koens, van Wijk and Koren.

The world of zeroness brings related technologies to solve security problems in Cloud Computing. I consider security to be soul (or self) of cloud computing. Without the soul there is no use of the body and the mind. IBM Cloud and other cloud providers are providing many different solutions to support the world of zeroness.