intunderflow

> If the intermediate is compromised you'll need to do a new key ceremony with the root to sign a new CRL, correct?

You can use Validation Authorities to avoid needing the full on root that can issue new certs just to revoke an existing one. https://en.wikipedia.org/wiki/Validation_authority

PKI revocation as a technology is definitely not the greatest thing in the world, the best protocol at the moment is OCSP with a specifically configured Validation Authority. But even then quite a lot of OCSP implementations in modern software are configured to continue if they can't make a connection.

Fortunately, because the usage of our CAs is very tight to Monzo and our partners, we can reach out and explicitly ban a certificate from our machines (and tell partners to do the same) without too much trouble (as compared to Public CA's who have no chance of being able to do this) in addition to following normal PKI revoking procedures.

Mint roots, sign intermediate CSRs

Everything lives in safes and those safes are covered by cameras, if you try to drill the safes you'll be found (or heard) a long time before you manage to break in

This will probably come in a future blog post (and also I don't lead this part of secret management so I don't have all the context), but our Intermediate's mostly live in nice locked down machines in AWS (avoiding exact product names because I don't want to tread on other peoples toes)

There's definitely a much bigger risk with an intermediate on the internet, however we at least have the mitigation of being able to revoke it if it goes wonky, the main priorities I see in this space are: (1) minimising the chance of a compromise as much as possible (very clear and well defined communication channels so that as few things are open to even being poked at for vulnz over the network as possible) and (2) being ready to react if there is a compromise (revoke the cert and recover)

We have an open API https://docs.monzo.com

Yeah this is confusing but that repository is basically just for Monzo employees, sorry :( https://news.ycombinator.com/item?id=29266757

We're going to remove that link

This is covered more here https://news.ycombinator.com/item?id=29266521

Sorry for not being up to your standards I guess :(

Qubes is awesome, I think the main thing it protects against though is an application you don't trust too much escalating it's privileges (for example a website sandbox escapes into the browser and then tries to go up further) - Since we're on an air-gapped, immutable system all the tools we have on our CD have some implicit trust, so if you manage to get software that isn't playing nice onto the OS, you've probably done it through hijacking the OS CD anyway (I covered a similar-ish question here: https://community.monzo.com/t/how-we-protect-our-most-sensit... )

We also don't run that many complex commands on the actual OS, it's basically one of three things 99% of the time:

- Mount this CD containing some CSRs or etc

- Ask the HSM to please sign this

- Burn a CD with these files and then report the hash / PGP word list of the content on the CD

Kickoff was 18th of October after I indicated to someone internally that I wanted to write something for the blog about this program (not gonna name them in case they don't want to be named :P)

First draft (very rough) was 22nd October

Second draft (toned around a bit) was 5th November

Security review + a proper edit happened while I was on Holiday on the week of 8th-12th November (lots of comments left for me), basically nothing got removed, I think one image and about 2-4 lines of text from memory

I came back to a bunch of comments (nearly all on the Monzo Tone of Voice https://monzo.com/tone-of-voice/), went through those, proof-read and then got a green light from:

- Engineering

- Marketing + Press

- Some other folks in Security (because of the content)

And then we moved this over from Google Docs where I was drafting it into our Blog system (Contentful), had a quick skim to make sure it read properly and then published :)

We haven't gone as far as a Faraday Cage inside an anechoic chamber because we think the risks of these attacks is (luckily) not big enough (yet) for now to justify these. Eventually though? Maybe.

There's also projects to guess keystrokes based on sound which don't even require you to be on the host device https://news.ycombinator.com/item?id=29266783

Funny you mention this because the SCIF tech specs from DNI.gov are cited a lot in our physical security envelope docs, interesting but very terse read, I wouldn't read the whole thing for fun: https://www.dni.gov/files/Governance/IC-Tech-Specs-for-Const...

I'd skip to Chapter 2: Risk Management and Chapter 3: Fixed Facility SCIF Construction

There's some interesting attacks based on working out the sound of each key on a keyboard and then guessing keystrokes - https://github.com/ggerganov/kbd-audio

I should have linked to an internal page that redirected there so people didn't get a misleading 404, but the internal coen repo is only open to all Monzo employees not the public because it contains some HSM specific stuff :( sorry - the public coen (which we're a fork of) is open though here https://github.com/iana-org/coen

I'm not paid enough to generate primes for RSA by hand :P

This is only for managing the most important secrets of all which are kept offline in safes for most of the time, development work just happens on regular Macbooks, I'm currently sat in my Bedroom writing this and I run this program / authored this blog post.

These sorts of precautions are pretty common at large companies, there's some good coverage of them generally here: https://en.wikipedia.org/wiki/Offline_root_certificate_autho...

This is only for secrets that are incredibly important to the point that their undetected loss could cause massive problems, I run these key ceremonies and I'm typing this from my bed on my work issued Macbook :)

A few things:

- Since all the components we purchase are kept air-gapped, you'd need to already be on a machine in the air-gapped system (which isn't assembled and powered on except when we need to deal with key material) to exploit a vulnerability

- We're keeping things as minimal as possible in what we trust from coming out a store, for example if we purchase a Laptop we gut it of most of its components before it goes near our key material, Laptop's dont need batteries (or even CMOS batteries) to run basic live systems so they're going out.

- Compromising one part of the system won't let you sneak private key materials out on its own by-design, the part we've tried to make the hardest is exfiltration, the only material that leaves the air-gapped system leaves either as QR codes on a screen or on CD-R drives that we keep for years in a safe in their own tamper evident bags. This is all part of an effort to try and make sneaking private material out (even if you had full control of the system) as difficult as possible to do without being detected.

(Disclaimer: I'm the author) the thought of using pencil and paper to do elliptic curves bends my mind

Delegated Proof of Stake is pretty cool, particularly as its applied in Nano (instant and feeless transactions), if someone manages to combine that with the transaction privacy of Monero that would be awesome in my view.

Like many laws, IP law doesn't apply to big powerful companies unless they go after another big company

I felt a great disturbance in the force, as if millions of pagers suddenly cried out in terror

I wouldn't hold your breath

Anything thus far on how they got in? Was it phishing, zero day, etc?

It works though. It turns out if you give people a platform a lot of them are willing to do free labor for little of value in return, just look at the explosion of games that rely on UGC like Roblox, or (as the author points out) Reddit. Even here we submit articles and get given points.

Why pay people when they're perfectly happy to work for (effectively) free?

Roblox made their developer tooling require you to be always online and signed in, even though it doesn't actually need this to function. This means that all development workflows have been bricked during this outage too. https://twitter.com/RBXStatus/status/1454815143607607300/pho...

Completely dead with nothing working, main site drops a maintenance page: https://roblox.com

They had an incident in the past where they returned nil for all get operations to their database, that caused some chaos at the time so it's not unprecedented: https://devforum.roblox.com/t/update-datastores-incident-dat...

There's probably a lesson in here about managing incidents, very few updates or acknowledgments there's even a major problem.

Will be interesting to find out what caused an incident big enough to kill their entire platform for so long (if they release details or they come out through the grapevine)

Repository to verify QR codes locally: https://github.com/ehn-dcc-development/ehn-sign-verify-pytho...