An Open-Source Framework for Developing Heterogeneous Distributed Enclave Applications
Pouyanrad, Sepideh
Scopelliti, Gianluca
In this talk, we present an open-source framework to develop heterogeneous, distributed enclaved applications. The main feature of our framework is to provide a high level of abstraction over the platform-specific TEE layer and over the secure communication between different modules, leaving to a developer only the task to write the application’s logic. We provide a notion of event-driven programming to develop distributed enclave applications in Rust and C for heterogeneous TEEs, including Intel SGX, ARM TrustZone and the open-source Sancus. This heterogeneity brings our work to a broad range of use cases, which include cloud processing, mobile devices and lightweight IoT. Our framework ensures strong security guarantees based upon mutual attestation of security-critical software components.
 Welcome everyone, my name is Sepideh Puyangral. I'm a PhD student in the Distineter Research Group at KU Ruben and I'm happy to present a recent work about an open source framework for developing heterogeneous distributed Enkelev application. These days, we built a smart environment that consists of several heterogeneous components and the application is distributed among multiple components. So all of them work together and exchanging information to each other over an untrusted network. This example could be like a health-scale use case from a smart environment and you see it contains a couple of sensors from heterogeneous vendors and some cloud processing, cloud recording of data on the other people's computer and in the end some health-scale professional might want to look at the data. So how we can make sure the interaction between different components is secure and a professional is looking at the right data and the whole system is kind of end-to-end secure. What we are presenting today is a framework to build secure application based on the terrestrial execution environment in all of these processors so that the doctor can be sure that the data they work with comes actually from an attested sensor and an actuator at the patient's home is guaranteed to only react to an interaction from doctor's computer. And finally, when you build this application you don't want to worry about the differences in the attestation mechanism or the properties of the communication network. Terrestrial execution environment is a relatively new technology in the modern processors that allows to run an application in a hard way protected environment called Enkelep. Enkelep are isolated cryptographically from the rest of the world to protect code and data from being accessed or modified by other entities. Besides, a mechanism called remote attestation is used to obtain remotely a proof that a running application is loaded inside the right enclave and wasn't tampered at the loading time. In TEE, all isolation and authentication primitives are implemented in hard way. That means your trusted computing base shrinks to the application module and a tiny layer of the hard way. Of course, as a result, the attack surface is reduced as much as possible. So here on the left system, an application needs to trust its code, the underlying operation system hypervisor and the hard way. In this situation, you know any vulnerability found anywhere in the platform might influence the security of the application. But in a hard way only TCP system, we can protect an application from a compromised operating system. And we can isolate a single piece of software so that really no one can interfere with it in an uncontrolled way. One implementation of TEE is Intel SGX. In SGX, the protected parts of an application are placed in Enkelep to be completely isolated from direct access. So the application will create this Enkelep and only enter the Enkelep during execution through something like a call gate. So SGX can ensure that non-Enkelep code cannot access Enkelep Pages in memory. Specifically, a portion of the main memory is reserved for the Enkelep and the Enkelep Pages outside the reserve memory are encrypted by a hard way unit called Memory Encryption Engine to protect from under-austed system software and cold boot attack. In addition, to confidentiality and integrity of code and data, other features are provided by SGX like attestation and data ceiling to Enkelep and authenticate the data before storing it on disk. Another very common TEE is Terasone that is implemented by ARM and currently used in a large number of smartphones. In ARM with Terasone, each of the physical processor cores provide two virtual cores called Normal Word and Secure Word. Hardware-based mechanism ensure that resources in the Normal Word cannot access Secure Word resources. To enforce this isolation, NSB is used to communicate the security-estate bitfing components. And to perform a context switch between words, the processor first passes through the monitor mode which serves as a gatekeeper via an interrupt external abort or explicit calls of the SMC instruction. And the address mapping in the Terasone MMU can be configured independently for each word. Also, IO devices can be dynamically configured as a secure or non-secure and for each interrupt, the generic interrupt controller can designate the word to handle it. Another interesting feature in Terasone is Secure Word. That is a change of trust is formed by verifying the integrity of the second stage bootloader and trusted OS before execution. This ensures that nobody has tampered with the operation system code when the device was powered off. And the last TEE we focus in our work is Senghuz. In Senghuz architecture, what we need is a simple memory management unit that implements the isolation techniques and a cryptographic unit that implements all symmetric crypto and hashing of operation system. Here you can see an overview of Enclaves on this Senghuz platform that have a continuous address space. In Senghuz, we have a code region that is associated with an Enclave and then we have a data region that is associated with the same Enclave. Senghuz uses a program counter-based memory access controller to ensure that the data of an Enclave is accessible if only the program counter is on the code section of the same Enclave. Therefore, the only way to enter the Enclave is through the entry point functions. And in the case of Senghuz, we have a node key that is encoded in the platform and from that we derive a key that is associated to each Enclave. So we basically hash the take section and the address of the data section with node key to derive an Enclave key that identifies how an Enclave is specifically loaded on a particular microcontroller. Moreover, remote attestation in Senghuz is a simple process because the Enclave key is only known by the Enclave and software provider. Therefore, if the software provider receives an encrypted message from the Enclave that is successfully decrypted, it can be sure the Enclave is running on tamper on a right node. Another important feature provided by Senghuz is secure I.O. Senghuz uses memory mapped I.O. to communicate with the devices. Therefore, to gain exclusive access to a device, it is sufficient to map the data section of an Enclave over the MMI origin of the device. So nobody expects the Enclave would be able to access the I.O. devices. So there are a range of architecture for hard way-based trusted computing. Each of them is platform-specific and comes with a different system footprint. But all of them provide a strong security guarantee like attestation, isolation and things like that, which is implemented in different ways. That means what S.JX is doing is something different from, for example, what Senghuz is doing. But the baseline is the same. So you can build upon this guarantee and you can use that in your system and construct system that are highly secure, even from a 16-bit microcontroller that communicates over the kilo to an end user devices or something like that. In order to design end-to-end secure smart environment, as I already explained, the data behind our implementation is based on the concept of authentic execution. This framework was proposed by Norman in 2015 to provide a strong assurance of the secure execution of a distributed application. According to the paper, they want to guarantee if an output is produced by the application, it is actually allowed to be produced by the application's source code and physical input event. In this framework, each component of distributed application runs in a trusted execution environment and thanks to the confidential computing provided by the TES and authentication encryption of the data, end-to-end security can be achieved in our smart city. The implementation provided by Norman only supports Senghuz processors, but this concept can be applied to a generic TEE to support heterogeneous systems in a real scenario. Thereby, our framework provides an implementation of authentic execution that supports Intel SGX, ARM Trason and Senghuz to allow development of applications in a heterogeneous environment. The SGX part of our framework was entirely written in Rust with a framework called Fortanix Enclave Development Platform. In order to develop applications for Trason, open source opti framework is used, which provides a collection of truth change, open source library and secure kernel that is implemented in C. And finally, with Senghuz toolchain implemented the Senghuz Encalave. Our framework aims to minimize the developer's effort as much as possible, thereby it automatically deploys the Enclaves on the supported TEE and then attests them using remote attestation and finally provides a secure communication between different components with cryptographic operations. And thereby it provides the developer an abstraction layer in which they only need to implement the application's logic. So we ensure this framework provides end-to-end security for a safety critical smart environment. And a demo of our framework will be presented now by my colleague Gianloka. Thanks for your attention to me. Thank you, Sepideh, for your introduction. Now I will show you a simple example about how to use this framework to build and run a secure distributed application using Senghuz and SGX. A couple of words about me before. I'm Gianloka and I'm a PhD student working on the FIGOS project promoted by KU11 and Ericsson. My work is about the integrity assurance for multi-component services and third-year networks. So this is the setup of our application. You can see that there are two Senghuz nodes and one SGX node and we have also two input and output devices. We have a button here that will be the input of our system and we want to perform some operation every time the button will be pressed. And here we have a LED instead and this LED will be toggled every time the button is pressed. Instead in the SGX node we will store the number of button presses and also we will provide an interface for the deployer and external users to interact with the system and get this value. The deployer is responsible for deployment and configuration of the modules and their connections. The user instead can be anyone connected on the same network and the user can retrieve the number of button presses by performing HTTP requests. Okay now we will see the deployment phase of our application. We provide as input to the deployer all the source files of each component of the application called, these components are called modules and also we provide a deployment descriptor which is a JSON configuration file which contains a description of all the nodes, modules and connections between modules. So the first step is to build binaries of every module and then send them to the corresponding nodes. On every node there is a untrusted software which is called Event Manager. This Event Manager is responsible of exchanging events between modules but also as shown in this case Event Manager is responsible of loading the modules inside the nodes. Of course the Event Manager is untrusted so we want to make sure that this loading process has been done correctly and for this reason we also perform a model testation and we want to make sure of first of all that the binaries have not been modified during the process and second of all that the modules are loaded inside the task execution environments. Also during the process we will establish secure channels between the deployer and modules using module keys. Each module will have a unique module key. After that now the modules are running and they are tested and now we will establish the connections between these modules. We take as input the same descriptor as before and we start with the establishment of this connection. First of all we establish the connections between modules and IU devices using the Sankus Securario functionality. After that we establish all the other connections between modules and between the deployer and modules. So here the blue arrows are the secure communication channels and every event exchange will be encrypted and authenticated and here the red arrow is just the HTTP channel between the user and web server so it's unsecured. Okay this is an example of the source code of the controller module and the thing to notice here is that the every module declares outputs and inputs. So a connection between two modules connects the output of the source module to the input of the destination module. So here with this controller module we write some special instructions to declare outputs and inputs. For controller we have two outputs, toggle led and increment presses and one input button pressed. But how to declare these connections between modules? This is done in the deployment descriptor. So in this example I declare two connections. The first connection is from the button driver to the controller. The second connection is a direct connection from the deployer to the web server. Okay now I will show you how this works in practice and if you are interested in this example you can go to my repository, you can see all the source code, you can see the tutorial if you want to run the demonstration of your local machine and don't worry if you don't have Sankus or SGX because you can run just the native version of this example and also I provide some Docker images so if you just want to run this example without installing anything on your machine you can do it. So if you go to my repository you can find all the tutorials for this. Okay this is my terminal now. Okay at the top right I have the SGX node and at the bottom right I have the Sankus node. Here I use just one single Sankus node for practical reasons but the application will behave the same. And as you can see here the deployment has been already made so all the modules are running and they are tested on each node. Here at the top left window this is the terminal of the deployer. So here I will send some commands to the system. The first I want to send is this is to initialize the web server so I will send an output command, an output event for the inner server connection passing as the input as argument the port I want to use. So if I trigger this output you can see here that web server now is listening to this port and if we try to reach this web server we get the number of button presses. In this case of course the number is already just zero. But if you want to trigger a button press of course you can do this physically. You can trigger the button physically. The problem is that I'm not physically close to the Sankus node so I cannot physically press the button and so for this reason I use another connection to simulate a button press but notice that this connection is still secured so we still have the security features for all the other connections. And so I will trigger another output of the trigger button connection and if I do so you can see that something happens. First of all the button driver notifies us that the button has been pressed. The controller has received the remote event on the button and the led driver has been turned on. And if we reach again the web server now we see that the number of button presses has incremented by one. But if we don't trust this HTTP communication because of course HTTP is not secure we can perform another request from the deployer side. In this case I will send a request which is the same principle as input output connections but in this case we expect a value in return. So we trigger a request of the connection get presses and here you can see that we get as response the number one. So in the end yes this is working properly and the button has been pressed only one time. Okay that's it. Coming back to the slides so in the end this framework provides strong integrity over the application behavior because we can only toggle the led if we press the button and we can only increment the value stored in database if we press the button. If we don't do it there is another way to do to increment the value of database or to toggle the led. But we have also confidentiality of the application state and sensitive data thanks to the execution environments and thanks to the secure communication channels between modules. We don't have availability because if an event is lost during the transmission nothing happens. So in the end this is still an ongoing work and as I said before we are providing support for class don which will be available soon but still we are working on improving the code deployment tools and the SGX side. So this is it thank you for your attention and now if you have some questions thank you.
 Welcome everyone, my name is Sepideh Puyangral.  I'm a PhD student in the Distineter Research Group at KU Ruben and I'm happy to present  a recent work about an open source framework for developing heterogeneous distributed  Enkelev application. These days, we built a smart environment that consists of several  heterogeneous components and the application is distributed among multiple components. So all  of them work together and exchanging information to each other over an untrusted network. This  example could be like a health-scale use case from a smart environment and you see it contains  a couple of sensors from heterogeneous vendors and some cloud processing, cloud recording of data  on the other people's computer and in the end some health-scale professional might want to look at  the data. So how we can make sure the interaction between different components is secure and a  professional is looking at the right data and the whole system is kind of end-to-end secure.  What we are presenting today is a framework to build secure application based on the  terrestrial execution environment in all of these processors so that the doctor can be sure that  the data they work with comes actually from an attested sensor and an actuator at the patient's  home is guaranteed to only react to an interaction from doctor's computer. And finally, when you  build this application you don't want to worry about the differences in the attestation mechanism  or the properties of the communication network. Terrestrial execution environment is a relatively  new technology in the modern processors that allows to run an application in a hard way protected  environment called Enkelep. Enkelep are isolated cryptographically from the rest of the world to  protect code and data from being accessed or modified by other entities. Besides, a mechanism  called remote attestation is used to obtain remotely a proof that a running application is  loaded inside the right enclave and wasn't tampered at the loading time. In TEE, all isolation and  authentication primitives are implemented in hard way. That means your trusted computing base  shrinks to the application module and a tiny layer of the hard way. Of course, as a result,  the attack surface is reduced as much as possible. So here on the left system, an application needs  to trust its code, the underlying operation system hypervisor and the hard way. In this situation,  you know any vulnerability found anywhere in the platform might influence the security of the  application. But in a hard way only TCP system, we can protect an application from a compromised  operating system. And we can isolate a single piece of software so that really no one can  interfere with it in an uncontrolled way. One implementation of TEE is Intel SGX. In SGX,  the protected parts of an application are placed in Enkelep to be completely isolated from direct  access. So the application will create this Enkelep and only enter the Enkelep during execution  through something like a call gate. So SGX can ensure that non-Enkelep code cannot access  Enkelep Pages in memory. Specifically, a portion of the main memory is reserved for the Enkelep  and the Enkelep Pages outside the reserve memory are encrypted by a hard way unit called Memory  Encryption Engine to protect from under-austed system software and cold boot attack. In addition,  to confidentiality and integrity of code and data, other features are provided by SGX like  attestation and data ceiling to Enkelep and authenticate the data before storing it on disk.  Another very common TEE is Terasone that is implemented by ARM and currently used in a  large number of smartphones. In ARM with Terasone, each of the physical processor cores provide two  virtual cores called Normal Word and Secure Word. Hardware-based mechanism ensure that resources  in the Normal Word cannot access Secure Word resources. To enforce this isolation, NSB is used  to communicate the security-estate bitfing components. And to perform a context switch between  words, the processor first passes through the monitor mode which serves as a gatekeeper via an  interrupt external abort or explicit calls of the SMC instruction. And the address mapping in the  Terasone MMU can be configured independently for each word. Also, IO devices can be dynamically  configured as a secure or non-secure and for each interrupt, the generic interrupt controller can  designate the word to handle it. Another interesting feature in Terasone is Secure Word. That is a  change of trust is formed by verifying the integrity of the second stage bootloader and  trusted OS before execution. This ensures that nobody has tampered with the operation system  code when the device was powered off. And the last TEE we focus in our work is Senghuz. In Senghuz  architecture, what we need is a simple memory management unit that implements the isolation  techniques and a cryptographic unit that implements all symmetric crypto and hashing of operation  system. Here you can see an overview of Enclaves on this Senghuz platform that have a continuous  address space. In Senghuz, we have a code region that is associated with an Enclave and then we  have a data region that is associated with the same Enclave. Senghuz uses a program counter-based  memory access controller to ensure that the data of an Enclave is accessible if only the program  counter is on the code section of the same Enclave. Therefore, the only way to enter the Enclave is  through the entry point functions. And in the case of Senghuz, we have a node key that is encoded  in the platform and from that we derive a key that is associated to each Enclave. So we basically  hash the take section and the address of the data section with node key to derive an Enclave key  that identifies how an Enclave is specifically loaded on a particular microcontroller.  Moreover, remote attestation in Senghuz is a simple process because the Enclave key  is only known by the Enclave and software provider.  Therefore, if the software provider receives an encrypted message from the Enclave that is  successfully decrypted, it can be sure the Enclave is running on tamper on a right node.  Another important feature provided by Senghuz is secure I.O. Senghuz uses memory mapped I.O. to  communicate with the devices. Therefore, to gain exclusive access to a device, it is sufficient  to map the data section of an Enclave over the MMI origin of the device. So nobody expects the  Enclave would be able to access the I.O. devices. So there are a range of architecture for hard  way-based trusted computing. Each of them is platform-specific and comes with a different  system footprint. But all of them provide a strong security guarantee like attestation,  isolation and things like that, which is implemented in different ways. That means what  S.JX is doing is something different from, for example, what Senghuz is doing. But the baseline  is the same. So you can build upon this guarantee and you can use that in your system and construct  system that are highly secure, even from a 16-bit microcontroller that communicates over the kilo  to an end user devices or something like that. In order to design end-to-end secure smart environment,  as I already explained, the data behind our implementation is based on the concept of  authentic execution. This framework was proposed by Norman in 2015 to provide a strong assurance of  the secure execution of a distributed application. According to the paper, they want to guarantee  if an output is produced by the application, it is actually allowed to be produced by the  application's source code and physical input event. In this framework, each component of distributed  application runs in a trusted execution environment and thanks to the confidential computing provided  by the TES and authentication encryption of the data, end-to-end security can be achieved in our  smart city. The implementation provided by Norman only supports Senghuz processors, but this concept  can be applied to a generic TEE to support heterogeneous systems in a real scenario.  Thereby, our framework provides an implementation of authentic execution that supports  Intel SGX, ARM Trason and Senghuz to allow development of applications in a heterogeneous environment.  The SGX part of our framework was entirely written in Rust with a framework called Fortanix  Enclave Development Platform. In order to develop applications for Trason, open source  opti framework is used, which provides a collection of truth change, open source library and secure  kernel that is implemented in C. And finally, with Senghuz toolchain implemented the Senghuz  Encalave. Our framework aims to minimize the developer's effort as much as possible, thereby  it automatically deploys the Enclaves on the supported TEE and then attests them using remote  attestation and finally provides a secure communication between different components  with cryptographic operations. And thereby it provides the developer an abstraction layer  in which they only need to implement the application's logic. So we ensure this framework  provides end-to-end security for a safety critical smart environment. And a demo of our  framework will be presented now by my colleague Gianloka. Thanks for your attention to me.  Thank you, Sepideh, for your introduction. Now I will show you a simple example about  how to use this framework to build and run a secure distributed application using Senghuz and SGX.  A couple of words about me before. I'm Gianloka and I'm a PhD student working on the FIGOS project  promoted by KU11 and Ericsson. My work is about the integrity assurance for multi-component services  and third-year networks. So this is the setup of our application. You can see that there are two  Senghuz nodes and one SGX node and we have also two input and output devices. We have a button here  that will be the input of our system and we want to perform some operation every time the button  will be pressed. And here we have a LED instead and this LED will be toggled every time the button  is pressed. Instead in the SGX node we will store the number of button presses and also we will  provide an interface for the deployer and external users to interact with the system and get this  value. The deployer is responsible for deployment and configuration of the modules and their  connections. The user instead can be anyone connected on the same network and the user can  retrieve the number of button presses by performing HTTP requests. Okay now we will see the deployment  phase of our application. We provide as input to the deployer all the source files of each component  of the application called, these components are called modules and also we provide a deployment  descriptor which is a JSON configuration file which contains a description of all the nodes,  modules and connections between modules. So the first step is to build binaries of every module  and then send them to the corresponding nodes. On every node there is a untrusted software which  is called Event Manager. This Event Manager is responsible of exchanging events between  modules but also as shown in this case Event Manager is responsible of loading the modules inside  the nodes. Of course the Event Manager is untrusted so we want to make sure that this loading process  has been done correctly and for this reason we also perform a model testation and we want to make  sure of first of all that the binaries have not been modified during the process and second of all  that the modules are loaded inside the task execution environments. Also during the process  we will establish secure channels between the deployer and modules using module keys. Each module  will have a unique module key. After that now the modules are running and they are tested  and now we will establish the connections between these modules.  We take as input the same descriptor as before and we start with the establishment of this  connection. First of all we establish the connections between modules and IU devices using the  Sankus Securario functionality. After that we establish all the other connections between modules  and between the deployer and modules. So here the blue arrows are the secure communication channels  and every event exchange will be encrypted and authenticated and here the red arrow is just the  HTTP channel between the user and web server so it's unsecured.  Okay this is an example of the source code of the controller module and the thing to notice here  is that the every module declares outputs and inputs. So a connection between two modules  connects the output of the source module to the input of the destination module. So here with this  controller module we write some special instructions to declare outputs and inputs.  For controller we have two outputs, toggle led and increment presses and one input button pressed.  But how to declare these connections between modules? This is done in the deployment descriptor.  So in this example I declare two connections. The first connection is from the button driver to the  controller. The second connection is a direct connection from the deployer to the web server.  Okay now I will show you how this works in practice and if you are interested in this example you can  go to my repository, you can see all the source code, you can see the tutorial if you want to  run the demonstration of your local machine and don't worry if you don't have Sankus or SGX because  you can run just the native version of this example and also I provide some Docker images so if you  just want to run this example without installing anything on your machine you can do it. So if you  go to my repository you can find all the tutorials for this. Okay this is my terminal now. Okay at  the top right I have the SGX node and at the bottom right I have the Sankus node. Here I use  just one single Sankus node for practical reasons but the application will behave the same.  And as you can see here the deployment has been already made so all the modules are running and  they are tested on each node. Here at the top left window this is the terminal of the deployer.  So here I will send some commands to the system. The first I want to send is this is to initialize  the web server so I will send an output command, an output event for the inner server connection  passing as the input as argument the port I want to use. So if I trigger this output you can see  here that web server now is listening to this port and if we try to reach this web server we get the  number of button presses. In this case of course the number is already just zero. But if you want to  trigger a button press of course you can do this physically. You can trigger the button physically.  The problem is that I'm not physically close to the Sankus node so I cannot physically press the  button and so for this reason I use another connection to simulate a button press but notice  that this connection is still secured so we still have the security features for all the other  connections. And so I will trigger another output of the trigger button connection and if I do so  you can see that something happens. First of all the button driver notifies us that the button has  been pressed. The controller has received the remote event on the button and the led driver has  been turned on. And if we reach again the web server now we see that the number of button presses  has incremented by one. But if we don't trust this HTTP communication because of course  HTTP is not secure we can perform another request from the deployer side. In this case I will send  a request which is the same principle as input output connections but in this case we expect a  value in return. So we trigger a request of the connection get presses and here you can see that  we get as response the number one. So in the end yes this is working properly and the button has  been pressed only one time. Okay that's it. Coming back to the slides so in the end this framework  provides strong integrity over the application behavior because we can only toggle the led  if we press the button and we can only increment the value stored in database if we press the button.  If we don't do it there is another way to do to increment the value of database or to toggle the  led. But we have also confidentiality of the application state and sensitive data thanks to the  execution environments and thanks to the secure communication channels between modules. We don't  have availability because if an event is lost during the transmission nothing happens.  So in the end this is still an ongoing work and as I said before we are providing support for  class don which will be available soon but still we are working on improving the code  deployment tools and the SGX side. So this is it thank you for your attention and now if you  have some questions thank you.
