In light of the above discussion, we describe our test-bed implementations for evaluating TEE-based CA. Our system uses the Intel SGX and OP-TEE along with implementations of three learning algorithms for performing trusted CA on
ARM and Intel chipsets. We present the details and challenges of implementing this on two commercially-available devices.
3.4.1 Intel SGX
Intel SGX was described previously in greater detail in Section2.4.6of Chapter 2. The first thing we note is that Intel SGX supports only a subset of C/C++ li-braries. We discovered, for example, that libraries found ubiquitously elsewhere, e.g. <locale>, <sstream> and <iostream>, were either partially or wholly unavailable. This is because, in present versions, SGX enclaves cannot use meth-ods reliant upon OS systems calls. Consequently, basic functions reliant on I/O, such as printf, had to be redefined – printing from enclaves requires a context switch to the Rich OS through an OCALL, where a system call is used to redirect characters to standard output. Intra-enclave thread creation is also unsupported, along with the rand and srand PRNGs, thus forcing calls to the CPU’s hardware RNG via the SGX-only function sgx_read_rand. Originally, we planned to use a popular C++ machine learning library, such as Shark6, that offered im-plementations of a variety of learning algorithms. Such libraries, however, rely heavily upon system calls and I/O functions, meaning bespoke, SGX-compatible algorithms had to be re-developed for use within enclaves. For complex learning algorithms, like SVMs and Random Forests, redesigning and reimplementing libraries with large code bases is difficult while retaining correctness without expert oversight. Indeed, popular SVM libraries have non-trivial code bases (>5,000 lines of code for LibSVM7). This issue was less problematic for kNN, LR and NB – all relatively simpler in nature – which were favoured in the test-bed implementation. These algorithms are described briefly in the following section.
3.4.2 Machine Learning Algorithms
In machine learning, classification is a supervised learning task in which a func-tion, f , which maps input features to output labels, is inferred/‘trained’ using a set of example input-output (feature-label) pairs. This example set is also known as the training set: T = {(F(1), C(1)), (F(2), C(2)), . . . , (F(n), C(n))}. A feature vector, F = (x1, x2, . . . , xm), comprises a vector of real-values, where m is the number of observed features, while C ∈ {1, . . . , c} represents the corresponding label or class (c = 2 for binary classification, e.g. authentication). Numerous clas-sification algorithms exist in order to model f using various techniques, such as Bayesian probability, finding the closest members in feature space, or minimising a cost function of a linear function that maps feature vectors to their labels (linear
6Shark Machine Learning:http//image.diku.dk/shark/
7LibSVM:https://www.csie.ntu.edu.tw/~cjlin/libsvm/
optimisation). The process of systematically classifying new feature vectors after training is known as ‘testing’. We describe the algorithms explored in this work below.
Naïve Bayes (NB) is a widely-used probabilistic classifier that uses Bayes’
Theorem with a strong independence assumption between features. Given a labelled training set, T, the training phase involves computing the label priors (the probabilities of each label occurring in the set, i.e. p(Ck)), and feature conditional probabilities (the probabilities of features occurring given the label, i.e. each p(xi|Ck)). A feature vector is subsequently classified by maximising the posterior probability for each class label Ck, given in Equation3.1. While strong independence between features may seem intuitively unwise, Naïve Bayes has been applied successfully in wider literature and, indeed, in CA successfully [119], [129], [130], [133].
k-Nearest Neighbour (kNN) classifies a feature vector, F , using the k closest neighbours to F in feature space (F ∈ Rm). That is, given a pre-existing training set, T, kNN measures the distance (typically Euclidean distance) between Fnew
and each F(i) ∈ T. Fnewassumes the label of the nearest k neighbours in T using majority vote. kNN has no dedicated training period, other than storing feature vectors with which to reference future examples.
Logistic Regression (LR) is a binary classification method in which the prob-ability of the occurrence of a positive example is found by computing the logit function (Equation3.2) over a weighted sum of the feature vector. That is, the probability of the label, c = 1, given an example feature vector F is found by computing the logit function, g, on the sum of weights multiplied by each fea-ture xi ∈ F .This is denoted in Equation3.3, where wi is the weight of the ith feature. The set of weights is found by minimising the ordinary least-squares cost function of the training examples and labels using gradient descent [151].
An open-source C++ implementation8of logistic regression was adapted for the test-bed implementations.
8‘A Simple LR Implementation in C++’: https://github.com/liyanghua/
logistic-regression-in-c--The test-beds implement TEE-compatible versions of the above algorithms and a simple API is exposed through which application developers can train and test data in the TEE from the Rich OS. All functions use purely ECALLs for SGX; no CA-specific data is divulged to the Rich OS other than: 1), a value indicating successful training, and 2), the authentication decision. The test-bed spawns a enclave that hosts each algorithm, which was implemented in C++ using Microsoft Visual Studio and the Intel SGX SDK, and compiled using the Intel compiler provided. The Intel SGX SDK allows the development of applications that instantiate enclaves natively. We implement the training and testing phases inside the enclave environment, which are managed through a restricted API from the host application. Only two context switches occur between SGX and the Rich OS: 1), to transfer raw sensor data from the Rich OS to the TEE; and 2), transferring an acknowledgement message (after training) or a boolean authentication value (testing) from the TEE to the Rich OS.
3.4.3 OP-TEE
OP-TEE [152] is an open-source, GlobalPlatform-compliant TEE framework de-veloped by Linaro, which currently supports executing alongside a custom mini-mal Linux-based kernel; Debian (also Linux-based); or, for certain development boards, Android OS. OP-TEE implements the GlobalPlatform system architecture (see Section2.4.7of Chapter2) using ARM TrustZone, and allows host applica-tions executing in the untrusted REE to communicate over the GlobalPlatform Client API to access Trusted Applications (TAs) executing in OP-TEE. A Linux driver is provided that uses ARM-based Secure Monitor Calls (SMC) to imple-ment world transitions between client applications in the REE and TEE TAs (see Section2.4.4). The OP-TEE OS provides interfaces for TAs to use, amongst oth-ers, software- and hardware-based cryptographic operations (depending on the development board), external SEs, clocks and timers, and secure storage using the sealing abstraction in the GlobalPlatform Internal API. Internally, OP-TEE currently uses cryptographic implementations from LibTomCrypt, such as for AES, SHA-2, RSA, Diffie-Hellman and Elliptic Curve Cryptography (ECC9). The reader is referred to the OP-TEE repository10 for a list of currently supported development boards, current issues, and existing and planned feature support.
Unsurprisingly, memory consumption quickly became problematic when working with large datasets within OP-TEE. For the current OP-TEE release (July 2018), 32MB RAM is allocated for the TEE kernel and all resident TAs, with the rest allocated to the untrusted world OS. For a standard TA, the Linaro Working
9At present, GlobalPlatform ECC support is limited to NIST-approved curves up to P521.
10OP-TEE:https://github.com/OP-TEE/optee_os
Group11recommends a default stack and heap size at 1kB (stack) and 32kB (data) respectively. While this can adjusted to a virtually arbitrary limit based on the RAM capabilities of the chosen platform – 2GB of RAM on our development board (HiKey LeMaker), which must also accommodate the REE – the Linaro Working Group recommends a maximum of 1MB for the stack and heap. These recommendations are advised to maximise the RAM available to the REE. For the purposes of this test-bed, this was exceeded in order to accommodate data above 1-day’s worth: to 1MB and 40MB for the stack and heap respectively in order to accommodate 21-days worth of training data for each user. (In comparison, Intel SGX supports up to 128MB PRM in RAM by default). As such, a potential OEM wishing to deploy TEE-based CA must be aware of CA’s larger run-time memory requirements.
The design of the OP-TEE test-bed comprises a REE-side application that communicates through the GlobalPlatform Client API, over the SMC secure monitor, and to the corresponding TA hosted by the TEE. Currently, OP-TEE does not support C++ TA development – requiring TAs and accompanying REE-side client applications to be written in C (C99, precisely) and compiled with GCC12. The OP-TEE CA TA exposed simple training and testing API functions for each algorithm, which were available to the untrusted REE client application. The algorithm code-base was identical to the SGX implementation in nature, but rather than communicating over the Intel SGX enclave boundary with its host application, the OP-TEE client application communicated over the GP Client API with its respective TA. Both test-beds exposed the same training and testing function definitions.