Okay, well, hello, I'm here, and I'm on the other side of the campus, and I've developed
spoke as part of my own program at the CaliLover, and it's a provision of a professor from
Duke, and a professor of business.
So spoke is a risk-related, and it's so full-base in the sense that it's only a
device on a very basic risk-wise, so it just uses PMP to ensure confidentiality, but
it only uses PMP and machine mode and user modes.
And this is important because spoke is really directed at super low-end of all risk-ship,
so it's really directed at embedded devices side-of-things, so it's a little different
from a keystone.
You might know Keystone, Keystone is another risk-5, so full-base, so multi-so-for-base,
T.E., spoke is a like keystone, but Keystone is not that suited for embedded devices.
spoke is heavily based on Sankers, Sankers is a mobility that has to take a closer, but
Sankers is more hardware-based, and at the beginning, as spoke was a like Sankers, but
in the end it ended up a little different, which means a so-share system or terminology, and
API is quite similar.
So first for the problem statement today, I will discuss the Q and Execution, I will
then spoke at the station, of course, and I'm just going to introduce the terminal situation
on some terminology, so the IP on the infrastructure provided is entity that controls all
the different nodes, so the nodes are marked not until node N here, and the nodes are
just some risk-free embedded devices that could be almost anything, and the software
provided is well-authent to deploy several modules called N-claves on to each of these nodes.
We call these N-claves and let's say several modules, because we all would use them as M-for-securety
management, we'd get a bit confusing, so the software provided has two N-claves on the first
node, N-clave 1 and N-clave 2, and the second software provided has one N-clave on the first
node N-clave 3, and on the last node, it has got N-clave J.
Okay, aside from these N-claves, N-claves also got its own interested operating system, and
we call this the interested operating system, because we work on the assumption that operating
system also in the full control of the attacker.
So our spoke works with the dial of your attacker model, so we assume that the attacker can
do any kind of software basic, so an attacker can also be deploying an N-clave, so an attacker
could potentially try to deploy an N-clave to one of the nodes, and then you have the security
manager, and that's actually the task of spoke, so spoke is the security manager, and it
oversees the execution of the N-claves and other interested operating system.
Now, I'm going to make a bit of an other oversimplified analogy, so in an owner operating system
you have got a program, so you got an operating system, and if I were in the techie, I wanted
to temper with, for example, the blue program, there are two weights to go about, is I could
take control of the operating system, and then interfere with the blue program, or I could
try to attack the blue program directly from some other program, basically, okay.
In spoke, we partition the memory into three parts, it doesn't need to be this partition
this is just an example partition, you can actually configure this, the first partition
is for the security manager, it's for spoke, and the second part is called the blue prison,
or I'll get into the second part called the blue prison, and the last partition is for the
resource operating system, and in the blue prison we will store the N-claves, and as you can see,
N-claves don't need to be contingent, so one N-clave is the gainingclave has two different parts,
and this is because N-claves exist out of a small entity called the blue-frame, and the blue
free is basically the atomic units in which spoke appropriates, and this is just a piece of
memory, with some permissions for the given N-clave, and also experimental version of spoke,
there aren't in line yet that can share, this was not a small instance now, and each N-clave
can basically have a text section to put an executable code and a section to add data to the data
section, and you can initialize and give N-claves both widths or without data section, okay.
Now, the interested opening system cannot access the security manager, and it can also not access
buffers, so when a software provider wants to actually initialize a new N-clave, it first makes
the secure connection to the infrastructure provider, then to a specific note, and it can then
send to the opening system, the N-clave, it wants to deploy. The interest opening system cannot
access access the buffers and directly, but it can use a sort of system calls to interact with
the security manager in order to actually deploy an N-clave in the buffers zone, basically.
Optionally, you can also place an N-claves instead, and in that case, you can actually deploy
an N-clave to the N-clave, so the interest of the existing system even doesn't get access to the
concrete code of the N-clave, but this is just optional. When our software provider wants to win,
an N-clave, it can just send a signal to the untrusted operating system, and an untrusted
operating system can then pass through the arguments, also can be optionally encrypted to the
concrete N-clave that needs to run it, and the security manager will basically run it,
and it can fully forward the same goes for input-ecting the N-clave, the sold-on by the security
manager. It's kind of an old-looking OS, and of course, the situation is also to the security manager.
Now, N-claves cannot access the code, but they can access their own buffers, okay.
And this is basically accomplished using PMP entries, so when the security manager is running,
it's really a machine mode. It's not only requires machine use modes,
contrary to Keystone, who also requires super-surprise mode, but only uses a machine
use mode. An machine mode is the security manager that oversees the execution of the
buffers or of the N-claves, and all of the untrusted operating system. And basically, when you
make a system call, we will switch back to machine mode, and the security manager will run,
and after it's done, it will switch back to user mode to either an N-clave or the untrusted operating
system, and in user mode, well, you cannot access a password memory, protected by PMP entries,
obviously, so that's how our spoke operates. Okay, then a neat little feature of spoke,
that's not that standard, is that spoke both allows to use relocatable enclaves and fixed enclaves.
So a fixed enclave is basically just an enclave, that is loaded into a fixed part of the memory,
and this is very useful because of a loaf and that is the vices use memory-maps IO.
And for memory-maps IO, you need to be able to load an enclave in a certain part of the memory.
For example, if you have some kind of cooling system and a first enclave control with cooling system,
it needs to be able to write to the memory-maps IO. And to search that, you can basically just
give the evidence with the memory-maps IO, and you can load in the double section of specific
address. And when you test the enclave, it will also attest that the enclave is loaded in a
correct place in memory. Now, sometimes it's more convenient to also allow for enclaves to be relocatable,
and that's why spoke allows both in combination. So you can use first a fixed enclave to
give the enclave access to the memory-maps IO, and also that you can use a second enclave
that uses realocatable codes. And this is shown here. So the first enclave is fixed,
and the second enclave is a realocatable enclave. And there is a little problem with realocatable
enclaves because they do not know where the data section and text section is exactly.
It spoke basically, says that by using a little buffer within the enclaves to pass
across the address of the text and the data section to the enclave. This makes attestation a little
difficult, but they basically treated the same after initialization and there are a few tricks
to get this working without having to keep any extra data about the enclaves.
Now, the last thing I want to mention about secure execution in spoke is that
so how spoke basically works is not yet a enclave always there. They're not
persistent in a sense that they always complete enclave a concrete pmp entry, and enclaves only
exist when they're running. So when spoke switches to the intrusive opening system or to an
over enclave, the enclave really doesn't exist, and it's just only present in the SM state.
And spoke basically, swap out the pmp entries. And this allows for many more enclaves than would
be normally possible with a limited amount of pmp entries. As I said, allows for enclaves to use
different buffers at different times. So it's possible to have an enclave, give it access to
a certain buffer, then introtect the buffer and give the enclave another buffer, it's also possible.
So it can be quite convenient in a lot of situations. Okay. Now, at a station, only one slot
or attestation, I'm just going to give a high level overview of how attestation focuses in spoke.
So spoke works with a key hierarchy that's very similar to the Sanker's key hierarchy,
as the top of the hierarchy you have a note key, that's a key specific to each note and it's just
randomly generated. And we then use a key derivation function, the Kdf over there. To basically
derive a key specific for each software provided when it makes a secure connection through that note.
And after we have a key for the software provided, we can basically make a key for each
enclaves specifically using that enclaves hash. And this key contains all the information we need to
attest the enclaves. In practice, we also give a mince word to prevent ripple attacks with
that's the basic ID of the key hierarchy. Okay. And spoke uses Hacker Star, Hacker Star is a
firmly verified cryptography library, I highly recommend reading the book, it's a really nice
paper. We don't need a lot of Hacker Star, I think spoke only uses some basic hash functions from Hacker
Star. It would also be possible to add additional encryption in spoke. Okay. So,
in practice, this is quite challenging because well, you have to divide the memory between the
code. So, our spoke keeps some internal data structures, I haven't shown here, you need to keep
something called the security manager states in check to make this work. And also,
enabling the different enclaves to communicate back to software provided is quite challenging.
We use a system with defects, with response defects. So, the enclaves can actually write to
parts of the internal operating system. So, it can dispense to the software provided. And again,
this also can be encrypted. And memory management, I've already discussed and there are also some
cryptographic changes with data enabling fixed and relocate more enclaves. Okay. So,
I've also done an evaluation of spoke, I don't think it's put online yet. And today, I'm only going
to discuss the just computing base of spoke. Performance of spoke hasn't been tested,
probably yet because spoke has really ran cameo and testing performance in cameo is a little sketchy
to say the least. So, in memory, you have basically five main parts of spoke here for Hacker Star.
That's basically just a hashing function function utility. You have the security
as some state manager has basically the internal, well, we call it data base of all the enclaves.
And the code surrounding that data base, then I have about 60 kilobytes for PMP dimensions,
which is basically shopping out to PMP entries. And then you have the security measure,
which is just the main part of spoke. And then something called intrusive library.
The intrusive library is not part of the DCB. It's just some utility, I provide to make it
easier to communicate with spoke because this is called to the SM can be quite challenging.
Okay, so this is the future works on spoke. First of all, here's silicon iteration would be
very nice. We've already found a candidate, the SP death kit, C02, spoke only bit us from
in the next year. Some of the verification spoke with us, so we really nice option.
Though it would be challenging because spoke is both written partially in assembly and C.
The nice thing about spoke is that it only relies on PMP. And it has already been updated by
the autos of Keystone, but I found it very fast, risk failed PMP. And Hacker Star is also, of course,
fully firmly verified, but it still will be quite challenging. And availability,
assuring availability is also quite important for spoke because it will, if it's several years
to probably run system that have real time constraints. And this could be fixed by adding a simple
schedule or something more advanced, like the time code system or all keystone. Okay, so in conclusion,
spoke is a mostly software based DE that provides acute execution and adaptation. And it's very
compact, so it can actually run on embedded systems. Okay, that was my presentation, any questions?
Yes, the gentleman in the back.
Okay, speak a bit up. I'm saying that that was very nice work.
Public vacation is a key point because we are talking about systems. So one of the questions that I have
to mention for my presentation is for the works that we need to explain to you, or do you
are interested in it? So is there some code code part that you are trying to find? So you
have to add a station code code, and a station code code? And a station code, oh yes, sorry.
So is there any part of a station code code that you have already been found or are you
planning to be found? Well, also, I have to be the question of course. So the question was,
if I have already verified a part of the attestation protocol, no I have not. So the attestation
protocol is verified in a sense that a heck of stock is basically attestation. All of the
attestation is then using a heck of a stock, and a stock has been formally verified, but
well, there are some steps between a heck of a stock and actually getting the attestation,
and those haven't been formally verified. I'm not quite sure how
form of verification will be done, it's possible, it's a subtle part. It hasn't been formally verified yet,
no. So are you using a MP or a MP MP? No, I'm using a reasonable, some of MP I think.
There is five, I hope, we have data that we have
educational response, and we've added, and you know,
started moving a special approach.
We've got a new service and extension to be in these
calls, TPMP, and we can use it to better isolate
and mode from, you know, because now,
every kind of other route to the NP towards the
access framework, in which case we have, you don't have
access, and it's a key recognition from
member of the system, probably very, very,
it's a problem.
So, however, then you provide access to the
community, and you also provide
access to the NP from that region.
There is isolation to the NP.
At least, I don't have a link.
Yeah, in the package.
Oh, sorry.
The question was, if I use EPMP or PMP,
so to be very close, focus only on KMU right now.
So, it's on Spike, and I think it's actually just
PMP, but it's something to consider for sure,
when I actually implementing this order,
you still can chip to use EPMP instead.
Is KMU got a EPMP?
Yeah. Okay.
Well, something to consider then.
How is this difference from the HX5,
might this own sort of security difference?
Do you happen to know?
Yeah, I do happen to know.
So, how is this difference from the,
I keep forgetting.
I was a different from HX5.
Could you quickly interpret HX5?
Because it's been a while since I've heard the pilot's paper.
The company, but they have a developer approach,
where they also try to have an N-clave-based
solution using sort of purely the machine use
a mode separation as far as I remember.
In their mighty zone approach,
to basically compartmentalize on claims
are the different code regions.
I haven't followed up the work,
so I don't know what happened to it.
Probably it's not as popular as one my team,
but maybe there are some shortcomings,
but that's why it was possible.
I actually think, well,
I think I took some inspiration from some of that,
so the similarity you've seen won't be coincidental.
I've fully got HX5.
If I remember correctly,
as another AEMS,
this is not aimed at embedded devices,
HX5.
So, Spook is really also aimed at embedded devices,
and HX5 has a much larger to suit computing-based,
and I don't think it's suitable for most risk-free
the device.
I might be wrong.
But this is also not a microcontroller type of thing.
It's not low end,
this is also like the embedded line of space, right?
It's a handy low end.
There's no virtual memory, so you won't be able to implement it.
No.
Okay.
Non-batch memory, but memory protection unit.
PMP.
All right.
So, you took it out in memory map.
I know,
and you're over there lying on a plane.
It's not essentially restricted.
And it device to any being in one plane.
Okay.
So, he asked if I'm using the memory map title,
and your question was,
if it only sticks to the memory map title,
or being in one end-clave,
and it is not.
Because you can still have multiple data sections over the end-mile.
Every part of the end-mile specifically is for one end-clave.
And this can be a bit challenging,
because in some cases you do not multiple end-claves
to have control over the same part of the end-mile.
But this also can be said that you're spitting parts of the end-tracing system over the end-mile.
And I'm living in an end-clave,
and I'm going to respond to the end-tracing system,
and then the drift drift operating system actually do the end-mile for the end-clave.
Now, as I've said,
there is already an experimental range of spook,
who plays around with this idea of having shared spooks,
for exactly that purpose.
So it's a very good question.
But right now,
it's possible that moving the sense that you can have two end-claves
with the same data section that's also protected
over the same part of the memory map title.
Thank you.
Last question.
Thank you.
Did you already have done an disintegration with any real operating system?
With any real operating system,
I have, I've remembered only one time.
Okay.
So no, spook hasn't been integrated properly with any real operating systems,
because in practice this won't also,
this won't be Linux or any operating system,
it will be probably a very tasty specific operating system
for that chip,
because these are embedded systems.
So the operating system,
we don't really look at it,
because it's also,
well, it's, it's the F-X-S-E,
in all of my research.
So we don't rely on it,
but it would be interesting,
because you could compare the performance,
give an,
a certain operating system,
give a certain task,
and compare it to all the operating systems,
and compare them.
So I think that would be a very interesting.
All right.
Let's say this speaker.
Thank you.