WEBVTT 00:00.000 --> 00:24.360 The high everyone, we are Ivan and Katsya from Gupta Deepmine and the topic of today's 00:24.360 --> 00:30.720 talk will be a test of noise protocol, a test of noise protocol for low to CBE, trusted 00:30.720 --> 00:38.440 execution environments and the agenda will be as following. First we will tell you about our 00:38.440 --> 00:45.400 specific use case and why we decided to use the noise protocol and in the rest of the 00:45.400 --> 00:50.800 talk we will tell you how exactly we are binding together the remote attestation and 00:50.800 --> 00:59.160 the noise encryption protocol. But to start with our use case which is project talk and this 00:59.160 --> 01:05.600 is a research project aimed to make it possible for users to reason about how the data is 01:05.600 --> 01:11.680 used by the server site and it should provide hardware guarantees and must be verified 01:11.680 --> 01:17.880 well by external reviewers. And we achieved this by using several building blocks and the 01:17.880 --> 01:25.360 first one is trust execution environments which means that oak is a framework to build 01:25.360 --> 01:31.440 applications on top of trust execution environments and because we wanted to be reviewed 01:31.440 --> 01:37.520 by external reviewers we are trying to make the job of reviewing as easy as possible by 01:37.520 --> 01:43.840 reducing the CBE so that the CBE should be minimal and in addition we are also using several 01:43.840 --> 01:50.480 unboxing techniques and we use restricted environments. The next building block is remote attestation 01:50.480 --> 01:56.040 and here it's important to note that the verification for the remote attestation evidence 01:56.040 --> 02:02.760 is done on the client device so we are not using any verification service that crosses the 02:02.760 --> 02:09.680 attestation results to the client and in addition we try to provide the complete view of the 02:09.680 --> 02:18.240 whole server payload to the client device. And thirdly we employ transparency which means that 02:18.240 --> 02:24.840 the project is open source and it's reproducibly buildable which means that if you review the 02:24.840 --> 02:31.080 code you can compile it yourself and you compile it into the same exact binary as the 02:31.080 --> 02:37.320 run on the server site and when you perform remote attestation you can compare the hashes 02:37.360 --> 02:44.360 you received from the server with the hashes that you reviewed yourself which makes remote attestation 02:44.360 --> 02:49.640 meaningful because you are not just receiving a set of hashes you can connect those hashes 02:49.640 --> 02:57.640 to the open source code. And lastly we also employ binary transparency by publishing all of the 02:57.640 --> 03:04.560 binaries that we serve on the server site in the external app and only on affordable transparency 03:04.560 --> 03:11.400 log. And this is done to prevent malicious inciders from creating targeted attacks on specific 03:11.400 --> 03:17.840 users so that when we use a connect to the server they know that they connect to the same 03:17.840 --> 03:24.560 exact binary that everyone else connects to because as part of the remote attestation we 03:24.560 --> 03:34.200 are also providing the inclusion proofs for the transparency logs so I previously mentioned 03:34.200 --> 03:41.840 that we try to reduce the TCP and in doing so we have implemented our own custom minimalistic 03:41.840 --> 03:50.160 firmware and operating system kernel written and Rust and the idea is that firmware it provides 03:50.160 --> 03:56.280 features of V bias plus bootloader and firmware is the thing that is generally measured by the 03:56.280 --> 04:02.400 hardware as part of remote attestation. And on top of this we have what we call the restricted 04:02.400 --> 04:10.800 kernel which is a custom Rust operating system kernel which provides a bare minimum set of features 04:10.800 --> 04:17.600 necessary to run our payloads which means that we have minimal Cisco interface we only have single 04:17.600 --> 04:25.040 thread and the main feature of restricted kernel is that we cannot have an attested executable pages. 04:26.040 --> 04:34.280 So the problem that we saw with running general Linux inside the TE is that the attestation the measurement 04:34.280 --> 04:42.200 that you get in attestation is the initial stage of the VM boot and after the VM has booted if the 04:42.200 --> 04:49.280 is Linux it can change, it can start new processes, it can create new executable pages and this is problematic 04:49.280 --> 04:56.640 because the attestation may no longer be valid when you yourself connect to the VM and this is why we 04:56.640 --> 05:06.800 restrict this in such a way so that when you connect to the VM this measurement stays valid and yeah I 05:06.800 --> 05:14.000 previously mentioned that we tried to provide the complete view of the server workload and this is 05:14.000 --> 05:21.360 done by employing the device identifier composition engine or dice and the idea behind dice is that 05:22.000 --> 05:28.400 the initial measurement that you get from hardware measures the firmware and you get a certificate for the 05:28.400 --> 05:34.560 hardware measurement but you also need to provide the measurements for all of the components that you have 05:34.560 --> 05:42.400 loaded into the VM so what we do is we use firmware to measure and sign the kernel and added to the 05:42.400 --> 05:48.960 certificate chain and the same is done for the trusted application that is loaded afterwards so what we end up with 05:48.960 --> 05:55.760 is a certificate chain that contains all of the measurement for every single component that is loaded into the 05:55.760 --> 06:07.520 VM memory and because we were trying to minimize the TCB we had a goal of creating a crypto protocol which 06:07.600 --> 06:16.160 will be minimalistic and we wanted it to have the ability to be bound together with remote attestation 06:16.960 --> 06:24.560 and because we already use remote attestation technically we didn't need to have PTI and even 06:24.560 --> 06:30.960 certificates and basically what we're trying to do is we remove the features that we don't necessarily 06:31.520 --> 06:38.080 need in order to minimize the TCB and an additional goal was to minimize the amount of parsers so we 06:38.080 --> 06:44.480 didn't want to have a protocol that requires you to use certain message formats for example because 06:44.480 --> 06:52.480 the more parsers you have in the codebase the more code reviewers have to look very carefully because 06:52.480 --> 06:59.440 more parsers means more places where you have malicious user input and because we like Rust very much 06:59.520 --> 07:06.240 we also wanted to have a Rust only implementation so what we ended up with is the noise protocol 07:06.240 --> 07:11.040 framework and I will give this presentation to Katia who will tell you more about how it works 07:17.600 --> 07:26.960 thanks a bunch can people in the back here me perfect so that's a perfect moment 07:26.960 --> 07:34.720 to admit that we like there is no noise protocol what the risk is a noise protocol framework 07:34.720 --> 07:40.720 so noise is a framework for designing minimalistic cryptographic protocols which are all directly 07:40.720 --> 07:48.080 based on the health and key agreement so the protocol doesn't assume the existence of certificates 07:48.080 --> 07:56.080 there is no PKI nobody guarantees anything you just directly run the development on a bunch of 07:56.240 --> 08:06.400 keys also all these protocols are defined in the byte format so we don't make it doesn't 08:06.400 --> 08:14.080 make any assumptions about what the wire format is it just specifies bytes which should make 08:14.160 --> 08:22.480 close place for implementation really easy at least in theory noise protocols optionally 08:24.320 --> 08:34.560 include authentication but it's not an necessary feature but it is a one that we can make some 08:34.560 --> 08:46.160 use of so let's take a look at noise protocol framework in modules so each noise protocol begins with 08:46.160 --> 08:53.840 the handshake and the handshakes are classified into patterns based on the keys that are used 08:53.840 --> 09:03.040 within the handshake to establish the shared symmetric key the keys can be a femoral so they 09:03.600 --> 09:13.520 are created specifically for each new session and for most noise patterns even if you do have 09:13.520 --> 09:20.640 static keys a femoral keys are still used why because it's helpful to prevent the replay attacks 09:22.400 --> 09:29.200 but if you do have static keys then you can also include them in the handshake and that's how 09:29.200 --> 09:36.480 authentication can be provided static keys can be either pre shared between the patches if you do have 09:36.480 --> 09:44.480 a PKI or also or some other way to distribute the keys but some noise patterns support 09:45.360 --> 09:54.240 exchanging the static keys during the handshake and all noise patterns can with formal proofs for 09:54.240 --> 10:01.280 some confidentiality and authentication guarantees so there is this really fun tool which I would 10:01.280 --> 10:08.880 encourage anyone interested to go and play with that helps you get acquainted with different 10:08.880 --> 10:16.640 noise patterns and for each patterns tells you exactly what guarantees you can get after sending 10:16.640 --> 10:23.920 each of the messages in the handshake because noise supports including payloads with its handshake 10:23.920 --> 10:30.400 messages but of course if the handshake has not yet complete security guarantees will be weaker 10:30.400 --> 10:42.000 you can see exactly how so let's take a look at one particular example of the noise protocol 10:42.000 --> 10:49.440 so in this scenario both parties have static keys which they have already exchanged during the 10:50.000 --> 11:02.320 period so now both parties have the keys and the orange arrows through the noise handshake itself 11:02.880 --> 11:09.600 so in a shayt are sense it's a femoral key and also the result of defeat helmet calculations between 11:10.240 --> 11:16.160 it's a femoral key and the static key of the other party and also a GIFI helmet computation 11:18.240 --> 11:26.400 based on its static key and the static key of the other party both parties maintain the local 11:26.400 --> 11:34.960 state and there are rules how the state is updated after each message so that's what responder 11:34.960 --> 11:42.320 does when it receives the message and it sends back its femoral key and differential months based on its 11:42.320 --> 11:50.000 femoral key and the keys and then you shayt are keys so that it has received in the previous step 11:50.720 --> 11:58.720 so now both parties can take the local state and use it to produce two symmetric keys 11:59.600 --> 12:04.080 one which will be used to encrypt the outgoing traffic and another one which will be used to 12:04.080 --> 12:11.600 decrypt the incoming one the dephatinetic month behind that is all in the noise specification 12:12.240 --> 12:22.640 but let's see how this protocol changes if one of the party doesn't have a static key anymore 12:22.640 --> 12:28.960 so now we need shayt are doesn't have the static key it only uses an femoral key for the handshake 12:29.600 --> 12:35.440 so but it's still somehow gets the static key of the responder now in the initial 12:35.440 --> 12:43.200 term message there is still it's a femoral key but only the DIFI helmet based only the femoral key 12:43.200 --> 12:50.800 and the static key of the responder and same goes for the responder messages but as you can see 12:50.800 --> 12:57.600 the drastically it will still include DIFI helmets on all key pairs that are actually involved 12:57.600 --> 13:04.400 in the handshake and in the end both parties still get their shayt symmetric keys 13:05.680 --> 13:11.440 now let's take the static key from the equation and what we get is basically just DIFI helmet 13:12.640 --> 13:19.120 key changed based on two femoral keys so what you can see from here is that noise 13:19.200 --> 13:24.880 protocol framework is really modular you are not obliged to implement each and every pattern 13:24.880 --> 13:35.920 you can pick what you need so this is the minimalistic cryptographic protocol that we 13:35.920 --> 13:45.760 wanted to take and bind it with our own attestation what it allows us to do it allows us to make 13:45.760 --> 13:51.200 that estation a separate step and use noise absolutely without modifications because again 13:51.200 --> 13:55.920 noise comes with this nice formal security proof we don't want to mess with that we also wanted 13:55.920 --> 14:03.360 to support bidirectional attestation and as a nice feature it would be cool if we could also 14:03.360 --> 14:12.400 support multiple attestations so that's what we did let's that's from the Unity 14:12.400 --> 14:21.040 actual attestation phase so attestation will be a separate step performed technically 14:21.040 --> 14:28.640 before the handshake but the reason why I wasn't sure answering the same question about whether 14:28.640 --> 14:36.560 we are pre-opposed handshake is that in the ideal world we could just run attestation super cheaply 14:37.120 --> 14:43.280 it would be super cool to run attestation over the cryptographic material directly from 14:43.280 --> 14:48.640 the handshake after the handshake and bind the through together in this way but we are not in 14:48.640 --> 14:59.040 the perfect world attestation is costly so also not all varieties of attestation that we use 14:59.040 --> 15:06.080 allow us to run it over the arbitrary material that we would need for this case so 15:06.080 --> 15:14.400 instead is we make sure that the evident that is the evident that we get contains binding key 15:15.520 --> 15:23.280 and we use this binding key to sign the noise handshake which by the way is a part of the 15:23.280 --> 15:29.840 noise specification so it's not something that we have invented it is specified that 15:30.800 --> 15:37.760 implementations of noise should make the handshake available through the clients specifically for 15:37.760 --> 15:45.200 this purpose which is for channel binding so we just take it and sign the handshake plus some other 15:45.200 --> 15:53.600 metadata of security and that's how we create the attestate secure channel this can be easily 15:53.600 --> 16:00.080 generalized for the bidirectional attestation so now both parties provide evidence evidence still 16:02.240 --> 16:06.880 contains the binding key both parties use this binding key to sign the handshake hair 16:07.920 --> 16:13.040 the only thing that will be needed is another message from the initiator to the responder 16:13.760 --> 16:20.720 and generalization from multiple attestation is also trivial just include a bunch of 16:21.680 --> 16:32.000 signatures in the final message of the handshake so that's what noise gives us a really small 16:32.000 --> 16:42.000 implementation noise itself is less than 1,000 lines of code this decay that we created for the 16:42.000 --> 16:47.280 attestation binding is a bit more but that's mostly because it's very configurable it's all configuration 16:48.240 --> 16:54.480 and we only need a small subset of creeps functions in order to make the total work we don't need 16:54.480 --> 17:05.360 additional parsers and we don't need to use PKI if we don't have one but it's a custom solution 17:05.360 --> 17:12.240 everyone hates custom solutions as to what is what practical for us you know some contrast to 17:13.200 --> 17:18.080 it's a standard and well accepted solution has a lot of features so basically everything that we could think 17:18.080 --> 17:25.680 of would be covered by some extension of TLS but the main problem in the natural voice that 17:26.560 --> 17:32.080 making TLS work in restricted kernel without the limitations that you want to describe 17:33.040 --> 17:40.640 it's probably draw a ball but hard so at the moment restricted kernel doesn't support 17:40.640 --> 17:50.160 trading it's written and rest so we need a C++ bindings that entails the use of the STD 17:51.120 --> 17:58.160 which we wanted to avoid and it was a pretty huge so what we like about our solution is that 17:58.800 --> 18:04.720 allowed us to focus on what we wanted to focus first which was a testation and just 18:06.960 --> 18:15.040 gave us a really minimal solution to plug the gap that we needed to have plug and so back to you 18:19.040 --> 18:25.440 yeah so in the end we had a very specific use case in which we wanted to minimize the TCP 18:25.440 --> 18:32.000 to make a reviewer's job easier and we wanted to have a very minimalistic crypto protocol to support 18:32.000 --> 18:38.160 our remote attestation and we ended up with choosing noise protocol framework picking a 18:38.160 --> 18:45.680 pattern implementing it and creating an SDK that allows us to bind remote attestation to our 18:45.680 --> 18:52.480 crypto protocol and all of the implementation is open source you can check it on GitHub and the first 18:52.560 --> 18:58.960 link is our project which contains multiple use case not only the one that I talked previously 18:59.760 --> 19:04.560 this is specifically noise implementation and this is a SDK for attestation binding 19:05.200 --> 19:10.800 so that's pretty much it for the talk thanks everyone for listening please feel free to ask any questions 19:15.920 --> 19:17.680 I think we have a first question here 19:22.480 --> 19:33.840 so the question was can we build firmware ourselves and the restricted kernel so the idea was that 19:34.400 --> 19:39.440 we wanted to split it into two parts we wanted to have a very very minimalistic firmware 19:39.440 --> 19:44.800 because it's not only for a restricted kernel we have other use cases where we use the same firmware 19:44.800 --> 19:50.880 but for example load Linux and like load containers on top of it so this is why we wanted to have 19:50.880 --> 19:59.520 this build as a module it is open source yeah everything is open source you can find the 19:59.520 --> 20:07.200 firmware is called stage zero and it's here you can find it and build it yes yes exactly 20:21.360 --> 20:35.880 we don't need to use you 20:35.880 --> 20:43.880 I'm absolutely agree. 20:43.880 --> 20:55.880 I'm a photographer, I was wondering why he didn't change the nonsense. 20:55.880 --> 21:05.880 If a model works as a model, it helps to protect for deploy attacks. 21:05.880 --> 21:10.880 Further, for the encrypted messages, nonsense are used and they are obligatory for the, 21:10.880 --> 21:13.880 but this is specified by the protocol. 21:13.880 --> 21:32.880 I think it's part of no specification that it is, I'm suppose, the question is, 21:32.880 --> 21:39.880 whether the Femeral Key is a sufficient substitute for nons and where it comes from. 21:39.880 --> 21:49.880 So, in our implementation, it is generated specifically for each session, and it's not coming from the verifier. 21:49.880 --> 21:57.880 You need to verify it to demonstrate the fraction of the evidence. 21:57.880 --> 22:02.880 Yeah, so it's definitely not how we demonstrate the fraction of evidence. 22:02.880 --> 22:07.880 I think for the fraction of the evidence, if one will be with us. 22:07.880 --> 22:13.880 So, yeah, the freshness is only provided by the evidence itself by the certificates that we include in the evidence. 22:13.880 --> 22:20.880 So, for example, I previously mentioned that we have transparency, lot of conclusion proofs, and they have expiration dates. 22:20.880 --> 22:26.880 And this is the main reason, how we, this is the main implementation of freshness for the evidence itself. 22:26.880 --> 22:33.880 Yeah, as for the nonsus in the noise protocol, the handshake contains the femoral keys, 22:33.880 --> 22:40.880 but then when the protocol starts and when the handshake is finished, we then check that it's actually bound to the evidence, 22:40.880 --> 22:51.880 and then there are nonsus in the ASGC and protocol that the client and server connect to. 22:51.880 --> 22:57.880 Yeah, we have a key. Yes, yes. 23:21.880 --> 23:31.880 So, I think that this is the key. 23:31.880 --> 23:36.880 I think that this is the key. 23:36.880 --> 23:57.880 Yeah. 23:57.880 --> 24:02.880 Yeah. 24:02.880 --> 24:12.880 So, the question was that the confusion comes from the freshness for the verifier all for the relaying party. 24:12.880 --> 24:20.880 Yeah, in our case, the relaying party and the verifier is the same thing. It's the client. 24:20.880 --> 24:23.880 Yeah, they both on the device. 24:32.880 --> 24:42.880 Yeah. 24:42.880 --> 24:53.880 Yeah. 24:53.880 --> 25:00.880 Yeah. 25:00.880 --> 25:10.880 Yeah. 25:10.880 --> 25:21.880 Yeah. 25:21.880 --> 25:28.880 Yeah. 25:28.880 --> 25:54.880 The question was, where was the measurement in the device? 25:54.880 --> 26:01.880 Yeah, the question was, where was the measurement in the device?