Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Crypto Anchors: Exfiltration Resistant Infrastructure

diogomonica.com

Post reply on HN
Print view View original

41–50 of 59 posts

Re: Crypto Anchors: Exfiltration Resistant Infrastructure

#41

Post by praxis23 »

jondubois wrote: post #25

The thing about security is that there is a point where you end up locking yourself out. Locking your data to your hardware raises the question of what would happen if the hardware failed? Also at first glance this seems to introduce difficulties with scalability across multiple machines. Also it might make it difficult to switch between infrastructure providers. The cost of this approach should be mentioned as a foo…

Smaller userbase means less damage for data holder (the company), not the actual damaged party (person, whose password is leaked). It's not the type of attack implemented on the threat vector that matters - you remove one, you introduce another, it's inevitable cycle of change. The problem is that this is a threat vector and it needs to be solved for no matter how large the sensitive dataset it.

So, yeah, the problem is political in a way that everyone is coming with their own agenda into it, which has little grounding in reality, yet affects decisions of many people substantially.

Re: Crypto Anchors: Exfiltration Resistant Infrastructure

#42

Post by praxis23 »

zaroth wrote: post #5

Another 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 s…

Even though I adore the concept (remember the original posts by J.Spilman in 2012 and kept rolling it in my head for a while), this introduces new remote SPOF for authentication process, doesn't it?

Re: Crypto Anchors: Exfiltration Resistant Infrastructure

#43

Post by joveian »

zaroth wrote: post #5

Another 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 s…

A similar technique can be used in embedded systems to enhance the speed that password derived keys become unrecoverable from memory after power off: instead of storing the key directly, store it as a value that must be xored with a hash of, say, 4k of random values that are only stored in memory. Then your key is fully unrecoverable after any 256 bits of the 4k bytes have decayed as long as the RNG used to generate the random bytes is suitable and the executed code (including the OS if there is one) is verified to not store temporary values that could be recovered.

For password authentication, IMO a much better solution is to generate strong random passwords (21 character base64) for users and tell them to write them down and/or use a password manager (I think web browser based storage of generated passwords can be done without the user needing to see the password at all). You can still memorize a small number of those over a few weeks if necessary and there is no good reason to memorize a bunch of passwords.

Re: Crypto Anchors: Exfiltration Resistant Infrastructure

#44

Post by cimnine »

jondubois wrote: post #25

The thing about security is that there is a point where you end up locking yourself out. Locking your data to your hardware raises the question of what would happen if the hardware failed? Also at first glance this seems to introduce difficulties with scalability across multiple machines. Also it might make it difficult to switch between infrastructure providers. The cost of this approach should be mentioned as a foo…

Commercial HSM have ways of exporting the key they hold onto smartcards. Usually the keys are split onto a number of smartcards, let's say 3. For increased robustness, each third is written to two smartcards. (We now have 6 cards.) These smartcards each belong to one person, who is the only one knowing the PIN that protects the third of the key it holds. Each of these smartcards is then brought to different bank vault, sealed in tamper-proof bags.

To restore the key, you need to bring 3 out of 6 persons to the so-called key ceremony, and each has to bring his smartcard and his PIN.

The same mechanism can be used to provision multiple HSMs with the same key material. But there are other means to do this. As soon as two HSM share a common secret, also known as Key Sharing Key, they are able to exchange all key material they possess in a secure manner.

Some HSM don't even bother to store the keys they generate within the bounds of their hardware. Only it's master key is stored in it's hardware, any other key is encrypted with the master key and stored on a shared filesystem.

If this sounds artificial to you, let me assure you that such procedures are in place at various companies who deal with raw credit card data, at least in Europe. The EMV committee, the PCI organization and each issuer of credit card do mandate such procedures.

And they are very strict. We once had to ship HSMs back to the vendor, because at some point they were not supervised by at least two persons. (At least the documentation thereof was missing.)

Re: Crypto Anchors: Exfiltration Resistant Infrastructure

#45

Post by cimnine »

cimnine wrote: post #44
jondubois wrote: post #25

The thing about security is that there is a point where you end up locking yourself out. Locking your data to your hardware raises the question of what would happen if the hardware failed? Also at first glance this seems to introduce difficulties with scalability across multiple machines. Also it might make it difficult to switch between infrastructure providers. The cost of this approach should be mentioned as a foo…

Commercial HSM have ways of exporting the key they hold onto smartcards. Usually the keys are split onto a number of smartcards, let's say 3. For increased robustness, each third is written to two smartcards. (We now have 6 cards.) These smartcards each belong to one person, who is the only one knowing the PIN that protects the third of the key it holds. Each of these smartcards is then brought to different bank vaul…

