In the recent release of Enarx Version 0.2.0, there has been this major milestone of integration of Networking Services with WASI, the runtime implemented within an Enarx Keep.
WASI is the System Interface for WebAssembly which provides us with an API that provides access to several Operating System like features and it's designed in such a way so that we can have access to these features outside the Web Browser.
Now, at the beginning of this BlogPost, I started off by saying that, in the recent release there has been Integration of Networking Services.
Now What does it mean and How does it matter?
Let's try to understand this
Why Make Network Requests inside a Trusted Execution Environment? 🤔
Let’s have a look at the Traditional Workflow of an Application making a request to the Outside World:
Let us for the time being assume that our Host Operating System is compromised. Now if any external entity/hacker tries to gain access to our System, it will have full access to the Hardware Stack including the PCI Buses and Memory.
Now with this assumption, we get an untrusted network stack with us and this untrusted network stack is involved in handling data packets between the Network Interface Card and the Application making use of the TCP/IP Stack. Now even if the Application is making use of let’s say the TLS Protocol, the metadata that is related to the data packet is not protected. Any malicious entity can now extract sensitive information from the metadata or modify the data packets for its own benefit.
Thus in a gist, we can say that the Network calls will always be processed by the Untrusted Component (which is the Host Operating System in our Case)
Thus, here comes Enarx to our Rescue
With Enarx, we are provided with leverage that ensures the confidentiality of network communications on an untrusted computer system. This leverage is our Trusted Execution Environment(TEE’s) that ensures the confidentiality of both the data and the metadata of our Data Packets.