The high everyone, we are Ivan and Katsya from Gupta Deepmine and the topic of today's
talk will be a test of noise protocol, a test of noise protocol for low to CBE, trusted
execution environments and the agenda will be as following. First we will tell you about our
specific use case and why we decided to use the noise protocol and in the rest of the
talk we will tell you how exactly we are binding together the remote attestation and
the noise encryption protocol. But to start with our use case which is project talk and this
is a research project aimed to make it possible for users to reason about how the data is
used by the server site and it should provide hardware guarantees and must be verified
well by external reviewers. And we achieved this by using several building blocks and the
first one is trust execution environments which means that oak is a framework to build
applications on top of trust execution environments and because we wanted to be reviewed
by external reviewers we are trying to make the job of reviewing as easy as possible by
reducing the CBE so that the CBE should be minimal and in addition we are also using several
unboxing techniques and we use restricted environments. The next building block is remote attestation
and here it's important to note that the verification for the remote attestation evidence
is done on the client device so we are not using any verification service that crosses the
attestation results to the client and in addition we try to provide the complete view of the
whole server payload to the client device. And thirdly we employ transparency which means that
the project is open source and it's reproducibly buildable which means that if you review the
code you can compile it yourself and you compile it into the same exact binary as the
run on the server site and when you perform remote attestation you can compare the hashes
you received from the server with the hashes that you reviewed yourself which makes remote attestation
meaningful because you are not just receiving a set of hashes you can connect those hashes
to the open source code. And lastly we also employ binary transparency by publishing all of the
binaries that we serve on the server site in the external app and only on affordable transparency
log. And this is done to prevent malicious inciders from creating targeted attacks on specific
users so that when we use a connect to the server they know that they connect to the same
exact binary that everyone else connects to because as part of the remote attestation we
are also providing the inclusion proofs for the transparency logs so I previously mentioned
that we try to reduce the TCP and in doing so we have implemented our own custom minimalistic
firmware and operating system kernel written and Rust and the idea is that firmware it provides
features of V bias plus bootloader and firmware is the thing that is generally measured by the
hardware as part of remote attestation. And on top of this we have what we call the restricted
kernel which is a custom Rust operating system kernel which provides a bare minimum set of features
necessary to run our payloads which means that we have minimal Cisco interface we only have single
thread and the main feature of restricted kernel is that we cannot have an attested executable pages.
So the problem that we saw with running general Linux inside the TE is that the attestation the measurement
that you get in attestation is the initial stage of the VM boot and after the VM has booted if the
is Linux it can change, it can start new processes, it can create new executable pages and this is problematic
because the attestation may no longer be valid when you yourself connect to the VM and this is why we
restrict this in such a way so that when you connect to the VM this measurement stays valid and yeah I
previously mentioned that we tried to provide the complete view of the server workload and this is
done by employing the device identifier composition engine or dice and the idea behind dice is that
the initial measurement that you get from hardware measures the firmware and you get a certificate for the
hardware measurement but you also need to provide the measurements for all of the components that you have
loaded into the VM so what we do is we use firmware to measure and sign the kernel and added to the
certificate chain and the same is done for the trusted application that is loaded afterwards so what we end up with
is a certificate chain that contains all of the measurement for every single component that is loaded into the
VM memory and because we were trying to minimize the TCB we had a goal of creating a crypto protocol which
will be minimalistic and we wanted it to have the ability to be bound together with remote attestation
and because we already use remote attestation technically we didn't need to have PTI and even
certificates and basically what we're trying to do is we remove the features that we don't necessarily
need in order to minimize the TCB and an additional goal was to minimize the amount of parsers so we
didn't want to have a protocol that requires you to use certain message formats for example because
the more parsers you have in the codebase the more code reviewers have to look very carefully because
more parsers means more places where you have malicious user input and because we like Rust very much
we also wanted to have a Rust only implementation so what we ended up with is the noise protocol
framework and I will give this presentation to Katia who will tell you more about how it works
thanks a bunch can people in the back here me perfect so that's a perfect moment
to admit that we like there is no noise protocol what the risk is a noise protocol framework
so noise is a framework for designing minimalistic cryptographic protocols which are all directly
based on the health and key agreement so the protocol doesn't assume the existence of certificates
there is no PKI nobody guarantees anything you just directly run the development on a bunch of
keys also all these protocols are defined in the byte format so we don't make it doesn't
make any assumptions about what the wire format is it just specifies bytes which should make
close place for implementation really easy at least in theory noise protocols optionally
include authentication but it's not an necessary feature but it is a one that we can make some
use of so let's take a look at noise protocol framework in modules so each noise protocol begins with
the handshake and the handshakes are classified into patterns based on the keys that are used
within the handshake to establish the shared symmetric key the keys can be a femoral so they
are created specifically for each new session and for most noise patterns even if you do have
static keys a femoral keys are still used why because it's helpful to prevent the replay attacks
but if you do have static keys then you can also include them in the handshake and that's how
authentication can be provided static keys can be either pre shared between the patches if you do have
a PKI or also or some other way to distribute the keys but some noise patterns support
exchanging the static keys during the handshake and all noise patterns can with formal proofs for
some confidentiality and authentication guarantees so there is this really fun tool which I would
encourage anyone interested to go and play with that helps you get acquainted with different
noise patterns and for each patterns tells you exactly what guarantees you can get after sending
each of the messages in the handshake because noise supports including payloads with its handshake
messages but of course if the handshake has not yet complete security guarantees will be weaker
you can see exactly how so let's take a look at one particular example of the noise protocol
so in this scenario both parties have static keys which they have already exchanged during the
period so now both parties have the keys and the orange arrows through the noise handshake itself
so in a shayt are sense it's a femoral key and also the result of defeat helmet calculations between
it's a femoral key and the static key of the other party and also a GIFI helmet computation
based on its static key and the static key of the other party both parties maintain the local
state and there are rules how the state is updated after each message so that's what responder
does when it receives the message and it sends back its femoral key and differential months based on its
femoral key and the keys and then you shayt are keys so that it has received in the previous step
so now both parties can take the local state and use it to produce two symmetric keys
one which will be used to encrypt the outgoing traffic and another one which will be used to
decrypt the incoming one the dephatinetic month behind that is all in the noise specification
but let's see how this protocol changes if one of the party doesn't have a static key anymore
so now we need shayt are doesn't have the static key it only uses an femoral key for the handshake
so but it's still somehow gets the static key of the responder now in the initial
term message there is still it's a femoral key but only the DIFI helmet based only the femoral key
and the static key of the responder and same goes for the responder messages but as you can see
the drastically it will still include DIFI helmets on all key pairs that are actually involved
in the handshake and in the end both parties still get their shayt symmetric keys
now let's take the static key from the equation and what we get is basically just DIFI helmet
key changed based on two femoral keys so what you can see from here is that noise
protocol framework is really modular you are not obliged to implement each and every pattern
you can pick what you need so this is the minimalistic cryptographic protocol that we
wanted to take and bind it with our own attestation what it allows us to do it allows us to make
that estation a separate step and use noise absolutely without modifications because again
noise comes with this nice formal security proof we don't want to mess with that we also wanted
to support bidirectional attestation and as a nice feature it would be cool if we could also
support multiple attestations so that's what we did let's that's from the Unity
actual attestation phase so attestation will be a separate step performed technically
before the handshake but the reason why I wasn't sure answering the same question about whether
we are pre-opposed handshake is that in the ideal world we could just run attestation super cheaply
it would be super cool to run attestation over the cryptographic material directly from
the handshake after the handshake and bind the through together in this way but we are not in
the perfect world attestation is costly so also not all varieties of attestation that we use
allow us to run it over the arbitrary material that we would need for this case so
instead is we make sure that the evident that is the evident that we get contains binding key
and we use this binding key to sign the noise handshake which by the way is a part of the
noise specification so it's not something that we have invented it is specified that
implementations of noise should make the handshake available through the clients specifically for
this purpose which is for channel binding so we just take it and sign the handshake plus some other
metadata of security and that's how we create the attestate secure channel this can be easily
generalized for the bidirectional attestation so now both parties provide evidence evidence still
contains the binding key both parties use this binding key to sign the handshake hair
the only thing that will be needed is another message from the initiator to the responder
and generalization from multiple attestation is also trivial just include a bunch of
signatures in the final message of the handshake so that's what noise gives us a really small
implementation noise itself is less than 1,000 lines of code this decay that we created for the
attestation binding is a bit more but that's mostly because it's very configurable it's all configuration
and we only need a small subset of creeps functions in order to make the total work we don't need
additional parsers and we don't need to use PKI if we don't have one but it's a custom solution
everyone hates custom solutions as to what is what practical for us you know some contrast to
it's a standard and well accepted solution has a lot of features so basically everything that we could think
of would be covered by some extension of TLS but the main problem in the natural voice that
making TLS work in restricted kernel without the limitations that you want to describe
it's probably draw a ball but hard so at the moment restricted kernel doesn't support
trading it's written and rest so we need a C++ bindings that entails the use of the STD
which we wanted to avoid and it was a pretty huge so what we like about our solution is that
allowed us to focus on what we wanted to focus first which was a testation and just
gave us a really minimal solution to plug the gap that we needed to have plug and so back to you
yeah so in the end we had a very specific use case in which we wanted to minimize the TCP
to make a reviewer's job easier and we wanted to have a very minimalistic crypto protocol to support
our remote attestation and we ended up with choosing noise protocol framework picking a
pattern implementing it and creating an SDK that allows us to bind remote attestation to our
crypto protocol and all of the implementation is open source you can check it on GitHub and the first
link is our project which contains multiple use case not only the one that I talked previously
this is specifically noise implementation and this is a SDK for attestation binding
so that's pretty much it for the talk thanks everyone for listening please feel free to ask any questions
I think we have a first question here
so the question was can we build firmware ourselves and the restricted kernel so the idea was that
we wanted to split it into two parts we wanted to have a very very minimalistic firmware
because it's not only for a restricted kernel we have other use cases where we use the same firmware
but for example load Linux and like load containers on top of it so this is why we wanted to have
this build as a module it is open source yeah everything is open source you can find the
firmware is called stage zero and it's here you can find it and build it yes yes exactly
we don't need to use you
I'm absolutely agree.
I'm a photographer, I was wondering why he didn't change the nonsense.
If a model works as a model, it helps to protect for deploy attacks.
Further, for the encrypted messages, nonsense are used and they are obligatory for the,
but this is specified by the protocol.
I think it's part of no specification that it is, I'm suppose, the question is,
whether the Femeral Key is a sufficient substitute for nons and where it comes from.
So, in our implementation, it is generated specifically for each session, and it's not coming from the verifier.
You need to verify it to demonstrate the fraction of the evidence.
Yeah, so it's definitely not how we demonstrate the fraction of evidence.
I think for the fraction of the evidence, if one will be with us.
So, yeah, the freshness is only provided by the evidence itself by the certificates that we include in the evidence.
So, for example, I previously mentioned that we have transparency, lot of conclusion proofs, and they have expiration dates.
And this is the main reason, how we, this is the main implementation of freshness for the evidence itself.
Yeah, as for the nonsus in the noise protocol, the handshake contains the femoral keys,
but then when the protocol starts and when the handshake is finished, we then check that it's actually bound to the evidence,
and then there are nonsus in the ASGC and protocol that the client and server connect to.
Yeah, we have a key. Yes, yes.
So, I think that this is the key.
I think that this is the key.
Yeah.
So, the question was that the confusion comes from the freshness for the verifier all for the relaying party.
Yeah, in our case, the relaying party and the verifier is the same thing. It's the client.
Yeah, they both on the device.
Yeah.
The question was, where was the measurement in the device?
Yeah, the question was, where was the measurement in the device?