From Stars to Bits : Space Infrastructure for Safe Computation

Transcript

Test test. Perfect. So hello everyone. Uh we are Philip and Tufik. We are working at space computer and we have prepared for you a great workshop regarding what we want to do and what are some of the challenges we are facing with respect to building solutions in space and our talk of the title is from starts to bits space infrastructure for safe computation. So I believe some of you might have already heard in the recent weeks months about the hype regarding space data centers and as we can see more and more it's not only becoming a hype but actually is becoming a reality. We have many companies working on it. We have Google looking into the solutions.

SpaceX of course, but also recent startup from YC called Starcloud is like really actively pushing on narrative. Just a few days ago, they raised a huge series A of over 170 millions to actually find a way on how to make efficiency of space data centers comparable to the one on Earth. So, we see that the tendency is clear. More compute will be shifting to space. What does it mean for us? Space is open for business more than ever before. And the main unlocking capabilities is to be fair due to Space X where we see that the launching of uh any type of gear to space is becoming way cheaper over the years where it started in the order of like tens of thousands of dollars per kilogram. Now with Falcon 9 it's in order of like thousands of dollars and

with Starship that should be available in the next years. We are talking about hundreds or even tens of dollars per kilogram which unlocks many new use cases that were not really thought of before. So what does it mean for us as a solution we want to build? We definitely envision that there will be a need for a lot of security in this context because uh space itself uh plays a important role in many activities regarding communication and other depending on who is the customer of course and we have to focus on providing communication with respect to edge computing and security on that side you have to focus on in case you actually want to execute any type of sensitive workload on the satellite in space either it's AI that we see currently is likely the driving

force for many aspects to storing keys and providing cap secure capabilities for your systems in space. You need to also have a way on how to ensure it. And lastly, since you will have more compute in space, you can also start to think about space inative applications that will be fully developed for solutions in space. And the question is what is the state of space as of now? We see that definitely there is a huge potential for the next 10 years with respect to Starling being available on most of the satellites and many others. But as of now we are not there yet. We can see that actually many of the issues that we are facing on earth or we have faced on earth maybe 20 30 years ago is actually still prominent with respect to space technologies. We

see a lot of challenges with respect to just even being able to communicate with your infrastructure unless you're using for example solutions like a styling which is still not widely adopted beyond SpaceX solutions. And uh this is also proven by recent studies where for example recent research has shown that around 50% of satellite traffic is still unencrypted especially if you consider that in the past uh only state level actors were actually able to go and for example listen to their to to their traffic. Nowadays it's becoming a commodity. If you just buy any type of cheaper defined radio, anyone can actually go and listen to traffic is being sent and broadcasted to earth. So we definitely see a huge shift and we have to start also adjust our architectures accordingly with that.

So our general idea is to crawl before you walk and walk before you run. So this is something we try to follow and actually we have seen over the past roughly 18 months when we started to build space computer there are actually many fundamental challenges we have to solve before we can actually reach the reality of large scale systems that can run in space and how we envision ourselves. We want to be providing a security layer where we can have and rely on other third party constellations but also use our own satellites that will be equipped with unique type of capabilities and users on Earth will be able to consume it. But of course we also envision in the future that other satellites themselves will be able to use our capabilities.

Well, it's quite a unique especially from a security perspective but it's also a pain from engineering perspective because we have to design for this stuff in mind with respect to physical isolation because once you send stuff it's a little bit hard to maintain it but also it provides very much superior security guarantees because the infrastructure operates beyond borders beyond reach and it's definitely immune to physical tempering once it's up in the space and this is definitely providing very interesting capabilities especially for those that might be familiar with some of the concepts of security. If you can't reach it, it definitely makes your attack vector quite more challenging with respect to physical access.

