Jump to content
Main menu
Main menu
move to sidebar
hide
Navigation
Main page
Recent changes
Random page
Help about MediaWiki
Matthews Lab
Search
Search
Appearance
Log in
Personal tools
Log in
Pages for logged out editors
learn more
Contributions
Talk
Editing
Work
(section)
Page
Discussion
British English
Read
Edit
Edit source
View history
Tools
Tools
move to sidebar
hide
Actions
Read
Edit
Edit source
View history
General
What links here
Related changes
Special pages
Page information
Appearance
move to sidebar
hide
Warning:
You are not logged in. Your IP address will be publicly visible if you make any edits. If you
log in
or
create an account
, your edits will be attributed to your username, along with other benefits.
Anti-spam check. Do
not
fill this in!
= h.h = Status: production project [[File:Work 2.png|thumb]] Intel processors contain a special feature called an ‘enclave’ that allows running code that can be isolated from the main host and hardware. The technology is very impressive but it can be quite complicated to use. To take advantage of its main features requires the use of expensive, non-commodity, server processors, and the main software libraries for interacting with these enclaves are written in C++ which comes with problems of their own. Writing code in C++ wouldn’t be a problem but one of the things I wanted was to write software that would be highly portable and run on other platforms. Some of the platforms I had in mind were 32 bit web assembly and mobile apps via native support. To top it off I’d like for my software to provide a good experience for other developers. They should not have to spend 9 hours acquiring dependencies to build my code. My solution was to build a single header library in standard C. There would be no C++ and especially no use of the standard template library because web assembly has a hard time compiling this without errors! For those who haven’t written much software in C the standard library is bare bones. There are no big numbers, no ‘dictionaries’ / hash tables, no ‘lists’, no regex, no JSON… or crypto support, in fact most of what you would expect from a modern language is missing. Still though… C is surprisingly elegant and far more beautiful than people give it credit for. So I added what was missing to the library. There’s a lot of code in the library that was written by other people and either modified for my needs or merged in. It includes code that was released under the public domain and various licenses that were either released under the GPL or are directly compatible with it. There is a credits file at the top of the library that explains exactly who is responsible for what, the license of the original code, and where it came from. <span id="what-i-learned-1"></span> == What I learned == When it comes to learning standard skills like software engineering there are countless books you can refer to. But the more specialised and cutting-edge work, almost research topics, you’re left to make sense of everything on your own. I found the learning curve for working with Intel enclaves very steep (though Microsoft certain made it easier to get started with their confidential compute VMs!) What I found myself doing is reading the Open Enclave SDK like it was a novel. I’d start from the build process and read all the way through to a working example project. Whenever I came across anything I didn’t understand I’d go off and learn exactly how that worked. Doing this I’d keep a notebook alongside it that eventually became detailed enough to describe the full system which contained information that wasn’t published anywhere else. Breaking everything down step-by-step eventually allowed me to learn enough to work with the SDK. One of the first things I built was a program that provided signed proof or ‘attestations’ that it is running inside an enclave. What’s cool about this is you can use this to securely exchange data and do computations between programs running on different hosts even if both of them are completely compromised. Such a possibility could lead to fundamental changes in the way we design software. <syntaxhighlight lang="json"> { "status": "success", "enclave": { "identity": { "id_version": 0, "security_version": 1, "product_id": 1, "unique_id": "162557E2547620EE9272546420F0353ABF0AD13F4F29C721BE8055C73470078C", "attributes": "07000000000000000700000000000000", "signer_id": "6C1F3D9B1303484398C5F71C118351309111165348311D0D83A5FFA4C0BDBFC1", "signer_pub": "..." }, "binary": "/enclave.signed" }, "report": { "header": { "version": 1, "type": "remote", "size": 4579 }, "quote": { "version": 3, "sign_type": 2, "qe_svn": 2, "pce_svn": 7, "uuid": "939A7233F79C4CA9940A0DB3957F0607", "sig_len": 4143, "user_data": "2E974C10644E147715A8A2D59A78BD8400000000" }, "body": { "cpusvn": "0D0D0205FF8003000000000000000000", "miscselect": 0, "isvprodid": 1, "isvsvn": 1, "attributes": "07000000000000000700000000000000", "mrenclave": "162557E2547620EE9272546420F0353ABF0AD13F4F29C721BE8055C73470078C", "mrsigner": "6C1F3D9B1303484398C5F71C118351309111165348311D0D83A5FFA4C0BDBFC1", "report_data": "rand_nosdfsdf", "report_data_sha256": "58D6939DA37987E3E67944D21538E9A35874BC64A3D07C0BD6F3FD83B9EA5F2B0000000000000000000000000000000000000000000000000000000000000000" }, "sig": "...", "pubs": "..." }, "hex": "...", "notes": "The hex field above contains the raw remote attestation report as returned from oe_get_remote_report from the enclave. Public keys and signatures for the report are from Intel. The enclaves pub key and signature match the authors who produced enclave.signed. The enclave is running smoothly on this host. To verify its operations on the host you would need the verification client, enclave source, claimed enclave binary, and enclave meta data." } </syntaxhighlight> I learned a lot about enclaves but also C++ build toolchains. Plus, how to design simple C software. Overall, it was a highly valuable experience from a security engineering and R & D perspective! <span id="what-i-would-change-1"></span> == What I would change == One mistake I made with this header library is not using a unique prefix for the names of functions. What this means is that if someone were to include this library and there were already a function name in their code that shares the same name as a function in the library then they would get compile errors. It’s not a huge problem to fix this but it is a task that seems very tedious. I can’t think of a simple way to fix this safely without having to manually rename every function. But maybe there’s a tool to match all functions and usages across the whole project and replace them at once. It could well be worth writing a script for this if there’s not. Just branch off and see if the code can be patched in place. Stage 1 is finding the definitions. Stage 2 is replacing their usage. A single namespace might actually make this easier. Other than that I’m honestly happy with this library. There’s a bunch of other financial code that I’ve written that uses this header and thus shares all of the same benefits that I’ll be releasing soon too. <span id="coinbend"></span>
Summary:
Please note that all contributions to Matthews Lab may be edited, altered, or removed by other contributors. If you do not want your writing to be edited mercilessly, then do not submit it here.
You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource (see
Matthews Lab:Copyrights
for details).
Do not submit copyrighted work without permission!
Cancel
Editing help
(opens in new window)