Live data from Hacker News

Crypto Anchors: Exfiltration Resistant Infrastructure

diogomonica.com

51–59 of 59 posts

Re: Crypto Anchors: Exfiltration Resistant Infrastructure

#51
post #20

If you're serious about preventing exfiltration, you'll do what the military does and use data diodes https://en.wikipedia.org/wiki/Unidirectional_network On a slightly tangent, people with physical access to a server can extract encryption keys from RAM by plugging into a PCI slot: https://github.com/ufrisk/pcileech

I think what will (should, perhaps?) ultimately happen -- and this is probably still years off -- is that we will stop using default routes on (most) hosts.

Publicly accessible servers and such will, of course, still have them, but things like, say, internal database servers or the PC belonging to Debbie in Payroll, won't.

Access to things outside of the "local network" (i.e., a company's entire network, not just the directly-connected subnet) will go through an intermediary (e.g., an HTTP(S) proxy) that performs per-connection authorization with a defauly deny.

It may end up looking a little differently than this -- a default deny on all outgoing IP traffic, for example, with only specific traffic permitted -- but I believe that, eventually, this is how we'll keep random hosts from being used to exfiltrate mass amounts of data.

TL;DR: Companies need to start filtering outgoing traffic and not letting any random host on the internal network connect out to any other random, arbitrary host in the world. This will be inconvenient and expensive (to manage), however, so we'll need a few more Equifax's before it begins to catch on.

Re: Crypto Anchors: Exfiltration Resistant Infrastructure

#52

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.

I bought a "real" HSM off of eBay (used, of course) a couple weeks ago but, unfortunately, it's apparently broken and so I need to return it. The price of these things is huuuuuge and that puts them out of reach to all but large companies. I think that Amazon is trying to solve that problem but, yeah, if I had that much to spend I would just buy a couple outright (they'd pay for themselves in a few months, compared to CloudHSM).

Re: Crypto Anchors: Exfiltration Resistant Infrastructure

#53
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…

HSM have other security properties that you cannot replicate with software. They are tamper resistant in a way a regular server is never going to be, and they have been engineered to prevent sidechannel attacks. The latter is something very hard to prevent with a regular server.

I agree that for the majority of usecases, a HSM is not necessary, but they do bring security to the table that a simple auth server cannot, at least not without significant engineering effort.

Re: Crypto Anchors: Exfiltration Resistant Infrastructure

#54
post #50

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…

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

1. Out of curiosity, do you actually do this? (The first part you propose.)

2. As a theoretical solution it is a bit weaker than the "simple" solution I think Google should obviously do, because under your proposal different spammers can coordinate, invalidating your privacy. (You didn't tell two different unrelated sites that you're the same person, but actually you are, which they could build into a targeted profile if they coordinate or, for example, are owned by the same parent company.) Granted this is a theoretical concern but it is there.

Re: Crypto Anchors: Exfiltration Resistant Infrastructure

#56
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…

This can't be too hard to build: 1. Generate 16TB of random data, backup/replicate many times 2. Think of data as 16 billion 1k pieces 3. Generate 64 random piece addresses using hashA(key) as seed 4. Concatenate the 64 pieces into one 64k chunk, and store hashB(chunk)

How about this? Take the old Blowfish block encryption algorithm and eliminate the key expansion and expand it so that the s-boxes and p-array take up 16TB of data? What you'd wind up with is a block cipher that has a 16TB key. Since Blowfish is clearly "prior art," and is unencumbered by patents, this might make this approach harder to attack using patent law.

Re: Crypto Anchors: Exfiltration Resistant Infrastructure

#57
post #50

Earlier quoted context omitted.

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

1. Out of curiosity, do you actually do this? (The first part you propose.) 2. As a theoretical solution it is a bit weaker than the "simple" solution I think Google should obviously do, because under your proposal different spammers can coordinate, invalidating your privacy. (You didn't tell two different unrelated sites that you're the same person, but actually you are, which they could build into a targeted profil…

Not exactly - a little more complex actually.

I have two emails: super_private@gmail.com which is only handed out to people I know in real life...I've had this one since 2004 and I still get zero unwanted emails on that address. Then, I have another address, super_public@gmail.com which mass forwards all mail to my super_private email, which then filters it according to the rules I've set up.

The reason I have the extra layer of indirection is because it wouldn't by very user friendly to force someone you know to email you with a plus sign and then some junk. This way I can give a 'normal' email address to normal people, and my filtering email address to auto signups and things like that.

2. You're right - I guess I'm not too worried about a profile being built for me, but this definitely would not handle that issue. I also use anonymous remailers like getnada.com if I am signing up for something which I think is particularly embarrassing if it gets out, but that is rare.

Re: Crypto Anchors: Exfiltration Resistant Infrastructure

#58
post #57

Earlier quoted context omitted.

1. Out of curiosity, do you actually do this? (The first part you propose.) 2. As a theoretical solution it is a bit weaker than the "simple" solution I think Google should obviously do, because under your proposal different spammers can coordinate, invalidating your privacy. (You didn't tell two different unrelated sites that you're the same person, but actually you are, which they could build into a targeted profil…

Not exactly - a little more complex actually. I have two emails: super_private@gmail.com which is only handed out to people I know in real life...I've had this one since 2004 and I still get zero unwanted emails on that address. Then, I have another address, super_public@gmail.com which mass forwards all mail to my super_private email, which then filters it according to the rules I've set up. The reason I have the ex…

thanks. I also have set up forwarding on some gmails. it's a bit of a pain.

Re: Crypto Anchors: Exfiltration Resistant Infrastructure

#59
post #37

Earlier quoted context omitted.

That is an excellent idea. But why 16TB of random data ? Why not encrypt some high entropy value (digits of pi, whatever) with a 100 character password and generate 16TB like that. You then use the 16TB as a password but you could regenerate and recover using a scrap of paper.

You can do either. But if you generate the data pool from a seed that you retain, then you're back to trying to protect a 256-bit value from leaking. Generating the data pool with constantly cycled and discarded keys (i.e. /dev/urandom) means the only way to have the pool is to go and get every single bit of it. We went the second route because I like sleeping at night and it just felt like retaining a seed would def…

Sure, but that's a 256-bit value that does not have to be present at the use point. So it's a lightweight anchor ! It's extremely heavy when someone else tries to move it, and yet when you move it yourself, it easily fits in your wallet on the tiniest of sd cards, or even on a scrap of paper.
Post reply on HN