Exploring Space and Time: Securing a Trustless Network

Exploring Space and Time is a deep-dive video interview series on the various components of the Space and Time platform. In this episode, Content Lead Catherine Hickox interviews Director of Architecture Henry Daly on how Space and Time secures user data in a trustless, decentralized network.

Henry is an accomplished problem-solver with experience in designing and implementing scalable, high-performance systems across a variety of industries including logistics, civil, defense, and transportation. He obtained a M.S. in Computer Science from the Georgia Institute of Technology and has published research on data structure optimization based on unique characteristics of modern hardware architecture. Previously, Henry has served as an individual contributor, product owner, project manager, and technical lead before matriculating into his current position, where he offers a uniquely creative and pragmatic approach to the engineering challenges at Space and Time.

Catherine Hickox: Hi, everybody. Welcome back to another episode of Exploring Space and Time. My name is Catherine Hickox. I'm the Content Lead here at Space and Time. And I'm here with Henry Daly, our Director of Architecture. Thanks for joining me, Henry.

Henry Daly: Thanks, Catherine. Hi, I'm Henry. I'm the Director of Architecture here at Space and Time. And primarily where I work is in client interfaces, and building the validation layer that sits on top of our network of data warehouses.

Catherine: Henry has a bit of a hand in everything we do here at Space and Time on the engineering side, so it's kind of hard to narrow down a topic to discuss today. But I thought we'd talk about something that is paramount to the entire function of the network, and that is security. So, Henry, let's talk about how Space and Time keeps the network secure. What are the guiding principles or basic building blocks of our security design?

Henry: For sure. The main thing to keep in mind is that we are a decentralized network. What that means is that we really can't have any secrets stored on the platform. This is because any malicious actor on the network could potentially snoop those secrets. Even a good actor could potentially snoop those secrets. So, traditional authentication and authorization schemes like passwords or role-based access control configuration are really not possible. The primary way that we solve this is by implementing asymmetric encryption for validating any authentication or authorization requests. What that means is that there are public keys and private keys. The users own their own private keys, and the platform just stores the public keys. Public keys aren't a secret; there's nothing that can really be done with them other than validating signatures coming from a user's private key.

Catherine: From the user perspective, what does the process of authenticating with Space and Time look like?

Henry: The primary way that users authenticate is to access our APIs, so I'll talk through that. First, users request a challenge that's tied to their username. The platform will randomly generate the temporary challenge for them and give it back to the user. The user encrypts that challenge with their private key to produce a signature. Once they have that signature, users can send that signature back to the platform. And the platform will verify that against their username and their public key. If that validation succeeds, ultimately the platform will create an access token and provide that back to the user. Our access tokens are JWTs, which are bearer tokens commonly used in the API world. Once a user has an access token, in following API requests, they can just provide the access token. This way, users don't have to calculate a signature every time they send a request.

Catherine: Interesting. Yeah, that seems like the perfect solution for accessing the network. On our side, what methods of authentication are supported?

Henry: So, another guiding principle was that we wanted to be flexible, and support was most common in Web3, which means that we support both Ethereum wallet based authentication as well as Ed25519. An important point to note here is that Ed25519 is better for developers building apps that are going to authenticate with our platform, whereas Ethereum wallet authentication is primarily used in our web app.

Catherine: So, we've talked about authentication, which is how we grant users access to the platform. But the other basic component of platform security here is authorization, or how we permission the different resources in Space and Time. What does the authorization solution look like?

Henry: Great question. Yeah, that's similar to authentication. So, just like the access token, for authorization we use bearer tokens to authorize requests. Now, the only difference is that instead of a JWT, we use biscuits.

Catherine: Tell me more about biscuits.

Henry: Sure. Biscuits are authorization tokens designed for decentralized verification, offline creation, and attenuation, and then a payload based on a logic language. Which really is perfect for our use case, because it allows users to fine-tune the access control they want, and there's really not a lot of complexity that we have to deal with on our side. So basically, just as a user would have a public/private key for authentication, a resource would have a public/private key associated with it. When a user creates a table, they provide that public key and then they generate biscuits with the private key as well as whatever access control configuration they want. And that biscuit will have a signature, based on that private key, that can be verified with the public key. All platform resources will be tied to this public key that the user provides. And then anytime those resources receive a request, the platform validates the signature against the resource public key.

Catherine: Wow, sounds complex. So, what if I want to create a table that anyone can read from but only I can write to? Do I have to share that biscuit with the entire world? That seems a little unpractical.

Henry: Great question. So, in addition to our biscuit authorization, we've also defined a variety of security models that allow for a more general configuration on a resource. For example, to answer your question, it's very easy for a user to specify a security model when they create a resource, like a table, that anyone in the world can read from that table, but only they can write to it, without needing to provide a biscuit.

Catherine: How do we ensure that, say, Henry's data warehouse doesn't have access to my private data if it's on his cluster?

Henry: Yeah, good question. Currently, we're building a platform-managed encryption solution, which is really powerful because it allows users to configure at the detail level, the column level, what they do and do not want to encrypt. We also provide powerful primitives such as format-preserving encryption, which just means that the encrypted data will be in the same format as, or look similar to, the unencrypted data, making it harder for snoopers to understand what is and is not encrypted.

Catherine: Wow. Yeah. That's fascinating. It's been really cool to hear about how deeply we've thought about security design for the overall platform and how thoroughly we are securing user data. I think that's one of the most important things to our users, knowing that their data is secure and managed appropriately on the decentralized network. Henry, thank you so much for talking to me today and shedding light on this topic, and we look forward to doing it again. 

Henry: Awesome. Thanks, Catherine.