Crypto Anchors: Exfiltration Resistant Infrastructure
diogomonica.com
Crypto Anchors: Exfiltration Resistant Infrastructure
1–10 of 59 posts
Re: Crypto Anchors: Exfiltration Resistant Infrastructure
#2So can you do any of this in a public cloud setup or is this an argument for having infrastructure that you control directly?
(I think AWS might have launched some sort of HSM service, but I haven't looked at the details and not clear if it could provide the right sort of guarantee)
Re: Crypto Anchors: Exfiltration Resistant Infrastructure
#3So can you do any of this in a public cloud setup or is this an argument for having infrastructure that you control directly? (I think AWS might have launched some sort of HSM service, but I haven't looked at the details and not clear if it could provide the right sort of guarantee)
You can definitely do this in public cloud HSMs.
Azure: https://azure.microsoft.com/en-us/pricing/details/key-vault/ AWS: https://aws.amazon.com/cloudhsm/
The only thing you're not able to do in a public cloud is run these in Secure Execution mode—where you get to actually execute arbitrary code inside of the enclave instead of just doing operations with keys that are protected by the HSMs.
Re: Crypto Anchors: Exfiltration Resistant Infrastructure
#4One of the great things that helps when building a crypto-anchor enabled infrastructure is to have Mutual TLS between all applications/containers. This allows you to authn/authz and only allow connections from specifically allowed apps/containers/microservices.
Mutual TLS can be a bit of work to get set up but leads to huge security wins over time as every RPC within your infrastructure is mediated by an authorization layer. We've helped out a bit with the SPIFFE project which is looking to make mutual TLS easy: https://spiffe.io/
Re: Crypto Anchors: Exfiltration Resistant Infrastructure
#5Another form of "crypto anchor" is Blind Hashing which uses a large pool of random data to defend the hashes. An attacker would need to exfiltrate over 90% of the data before they could run an offline attack on hashes blinded by the data pool. The bigger the data pool, the more data an attacker would have to steal, and the more hashes/sec you can run.
So while iterative/computational hashing is only secure if it is slow and if the password is strong, Blind Hashing prevents offline attacks even against weak passwords and actually runs faster as you increase the cost factor.
In this case it's more like an an actual anchor -- technically we call this Bounded Retrieval Model -- the idea that we size the network bandwidth to make it take 300 days at full line rate to steal the data over the network. So it's a physical limitation rather than trusting a black box to protect 256 bits like an HSM.
If you're interested here's an intro [0], a tech spec [1], and an academic paper [2] by Moses Liskov at MITRE.
Disclaimer: I'm Founder/CTO of BlindHash.com which is basicallly Data Pool as a Service -- we provide an API into a geo-replicated 16TB (and growing) data pool.
[0] - https://s3.amazonaws.com/blindhash/BlindHash+Architecture+Gu...
[1] - https://docs.wixstatic.com/ugd/005c1c_5996c661899e4d09a28b9a...
Re: Crypto Anchors: Exfiltration Resistant Infrastructure
#6Folks shouldn't necessarily be scared off by the use of HSMs in this model -- HSMs are an add-on that adds an additional layer of security. That said, there are still significant wins to segmenting the applications that hold keys, particularly if they are on hosts separate from your front-end or application logic hosts. This architecture still forces attackers to only have access to data within your infrastructure, which allows your detection systems to have a chance to catch people before they leave with all the data.
Re: Crypto Anchors: Exfiltration Resistant Infrastructure
#7Same common sense logic
Re: Crypto Anchors: Exfiltration Resistant Infrastructure
#8One of the great things that helps when building a crypto-anchor enabled infrastructure is to have Mutual TLS between all applications/containers. This allows you to authn/authz and only allow connections from specifically allowed apps/containers/microservices. Mutual TLS can be a bit of work to get set up but leads to huge security wins over time as every RPC within your infrastructure is mediated by an authorizatio…
SPIFFE's lucky to have Docker, Google, and others helping drive forward the idea of consumable service authentication frameworks like SPIRE. OSS was just launched a little more than one week ago (https://blog.scytale.io/say-hello-to-spire-7e133fad72ca).
Re: Crypto Anchors: Exfiltration Resistant Infrastructure
#9I am ambivalent about using HSMs to protect password databases, because if you're going to do that, you might as well simply introduce a minimalized authentication server (ie: something with an interface). It'll have approximately the same attack surface, it actually helps your architecture in other ways, and it precludes attackers from getting hashes in the first place (at least, the same way an HSM does with the HMAC key).
A Go, Rust, or (minimal, non-framework) Java authentication server speaking HTTPS to solely that AuthN interface and sharing no database with anything else is extremely unlikely to be part of any realistic "kill chain"; it'll be among the last things on your network compromised.
Meanwhile: you get to stick with technology you fully understand and can manage (simple HTTP application servers and a decent password hash) and monitor.
HSMs have a lot of uses elsewhere in secure architectures, but the password storage use case is overblown.
Re: Crypto Anchors: Exfiltration Resistant Infrastructure
#10I am ambivalent about using HSMs to protect password databases, because if you're going to do that, you might as well simply introduce a minimalized authentication server (ie: something with an interface). It'll have approximately the same attack surface, it actually helps your architecture in other ways, and it precludes attackers from getting hashes in the first place (at least, the same way an HSM does with the HM…
But if you have your authentication server, that server becomes a target. And unless you're using an HSM under the hood, you're still exposed to hashes being stolen.
I think the idea of the author is to protect the operation with hardware.