This kind of when we dive into the aspects of how do we envision the infrastructure to be uh usable for safe computation. So we see that of course the users on earth should have a seamless experience as they are used to for interacting with AWS or other solutions. As of now it's very far from that but it's basically where we come uh as a company to provide the solution. We are designing our secure gateway called orbit port that aims to provide the interface between the users on earth expose the services to them but also provide the abstraction to the users so they can easily communicate with what is happening in space either with other satellites with our own satellites or as we will introduce later on space fabric equipped satellites and orbit itself

will be managing the the interface between different type of ground station providers. As a fun note, you read it right. These are actually really mailboxes. As of now, if you want to talk with some of your infrastructure in space, you really have to rely on sending your messages to a ground station provider via email that will eventually forward it to space. And depending on the ground station provider, some are a bit more sophisticated with an API, some are not there yet. This is basically also one of the pain points we want to solve with orbit board. We want to unify the interfaces that will be facing to the ground station providers and you as a user can just like interact via a API that you are comfortable with and can later on make sure that it will be able to communicate with your infrastructure

in space kind of unlocking each of the individual items on the figure. So we'll be starting actually what does it mean uh to run something on our satellites or what is actually space fabric itself. Maybe quick raise of hands who of you have heard of trusted execution environments. Wow. We have a TE crowd here which is great. So I will just go over it quickly for the for the people online. uh general tees are an isolated region on a CPU that is providing additional instructions to your application that you can later execute and run and it promises secure location for your code and data and in general depending on the type of a TE it aims to offer confidentiality and integrity for the data that are running inside of the enclave and I think most crucial aspects

it's providing uh stationation capabilities so you can actually convince others uh with a cryptographic proof that your application is actually running inside of a trusted execution environment itself For those that already know uh there are in general two types of families process based families and VM based solutions there as it's kind of from the from the name clear we have for the process based solutions we in general uh see that we are just able to uh run a particular sensitive compute as a part of the process inside of the enclave and for the VM based solutions as it's kind of from the name obvious we actually putting the whole confidential virtual machine that is something that uh you can easily run and spin. The main difference is the size of so-called

trusted compute base. Uh so of course if you have the whole virtual machine this assumed to be trusted running inside of the TE it's a bit larger in comparison to the process based solutions and also the threat model is slightly different in the context that you here you assume malicious hypervisor and actually for the process based you can assume malicious uh malicious host operating system as well and in in recent months and years we have seen quite a few issues with the TE especially due to the threat model they have which basically currently relies on a so-called guy with a Glock who is actually ensuring the physical protection of TEES and of course as we have seen in recent months there were quite a few attacks exposing actually some of the sensitive key material out of the TE and even be able

to uh create a test station that your uh code is actually running in an authentic information which inherently means which is my other line of work inherently means that actually you have to trust the operator not to behave maliciously which of course is always sparking when there's a new issue with TE it's always sparking working an interesting uh uh ex wars with respect to posts that these are that and they don't have future. I think uh it's not about that. I think these definitely provide an interesting value and I think they should be considered as one of the security solutions we have out there in combination with cryptographic based solution and for that we going to introduced one of our solution actually aims to solve some of the issues we know with TES and

this is called space fabric we just published it u last week and it generally tries to actually think of a future architecture for designing confidential computing in space and it tries to address some of the challenges we see with these on And I will just provide some of the key contributions in in here in high level and kind of how do we position oursel. So in the past there was also the direction about like just space te which was the idea of like having a software uh that is just available on your particular machine with physical isolation. But what we start to see more and more and this will be definitely a big topic in the space industry is like you want to not having a dedicated satellite for your particular mission but you start to be interested in multi-tenancy. But does it mean that you

are not necessarily in the mood to trusting the other people that are sharing the same infrastructure and for that we are designing space fabric that is providing quite an interesting set of capabilities. Some of the unique uh issues we that are known in the TE community is that of course uh I didn't dive into the detail before as a part of the TEDestation flow usually the manufacturer itself is injecting itself into the hard root of trust. um tees in general have the issue that they tell actually what is the code they are running but they don't actually tell you anything about where is the code that is running of course the other aspect is the auditability and supply chain and lastly especially I think with the announcement of Google everyone is talking about it quite heavily had to put it to the slides yesterday is the

