Okay, good morning, everyone, thank you for attending this talk, so today I'm going to present
you all about our work here that the title is actually TC4SE is called trusted channel
for secure on-clave, but basically the whole idea is like the title that I gave in the
false-dem talks, like building like a more high-performance trusted channel for secure on-clave.
So this is basically like a work that I've been doing, I mean like that I did and published
about almost one and a half years ago, and it's already published, but I'm going to
represent here because it is also relevant to the work about attestation and also like
the work itself is publicly available as a source code and also the paper that you can
also obtain if you're more interested in how I'm doing with the work.
So I'm going to start about talking in here, what is the trusted channel in this case,
like I'm trying to borrow the definition from from GASMIA at all about the trusted channel,
basically trusted channel is a secure channel where the trust works, you know, is bound
into the configuration of the endpoints, and that basically in here what our work as well
is that we're trying to focus more on where the trust lies, not on the directly on the
protocol itself, but what are the trust that underlying that underlies the protocol itself,
like in here like if we have to separate machines like machine A and machine B, basically
like the TLS endpoint in here like we'll terminate inside an application and the TLS
is the trust is gained from the private key that is owned by a certain machines and is
verified by a certificate also, some certificate authority where the both machine shoot
trust.
So therefore when the communication and the authentication happens, when each other wants
to authenticate each other, they rely on the trust that they have to disinfectate authority
to establish that that is the valid trusted party that they want to communicate.
So basically the trust boundary in here in the baseline of the TLS channel, basically on
the machines on each machines and on the certificate authority itself.
So from this actually and on our work as well with NLSGX, it comes into the initial questions.
How actually if we want to establish a trusted channel, if we want to build a trusted
communication channel between two separate secure on-clave that is separated by machines,
they actually shoot with terminates the endpoint.
So basically the endpoint should terminate inside the on-clave binary.
If we see from the previous slides the TLS terminates in the application for the application
for the process based on-clave like we found earlier already talk about, basically you
have to terminate the TLS inside the on-clave because that's where actually the cryptographic
and the private parts of the trusted channel will be stored.
So therefore like the end-point should terminate inside the on-clave.
And then how can actually we verify the trusted channel that is, I mean like that is established
by the rightful trusted execution.
So of course in here that we can use a station to prove that the trusted channel is created
by an actual on-clave that is running on a machine that has a T capability in this case
in TLS GX and at the same time actually how to mutually identify each other to achieve
full trust on the trusted channel.
In here we want to attach actually the trust from the trusted channel from the baseline
of the TLS using the attestation.
So actually from the workshop on the Friday actually I also found out that there is a
terminology that I can borrow basically that we perform a T attestation on the T that
is being used for establishing the TLS the on-clave and continuing to that I'm going to
talk a little bit about what is the trust behind the Intel Dcap.
Earlier that Usama already gave an introduction about the Intel Dcap and like there are
attestation specifically for Intel SGX that is Intel APT and Intel Dcap.
So APT is already mentioned as well as already kind of deprecated because Intel gave
more in favor to use Dcap.
So basically this is going forward if you want to establish or use attestation in Intel
SGX or TDX you should you have to use this kind of mechanism.
So in here I'm going to I'm providing you the diagram what is the trust in the underlying
of the Dcap mechanism.
So in the Dcap there is a several enclaves in here which is basically the called I think
infrastructure on-clave or that is important to produce the quotes or basically the attestation
and also like to verify the quotes and also to establish like to obtain what they call the
PC case certificates.
So the trust on the underlying Intel Dcap basically lies from the hardware key that is
that Intel said basically we have to trust Intel in here.
So Intel actually guaranteed that it is installed during the manufacturing process of
the processor so basically it is a hardware-based key and then they derived into the platform
profitioning ID which is basically to identify that it is a valid Intel machine that has
SGX.
Intel basically store this PPI and can use that to identify when using this certification platform
certification on-clave they will generate some and creep the PPI in here and they will
send into Intel PCS server Intel PCS basically a surface by Intel that they will actually
process the PCP ID as a PCK request and then they will generate the PCK certificate which
will be basically similar in like for example in TPM there is endorsement key and endorsement
certificate and Intel PCK certificate is roughly like behaves in a similar way because
they can be used to actually sort like a verify the trust when we are very fine the quotes
that we receive from Intel SGX on-clave and on the same time the hardware key is also used
to derive the root ceiling key which is actually to be used to do for the to generate the
apostation key so all the apostation will actually be signed by this apostation key and
then like it is also derived from the owner epoch basically like some random random number
that is stored in the platform that when you profission the machine for the first time so
basically it kind of gives like an on-limity in the sense basically if you want to to to
reprofission your machines you only need to reset the owner epoch because like you cannot
reset the hardware key because hardware key you always be the same but you want to reset that
because you want to reinstall the machine for example you reset this owner epoch and then like
all the underlying attestation will have a different values because now the root ceiling
key will be different and then the interns like the apostation key will also be different and
then the apostation itself basically it will carry the information from the on-clave measurement
which is MR on-clave which is the hash of the on-clave binaries and also the MR signer which
is the signature of who also the on-clave the creator of the on-clave apart from that we can attach
an authenticated data I think there are some like maybe 40 bytes or something that you can
attach as part of of the quotes and then these quotes will be signed by the quoting on-clave
in here and then the verification can happen by the remote part that they verify that because the
PCK certificate is also attached in here they can verify that if the PCK certificate
has the root of trust into the Intel SGX to the CA because that's how they verify the trust
in the Intel DCAP so going from this basically what is the state of the art that we have there
is the Intel RATLS the one that also have been mentioned a lot basically this is the one that is
proposed by Intel and there are some other work by in here by by Arto Niemie and the
and teams about the trusted socket layer which is the they similarly using attestation in here
but they don't they don't abandon the the the certificate authority if they are using like
PKI infrastructure because in the Intel attestation in here in Intel RATLS they don't
basically use use PKI because they only use basically a self-science certificate the keys
generated inside the on-clave yeah it's generated securely but basically they don't use
PKI mechanism they only use the X5 on-clave certificate as the container of the quotes
so quote verification happens during the handshake like a U-sum already mentioned there is like
like like a pre handshake in the in-tra handshake and post handshake
basically the verification of the RATLS happens in the handshake but the generation of the quotes
happens on the beforehand because it is only happened when when you're initiating the on-clave
for the first time while meanwhile for the trusted socket channel also that is not necessarily
for Intel SGX but basically like it can be applied as well in Intel SGX and then like in this team
basically they quotes the TLS parameters like like for example like the I think like the DC Helman
materials or something like that for for the KX chain and then use that as an attestation so
therefore like the TLS also have the the attestation what do you call like like the
attestation properties so that's basically those two two two what do you call two schemes
that we also evaluate in here and then we identified certain limitations in here one of
them is that dependency on the attestation infrastructure if we actually already see earlier that
the verification like in the decab that you also actually requires to connect into Intel infrastructure
to perform the verification because the one that I haven't mentioned in the previous diagram is how
you perform verification the verification of Intel decab for example the required collateral
can only be obtained from Intel PCS server or if you install what they call a PCCS so they
kind of PC like platform certification cash in service so basically you install a some kind of server
I think like I think it's their reference implementation is not GS server that kind of cash
the request from your machines to PCS so therefore like whenever you request for for for for for
for for for the collateral data for the verification they don't have to spam Intel server so
that's why the like for example I believe that the Azure certification and stuff like that
basically implementing those patterns because like Intel doesn't want everyone just to directly
like spam their server to obtain those data because like if you perform attestation in a more like
like a like a periodic manner I mean basically you can spam Intel has to provide those computing
power and I think that's the one that they want to avoid so they kind of but still like there is a
dependency in here that you have to connect into those PCS or PCCS server and basically if you
depend on building trust a channel into that system if you if adversary basically severe that connection
you cannot establish and trust a channel between on-trace you cannot verify because the verification one of the
verification the verifiers I mean it's unavailable so it can be like one of the like one of the factor
that can potential to be an attack surface another another like issues that we found out is like
performance and also implementation complexity especially if you want to attach
in the parts of inside inside the handshake like the one that that I mentioned the trusted socket layer
implementation that they try to use like the key material for the key exchange as part of the one
used for the attestation so basically they are quoting like the key material for the key exchange
if they I mean like it's quite difficult actually to implement that directly in open SSL so one of our
one of our like goal when when I was doing this research was how easy it would be implemented I mean
it's not that easy to get those information directly from open SSL unless that you actually
like dig down directly into the source code because there's no direct interface to do that
and then the other thing is that also the trust chain and a boundary and especially like if you
like in the intel area TLS they doesn't even have any like a trust like into the into the
root CA certificate so basically you kind of like disregard all the trust chain that it has I mean
like you cannot simply like for example you receive like a certificate from a proper certificate
authority for example less than creep or something like that and you cannot use that in power
together with the attestation so that's why in here that we try to simplify we propose
this what what what we call that TC4S is or like an implementation of a trust channel for secure
on-clave basically to simplify by by by by directing which part that you can trust and which part
that that that you can actually assume based on the protection model of the Intel SGX in here
like I kind of give you like the comparison between the RTLS TLS and TC4S E we try to do a lot of
stuff like in the initial setup even like from the T generation code generation and
verification from the initial setup so therefore during the TLS handshake I mean we don't really
have to do a lot of like like like like like a like a code generation and certification during
when we want to establish a trust channel so from the from the from the design from the trust design
perspective basically this is how it works so in case that we have two machines assume that machine
A will acts as a server that will have like the basically the the main route of trust
basically yeah like we we create a certificate like similar in the RTLS basically create a self
science certificate but then to to let machine B to trust machine A they have to transfer and
then attest that certificate and then the machine B has to has to store the the the trust
that certificate in the trust that certificate store so basically it acts as like like a CA store
like in our operating system but again in the Intel SGX threat model you don't really trust the
operating system itself so you have to store your certificate directly so in here you have your
internal trusted certificate store that you use to actually verify the the certificate later on when
you establish a TLS channel and then on the other hand to let the machine A trust machine B
machine B has to prove themselves by building a CSR from their certificate from their from the
private T and then their CSR has to be quoted I mean like to pass through the at a station
from the SGX and pass into the machine A where machine A will then sign the certificate and
give back into machine B so therefore like machine A machine B can communicate using mutual
mutual authentication like MTLS and then like the the trust can be achieved by like like like the
the certificate the private key of the machine B is actually signed by machine A so and then like
because machine A knows it is actually from them the private keys only stored by them so basically
you're achieving the full trust that a machine B is recognized by machine A and then basically continuing
without having to to repeat that the station when you want to establish the the trust channel
on the next step and in here basically like I'm I'm I'm showing more like the diagrams on
how you establish the the T I mean like to establish the trust like initially like to generate
the the self-science certificate and then build the CSR and then like a perform the at a station
in here generate the at a station in here and then they're exchanging each other and verify each other
and then while the client machine will seal the certificate in their internal trusted store
and then the server machines will sign the certificate signed the CSR and then give back
into the client machines so the client machines can actually use that for the mutual authentication
and finally like we perform some evaluations in here that we kind of see like like
from the network load and also the the time that requires to initiate a channel this mechanism
outperforms other mechanism that performs forifications and at a station verification and
generations during the handshaking like the RTLS and the TSL scheme so therefore like basically
you can you can carry all of the operations regarding at a station in the initial setup
and like during the channel initiation initiation when you're established the TLS channel you
don't have to repeat the at a station but you still have the same trust because the T is generated
inside the on-clave SGX provides the guarantee that the T I mean like if you seal the T I mean only
that on-clave on that machine can unseal the T so therefore it cannot be moved it cannot be migrated
into another machines and then like the trust will still be established I mean the at a station
trust is still there so the challenge that we have in here basically yeah the one in TC4S
if we provide the reference implementation in here that that basically you can follow and it is the
one that is we open source and you can just adapt if you want to have similar scenario you can just
adapt using this scheme and for airtight scenario it is also possible to strip down the intel
decap architecture and infrastructure basically I mentioned earlier that you have to installed
some not GS server and stuff like that we can kind of actually eliminate that and manually
contact intel PCS server obtain our collateral and PCK certificate or self at install into our
on-clave without having to use those type of setup so in in some cases if you want to implement
some kind of airtight scenario you can actually achieve that as well and also this scenario
may also be applied in the on-clave container solutions or even like possibly TDX because like
TDS also use decap so I think they only have a little bit differences in what they are
quoting but this kind of scheme can also be applied in there so finally to conclude basically
this is an attempt to simplify establishing a trosset channel between two remote enclaves
and then basically we leverage the existing TLS protocol without modifying the protocol or even the
handshake itself and then we link the security properties of the PKI of the TLS into the intel intel
decap intel SGX route of trust and then we try to compare qualitatively compare the proposed approach
that it is also a part of the source code so if you if you go into the into the repository you
will also have the example that we try to build the RATLS and also the TSL scheme that we discussed
earlier and basically after after the discussion that we have last Friday I also realized that
now there is the CSR attestation draft that basically performs almost similarly in my opinion and
then that we want to use that for attest the TLS scheme so it's kind of like some similar there
some similarities in that sense so I guess that's it and then that's the link if you want to look
out for more and you can also you can also see the fourth damage for the link into the paper if you
want to see a little bit more details okay thank you very much so if you have any questions we have
about five minutes yeah I guess
okay so the first question is is that how how different it is with the RATLS and then like
the second question is how to maintain the the freshness so the first question the differences
in the RATLS in here is that RATLS doesn't have those like certificate store in there and
basically in RATLS they use the private the private key they generated in the marketplace as
FML so they don't store they don't seal the key I mean it's possible to seal the key but then
I mean they also but one of the point in here is that the verification so typically also happen
during the the establishment of the trust the channel because they don't store the key of each
other so therefore like that's the one that we try to leverage in in the scheme because we have
the certificate store so the and then we retain that certificate store and seal the key as well so
whenever you reboot the uncleaf or there is a power state or stuff like that the trust is still there
and then for the second part about the freshness yeah this is also the questions a lot
like that we that we receive the thing is that Intel at the station actually doesn't
provide any means about freshness if we see this the quote data only give you i'm around
cliff mn signer and some informations about the about the the SGXT CD actually in the in the
collateral that I mentioned you earlier like for example like the I think there is like a
like a software version or something like that that's the only thing that they carry
in the certificate there is no non there is no time and then the other problems actually with Intel
SGXT is that especially in SGX in TDX maybe is a little bit a little bit soft in Intel SGX
basically there's no notion of trust the time so you cannot actually like establish like when is
it created or how fresh it is so that's actually indeed a challenge so for the freshness
this doesn't really solve any replay attack because yeah Intel SGX like Intel D cap and the
at the station they don't provide such thing it's quite different with a TPM at the station
because they do have like at least like their own time counter and then they do have like monotonic
counter internally but Intel SGX they don't have that I mean they did have that but they erased
completely something yeah the question you can inject some user data yeah in this in the
authenticated data itself that's how you inject the data and then that will be part of the quote
itself because the signature of the quote will include the authenticated data so that's actually
where you put the CSR as well so therefore like the CSR can be verified using the the signature
of the quotes yes you can yes you can
I would say not the problem with the details but rather the way that are it's political
itself but yes indeed I mean we can use those nons but the thing is that if you want to see
the freshness in terms of for example in the time frame I mean it's impossible because like you
cannot even store which nons that you have been using for example and then like you can just
repeat the nons when you restart the unpack if you don't store the nons and then like if you
for example you store the on-clave and then seal the data and then the on-clave is rebooted
with the with the nons that is previously has been used but then they replay that I mean
that's the I mean like you can still reuse the nons and then repeat the same stuff because I mean
the freshness in here like for example that you want to achieve is that when are you going to
to to expire of the certificate for example because like in x549 certificate there is like
expiration or something like that this is a problem in tell us just because we cannot really do that
in a sense that the SGX on-clave can aware that this is the this is my current time securely
in a secure manner because there is no notion of a trust of time so for the sense of that freshness
I think that's kind of the difficult stuff that you have to do with SGX yes indeed
can you repeat again yes so the question is that do you verify the m around-clave and
an mr scanner yes during the during the steps that I mentioned earlier in one of the slides
basically that's the part the basically the on-clave should verify because that's how you know
the identity of whom on which on-clave that you're talking to so basically yeah there will that
will be the part of the verification itself as already this coming from a proper the on-clave
that you want to talk to or not because like the identity in here that the Intel attestation gives
is only the identity of the on-clave and the signer typically the signer part is the one that
may be you're more interested because then you know this is the on-clave the idea for something
like that okay thank you