 Okay, so I will talk today about combining superpowers, right? We have these two superheroes here. The one is the NPC hero, the other one is the confidential computing hero. Can we make them work together in an efficient way? So that we can leverage the benefits of both and create something even more powerful. So I skipped the next slide because Paul basically said everything already that is on that slide. Ah, one thing is missing, so this is joint work with some of my colleagues from Bosch research. So Jonas Eppard, Vincent Rieder and Christoph Bösch. Two or three sentences about Bosch because maybe nobody, not everybody knows about Bosch in detail. So we are really a huge company, over 400,000 employees all over the world. 470 subsidiaries located in more than 60 countries. We are active in various spaces, not only refrigerators and appliances. Mobility solutions is our strongest division, but also industrial technology, energy building and consumer goods. So I personally, I work in Bosch research. We look into, as the name implies, research and pre-development. I'm one happy guy among a crowd of 1,800 people working in all these different areas. So of course that's not everything. IT, we are distributed around a globe, nine different research facilities, everybody over the world. We look into 12 different strategic portfolios and one of these portfolios is information and communication technology. And that's why I'm talking here today. We have a lot of PhD students, so if you know anybody who is interested in the topic, please tell them to reach out. We are always open to host these bright guys in our company. So we will talk about confidential computing, which I presume you know very well, maybe even better than me or probably better than me. So I will not focus on that. I will give a quick introduction to secure multi-party computation so that you understand what I'm talking about in the follow-up slides then. So what is secure multi-party computation? So in the first place it's collaboration enabling technology. So what it allows you to or more parties to using cryptographic protocols to compute on a data set that consists of data sets coming from different people without actually bringing it together in one place. So that's the whole idea of MPC. What we do with carbine stack, so Paul mentioned it quickly, so we try to make this enterprise great, right? So there are a lot of startups in that space, but we think the better approach is doing it in an open context as an open source project in open collaboration. The basic idea is to combine the cryptographic protocols, state-of-the-art ones, and combine them with cloud-native technology to create something that has all the nice capabilities of cloud-native solution, scalability, elasticity, reliability and so on and so forth, you name it. We also look into research aspects, so that's the small again chart at the bottom left. As of today there are still a couple of open questions, so what is I think undisputed is that it's a very secure technology because it roots in math, right? You can prove the protocols. Of course you have to do a good job in implementing it, but from that basis it's the best you can get. But there are still some problems regarding cost efficiency, so these technologies typically, depending on the use case, have very significant overhead. So we talk about auto-magnitude, it's not single digit percentages like for confidential computing. They also have a maturity problem still, so there are solutions out there that can be adopted, but it still requires a lot of effort to bring your existing solutions on top of that. And then finally usability is also something that is related to that. And what we want to achieve with our research work is to close these gaps to make it in maybe a little bit more far future, as usable as confidential as of today. So a quick intro into secure multi-party computation. So we will talk about three things. The first is IO, the second one is doing additions, the third one is multiplication. These are the three things that you need, and then based on that you can build whatever you can do with a regular computer as well. So what we do here is called additive secret sharing. So you see these three secrets on the right, these red circles, these are the secrets that you have, right? So one player has a seven, the other one has a four, and the last one has a nine. And what you do now is called secret sharing. So you split up that secret into three numbers in that case, because we have three players. So the seven is split up into one, two, four, and the sum of it is of course seven. You do the same for the others. And then you do secret sharing. That is distributing one of these secret shares, so one of these numbers in the case of seven, player one, the one is he keeps for himself, the two he sends to player two, the four he sends to player three, right? And that every party does that. And then we have the input phase is done. What you can do now is you can do addition simply by the fact that addition is commutative. You can just do the computation, the addition locally, which is the step from the second blue row to the first green row. So you add one, zero, and two. This gives you three and so on for the others as well. And then you again, now you want to do the output. So distribute the result of the addition and then you distribute your number that you have calculated locally on the secret shares from everybody to the other parties. Then you can do the sum again. And what you can see is now 20 is exactly the result of adding seven, four, and nine at the top, right? So that is how addition works. That is super simple. It's also a little bit simplified because we usually, at least in carbine stack, we work in the active security model. That means you have to make sure that people cannot cheat. And that adds a little bit more of involved protocols here, but that's the basic approach, right? Now we come to multiplication. We will not go through everything because that's a little bit more complex. But the key takeaway is that modern MPC protocols are built in a way where you have two independent phases. The first one is the offline phase. The other one is the online phase. In the offline phase, you use kind of heavy cryptographic protocols like oblivious transform or morphic encryption and others to create so-called correlated randomness. So what does that mean? So randomness, it's clear. So these are random numbers. And in the case for multiplication, we have three of these numbers for every multiplication that you want to do in the distributed setting. And it's called correlated because there is a correlation between these random numbers that you generate. So we have A, B and C and the correlation is that A times B is C. And now these numbers are generated in a way that every party possesses only, as before, for the addition example, the secret shares and not the numbers itself. And then you can use, I will not go through it as I said, because it's a little bit involved. So you can use these numbers to do multiplications also in a similar way as you do the additions without only using local operations after some network operation. The thing that you have to take away here is that this is done in an offline phase and it includes very expensive cryptographic operations in terms of compute complexity and communication. So what do we do with that now? So what we do, we build what we call an always encrypted collaboration substrate. It's marketing, blah, blah, but anyway. So we build a platform where the data that parties put in is actually kept encrypted all the time. The difference between MPC and confidential computing is here that it's really kept encrypted all the time, even when it's processed, right? So for confidential computing, as soon as it leaves memory, it gets encrypted and it's processed in the clear text. And then when right back to memory, it's encrypted again. So this is not a case here. It stays encrypted all the time. So it's a multi-step process. So first of all, the parties that want to engage in a joint community, a computation, they form a cluster of parties. So these are the four offices that you see there. And then they engage in a binding process to each other where some secret keys are generated that are used later on for ensuring that people cannot cheat. And then the parties submit their inputs, in a way, as described before, so that nobody else knows the secrets of one party. And then they can define also who has access to what, to the input data, to the output data, to intermediate results that can be set up using a policy. And then the computation is performed. And finally they can, using this output operation that we saw in the addition slide, they can pull together the secret shares again and finally get the result of the computation. So what can you do with that? I think there is a very big overlap between what can be done with contribution computing and what can be done with secure multi-party computation. So you can do this virtual data pooling. So bring together data from many, many organizations or parties without actually exposing that data to the others and still be able to do analytics on top of it and so on. That's, I think, as of today, the most successful branch where MPC is used. So you see all these software wallets, many of them use secure multi-party computation to secure the secret keys. And that's exactly what you can do with it. You can create kind of a virtual HSM that uses secure multi-party computation to split the keys into secret shares and then distribute it, which means you have to successfully attack all of the places where these secret shares are located to actually recover the key and also to invalidate the security of operations done with that secret key. Private correlation, so that's also an interesting technique that can be built on top of MPC. So let's assume Paul has a list of people he talks to about confidential computing. I have one talking about MPC. We want to know the intersection between these two sets without exposing our lists to each other. And that's what you can do with that, with cryptographic guarantees again. And the last thing is collaborative learning. That's federated learning. That's maybe a different term that you can use for it. And you can for certain parts of the federated learning process, not the training itself, but for doing the aggregation then in the back end you can use secure multi-party computation to do that with these cryptographic guarantees. Okay, so I hope that gives you at least a high level idea of what MPC is. And now the question is, so I announced this talk as pets of the world unite. So what do we want to unite here? How do we want to do that? And why do we do that? So to give a little bit more context again, let's quickly go through a matrix of what these different technologies provide you with. So confidential computing in terms of overhead, we have seen that in our joint work with Intel for example, the overheads can be brought down to basically negligible amounts. It depends on the use case, how many IO is involved and so on. But in general you can say the overheads are very small. For secure multi-party computation, the compute overhead is, I would say, significant. So as I said, orders of magnitude. I think the best that you can get is one order of magnitude, depends on the use case of course. That's kind of the lower bound. But the communication overhead, that is massive, right? You will see that in one of the follow-up slides. Homomorphic encryption, it's the other way around, right? The computing overhead is very massive and the communication overhead is significant. Communication overhead comes from the fact that you have to encrypt your local inputs with very long public keys and this creates huge input data. Trusted compute base, so by the way I'm generalizing you, right? So there might be arguments for each of these entries in this table. But we can do that maybe afterwards. Trusted compute base, so it depends on which kind of T you use for confidential computing. It can be significant to large depending on what you use for these other techniques. It's rather small because assuming open source you can have a look into everything so you don't have to trust it necessarily. And it's software only of course. If you have open source you can look into everything which is not the case for confidential computing techniques, typically at least. Security wise, I insist a little bit on making this distinction for confidential computing. It's protected in use while for these cryptographic methods it's encrypted in use. That's a difference. Security assumptions, so for confidential computing it's the correctness of the hardware implementation plus software SDK as well of course. But for secure multi-party computation it's non-collusion. If all of these three parties that you saw on one of the recent slides work together then of course the secrets can be reconstructed easily. So if that assumption cannot be made reasonably then it makes no sense. And for homomorphic encryption it's the secrecy of the keys, right? For the scope, for the cryptographic methods you typically can't protect only the data. There are schemes that also protect the code or the algorithms that are used but these are so inefficient that you typically can't use them. For confidential computing it's both and that's of course a nice attribute because often we encounter use cases where also the IP that is in the algorithms is very valuable. Ease of use, we discussed it before already. So for if you use VM-based keys today it's more or less lift and shift. You can with very low effort take your existing workloads and put them into the confidential computing domain. For the computing and encrypted data technologies that's not the case. There has been a lot of progress in the field of compilers for homomorphic encryption in particular but typically you have to re-implement your algorithms on these architectures. So sweet spot I would say for confidential computing it's whenever high performance is required machine learning use cases for example or simulations then there is at the moment no real alternative to that. For the others, for secure multi-party computation my let's say Ligmo's test would be are there more than one party involved that has its own data set that has to be processed somehow. And for homomorphic encryption it's offloading right. So there are multi-party schemes for homomorphic encryption as well but again very inefficient so you wouldn't typically use them today. So now how does the pet space develop from my point of view? So what we see and still see to some extent is kind of this coexistence right. Some people deploy confidential computing for a workload others NPC other some homomorphic encryption but they are not really built on top of each other or integrated with each other. I think this is changing now. Paul mentioned a couple of examples for that that some NPC companies are now integrating NPC with confidential computing and that I would call that stacking so you take the one solution put the other one on top of it or inside of it and they then benefit from the properties of the typically the direction is right NPC on top and then confidential computing as the infrastructure and then in the little bit more far future I think there will be I called that amalgamation so things will grow together more closely will be more deeply integrated to leverage the benefits of each technology and I will show you an example for that in a second. So the one is in production today cutting edge stacking I think people are trying to establish that now make first POCs for that and these amalgamation thing requires research and is a little bit more in the future from my point of view. So first example is stacking and we work together with Edgeless here to use their constellation platform which is as you probably know a Kubernetes distribution that deploys the workers in confidential VMs and that has a very nice feature that you don't have to change a lot when you do that and get a fully protected Kubernetes cluster and what we did together is we deployed Carvine stack which you will a little bit more on one of the next slides inside the constellation cluster and the really cool thing has been that we had to change nothing it just worked out of the box it's a complex system Carvine stack so it includes Knative, Istio and a lot of other cloud native components and this worked seamlessly without any changes required so that's kudos to Edgeless systems really great technology you will be able to read more about that on our blog and very soon it's not ready yet but will be published in a couple of days so can we do it even better? I mean it's kind of straightforward right? It worked out of the box more or less everybody can do it today but is there even more potential in it? and to understand that I quickly explain how the services within Carvine stack work so we have four of them at the moment we have a storage subsystem and a computation subsystem the storage subsystem consists of M4 this is where the secret shares live that I have explained on the MPC slides we have Castor that is the service that stores this correlated randomness for letter consumption we have Klischko that's the service that generates the correlated randomness and stores it in Castor and we have ephemeral which uses Knative to allow for function as a service for MPC and now what's the problem here? so that's one instance of Carvine stack running right? and typically we have at least two so there is another virtual cloud provider that hosts exactly the same service and these have to communicate we have learned that for multiplications they have to communicate and also for generating the offline material they have to communicate and now look at the numbers so for the online phase for 100 k ops per second they have to communicate so these are ballpark numbers right? rounded to the order of magnitude so 10 megabytes per second communication all the time while they do the computation for the offline phase it's much worse so for this 100 k ops per second you need 1 gigabyte per second communication between these two parties and that's of course a lot if you do the math here taking Azure egress bandwidth pricing you get a 100 US dollar per hour just for the communication stuff right? I've read that it's an hour squared oh sorry no no that's that's just the so what is the take away here? so MPC is a chatterbox and if you deploy it on a public cloud you pay insanely high amounts of money for it so what can we do about it? yeah I think it's more or less straightforward right? so we took one of the so mp speeds that's on the right side below this factory symbol that's the state-of-the-art MPC framework and what they have they have a so-called fake offline phase or you can also call it a trusted dealer or a deterministic offline phase which doesn't use a cryptographic method for generating this offline material it's locally right? with just coming up with two random numbers and then calculate the product out of it do the secret sharing then you have the correlated randomness for multiplications and of course that's completely insecure so in that way it doesn't work but what we did is we put this factory inside a Grameen library OS using SGX for ensuring the confidential computing properties so what does that help? so first of all it's deterministic the reason why that is the case so these are the two parties right? left from the last slide that we saw so the left side creates correlated randomness and the right side creates correlated randomness but of course if these do not match then it will not work because the correlation will not hold anymore and that's the reason why they exchange a seed at the beginning the seed is used to initialize the pseudo-random number generator and leads to the fact that both create the same correlated randomness and on both sides you use only the local shares to work with it so that's again the sequence diagram for what happens so the parties request for correlated randomness then the generators they do remote attested TLS with mutual attestation to be sure that the thing that runs there is actually a secure platform and also we run the factory used to generate the correlated randomness and as soon as they have ensured that this is the case they start exchanging secret parameters to initialize this factory and then if this is done they can start creating the correlated randomness and deliver it locally to the cluster service for storing it so what is the benefits of this? so first of all it's multiple orders of magnitude faster than the cryptographic method that's because it's just coming up with these triples locally so that's super fast, you don't have any cryptography in there but even better is there is nearly no communication cost involved but the only thing that goes over the LAN boundary is basically the seed and this makey-shed exchange so you have virtually no cost of course the trade-off there is no free lunch so you have to trust that the T implementation is secure but you don't have cryptographic guarantees anymore so that's the first step can we go even better and that is now next step so it has not been implemented so far but this is what I meant when I gave the subtitle to my talk Capture the middle ground between security and performance so by the way this doesn't mean that at the crossing of these two lines there is zero I wouldn't put CC protected workload in the low security space there is a lot of space below here that is not sure on a slide so we would have the cryptographic offline phase it's very secure but super slow, right? that means it's here on the x-axis to the very left and on the y-axis for security very high on the other side we have CC protected which is super performant but from a security perspective it's not as or at least you cannot prove it's security let's say this way and then we have number three that is the implementation that I just described now the question is can we do better so the first attempt would be to get rid of the second T instance here and just have one, right? you can still do remote attestation for both sides and it basically would result in the same correlated randomness being generated but the difference is that now you can see again the land boundary so this dashed blue line you can see that a lot of so the correlated randomness itself is large, right? so you have to again transfer all that data over the land boundary creating again egress bandwidth cost on Azure so I would think this is not better than the other can we do better still? so and that's the next idea that we had so when I described the MPC protocols we talked about a very specific security model which is called active secure malicious majority that means n-1 parties, MPC parties could be corrupt and the security is still there and the second one is active security the players can arbitrarily divert from the protocol and do whatever they want, the security is still not compromised there is another class which is called honest majority active security and there you have to ensure as the name implies that you have an honest majority within the MPC setting so in that case with three parties you have to be sure that no more than one of these boxes is broken, right? and now the idea is, okay, the good thing is that these protocols have very low communication cost compared to the malicious security active security protocol and now by doing this we can do the following we can use MPC within that dashed rounded box to set up another MPC cluster and have a generator run in each of the T-protected boxes and you use different T implementations for that so that means to break that system so we still have the same benefits as before only the thick lines are the high bandwidth connections so these do not cross the boundary, the LAN boundary but on the other hand since you have now three independent T implementations and using this MPC protocol that I described you can be sure that an attacker have to break two of these T's simultaneously and it's still all fine, right? okay, next level of sophistication would be kind of doing the same thing as we did for the non-MPC setting so you would replicate that setting on both sides and just exchange the seed again and then they locally compute all the triples or the correlated randomness as before whether this is really better or not has to be proven so we have not implemented it, not tested it I would doubt that it's better, I would say the number five is still the better one but that has to be seen so that would be from my point of view an example for amalgamation so we use the properties of one technology to improve the technology or the missing parts from the other technology so, again, back to carbine stack what do we try to achieve with carbine stack? we want to democratize MPC we live in a world currently where MPC is largely proprietary we have startups out there that build their own solution if you manage with your partners to agree on a technology provider you still have a vendor lock-in because these things are not interoperable at the moment it can be opaque so, of course, I think you can agree with these startups to open up their source code so that you can have a look but it's not open source in the first place and that means it also needs to be trusted and what we want to achieve with carbine stack is to change it having an open MPC framework where everybody can look into where everybody can integrate with their specific MPC engines for example which then would create network effects because of this ecosystem every player that comes adds to the value of the network which, again, stimulates people to join the network it's future-proof because you have a lot of momentum in that community to bring forward the technology you have more rapid innovation because you can more easily work together also across company boundaries yeah, it's transparent and everybody can look at the source code and now we will add this implementation to carbine stack so that when you deploy to the cloud you have significantly lower cost with still reasonable security guarantees and you can choose, right? with one super high security you can still use the classical cryptographic protocols for that okay, so that's my last slide so if you like carbine stack show us your love give us a star on github if you see benefit in secure multi-party computation in general you can also consider joining the initiative and we have, end of November we have the carbine stack conference the second time, so that will be hosted in our headquarters research headquarters in Germany last time we had over 60 people from over 30 companies that have been interested in that and we will discuss a lot of technical improvements that we did throughout the last year to show the people what the combination of NPC and the alternative actually brings to the world so that's the idea so with that said, that is my talk thank you thank you very much indeed we do have some time for questions I've got about a million so I'll start with one if I may and you can think up more questions and let's go with that so my first one was what's the state of the art for this sort of stuff and quantum resistance? where are we with that? is there good stuff happening we are not quite sure we are not quite sure of it, that's true so the online phase typically is information theoretically secure, so there is no problem for the offline phase it depends on which concrete cryptography mechanisms you use but there are for example lattice based systems that are believed to be quantum resistant and then that would work out but time has to show whether this is true or not thank you any questions in the audience? Osama thank you very much it was specifically interesting the slide in which you showed the confidential computing compared to other technologies so morphic encryption and multi-party computation it was very interesting I have one question about that slide so in that you mentioned that the TCB for process based is significant and for VM based it's large I would have expected the other way around and I would like some clarification on that because the VM you are trusting the whole VM and in process based you are trusting that process specifically and I would have expected the other way around so I just want to be sure I think we have just different interpretations of the words so significant is for me lower than large so large means it's yeah maybe that's I have to use maybe different words for that but I think we are in agreement here and I'm going to I would take an issue with the number of these as well for a variety of this this is you say this is kind of the average or one way of doing it it is possible to have very small TCBs for both the process based and VM based that if you are writing your own rather than taking an entire sort of standard VM the approach that NUX has taken and some others have taken as well it is possible to have those small so that may be kind of right on the average but I think there's a number of these can shift in various directions and I think that's one of the areas where there's a lot of work that still needs to happen on the technical side and it's really really interesting any other questions again I've got loads so I just want to ask a question okay it's me then so you talked about using RITLS about for attestation I was very glad to hear the word attestation used because it's a kind of important one in this context is are you doing things in a way that the the carbine itself is attestation aware or is that attestation passed out to other parties for them to make decisions about trustworthiness of what's going on and also are you using the attestation for the code as well as the data you mentioned you can of course I think for the first approach so this is what we did with actual systems so here you would as a user of the platform do the remote attestation against the whole platform so that would be one of the scenarios that you described for the other one it's rather between the parties so for these guys they want to be sure before they're exposed so the Mackey share if that is leaked then the whole security of the platform is gone so that means they have to make sure before sharing that the remote attestation to ensure that this is really the case so in this case between the carbine stack instances and in the other case between the user of carbine stack and carbine stack itself so both for those of you who don't know this report I'll introduce myself I'm Mike Vasell I'm the executive director of the Computing Consortium I'm helping host this with Paul and I'm really pleased that we're talking about attestation in a variety of ways I think it's one of the things that's going to change as maturity of the market comes in people begin to realise attestation is vastly important but you just highlighted two different ways of using it sort of within process or across between parties and then externally to the more of the sort of orchestration layer almost if you will and I think there's going to be lots of conversations about that and I'd love to see the companies here who are represented thinking about all those things as we go and any other questions we got time for one more question, go for it so you mentioned that I mean the main purpose here is to reduce the communication due to the cost in the cloud does it also help with the performance because the offline phase needs less communication does it yes it does help with performance so that was the takeaway here right so it's multiple orders of magnitude faster in generation as well okay and you said initially the best case would be one magnitude of performance decrease so that you could get almost up to to native speed then or here we get it almost up to speed with the fake offline phase unprotected performance which is as good as it can get okay I'm going to ask one more what's combine written in oh it's a mix so we have these computation services that I mentioned so ephemeral and klichkordies are written in go it's a cloud system right so you get the most people with that interest and skills and storage layers are written mostly because of legacy in java and then the clients is all you can think of right even web assemblies one language that we support for the client side because we don't want to implement everything and again for each language so we have a full methods and proofs person here and I'd love to have a discussion at some point about the trust you can have in your implementation given a variety of those things but we don't really have time for that please a round of applause if we may for Sven that was really interesting