Recently I am developing a trusted computing project with the help of an Intel SGX Enclave.
To verify an Enclave i need the Quote generated by the Quoting-Enclave.
I know how it works theoretically and how to start an Enclave.
But I am not able to find any code examples or detailed explanation on how to recieve the quote for an Enclave and sending it to the calling programm.
Can someone please explain that to me through an example?
Thanks!
Well, what you are trying to do is called Attestation.
Attestation is a process to verify:
whether an enclave is running the expected bynaries (signed library), and,
whether it is running in a real SGX enabled processor.
Attestation usually is required prior to providing secrets to an enclave. This process is called Provisioning.
There are two kinds of Attestation:
Local Attestation: two enclaves, running on the same Platform (PC) want to "verify" each other.
Remote Attestation: a Service Provicer needs to verify an enclave remotely.
You mention Quote Enclave (QE) so I suppose you are using Remote attestation.
If you are searching for examples, please refer to the example projects comming with the Intel SGX SDK, or the ones available at the Intel SGX site.
Related
I have been looking around for a simple Bluetooth LE library in C that allows me to scan for BLE devices, connect and receive periodic notifications from a given service UUID from the BLE device. Something that directly works with Bluetooth sockets and libbluetooth(created from BlueZ) and not using DBUS. Pairing and security functionality are not required.
Came across https://github.com/labapart/gattlib. Appears to be good but uses dbus API and has dependency on libdbus, glib, so on. To use this library, there is an additional 5MB of libraries required, hence decided to go without dbus. We do not have space on our device to support 5MB of bluetooth stack on compressed rootfs image. The total size of our rootfs image is 9 MB. The bluetooth stack with dbus itself appears to be more than 50% of our rootfs size.
There is also - https://github.com/edrosten/libblepp which is in c++ and doesn't use dbus. This would require to write a C wrapper to be used in C programs and also overhead of C++ constructs such as compiler generated copy constructors, assignment operators and so on. Also issues in cross-compiling.
Target board is Xilinx Zynq running Linux and the build system is buildroot.
Please suggest.
Thanks
Found a solution, it may be of help for someone...
After searching and going through Linux Conference and IOT conference videos on youtube, figured that Bluez has light weight executables and the code is present in src/shared folder of Bluez. For btgattclient.c produces "gatt-client" executable when compiled which does the same functionality as "gatttool" and is not dependant on bluetoothd or dbus. The only dependency it has is on glib-2.0.
This is helpful if we need lightweight tools when the OS has no bluetoothd running or has no dbus library installed.
Thanks
If you want to use BlueZ for BLE communication, the only supported API is the D-Bus API. Everything else is either discouraged or deprecated.
If you want something more minimal and/or not use BlueZ at all, you can use the HCI_CHANNEL_USER feature in Linux to get raw access to the HCI connection in the kernel. With this you can use any Bluetooth Host stack software or write your own minimal if you only require an extremely small subset.
Questions asking for software library recommendations are not allowed on Stack Overflow due to the possibility for opinion-based results though.
I'm using SCONE Docker image to run my code inside Intel SGX enclave.
SCONE handles the creation of enclaves and their eventual destruction, which makes my life as a programmer easier. But if I want to perform a Local or Remote Attestation of my code inside the enclave, I need to rely on SCONE's proprietary service.
I wonder if it's possible to create a report for attestation from within the current enclave. In other words, the code running inside the enclave must be able to create an attestation report and send it out - all without leaving the enclave.
I've checked Intel SGX documentation and samples code. All of the calls to EREPORT function rely on knowing the Enclave ID, which I don't know (SCONE creates enclaves on my behalf). Hence my question is mainly about the way to find out the enclave information from within it.
Is it actually possible?
If I build a CorDapp in Corda open source that walks through all transaction chain to collect some data, I suppose that when SGX is enabled in Enterprise version it won't be possible, right?
That's correct. When SGX is enabled, the transaction chain will be stored in encrypted form, readable only by the enclave. You thus won't be able to walk through and read the contents of the chain.
I'm trying to understand the difference between SGX threads enabled by TCS and untrusted threading provided by SDK.
If I understand correctly, TCS enables multiple logical processors to enter the same enclave. Each logical processor will have its own TCS and hence its own entry point (the OENTRY field in TCS). Each thread runs until an AEX happens or reaches the end of the thread. However, these threads enabled by TCS have no way to synchronize with each other yet. At least, there is no SGX instruction for synchronize.
Then, on the other hand, the SGX SDK offers a set of Thread Synchronization Primitives, mainly mutex and condition variable. These primitives are not trusted since they're eventually served by OS.
My question is, are these Thread Synchronization Primitives meant to be used by TCS threads? If so, wouldn't this deteriorate the security? The OS is able to play with scheduling as it wishes.
First, let us deal with your somewhat unclear terminology of
SGX threads enabled by TCS and untrusted threading provided by SDK.
Inside an enclave, only "trusted" threads can execute. There is no "untrusted" threading inside an enclave. Possibly, the following sentence in the SDK Guide [1] misled you:
Creating threads inside the enclave is not supported. Threads that run inside the enclave are created within the (untrusted) application.
The untrusted application has to set up the TCS pages (for more background on TCS see [2]). So how can the TCS set up by the untrusted application be the foundation for trusted threads inside the enclave? [2] gives the answer:
EENTER is only guaranteed to perform controlled jumps inside an enclave’s code if the contents of all the TCS pages are measured.
By measuring the TCS pages, the integrity of the threads (the TCS defines the allowed entry points) can be verified through enclave attestation. So only known-good execution paths can be executed within the enclave.
Second, let us look at the synchronization primitives.
The SDK does offer synchronization primitives, which you say are not to be trusted because they are eventually served by the OS. Lets look at the description of these primitives in [1]:
sgx_spin_lock() and unlock operate solely within the enclave (using atomic operations), with no need for OS interaction (no OCALL). Using a spinlock, you could yourself implement higher-level primitives.
sgx_thread_mutex_init() also does not make an OCALL. The mutex data structure is initialized within the enclave.
sgx_thread_mutex_lock() and unlock potentially perform OCALLS. However, since the mutex data is within the enclave, they can always enforce correctness of locking within the secure enclave.
Looking at the descriptions of the mutex functions, my guess is that the OCALLs serve to implement non-busy waiting outside the enclave. This is indeed handled by the OS, and susceptible to attacks. The OS may choose not to wake a thread waiting outside the enclave. But it can also choose to interrupt a thread running inside an enclave. SGX does not protect against DoS attacks (Denial of Service) from the (potentially compromised) OS.
To summarize, spin-locks (and by extension any higher-level synchronization) can be implemented securely inside an enclave. However, SGX does not protect against DoS attacks, and therefor you cannot assume that a thread will run. This also applies to locking primitives: a thread waiting on a mutex might not be awakened when the mutex is freed. Realizing this inherent limitation, the SDK designers chose to use (untrusted) OCALLs to efficiently implement some synchronization primitives (i.e. non-busy waiting).
[1] SGX SDK Guide
[2] SGX Explained
qweruiop, regarding your question in the comment (my answer is too long for a comment):
I would still count that as a DoS attack: the OS, which manages the resources of enclaves, denies T access to the resource CPU processing time.
But I agree, you do have to design the other threads running in that enclave with the awareness that T might never run. The semantics are different from running threads on a platform you control. If you want to be absolutely sure that the condition variable is checked, you have to do so on a platform you control.
The sgx_status_t returned by each proxy function (e.g. when making an ECALL into an enclave) can return SGX_ERROR_OUT_OF_TCS. So the SDK should handle all threading for you - just make ECALLs from two different ("untrusted") threads A and B outside the enclave, and the execution flow should continue in two ("trusted") threads inside the enclave, each bound to a separate TCS (assuming 2 unused TCS are available).
I had the idea of running a small service next to the OS but I'm not sure if it is possible. I tried to figure it out by reading some docs but didn't get far, so here comes my question.
I read about the UEFI runtime services.
Would it be possible to have a small module in the firmware which runs next to what ever operating system is used and that sends information concerning the location of the device to an address on the internet?
As far as my knowledge goes, I would say that it should not possbile to run something in the background once UEFI handed the control over to the OS kernel.
To clarify my intentions, I would like to have something like that on my laptop. There is the Prey project but it is installed inside the OS. I'm using a Linux distribution without autologin. If somebody would steal it they would probably just install Windows.
What you want to do is prohibited because that would be the gateway for viruses, loggers and other malwares.
That said, if you want to get some code running aside of the OS, you should look at System Management Mode (SMM).
SMM is an execution mode of the x86 processors orthogonal to the standard protected mode. SMM allows the BIOS to completely suspend the OS on all the CPUs at once and enter in SMM mode to execute some BIOS services. Switching to SMM mode happens right now on your x86 machine, as you're reading this Stackoverflow answer. It is triggered either by:
hardware: a dedicated System Management Interrupt line (SMI#), very similar to how IRQs work,
software: via an I/O access to a location considered special by the motherboard logic (port 0xb2 is common).
SMM services are called SMM handlers and for instance sensors values are very often retrieved by the means of a SMM call to a SMM handler.
SMM handlers are setup during the DXE phase of UEFI firmware initialization into the SMRAM, an area dedicated to SMM handlers. See the following diagram:
SMM Drivers are dispatched by the SMM Core during the DXE Phase. So
additional SMI handlers can be registered in the DXE Phase. Late in
the DXE Phase, when no more SMM drivers can be dispatched, SMRAM will
be locked down (as recommended practice). Once SMRAM is locked down,
no additional SMM Drivers may be dispatched, so not additional SMI
handlers can be registered. For example, an SMM Driver that registers
an SMI handler cannot be loaded from the EFI Shell or be added as a
DriverOption in the UEFI Boot Manager.
source: tianocore
This means that the code of your SMM handler must be present in the BIOS image, which implies rebuilding the BIOS with your handler added. It's tricky but tools exist out there to both provide a DXE environment and build your SMM handler code into a PE executable, as well as other tools to add a DXE driver to an existing BIOS image. Not all BIOS manufacturers are supported though. It's risky unless your Flash chip is in a socket and you can reprogram it externally.
But the first thing is to check if the SMRAM is locked on your system. If you're lucky you can add your very own SMM handler directly in SMRAM. It's fidly but doable.
Note: SMM handlers inside the BIOS are independent from the OS so it would run even if a robber installs a new Operating System, which is what you want. However being outside of an OS has huge disadvantages: you'd need to embedd in your SMM handler a driver for the network interface (a polling-only, interrupt-less driver!) and wlan 802.11, DHCP and IP support to connect to the Wifi and get your data routed to an external host on the Internet. How would you determine the wifi SSID and password? Well you could wait for the OS to initialize the network adapter for you, but you'd need to save/restore the full state of the network host controller between calls. Not a small or easy project.
As far as my knowledge goes, I would say that it should not possbile to run something in the background once UEFI handed the control over to the OS kernel.
I agree. Certainly, the boot environment (prior to ExitBootServices() only uses a single threaded model.
There is no concept of threads in the UEFI spec as far as I can see. Furthermore each runtime service is something the OS deliberately invokes, much like the OS provides system calls for applications. Once you enter a runtime system function, note the following restriction from 7.1:
Callers are prohibited from using certain other services from another processor or on the same
processor following an interrupt as specified in Table 30.
Depending on which parts of the UEFI firmware your runtime service needed access to would depend on which firmware functions would be non-reentrant whilst your call was busy.
Which is to say that, even if you were prepared to sacrifice a thread to sit eternally inside an EFI runtime service, you could well block the entire rest of the kernel from using other runtime services.
I do not think it is going to be possible unfortunately, but interesting question all the same!