Mike Hearn, London 2014 [video presentation]

[TruckStyling]

What about a scenario brought up by a reddit user: a hotel clerk in a tourist destination handles a hundred international passports in a day. Is there some way they can surreptitiously grab a signature from each of them and use them for an attack?

Isn't necessary.

There were already three announcements (just on this forum) that big database dumps of x00.000 real passport data records with signing keys (if holder applied for passport with keys) will be released if this stuff doesn't stop.
It's known from most countries that only 5% till 25% of the passports are signed. Reasons: people don't want that and passports with keys are more expensive in applying fees. People who dont applied for keys get passports contain that an empty or dead chip, depends on country.

[NanoAkron]

TruckStyling, thank you for bringing this up.

Centrally issued external tokens are inherently corruptible. This is why bitcoin exists in the first place - to transfer value in a decentralised, trustless manner.

If Mike Hearn cannot think of a means of trusting nodes that does not require a zero-trust, decentralised solution then I suggest he waits until someone else develops one.

[trilli0n]

Several posts on reddit indicate lists of passport numbers exist. If this is true, it would be trivial to obtain a large number of proof of passports.

And I am really struggling with the problem that this is supposed to solve. Mike gives an example where someone enters a public place, and connects to the internet using a random wifi hotspot. This hotspot is then not a real hotspot but a fake one set up for this man-in-the-middle attack. It creates a simulation of the bitcoin network with fake nodes to trick the connected clients that they are connected to the real network. A transaction by the client would seem to have gone through fine, however it would never be sent to and confirmed by the real nodes.

So, for this attack to work, someone must be tricked to connect to the internet through a malicious provider, and chose not to verify adequatly whether his transaction has been accepted by the network.
I think this attack vector is difficult to execute because it relies on a naive and careless user connecting through a malicious link. Tricking a node into connecting through a malicious link is already an aspect of this attack that is difficult to carry out on a large scale anyway. And it seems that the proposed solution does not resolve the issue at all.

Indeed, there must be a better way of making it impossible to impersonate previously seen peers, up to a point where this attack becomes unfeasible. For instance, by implementing a challenge-response between nodes, such that nodes can verify that a node they connected to a month ago is still the same node now and not part of some instant simulation. Do this for a couple of nodes, and in this way it can be verified that at least some nodes (ones that had been seen before) are the same one as during the first time a connection was set up with them. This would require a man-in-the-middle attack using a simulation to convince a node to send its transaction while only connected to nodes it sees for the first time. A node that usually sees a number of known nodes would be alerted by this and can refuse to send the transaction, especially when connected through a previously unseen (wifi) internet link.

Sorry for blatantly reposting my reddit comment on this issue, but I care about it.

[erik777]

We are talking about new relative node trust options on this thread.   

Our setup is we don't want any external dependency, third parties, or general human trust.  Obviously, you can't completely evade the concept of "trust" in this problem, but you can make your solution depend on the trustless network instead of externally or on people-based attestation.  You can develop relative trust based on context using facts derived from the Bitcoin network itself. 

I'd create a new thread, but we're still waiting for Mike to say he's throwing out the ePassport idea.  Until then, we're determined to help the OP on that thread. 

[Mike Hearn]

What about a scenario brought up by a reddit user: a hotel clerk in a tourist destination handles a hundred international passports in a day. Is there some way they can surreptitiously grab a signature from each of them and use them for an attack?

Yes. Passports don't have PIN numbers attached because they're meant to be used with biometrics instead. The zero-knowledge proof of passport is really a proof of passport possession.

For a corrupt hotel clerk to create ZKPOPs they'd just have to do the same process as ordinary users - scan the photo page or type the BAC details in by hand, then NFC scan the passport chip and process the output. If a customer can see their passport at all times this shouldn't be possible without arousing suspicion. If they take it away then they could do it.

Is this a problem? Well, it's not ideal, but any security system has to make a tradeoff between usability and robustness. In this case the usability would be pretty good if you have an Android NFC phone and a laptop (the SNARKS are too intensive to create on a phone so you'd need a computer to help it), I think it'd not make setting up a node much harder. Certainly it's more complicated and lower throughput than building a botnet.

If you wanted to solve this anyway, you would have to pair it with some third party that verified your face against the passport data. For instance, pick one of N third parties who do a Skype video chat with you, where you hold up a word they give you on a piece of paper, and then it's matched against the passport. Obviously this is more complicated, expensive and involves introducing more ID verification authorities who do the face matching. It may still be easier/cheaper than what Bitcoin exchanges make people do though.

So I tried an app out with my phone and it read the biometric,photo and ID details fine. The security info says the signatures are OK but it seems there is no "Active Authentication", meaning the passport could be cloned.

Biometrics data is unreadable because it's encrypted under a key only governments have (edit: to be more precise, the passport challenges the reader which must sign with a country-specific key). The rest of the data is encrypted under a key derived from the photo page because it's just a copy of what you can already see.