postquantum cryptographic transition it's possible just like it's something that has to be I think more actively discussed as well and looking at it we try to look for possible solutions um to these problems. So uh what we identify will be the suitable solution is make sure that the private keys that are used as a part of attestations are never generated on earth. uh we are actually relying on two secure elements for our attestation flow that one of them is open source completely meaning actually even the the hardware design and the firmware is open source and the second one is established a certified solution and we have identified and designed our own instantiation of so-called proof of execution triangulation

uh in a short proof of ET you can ask what came up first if the ET or the actually uh words behind it in this case we We're focusing on uh actually describing which is the interesting property is trying to find a way on how we can actually prove our execution is happening in space and for that we have instantiated our protocol that we call satellite execution assurance protocol that actually is kind of using the ground stations uh to issue a form of like a challenge response protocol that will ensure that your satellite is actually really an authentic satellite and it's running in space and we are in general providing and using the secure approach of making sure the host is secure. We are trying to minimize the

TCB. Uh we are finding the aspects of how to offload the sensitive compute to the TE in combination with the HSM that are providing us the key material and in general try to provide attestations to its user. So we are unfolding all of these uh aspects in the paper. about the cool part from our side uh that satellites equipped with our solution will be available later on this year because we have three missions uh plans ahead of us and the first one will be later on this year in October. So if you're interested to find out more you can check out the space paper and with that we kind of covered what is happening in the space. Now let's dive into actually how do we communicate with it and this is the part where again orbit port comes into the picture and it aims to provide to the users this uh

trust minimized gateway that is able to communicate it's providing also the ent confidentiality and integrity and it in in general aims to unlock several of our use cases one of them will be CTRNG as we'll be looking into more detailed and as of now we are the only party managing it but actually we'll be uh partnering with several people to actually run uh our gateway uh inside of their infrastructure inside of TES as well on earth and we in general want to unlock and make this gateway more trust minimized. So one of the solution is to use TE's on earth as well partner with other people and in general make it open source so actually other people can also go and deploy their instance of orbitport and in the future make sure that anyone who just wants to interact

with infrastructure can run it on prem or in different type of settings as well. So on that part we kind of covered the confidential comput in space. We can now communicate with it. Let's see what are some of the features we can unlock. Um so one of them is randomness. Um it's one of the I would say uh funky funky for us because of course you always want to get some radiation from space and now is the question how can you actually consume it. uh to be diving into the details actually what are some of the the tricks we do to make sure that the user is confident that our randomness is related to random number that we are consuming and we already have couple of recipes you can play with if you're interested and in general we are looking

also into the aspects of not only public randomness that you can consume as you are used to for NFTs and others but also find a way on how we can consume private randomness in consensus or other cryptographic protocols themselves and something that's very exciting for us is key management service which is a new offering. We are currently launching in phase zero for initial partnership integration. In general as of now we are building the solution uh custom to us because of course we have to build for space where we want to run eventually the whole KMS stack but for now we are starting to build it on earth with eventually transition in a hybrid setting between earth and space and eventually running it full in space which will be unlocked by thresholdizing some of the components and using the

dees along the way. So if you are interested let us know. We also have a portal basically as people are used to if you want to register uh through through you can get your you can get your respective tokens and you can start to play around with infrastructure. Okay and I think with that we covered most of the aspects of the workflow and to will now unlock more of the details regarding CTRNG. Thank you. >> Great. Uh thanks Philip for giving an overview. So yeah, one of the um applications that we have with our space infrastructure is CT RNG and um we're first thinking where are we talking about randomness like usually when we're talking about cryptographic protocol security uh we're talking about code

