How we protect our most sensitive secrets from the most determined attackers

Are we talking the real most determined attackers like the US or China who can easily deploy $10B (i.e. a team of ~3,000 people fulltime for 3 years) for a strategic advantage?

Or $1B (i.e. ~300 people for 3 years) which is within reach of every government, international criminal organization, and thousands of multinationals?

Or $100M (i.e. ~30 people for 3 years) which is now just a line item for those organizations?

Or $10M (i.e. ~3 people for 3 years) which is 10x better than the "gold standard" used by every other bank in the world, but still profitable for small criminal outfits doing ransomware attacks?

Are there any legally binding marketing statements made by any associated security executive on where they sit in these 4 orders of magnitudes of "most determined attackers"?

It is frankly absurd that we continue to allow statements like "secure", "reasonably secure", "most determined", or whatever without expecting some degree of quantification within 4(!) orders of magnitude. If you can not quantify or demarcate an accurate lower bound within 4 orders of magnitude you probably have no idea what you are doing.

https://www.iana.org/dnssec/archive

https://www.iana.org/dnssec/ceremonies

https://www.youtube.com/channel/UChND9hEeJQjtLDFZ-m8U47A

Source: formerly at one of the largest banks.

I mean it's seven, it's literally written in the attached PDF describing the ceremony procedure.

[1] https://github.com/iana-org/coen

Point being that yes, you need to ensure that your root certs are super secure and that you have a full documented, videotaped chain-of-custody. But then at some point you need to use that root cert to sign some other cert that DOES live in your infrastructure and is used to sign requests. How do you control your systems at the point where you need to use your cert (or a cert chain) to sign requests that by their nature must be connected to the Internet?

I think this is an unfortunate framing. The property of public key cryptography is that unlike secrets such as passwords only one party has the private key. This instantly eliminates an important class of potential problems.

And unlike with something sophisticated like an asymmetric PAKE, I think it is relatively practical to explain this benefit to end users, Monzo's counter-parties can't lose a private key they don't have and can't produce signatures from Monzo themselves. If there are signatures that shouldn't exist Monzo knows the problem necessarily must be with their systems.

British Banks rely far too much on trust. A symptom of this is that periodically a big merchant (e.g. a supermarket) will accidentally run a transaction feed twice (e.g. all card transactions at Tesco on Thursday happen twice). The bank could insist (as it does for its own personal account holders) that these transactions have unique IDs authenticated by the card, which would thus mean the duplicates are rejected, but it trusts these huge merchant customers, so all the transactions they say occurred are just assumed to be fine, and the result is that the banks eat a bunch of customer anger and costs. It was remarkable to me that this would happen in 1995. It's outrageous that it still happens today, but it does.

It's an interesting contrast with how carefully root CA keys are handled in this kind of setup, compared to things like Kubernetes clusters, where you'll typically get 3+ root CA keys in the clear on the API server disks, and I've seen them committed to configmaps (e.g. in RKEs default setup), and even checked into GH repo's...

presumably this is kept in a locked cabinet, in a basement locked room, behind a sign "BEWARE OF THE LEOPARD"

Admit it...y'all just want a good reason to go to MicroCenter, right?

HSMs should only sign messages if a minimum number of authorized users request the message to be signed (by its hash), and downstream systems should only trust messages signed by a quorum of HSMs (at least 2).

For banking as an example, each bank should require some minimum number of distinct authorized signatures on each transfer request from another bank.

Individuals can have a personal public/private key, but HSM actions should also require multi-signature requests from both the user key (stored on FIDO2 or smart card) and a device signature from a list of devices the user is authorized to use, which reduces the risk of rogue devices tricking users into signing requests.

Go back to using bog-standard laptops everywhere because no single device is in the critical path of security; if a single HSM loses its keys then have it generate new ones and add the new keys to the set of N possible keys allowed for root signatures and remove the old one. Only if too many HSMs need to have their keys restored would administrative users have to resort to SSSS to recover all HSM keypairs at once, but the procedure would be done one HSM at a time with potentially different sets of users responsible for recovering each HSM. There never needs to be a single set of people that can restore the entire PKI; instead have K groups (for K KSMs) of N people, of whom M of each group are required to restore an individual HSM, where only L HSMs are required to operate the PKI. There can even be some intersection between the groups of users per HSM so long as the intersection between any two HSMs < M.

I wish it was available as a reproducible build on F-Droid. That's how critical apps ought to be distributed.

This is a common trope in security-oriented businesses: more security is a good thing, but the consumer often isn't afforded the same attention.

It is a shame the article doesn't bother to cite nor link to its source.

I wonder if Monzo has done a similar deep dive into how they structure their architecture/security practices to protect against the threat of this information+encryption keys being stolen.

Any Devops on HN to tell us about the last time they implemented a change on a Monzo API ?

404 is it a private repo?

This sentence made me believe in the incompetence of the authors.