Tensegrity

Silly me. I just recently realized that the t4g.small instances I’ve been eyeing have the AWS Nitro enclave stuff. This is horrendously cool technology that I thought was out of my reach given that I was focusing on cheap ass EC2 instances. Well, no need to ignore the Nitro enclaves any more.

Following the link above to the Nitro documentation from AWS will give you all the information you really need. For my use in Sky, there’s a kind of demo of what I”m currently working on in the form of a Spring Boot application running in the Nitro Enclave. This is pretty cool in that they have a nice demo of the model and it runs a frickin’ java VM in the trusted enclave. Hilariously cool.

Trusted Enclaves

The model Nitro provides is pretty nice. At the top level you have your normal application/process and you can spawn enclaves that process can communicate with over the VSock communications abstraction

The VSock interface is straightforward and – of course – it turns out that Netty already provides a socket abstraction one can use in place of the mechanism that the above demo uses. It’s pretty cool because I, your humble narrator, can use that socket abstraction to run GRPC services in the enclave, as befits a platform of civilized tastes.

The diagram above shows the current state of the Sky application, using the trusted enclave to host the Sanctum Sanctorum. The Sanctum is where all the secrets live. The enclave provides a secure host environment for the Sanctum and Sky uses that to provide the base identity and secret processing – e.g. Fernet Token generation as well as Stereotomy Identity.

Well, we’ll see, actually. I haven’t tested out the Netty VSock library, so it may fail miserably for some yet unknown reason. 🤞 I’ve added it to Apollo and started the regime of validation.

But regardless of whether I can actually get GRPC over Netty VSock to work, this really represents some amazing technology. For me, running Java in the enclave is cool for several reasons, of course, but I’m gonna run a GraalVM AOT optimized version of my evil planz in the enclave, so that will be pretty cool. Should be tiny, too, as I’m only running the Sanctum in the enclave, not the entire Sky application.

Combining the Streams

I had been working on the final provisioning pieces of Sky when I blundered into this rediscovery of what should have been obvious from day 0 – lol. So the upshot is that I can move the Sanctum Sanctorum from the current insecure execution host, into the Nitro enclave where it can nestle in without fear, as shown in the diagram above.

Basically, I just violated the “laws of distributed computing” and made a blocking, reasonably transparent interface for the Apollo ControlledIdentifier interface from Stereotomy and also exposed the KERL api. This nicely pins the set of APIs and I can then wrap the Signer and Verifier to provide the necessary foundation to run the ControlledIdentifierMember that is the base identity staple of Sky nodes.

This seems to have worked out very well, but I should get the actual Attestation flow working for Nitro enclaves, which sadly will require me to wrap a Rust! library to do all the cryptographic things necessary to validate the attestation document for these enclaves. I need to do that to integrate into the Gorgoneion attestation flow (and I can provide a nonce!).

I know some folk who love Rust! so maybe they can help me integrate that into Java. The libraries I need to use have C bindings, so perhaps that will work well enough for me and I can proceed with that. In any event, will have to figure out that in parallel with the provisioning work I’ve been doing. Just am fearing another platform specific workflow, but…

Atomic Provisioning

I did some work on the Gorgoneion attestation protocol to accommodate provisioning. This actually worked out nicely as I had already emplaced a session encryption key pair for the node. This was originally used to transport the Shamir shares when bootstrapping in that mode. However, it’s simply reused here to provide a secure provisioning channel for the shared secret from one enclave to another enclave in Sky – lol. So that worked out extremely well.

Following the natural progression of all things, that mechanism is used to provision using a short term Fernet token that can be provisioned with the node in the Environment. That makes it really simple (ish, I guess) to spin these nodes up and obviates the need to perform the attestation check using the Nitro enclave attestation document – as cool as that would be .

One of the tricky things in provisioning is dealing with attestation, of course, which is what I’m supposed to be solving with Gorgoneion anyway. And like most – if not all – of systems that manage these types of things and provide these types of services, there are race conditions around the initial establishment that are particularly nasty to resolve. And so I was quite pleased that it was incredibly straight forward to cleanly resolve the potential race conditions around initial provisioning with the humble SQL transaction.

In Apollo, and thus Sky, the model really is a fully functional SQL database. Not just some random key/value NOSQL store. In this case, what we can leverage is the ancient concept of a stored procedure. In the block chain world, there’s the concept of a “smart” contract. This is a rather poor substitute for what SQL databases have had for years in the form of stored procedures. Basically code that is run as part of the transaction, “inside the system”. The analogy stops there, of course, in that block chain does not have transaction scope, nor is any of the code that runs in a smart contract able to prevent, change or add additional data changes during the “transaction”. All normal things one can do in a stored procedure.

And these capabilities make it straightforward to implement a provisioning step without any race conditions, in a completely transactional and secure fashion. Just as nature intended. In Sky, when provisioning from a supplied, short term validity token, we simply do that provisioning in stored procedure. It may not look like much, but this is a rather important feature of Apollo: we process SQL commands at each node – it’s a replicated SQL state machine. And what that allows us to do is take advantage of an amazing variety of tools that we’ve developed over the past 50 years to solve problems like this – things like calling a stored procedure as part of the transaction.