about audit about monitoring and which treat randomness as an assumption but we should not um so randomness is used in in a lot of places in decentralized application uh in web tree mechanism such as selection in ordering or consensus and also in core cryptographic protocol like if you have any K generation uh signature nons generation you need strong randomness and so uh the problem that we're trying to solve here is uh basically basically making sure that we having true randomness. We want to make sure that we are generating randomness correctly that nobody is able to guess it in case that we have real private randomness that nobody also is able to bias it or

influence the random number that we're going to get and also we need to make it verifiable by the user and we can see that as a randomness supply chain like we're starting with randomness collection and at the end we want to have a randomness that is usable by by the user in the application layer. And what we are going to see is all the steps in between so that the user can be confident about it. Um what are the current existing solution? Um for now we have external solution in which the user that uses the randomness does not generate it itself and we have here again different subcategories. We have chain solution.

Um so it's easy for the user to use it but he has to trust someone else to to provide to provide thatness to it. Uh we have also some onchain solutions. Uh it's uh transparent and easier to consume but um it's harder to deliver because there is not really a native randomness on chain. So you have to trust someone to provide that randomness to you and uh how you trust that person or how do you trust that group of person and it's also harder to deliver. So this is one group of solution and the other way you can just not trust anyone and generate your randomness locally um maybe on your computer or just by an external device um but it's a bit complicated to make it uh to make it

right and also you vulnerable to several kind of attacks like chum side channel attacks and your device can be compromised also. So we need a solution for all of this uh that keep the source trusted to make sure that you know what's happening how the the randomness is generated and uh that randomness should be preserved through transportation and at the end you should be able to verify what's happening and that's the role of our CT RNG which is cosmic true random number generation. Um so we're taking randomness from space uh space radiation which is as much as we know for now a nondeterministic process and use it uh as a source of randomness

and one of the main benefit of it is like uh it's outside of reach of any earth attacker. So um any side channel attacks any compromission is an old threat model. And now the question is how can we confident that that randomness is correctly generated and transported. So Philip briefly talked about T is and it's one part of the solution and now let's take a look at other part of the solution. So when we want to verify that randomness is correctly generated we have two parts of the story. The first part is uh internal view. Us as a designer at space computer we have access to data that public user does not have. Uh we have access to the internal state. uh we have access to the data uh

uh that is captured by the sensors and we have access to the whole system and in other hand uh the user he only has access to the public information he has access to the documentation to open source code to any attestation that we publish and of course he has access to the random number and uh it's two different versions that need to be separated se separately um so yeah before diving uh into the separation uh let's just briefly take a look at the type of random number generator. So a TRNG is a true random number generator and it extract randomness from a physical source. Um it's nondeterministic which is what we want from a randomness source. Uh but it

has a lower throughput because uh each time you want randomness you have to query that source of randomness. And on the other hand we have PR RNG which are so the random number generators and they um you give it a seed as an input and you uh just get an out as an output a sequence of random number uh it's sort of random so it's deterministic uh and it's faster but it's predictable. So if an attacker get access to the input seed then he's able to recover the the whole sequence of number and so uh let's start here with internal verification. How first we make sure as designer to correctly generate that randomness and for this we use the NIST SPN 190 series which is certification framework and uh it's divided in three

parts. So NIST a is about how to correctly um design a deterministic random bit generator which is the NIST equivalent of a secure PRNG. Um on our end we're not reinventing anything. We will use existing one like CH20. So I'm not diving into this. Uh N B is about the entropy source and the entropy estimation. How we make sure that the sensor is in space are providing enough randomness. And N C is about combining um NIST A and N B the entropy source and the DRPG to have a full usable RNG.

So let's take a look at NISB B and the analysis of um the source of entropy. So we first here have um the analog noise source which is our row row space radiation in our end and we digitalize it and we get some row data and this is first digital noise source we can apply some conditioning on it. I'll explain in more detail what are the goal of this and then we need to apply some health alto to make sure that it's working correctly and all of this forms the entropy source and our goal is to ask how random is our source but what is it exactly how random is the source let's try to define it so um imagine that I have a source of