... because at some point they were not supervised by at least two persons, before it was taken into operation, that is. (Afterwards, they have to be locked into a rack that requires two different badges to open it's doors and which must have a CCTV system recording it at all times.)

Re: Crypto Anchors: Exfiltration Resistant Infrastructure

#46

Post by zaroth »

praxis23 wrote: post #42
zaroth wrote: post #5

Another 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 s…

Even though I adore the concept (remember the original posts by J.Spilman in 2012 and kept rolling it in my head for a while), this introduces new remote SPOF for authentication process, doesn't it?

Very flattering that you remember :-) It's still me.

One nice thing about the design is that since the data pool isn't actually storing hashes, it doesn't change over time (except when you want to grow it) it's easy to have multiple data centers that operate completely independently.

Different copies of the data pool, different networks, different DNS, etc. The client library will retry/fail-over between data centers. So while yes, you do have to make a successful API call, it's not a SPOF.

It's very easy to replicate / add redundancy when there's no active sync required between sites. The only inter-site communication we have currently is when new accounts are created, to distribute the AppID, and to aggregate usage stats, which is batched and when it fails will just pickup where it left off once the network is back up.

Re: Crypto Anchors: Exfiltration Resistant Infrastructure

#47

Post by logicallee »

tyingq wrote: post #38
logicallee wrote: post #35

Earlier quoted context omitted.

I don't think it's a bummer that they patented it. In October of 2037 (assuming they received it today), it will be available for the whole world to use. Until then, it will still be available for the whole world to use, just for a small licensing fee. In the mean time alternatives can also be developed. This technique could have been invented and promoted starting in 1997 (20 years ago) but only through the protecti…

>Until then, it will still be available for the whole world to use, just for a small licensing fee They don't appear to be selling right to use licenses. Most of the text on their site suggests a cloud based service, which I suspect will be usage based. All that to say it is perhaps too soon to judge the end user cost as small. Maybe it will be, maybe not.

But my point in this case is that if they hadn't patented it and be pushing it we wouldn't even be talking about this. It promotes it OR alternatives.

The impact on consumers is positive even if they only get meager access for 20 years. (For example the patent owner could just be bad at economics and set their price too high, thinking they would get more profit than via wide adoption: they might not set it at the monopolist's profit-maximizing price point.)

Even so, everyone gets it after a while (20 years.)

Re: Crypto Anchors: Exfiltration Resistant Infrastructure

#48

Post by cbisnett »

Out of curiosity I went to look at the pricing for Amazon’s CloudHSM service for AWS and nearly spit out my drink. $5,000 up front cost per device and $1.88/hr and they suggest running two for high availability. At those prices I don’t think you’ll see this catch on anytime soon.

Re: Crypto Anchors: Exfiltration Resistant Infrastructure

#49

Post by ptoomey3 »

bigmac wrote: post #15
tptacek wrote: post #9

I 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…

We discuss exactly this architecture in the talk we gave back in 2014. See here for the part where we discuss it: https://youtu.be/lrGbK6fE7bI?t=16m31s Basically we 100% agree with you that an authentication service should do this job. The HSM is extra credit. Although it does help in cases where the auth service's DB is leaked through some other means (e.g. backups). I will say that I'd depart with you on the return…

We recently developed/deployed a simple “crypto as a service” API for other apps/services to use for easy encrypting, integrity protecting, etc. It was originally developed with an HSM and eventually decided to redo it without. There were lots of unanswered questions with the HSM in terms of having the operational experience to know how they would scale across data centers, how well replication would work, how well failovers would work, etc. We had much stronger confidence in a plain old golang service, MySQL, and leveraging Vault as a master key issuer. We basically key wrap/integrity protect everything in the DB and present a simple Grpc interface. An HSM would have been nice, but a small/simple service isolated from other systems largely gets us what we want, and with the confidence to scale it as we would any other application.

Re: Crypto Anchors: Exfiltration Resistant Infrastructure

#50

Post by oh_sigh »

logicallee wrote: post #35
flipp3r wrote: post #26

Earlier quoted context omitted.

This looks like a pretty good technique, that's coming from someone who has collected 240GB+ of user:password dumps. I certainly wouldn't get 16TB of disks just for that if it were ever leaked. Bummer(not for me :p) that you guys went the route of patenting it and keeping it proprietary & only available through an API. I think it would be adopted in no time if it were open source, and I'd definitely like to see somet…

I don't think it's a bummer that they patented it. In October of 2037 (assuming they received it today), it will be available for the whole world to use. Until then, it will still be available for the whole world to use, just for a small licensing fee. In the mean time alternatives can also be developed. This technique could have been invented and promoted starting in 1997 (20 years ago) but only through the protecti…

Simply filter all email to a non-plus address to spam, and then only give out random oh_sigh+aslkdfjslkdjf@gmail.com addresses. Now, if a spammer strips it off, they just get put directly into your spam box. Where stupid regexes don't like the plus, you have the . allowance for gmail, where foobar@gmail, f.oobar@, f.o.obar@, foob.a.r@, etc all get routed to the first address. gmail lets you have up to 30 character user names, so you can encode 2^28 = ~268M unique emails into that. But those sites are very rare.
Post reply on HN