tee_sancus_0_179.png tee_sancus_180_467.png tee_sancus_468_2327.png tee_sancus_2328_3479.png tee_sancus_3480_4271.png tee_sancus_4272_10823.png tee_sancus_10824_11915.png tee_sancus_11916_13535.png tee_sancus_13536_15707.png tee_sancus_15708_15923.png tee_sancus_15924_16247.png tee_sancus_16248_16871.png tee_sancus_16872_17087.png tee_sancus_17088_17171.png tee_sancus_17172_17591.png tee_sancus_17592_19919.png tee_sancus_19920_20651.png tee_sancus_20652_21335.png tee_sancus_21336_22667.png tee_sancus_22668_23555.png tee_sancus_23556_24683.png tee_sancus_24684_24755.png tee_sancus_24756_25019.png tee_sancus_25020_27791.png tee_sancus_27792_27851.png tee_sancus_27852_28319.png tee_sancus_28320_28703.png tee_sancus_28704_29147.png tee_sancus_29148_29327.png tee_sancus_29328_29721.png
Welcome everyone, my name is Sepideh Puyangral. I'm a PhD student in the Distineter Research Group at KU Ruben and I'm happy to present a recent work about an open source framework for developing heterogeneous distributed Enkelev application. These days, we built a smart environment that consists of several heterogeneous components and the application is distributed among multiple components. So all of them work together and exchanging information to each other over an untrusted network. This example could be like a health-scale use case from a smart environment and you see it contains a couple of sensors from heterogeneous vendors and some cloud processing, cloud recording of data on the other people's computer and in the end some health-scale professional might want to look at the data. So how we can make sure the interaction between different components is secure and a professional is looking at the right data and the whole system is kind of end-to-end secure. What we are presenting today is a framework to build secure application based on the terrestrial execution environment in all of these processors so that the doctor can be sure that the data they work with comes actually from an attested sensor and an actuator at the patient's home is guaranteed to only react to an interaction from doctor's computer. And finally, when you build this application you don't want to worry about the differences in the attestation mechanism or the properties of the communication network. Terrestrial execution environment is a relatively new technology in the modern processors that allows to run an application in a hard way protected environment called Enkelep. Enkelep are isolated cryptographically from the rest of the world to protect code and data from being accessed or modified by other entities. Besides, a mechanism called remote attestation is used to obtain remotely a proof that a running application is loaded inside the right enclave and wasn't tampered at the loading time. In TEE, all isolation and authentication primitives are implemented in hard way. That means your trusted computing base shrinks to the application module and a tiny layer of the hard way. Of course, as a result, the attack surface is reduced as much as possible. So here on the left system, an application needs to trust its code, the underlying operation system hypervisor and the hard way. In this situation, you know any vulnerability found anywhere in the platform might influence the security of the application. But in a hard way only TCP system, we can protect an application from a compromised operating system. And we can isolate a single piece of software so that really no one can interfere with it in an uncontrolled way. One implementation of TEE is Intel SGX. In SGX, the protected parts of an application are placed in Enkelep to be completely isolated from direct access. So the application will create this Enkelep and only enter the Enkelep during execution through something like a call gate. So SGX can ensure that non-Enkelep code cannot access Enkelep Pages in memory. Specifically, a portion of the main memory is reserved for the Enkelep and the Enkelep Pages outside the reserve memory are encrypted by a hard way unit called Memory Encryption Engine to protect from under-austed system software and cold boot attack. In addition, to confidentiality and integrity of code and data, other features are provided by SGX like attestation and data ceiling to Enkelep and authenticate the data before storing it on disk. Another very common TEE is Terasone that is implemented by ARM and currently used in a large number of smartphones. In ARM with Terasone, each of the physical processor cores provide two virtual cores called Normal Word and Secure Word. Hardware-based mechanism ensure that resources in the Normal Word cannot access Secure Word resources. To enforce this isolation, NSB is used to communicate the security-estate bitfing components. And to perform a context switch between words, the processor first passes through the monitor mode which serves as a gatekeeper via an interrupt external abort or explicit calls of the SMC instruction. And the address mapping in the Terasone MMU can be configured independently for each word. Also, IO devices can be dynamically configured as a secure or non-secure and for each interrupt, the generic interrupt controller can designate the word to handle it. Another interesting feature in Terasone is Secure Word. That is a change of trust is formed by verifying the integrity of the second stage bootloader and trusted OS before execution. This ensures that nobody has tampered with the operation system code when the device was powered off. And the last TEE we focus in our work is Senghuz. In Senghuz architecture, what we need is a simple memory management unit that implements the isolation techniques and a cryptographic unit that implements all symmetric crypto and hashing of operation system. Here you can see an overview of Enclaves on this Senghuz platform that have a continuous address space. In Senghuz, we have a code region that is associated with an Enclave and then we have a data region that is associated with the same Enclave. Senghuz uses a program counter-based memory access controller to ensure that the data of an Enclave is accessible if only the program counter is on the code section of the same Enclave. Therefore, the only way to enter the Enclave is through the entry point functions. And in the case of Senghuz, we have a node key that is encoded in the platform and from that we derive a key that is associated to each Enclave. So we basically hash the take section and the address of the data section with node key to derive an Enclave key that identifies how an Enclave is specifically loaded on a particular microcontroller. Moreover, remote attestation in Senghuz is a simple process because the Enclave key is only known by the Enclave and software provider. Therefore, if the software provider receives an encrypted message from the Enclave that is successfully decrypted, it can be sure the Enclave is running on tamper on a right node. Another important feature provided by Senghuz is secure I.O. Senghuz uses memory mapped I.O. to communicate with the devices. Therefore, to gain exclusive access to a device, it is sufficient to map the data section of an Enclave over the MMI origin of the device. So nobody expects the Enclave would be able to access the I.O. devices. So there are a range of architecture for hard way-based trusted computing. Each of them is platform-specific and comes with a different system footprint. But all of them provide a strong security guarantee like attestation, isolation and things like that, which is implemented in different ways. That means what S.JX is doing is something different from, for example, what Senghuz is doing. But the baseline is the same. So you can build upon this guarantee and you can use that in your system and construct system that are highly secure, even from a 16-bit microcontroller that communicates over the kilo to an end user devices or something like that. In order to design end-to-end secure smart environment, as I already explained, the data behind our implementation is based on the concept of authentic execution. This framework was proposed by Norman in 2015 to provide a strong assurance of the secure execution of a distributed application. According to the paper, they want to guarantee if an output is produced by the application, it is actually allowed to be produced by the application's source code and physical input event. In this framework, each component of distributed application runs in a trusted execution environment and thanks to the confidential computing provided by the TES and authentication encryption of the data, end-to-end security can be achieved in our smart city. The implementation provided by Norman only supports Senghuz processors, but this concept can be applied to a generic TEE to support heterogeneous systems in a real scenario. Thereby, our framework provides an implementation of authentic execution that supports Intel SGX, ARM Trason and Senghuz to allow development of applications in a heterogeneous environment. The SGX part of our framework was entirely written in Rust with a framework called Fortanix Enclave Development Platform. In order to develop applications for Trason, open source opti framework is used, which provides a collection of truth change, open source library and secure kernel that is implemented in C. And finally, with Senghuz toolchain implemented the Senghuz Encalave. Our framework aims to minimize the developer's effort as much as possible, thereby it automatically deploys the Enclaves on the supported TEE and then attests them using remote attestation and finally provides a secure communication between different components with cryptographic operations. And thereby it provides the developer an abstraction layer in which they only need to implement the application's logic. So we ensure this framework provides end-to-end security for a safety critical smart environment. And a demo of our framework will be presented now by my colleague Gianloka. Thanks for your attention to me. Thank you, Sepideh, for your introduction. Now I will show you a simple example about how to use this framework to build and run a secure distributed application using Senghuz and SGX. A couple of words about me before. I'm Gianloka and I'm a PhD student working on the FIGOS project promoted by KU11 and Ericsson. My work is about the integrity assurance for multi-component services and third-year networks. So this is the setup of our application. You can see that there are two Senghuz nodes and one SGX node and we have also two input and output devices. We have a button here that will be the input of our system and we want to perform some operation every time the button will be pressed. And here we have a LED instead and this LED will be toggled every time the button is pressed. Instead in the SGX node we will store the number of button presses and also we will provide an interface for the deployer and external users to interact with the system and get this value. The deployer is responsible for deployment and configuration of the modules and their connections. The user instead can be anyone connected on the same network and the user can retrieve the number of button presses by performing HTTP requests. Okay now we will see the deployment phase of our application. We provide as input to the deployer all the source files of each component of the application called, these components are called modules and also we provide a deployment descriptor which is a JSON configuration file which contains a description of all the nodes, modules and connections between modules. So the first step is to build binaries of every module and then send them to the corresponding nodes. On every node there is a untrusted software which is called Event Manager. This Event Manager is responsible of exchanging events between modules but also as shown in this case Event Manager is responsible of loading the modules inside the nodes. Of course the Event Manager is untrusted so we want to make sure that this loading process has been done correctly and for this reason we also perform a model testation and we want to make sure of first of all that the binaries have not been modified during the process and second of all that the modules are loaded inside the task execution environments. Also during the process we will establish secure channels between the deployer and modules using module keys. Each module will have a unique module key. After that now the modules are running and they are tested and now we will establish the connections between these modules. We take as input the same descriptor as before and we start with the establishment of this connection. First of all we establish the connections between modules and IU devices using the Sankus Securario functionality. After that we establish all the other connections between modules and between the deployer and modules. So here the blue arrows are the secure communication channels and every event exchange will be encrypted and authenticated and here the red arrow is just the HTTP channel between the user and web server so it's unsecured. Okay this is an example of the source code of the controller module and the thing to notice here is that the every module declares outputs and inputs. So a connection between two modules connects the output of the source module to the input of the destination module. So here with this controller module we write some special instructions to declare outputs and inputs. For controller we have two outputs, toggle led and increment presses and one input button pressed. But how to declare these connections between modules? This is done in the deployment descriptor. So in this example I declare two connections. The first connection is from the button driver to the controller. The second connection is a direct connection from the deployer to the web server. Okay now I will show you how this works in practice and if you are interested in this example you can go to my repository, you can see all the source code, you can see the tutorial if you want to run the demonstration of your local machine and don't worry if you don't have Sankus or SGX because you can run just the native version of this example and also I provide some Docker images so if you just want to run this example without installing anything on your machine you can do it. So if you go to my repository you can find all the tutorials for this. Okay this is my terminal now. Okay at the top right I have the SGX node and at the bottom right I have the Sankus node. Here I use just one single Sankus node for practical reasons but the application will behave the same. And as you can see here the deployment has been already made so all the modules are running and they are tested on each node. Here at the top left window this is the terminal of the deployer. So here I will send some commands to the system. The first I want to send is this is to initialize the web server so I will send an output command, an output event for the inner server connection passing as the input as argument the port I want to use. So if I trigger this output you can see here that web server now is listening to this port and if we try to reach this web server we get the number of button presses. In this case of course the number is already just zero. But if you want to trigger a button press of course you can do this physically. You can trigger the button physically. The problem is that I'm not physically close to the Sankus node so I cannot physically press the button and so for this reason I use another connection to simulate a button press but notice that this connection is still secured so we still have the security features for all the other connections. And so I will trigger another output of the trigger button connection and if I do so you can see that something happens. First of all the button driver notifies us that the button has been pressed. The controller has received the remote event on the button and the led driver has been turned on. And if we reach again the web server now we see that the number of button presses has incremented by one. But if we don't trust this HTTP communication because of course HTTP is not secure we can perform another request from the deployer side. In this case I will send a request which is the same principle as input output connections but in this case we expect a value in return. So we trigger a request of the connection get presses and here you can see that we get as response the number one. So in the end yes this is working properly and the button has been pressed only one time. Okay that's it. Coming back to the slides so in the end this framework provides strong integrity over the application behavior because we can only toggle the led if we press the button and we can only increment the value stored in database if we press the button. If we don't do it there is another way to do to increment the value of database or to toggle the led. But we have also confidentiality of the application state and sensitive data thanks to the execution environments and thanks to the secure communication channels between modules. We don't have availability because if an event is lost during the transmission nothing happens. So in the end this is still an ongoing work and as I said before we are providing support for class don which will be available soon but still we are working on improving the code deployment tools and the SGX side. So this is it thank you for your attention and now if you have some questions thank you.
developing heterogeneous distributed Enkelev heterogeneous components and the application is and some cloud processing, cloud recording of interaction between different components is framework to build secure application based on off. And the last TEE we focus in our work is strong security guarantee like attestation, proposed by Norman in 2015 to provide a strong assurance of the secure execution of a execution that supports Intel SGX, ARM Trason and heterogeneous environment. The SGX part of our Platform. In order to develop applications for finally provides a secure communication between an abstraction layer in which they only need to implement the application's logic. So we ensure use this framework to build and run a secure provides strong integrity over the application secure communication channels between modules. We