randomness for example I have a source that outputs number between 1 and 10 and you here an attacker and trying to guess what will be my next output? Um so if my source is fair for example um H value is probable at 10%. Whatever you will be guessing uh you will have a success rate of 10%. Which is as good as we want as much uh as possible in that case. If our source is based for example seven appear 50% of the time. If you choose seven, you will have a success rate of 50%. And so you will have a higher head of higher rate of guessing. And we can assume that my source is um less good than this one.

And if my source is broken, then you you choose seven and you have 100% success rate. And so we can try to think about randomness as the more success rate has an attacker on guessing my next number. But you could be telling me like for example if my source is based and two appears 0% of the time if you choose two you will have 0% success rate and we could conclude that this source is better than this one even if it's biased. But our goal here is to take um your best guess as an attacker so that on our end we have a lower bound on our entropy estimation so that we know that we have at least that much entropy in it

and it's a conservative way of thinking about security and this is just the formalization of this intuition. Um so we define the entropy as uh the opposite of the logarithism of pmax where pmax is the best guess of the attacker and when we apply it to the result before we just see that the lower is paymax uh we end up with a higher entropy and the more our source is broken uh the less entropy we have and it makes sense and so we know how to uh to define entropy and to define entropy we need to calculate pmax but in practice This pmax is not that easy to calculate and we need to estimate it and uh for that we

have estimators and um we have a different way to to calculate it and it first depends on the model. If your variable is is iid identically distributed and independent then you can just count symbol frequencies and then get an estimation of pmax depending on what is your frequency in your data set. But if in if it's not an idea uh you have a need that provides some other estimators you have for example mark of chain or compression based estimator and um yeah so the goal here is to take all that list of estimator you have around 10 and you calculate you take the minimum and that's your lower bound and um to do this on the raw data

calculation you need to take around 1 million data point uh uh to collect them uh before any calculation. Um, so also you need to perform health tests. You need to perform a health test at startup to make sure that you each time that you're restarting your source, it started correctly. You need to have also test on demand to make sure that whenever you're having an sensitive operation, um you you make sure and check that your source is working correctly. And you also make sure uh need to have continuous testing to make sure that um it's not sliding over time.

And for example, some test it includes like repetition count test. Uh it detects a long rough of identical value. If you have like a lot of zeros, it should be warming up. And the adapt add adaptative proportion test. Also, it checks how the frequency is evolving over time. If you used to have a certain frequency and now it's changing, you should have an alert. Um and then once you have your row output um you need you may apply conditioning depending on what is your corality on your output because you still can have some bias or correlation and for example if you have an output of eight bits maybe inside it you only have four bits of entropy and your goal is to compress it into a cleaner output so

that now in four bits you have four bits of entropies and you need to understand that um this conditioning it does not create more entropy Um and you need to estimate the entropy before applying that conditioning and then depending on which conditioning you use if it's approved by NIST or not then you're able to claim full entropy or not saying like if I provide eight bits 100% of that amount is full entropy. Um so yeah now let's talk about Nissi.

So this is about the construction of the full random bin generator and so we've just seen how to estimate entropy on the entropy source. We've not seen but we will be using a DRBG from N A and N C is about combining both like you have the entropy source and you give it as an input to the to the DRBG and it explain how to seed and receive from the source. uh when it explained also what is a bit limit uh because you can't like use one seed and generate random numbers infinitely. It explained what bit limit you should use and it also explained how to combine multiple sources if you have more than one.

