Infrastructure as Code (IaC) has a property that there doesn’t seem to be an intuitive answer to: managing holistic state versus managing a subset of state. Terraform seems to have the hardest time with this; when managing state of a deployment, when is it easier to manage just a single application compared to managing all state in one deployment. This becomes exasperated when the underlying infrastructure or platform that the application lives on is also managed by IaC, and perhaps making changes is destructive to the original deployment. Doing all of the management in one deployment does mean that there’s less messy dependencies and ordering issues when deprovisioning, but making changes to whole swathes of infrastructure in one unwieldy state ultimately feels like a double edged sword. My bias may come from using Cloudformation, where a single account exists and exports manage relationships between stacks, but that also does not feel like a correct answer for all cases either.

I recently read Cryptonomicon, a novel by Neal Stephenson, where one of the characters develops a cryptosystem, Pontifex, based on a deck of playing cards. In reality, Bruce Schnieder made the system, and is a symmetric key system stream cipher, and while slow appears robust. I haven’t put in time to investigate the system for flaws or weaknesses, but I had a thought: what about a similar encryption system for use with a deck of Magic: The Gathering cards. There are some facets to this system that put restrictions on key creation. Depending on the format, MTG decks can have multiples of cards; the format Commander only allows single copies of cards (except for lands), and is a 99 card deck, increasing the key size. A useful deck would likely need more than one basic land, but not nessicarily; there may be a way to allow multiple basic lands by means of having different printings of each land. Pontifex uses the value of each card in the system, and each card is only printed a single time in each deck of cards. With thousands of MTG cards, it may be impractical to have each card have a unique value associated with it, except cards printed after a certain date (the majority) have a collector number associated with it. Each set of cards has collector number 1-(number of cards in the set), as so by prefixing the set number (by release date), there would be a unique number for each card, to be added and modularlly added to the plaintext to retrieve the ciphertext. This may be completely overbuilt and impractical, as it would be extrememly tedious to do by hand, but exploring the crytographic properties is interesting.

A collection of some thoughts about BZT, zero trust solutions, and zero trust in general.

Device-aided BZT

Trusted device start is an important factor in a zero trust architecture. Storing a secret key in a TPM and using that Key to authenticate a device and encrypt is a solid baseline to work past in the boot process.

Such a process would look like storing a secret key in the TPM, and use it with the IPSEC daemon. IPSEC policy drops non-IPSEC as normal to and from devices. Client auths normally over strong auth when attempting to use application traffic.