AA is irrelevant for this scheme. I mentioned it in the talk only to introduce the "real" solution. AA lets you prove ownership of the passport over the internet by challenging it with a nonce that's signed, but it doesn't provide any way to hide data so it can be anonymous.

[waxwing]

<snipped>
AA is irrelevant for this scheme. I mentioned it in the talk only to introduce the "real" solution. AA lets you prove ownership of the passport over the internet by challenging it with a nonce that's signed, but it doesn't provide any way to hide data so it can be anonymous.

Thanks for the answer. I watched the video again and understand a bit better what you're aiming at. I think I get the interaction between elements now: AA prevents cloning, but we don't have that in practice. Also, ZKP wouldn't work with AA because AA checks a signature, but to do that you have to have a pubkey (something like that?)


But on the other hand ZKP + Skype seems to make no sense; I mean, yeah, *some* data might still be hidden but really it does destroy anonymity, in a very visceral way..

Looking at this combination of elements I can't see how it's going to work - assuming (a) AA destroys the possibility of anonymity and/or (b) AA isn't available, as is the case today for most countries(?)

[Mike Hearn]

Well, AA is best seen as a feature intended to stop you copying the data from one passport to another. The private key used in AA can't be exported from the chip. I guess it's not popular because the physical anti-cloning features might be good enough to keep passport fraud at acceptable levels, and anyway, duplicating an existing passport must be much less useful than creating an entirely fake one - the digital signatures are enough to tackle that.

With ZKP you don't need AA at all, it just has no role to play.

[Mike Hearn]

BTW the slides are here:

https://docs.google.com/file/d/0B4t9VJLm_PWhRkFKa1pQTm54WU0/edit?hl=en&forcehl=1

[waxwing]

Well, AA is best seen as a feature intended to stop you copying the data from one passport to another. The private key used in AA can't be exported from the chip. I guess it's not popular because the physical anti-cloning features might be good enough to keep passport fraud at acceptable levels, and anyway, duplicating an existing passport must be much less useful than creating an entirely fake one - the digital signatures are enough to tackle that.

I do agree that it makes sense that AA is not seen as a priority, because the intended use case is to compare the person with the passport - in that scenario cloning is not quite so big a threat.

With ZKP you don't need AA at all, it just has no role to play.

But without AA you have no meaningful protection against cloning, so I can't see what defence there is against Sybil if you also want anonymity. (Assuming I was correct about my interpretation of why ZKP+AA doesn't work, was I?)

[Mike Hearn]

The attack you're talking about is the bad hotel clerk, right? So AA doesn't achieve anything there because they aren't "cloning" your passport in the sense of making a copy of it, they're just temporarily gaining access to it.

In theory, with AA you could literally attach your passport to your bitcoind full node and have it respond to a challenge on every new connection - this would solve the bad hotel clerk attack because you'd need ongoing access to the passport to run the anti-sybil algorithm. But yuck. Not convenient, not anonymous. We want a one-shot process that derives some data from a single possession, otherwise it's too inconvenient. ZKP does that, but if you only need a single possession, then .....

.... hmm this line of thinking yields a new idea. Perhaps to create this proof you could prove possession of the passport twice, separated in time. Sure, sometimes you give up your passport for a brief period. But probably not for a month at a time. Unfortunately the proving process doesn't have any notion of time. It might be possible to use the block chain, but I'm not sure and would have to think about it more.

Anyway all this is highly theoretical for now. It's not even possible to try implementing until the SCIPR group open source their code.

[Mike Hearn]

Oh, for the face match thing - it can be "anonymous" in the sense that all they need to do is match two faces together. They wouldn't necessarily have to know the real name/location/birthday/etc matched with the face. Someone has to check it though. There's no other way to prove you're the "real" owner of the passport vs someone who borrowed it for a bit.

[tvbcof]

Yes. Passports don't have PIN numbers attached because they're meant to be used with biometrics instead. The zero-knowledge proof of passport is really a proof of passport possession.

For a corrupt hotel clerk to create ZKPOPs they'd just have to do the same process as ordinary users - scan the photo page or type the BAC details in by hand, then NFC scan the passport chip and process the output. If a customer can see their passport at all times this shouldn't be possible without arousing suspicion. If they take it away then they could do it.
....

Last time I was in China, my 'building got in trouble.'  As a lodger, I noticed this because I got a note saying they needed my passport for a day and instructing me to drop it off at the lobby.