And yeah, what we need to understand here is that this certification is a baseline. Um, we should not trade it as a proof that our source is secure, but uh it's something that considered good enough to be used in most cryptographic application. But um we still have to keep up with research because yeah we we have a lot of new attacks and things that are discovered and so here uh with our randomness supply chain. So we have um some um randomness generation here. Uh for example, yeah space radiation that we discussed. Um we sample digitalize it and then we have our row data collection and then we can apply the internal verification us as a team as we discussed which is uh entropy

modeling uh health test and then conditioning and then we will see how uh is it can be usable uh to the external verification and so yeah for recall external verification it's u uh for the user point of view. So the user it sees our product as a black box and he only has uh the public information that's available and his goal is to check as much as possible if the received value look correct and um we have two tools for this we have a statistical verification that I'll explain and cryptographic mechanism that Philip talked about it briefly but I'll re go on it again and so the statistical verification the goal is uh that the user he got some

random numbers that we provided from S computer and uh he want to take a look at this random number and say does it look random and the goal is to detect bias or correlation uh but it only try to look if it looks random. It cannot prove that it's random. It's only trying to guess if there is things that are obviously broken but that's the most that it can do and um in practice we have some uh statistical test like die hard or die harder on NIST but the most recent one are test user one and pract and we'll see how it works.

So um each test on test user one it computes the testic on the data and see how much is it pricing. For example, let's say that we have a generator that outputs number between 1 and 10. And let's say we're drawing one uh,000 number and our statistic will be counting how much seven do we have. We expect to have 107. But we can do more than this. We can say that we have less than 1% than of filing outside the 75 125 range. And we have around 10% chance of filing outside the 85 115 range. And we can use this to say for example if we get like

five 500 as a count it's suspicious. It's still possible if we get it one time um it can it can still be true but if we have different test and we have different uh very low probability then we can suggest that our the entropy source is broken and uh so yeah the p value is what formulizes it's is how surprising is the ex expected result under our hypothesis and yeah if the p value is too small we reject our hypothesis and if it's not too small then we can just say that we were not able to reject our hypothesis but we cannot prove anything here and um yeah so concerning statistical verification we we will very soon

release a library on it which is a rest library which include two of the most recent test which is test user one and pract and we have two kind of bindings here rest to see in order to be able to call our code um our rest code to the library and C2 rest in order to be able to call back the resist And yeah, the goal is that this is open source and pluggable into whatever rest repository. So you're able to verify with this our source of randomness. But whatever source of randomness u in the crypto world, you can verify it with this statistical verification library.

And here we just have an example of how it's working. So we took an example with the classic uh RNG which is CH20. you define it uh you you register it and then uh depending on which battery test you want to run for example if it's small verification you want to do or the big one you run the corresponding test and then you do your verification and then yeah cry this was statistical verification and now let's look at the other way of verif verifying things which is cryptographic verification and one of the first uh way we can verify things by having signatures on the output if the data is signed and I know that the data come from the satellite.

So I know where it's coming from but I just know that it's coming from the satellite. I don't know if it was what generated correctly and that's the role of TE at test stations is to make sure that I know that this number was generated on this satellite and I know it was generated with this code and this process and it's attested and uh another uh thing is verifiable DRBG output. Uh we can imagine for public beacons that um uh us as space computer we can commit to a JRBG seed and later when we reveal that seed the user can replay the sequence verify it himself and uh we have also some option to not only commit on a seed and use that seed

as the input of the DRBG but commit on a seed and use the input as a hash of the seed and a public value for example a block hash so that um we know that we have not biased to the output. So yeah, it all depends on on the use case and here yeah we can retake a look at the randomness supply chain to to to situate things. Um so one of the thing we've talked about is space radiation but on space we also have TPMS and HSM that are true source of generation and that have a a way to generate random number. So space radiation is one of the source but we have two others that are also NIST approved and uh so yeah we've seen how we collect the data we've seen

