This section describes the partitioning of theMemcachedkey-value store3to run on top of the TrApps platform. Memcached is an in-memory key-value store written in the C programming language. Partitioning of this application follows the principles defined in the previous sections with the goal of protecting the confidentiality of the data stored in Memcached. Furthermore, this use case application showcases the functionality of the TrApps platform and delivers a proof of concept, also it provides an estimate of the possible performance of the TrApps platform.
4.4 Secure Memcached on TrApps
4.4.1 Design and Implementation of Secure Memcached on TrApps
The system architecture of Secure Memcached is illustrated in Figure 4.2, which shows that the partitioning of Memcached to run on TrApps leads to a trusted and untrusted component supposed to be deployed in secure and normal world of TrustZone re-spectively. The communication between those two components across the TrustZone’s world boundary is processed via the TrApps driver (c.f. Chapter 3).
According to the principle of reducing the TCB, as a starting point all business logic of Memcached is considered untrusted. Then, code that can only work with plain text is identified and offloaded to a TEE. The general idea now is to protect the client-server communication—for example by using TLS, the state of the art technology for this purpose—while terminating that encryption only inside the TEE on the server side.
This ensures that plain text is never available outside of the TEE (unless the TEE decides to hand out the data). Then, the trusted component analyses the incoming data and, in case of the Memcached example, identifies keys and values of key-value pairs as the sensitive data that is to be protected.
The most important and most common requests to a key-value store areget()and set(), whereas aget()request will only contain the key whose value is being requested, andset()contains key and value which is to be stored by the server. In order to protect the data, the TEE encrypts the plain text key and value of the key-value pair with a symmetric encryption mechanism using a secret encryption key only known to the TEE and forwards the encrypted data to the actual (untrusted) database.
Without server-side operations that need to be executed on the plain text data, the whole service could reside in the untrusted environment and clients could be adjusted to encrypt the data before interacting with the server. However, this would increase the complexity of key distribution and management, because in that case all clients would need to agree on a shared encryption key and future exclusion of malicious clients is much harder. However, apart from theget()andset()operations, Mem-cached also supportsincrement()anddecrement()operations. In order to execute anincrement()(ordecrement()) operation, the server needs to know the plain text of the data. Thus, Secure Memcached encrypts key and value data fromget()andset() requests. This allows to call into the trusted component during the processing of an increment()ordecrement()operation, decrypt the data, execute the operation on the plain text and encrypt the altered data before leaving the TEE. Hence, during the ex-ecution of theget()andset()operations the trusted component has to encrypt key and value of all incoming requests, respectively.
3Memcachedhttp://memcached.org/
0 500 1000 1500 2000
0 1000 2000 3000 4000 5000 6000 7000 8000 9000 10000
Throughput [Op/s]
Payload size [Byte]
Memcached Secure memcached
Figure 4.3: Throughput of Secure Memcached on TrApps.
As mentioned above, usage of TLS as opposed to a shared secret that all clients need to know also poses the advantage of simpler and more flexible key management. Clients could connect to the server and a secret encryption key is negotiated for each connec-tion individually. The TEE is the only component that has access to the symmetric encryption key of all encrypted data stored on the server. This makes it easy to inte-grate access control mechanisms into the TEE and to exclude rogue clients that have been benign and turned malicious later on. Because the clients never knew the en-cryption key of the data, they can not extract any information from the encrypted data on the server if they got a chance to access it. Only data a client has actually accessed during the time she was permitted to access the server is known to that client. In addi-tion, this approach removes the necessity to have a key distribution mechanism for the encryption key between all benign clients. Clients only need to be able to establish an authentic TLS connection with the server, therefore it is crucial to ensure authenticity of the server’s TLS certificate.
4.4.2 Evaluation of Secure Memcached on TrApps
We have measured the impact of using TrustZone-enhanced security on the basis of TrApps in the form of the TrApps-secured Memcached in-memory key-value store ap-plication. For the evaluation we started the official Memcached benchmarking applica-tionmemslapon a remote host and issued requests to the service. The TrApps-secured memcached service has been executed on the NXP i.MX53 development board4running
4c.f.https://www.nxp.com/design/development-boards/i.mx-evaluation-and-development-boards/
i.mx53-quick-start-board:IMX53QSB, last accessed 09/2020.