I did not wish to give up my passport.  As a compromise a van load of cops, and a box of about 100 passports, and me made our way to the police station.  I gave my passport to a lady in the front room of the station.  She copied something off it by hand and handed it back.  The cops too the box of remaining passports into the back room and kindly gave me a lift back to my point of beginning (and didn't even beat me up!)

Thankfully there is no corruption in China and the people are to unsophisticated to do anything with electronic hardware so there was no danger to the passports.

It's a bad idea to let go control of one's passport.  All the travel literature says so.  The trouble is that it is relatively easy for authorities (and others) to make that become the most rational thing to do.  It's also a marvelously stupid idea to give someone the password to one's on-line bank account yet enough people will do it so that Coinbase offers it as a 'service'.


BTW, you know who doesn't fuck with the cops?  The Chinese!  The reaction from my friends when I told them I had to go to the police station was a half a second of wide-eyed terror.  It was similar to the reaction of the round-table participants at the 2013 San Jose conference when it sunk in that the audience question guy was talking about mixing private keys (which I found telling about the methods of blockchain analysis that are likely underway or being contemplated.)

[waxwing]

The attack you're talking about is the bad hotel clerk, right? So AA doesn't achieve anything there because they aren't "cloning" your passport in the sense of making a copy of it, they're just temporarily gaining access to it.

I was thinking that the hotel clerk attack was possible *without* AA. But the rest of your reply makes me see we're basically on the same page now - the only way it works is with repeated challenge-response, which means you need AA or the Skype thing, which is a pretty nasty hack that people probably won't go for.

[Mike Hearn]

You could start out by just not doing any face matching and if people do start stealing/borrowing passports to do sybil attacks, see if people are willing to "upgrade" later. It's easy to map out all kinds of possible attacks on any system, but whether they end up occurring in practice or not is often a bit of a crapshoot.

[waxwing]

You could start out by just not doing any face matching and if people do start stealing/borrowing passports to do sybil attacks, see if people are willing to "upgrade" later. It's easy to map out all kinds of possible attacks on any system, but whether they end up occurring in practice or not is often a bit of a crapshoot.

Difficult to argue with that, but on the other hand - weaknesses attract attacks, even ones that look unrealistic.

One alternative point of view is to say that the attack you proposed, basically a "spoof the bitcoin network" attack, is best defended against with existing authentication systems. I know it's not trendy to say, but I would view it like this: if I do a localbitcoins trade, I'm going to go to https://blockchain.info for my confirmations, as well as using a node or electrum wallet on my laptop. These two separate channels make an attack monstrously difficult to mount from outside. If my laptop is compromised fully, then nothing I can do on it will help - so if I'm paranoid (or don't trust my own opsec), I use another channel - probably not my own phone in that case, rather ask the coffeeshop owner to double check blockchain.info.

This approach makes more sense to me.

[NanoAkron]

You could start out by just not doing any face matching and if people do start stealing/borrowing passports to do sybil attacks, see if people are willing to "upgrade" later. It's easy to map out all kinds of possible attacks on any system, but whether they end up occurring in practice or not is often a bit of a crapshoot.

Great idea Mike, start with it as optional verification and later ensure it becomes compulsory.

I'm trusting you less and less with this. You need to recognise how wrong you are with the idea of using external tokens to verify nodes and admit this.

[trilli0n]

To mitigate an ad-hoc Sybil attack, isn't it sufficient to be able for a node to discover the following circumstances:

• peers which have been seen previously (pre-Sybil attack) are either no longer available or imposters,
• all available peers which act normal are previously unseen peers.

If a Sybil attack is staged using a malicious wifi hotspot in a public place, it can essentially be detected by looking for these conditions.

Right?

[Mike Hearn]

Nodes don't have any way to authenticate themselves currently so you can't do that.

If you could do that, the question is what do you do next? Can you tell the difference between "the nodes I was previously using have simply gone offline because I was away for a month" vs "I am being attacked"?

[trilli0n]

Nodes don't have any way to authenticate themselves currently so you can't do that.

For this a simple challenge-response can be used, and setting up a secure channel using a shared secret exchanged during the first time they discovered each other.

If you could do that, the question is what do you do next? Can you tell the difference between "the nodes I was previously using have simply gone offline because I was away for a month" vs "I am being attacked"?

No, but in your own example, you mention:

• walking into a coffee shop and connecting through a random, never seen before hotspot,
• not wanting to wait for confirmations of a transaction.

If under these circumstances, none of the nodes I have seen before appear on-line, then that would be more than a little suspicious, and I can either try to use a different channel to connect to the internet, or simply wait for any transaction to confirm, or both.

In general, it is suspicious if all nodes on the network seem new from one moment to the next.

This would sufficiently solve a Sybil attack, which is quite difficult to execute already, and, by your own words, has never been performed before.

This Proof of Passport just seems a solution in search of a problem. And the solution does not even work.

[waxwing]

Now we've had a chat about it, my view of this is starting to crystallize. The problem for me is not so much that the trust root being proposed is governmental (although I don't like it). That is not so far away from using a corporation as a trust root. The problem is fitness for purpose. These passport systems were designed to match a physically present human being to an entry in an ID database. They don't provide for a uniqueness guarantee combined with anonymity, even using ZKP (from our conversation thus far).

Using passports in this way is hacking in the purest sense. These approaches *can* work, for a while; for example using Amazon as trust root in an oracle as we did in the ssllog project, actually does work - but it may break at any time in the future, precisely because our intended functionality is of no interest to Amazon, and that's the same problem you have with passports. And unlike the Amazon oracle, I don't think this passport system even works right now (I mean assuming the snark/scip/zkp or whatever stuff works), because of the mismatch I mention above.