how we do internal verification and now we have uh our input uh our output the user can verify it and uh first perform a cryptographic attestation verification but also perform statistical testing on it and now he has an input that he can use in whatever he want in K generation uh in threshold DCDSA in leader election and this is all like private bacon example but we also can provide public beacon output to make sure that for example if you have a lottery or whatever public number that is needed it can be used also and so yeah we're presenting now a crypto CTNG which is our library that enables you as a user to access the

random numbers that we're providing from space and yeah it's a a rust library that transports that entropy uh from our back end to the user. Uh it implements the standard sets so that it's pluggable and can be replaced any uh in any RNG. It has three entropy sources. Uh the first one is IPFS beacon which is 32 by blocks uh that comes from the CTRNG back end. This is our main source. Another one is local OS. If you don't trust the randomness for space or if you want maximum security uh you can use your local one in order to get it mixed so that you have the randomness from space your local randomness and you exor both uh you have three modes then you have

row entropy if you just want the entropy and then plug it into your custom crypto cryptography mechanism and um if you want to have our DRBG on top of it which is a chhat 20 construction you can use per hour and then you can apply auto receipt on top of it which is like every 3200 bytes or every week whichever come first and if you want maximum security you can use a prediction resistant mode in which you're calling uh our IPI at every call in order to receive your RNG. Uh so let's take a look at an example of integration into an existing cryptographic protocol. So for recall what is threshold ECDSA? Uh instead of having um one user that have a secret

key and that generates a signature uh we're splitting that private key into different shares and then each user has a share that he used to generate a partial signature and we can combine this partial signature to get the final signature. So it's a way to split the private key to have some more security and we could say that uh it's already provides enough security like if each user is generating randomness on its own maybe I'm able to guess one uh part randomness but it will be very hard to guess the other but that's when we see that we have some setups in which it's difficult uh for example when we have some virtual machine and in some configuration if they have some same

setup configur uration we can end up by being able to gather the randomness from all the VM concurrently. So here we having uh the code of um the loess repository from DFNS in which they perform threshold DCDSA. So first we define our EPFS random source with a beacon key and there we're able to call it like this with CTRNG. IPFS and we give our beacon key as an input and once we've defined our CTR RNG we are simply able to call it with CTRNG next block and so for each each user each party in the protocol uh he's calling a block in the CTNG protocol and we're having a

base seed and then this base seed uh can be used in different part of the protocol in the key gen in auxiliary data generation uh which is uh the key generation and split and splitting part and uh then we can run signing and so here in this specific repository um they do not use our specific uh DRBG uh so we tried to adapt to their implementation um they're using their seed and then they are deriving it for each stage for example here it's K generation so it's stage one and so for each stage they derive the seed in order to get local randomness that is different for each round without having

to retrigger different randomness generation and um yeah so we derive randomness and uh and then we we can run the kitchen and yes that was the big picture so thanks for being here listening and uh if you have any need for randomness integration or anything else let me know >> great we are happy to take any questions from the audience or we will be also here later on. I think we have still quite some time.

>> Yeah, >> very technical deep dive. So, thanks for that. Um, I have a bit of a like I guess general question. So, there's been a destruction of couple of SpaceX satellites in the last two days. I think two went down. Um is there is any data redundancies that you're thinking like if there's a anything in space and you cannot service that and it goes offline like uh you you probably cannot store data for long periods of time there. So how how to deal with that?

>> Yeah, it's a great question. >> Yeah, it's a great question. So we are actually on that part already thinking of the designs with respect to that. This is and it's kind of a layered approach. So one part of course if it's a single satellite that we'll be initially having it's of course hard to have too much redundancy on that front of if something goes wrong with the particular spacecraft it's a problem but already on this particular spacecraft we actually are adding multiple redundancies. So you for example have more of the same boards on board of the particular satellite as well. So in case one of the boards is for example damaged due to radiation or over the extended period of time of just being in a bit more of a hostile environment in space we can switch to the other board and also on the particular board we actually

have two instances of the TES. So that way we can actually handle uh the the particular sensitive compute in two different modes and uh with respect to the data itself we are since most of the sensitive operation will be running inside of the TE we actually also encrypting them with the respective key and we are later on storing the copies of the encrypted data in different locations on the satellite as well. So that way even if there's a issue with a particular storage for example at the the SD card uh we have a way on how to deal with it and moving forward we of course want to also have a remancing across multiple satellites that is also the motivation why we don't want to have only a single satellite but a constellation because you can later on distribute and synchronize the state

across multiple peers and satellites in space because what you're mentioning is possible it can happen and in general also there will be a char in the network like some satellites will disappear some satellites will join. So you'll basically have to always make sure that there is enough redundancy across the different peers. One of the solution to was talking about is of course to use also at least on a cryptographic level uh to protect the private key to thresholdize them and have them stored at multiple locations and uh think about it in a structured manner. We're actually currently like working on a more detailed blog post on outlining our strategy which is like a mix of hardware and software solutions to make sure that for example we are on a regular basis uh also doing health checks because even if

the data are stored it doesn't mean that they are healthy they can for example be a bit flip on the radiation for front. So you want also to have a regular checkups that basically all of the health of the files is is still up there. >> Right. Can I actually add to this? Uh, you said there's a bit flip with potential radiation and I assume that with like solar flares and it might happen more frequent than you might expect. So like uh what kind of like health checks would you perform and how do you verify that the data is u still like the randomness is random.

It's not like becoming unrandom in that sense. for randomness actually this will maybe be helpful for us but for example for private keys it can be a problem so we want to be either doing check sums of the private keys if we happen to have access to them uh this is one part and if for example if they are generated and stored inside of the HSM we cannot of course do a check sum on the private key because we never get to see it uh but what we can do is to just make it sign and dummy data and verify it against the respective public key basically and if there will be some issue that we will observe we will have to regenerate the the whole private key and the successive keys afterwards So we will have to uh basically do again like a layered approach uh to to solve

this issue. But on a positive note uh our satellites will be running on on LEO and actually if you do quite a reasonable effort of putting some shielding onto the payload, you don't really have to worry about radiation as much. uh at least when talking with partners and discussing what are the cap what is the likelihood of uh single uh radiation even happening for example uh the bit flip uh during the experience of their spacecrafts uh it never basically happen in the past so in LEO actually you are quite safe because you are still quite close to the earth and uh it's not such a big problem but of course what is a general problem is that your hardware will be decaying a bit faster in comparison to on earth solutions as

Hey, thanks for the talk. Um, I have a question because I don't know anything about space computing. How are you going to deal with the outdated computers? For example, you send a computer today. In 10 years, the compute power that it has is not state-of-the-art anymore. and I don't want to use it. So, how are you going to sort them off? >> Yeah, it's a feature and a bug of space, you know, in some way. But basically, they will burn like so they will eventually burn on a re-entry to the atmosphere. So, which is I think quite we are using it currently more as a as a feature, you know, because if you have sensitive key material that is already in space and it burns on re-entry, it's quite hard to actually go and try to get a private keys once the the spacecraft

is there. But definitely, it's something that um we have to think about. But at least as of now, especially if you're launching satellites into space, you also have to have so-called sustainability plan, which basically is kind of telling you what is going to happen with your satellites at the end of the life. Uh for LEO, it's rather straightforward. They will actually just burn. For geocatellites, it's quite funny, but they basically don't want to use enough um propellant to be sending the satellite back to Earth and burning an atmosphere. they just push it farther from the earth and they're just like stuck there. So actually if you look at some of the pictures you basically have a graveyard of old satellites that are beyond the geostationary uh environment.

So they are still there from 70s 80s. They're just like chilling there. So for us, we want to rather burn them in atmosphere because we're focusing on Leo. Yeah. Okay. Then if there are no other questions, well, feel free to reach out afterwards and hope to see you around. Thank you.