Topic: Nakapay - Looking for feedback and discussion (Read 2289 times)
Bumping for further interest.
Just a wallet that has integrated the protocol.
Does this work for you?
Could you maybe illustrate your idea graphically or with pictures, rather than a text-based description?
Might help me get my head around it.
Might help me get my head around it.
Bumping for more discussion.
No problem. Like I said before, I don't even think the 2nd signature is necessary... but what I've learned pitching this is that developers are cautious in the extreme, so if the 2nd signature needs to be part of the protocol before they'll integrate it, then that's what needs to be done.
Okay - well that makes a bit more sense.
I don't have time to look into it more now but hope I've helped at least let you explain your system a bit better.
I don't have time to look into it more now but hope I've helped at least let you explain your system a bit better.
The signature isn't published, but rather the receiving address that is always used by that particular server. All this is relayed via POST in my API.
So for example, let's suppose an invoice looks like this...
1BsxY5CntmGxhiG6oRoWMQH46NJGzFbhdm
CIYAM
1BTC
24hours
123ABC
HIqMau/YWyWnWDqdtCwDvpKgNg3esXRij6C8bYoSqjrN7bAvUJRsK0epASyzug65ilC3CTMfrDX7M9fznWLbLM0=
HPCymODWJcKkiM351czoB6uBIaKHMHueKpO2uGbvCAtjTBdD1F0yJ0/PWHMMNh/H7gIkUjsmuLLC6ZB4aTHmCLM=
There are two signatures. The first lines 1-5 signed by 1BsxY5CntmGxhiG6oRoWMQH46NJGzFbhdm, which might be your receiving address in the above example. The second is lines 1-6 signed by Nakapay's publicly known receiving address that is hard coded into the wallets that pull invoices from Nakapay.
You can verify that 1MDwHwniq6qnbieBhhU1kZbgZuhoajc7MD signed it.
So for example, let's suppose an invoice looks like this...
1BsxY5CntmGxhiG6oRoWMQH46NJGzFbhdm
CIYAM
1BTC
24hours
123ABC
HIqMau/YWyWnWDqdtCwDvpKgNg3esXRij6C8bYoSqjrN7bAvUJRsK0epASyzug65ilC3CTMfrDX7M9fznWLbLM0=
HPCymODWJcKkiM351czoB6uBIaKHMHueKpO2uGbvCAtjTBdD1F0yJ0/PWHMMNh/H7gIkUjsmuLLC6ZB4aTHmCLM=
There are two signatures. The first lines 1-5 signed by 1BsxY5CntmGxhiG6oRoWMQH46NJGzFbhdm, which might be your receiving address in the above example. The second is lines 1-6 signed by Nakapay's publicly known receiving address that is hard coded into the wallets that pull invoices from Nakapay.
You can verify that 1MDwHwniq6qnbieBhhU1kZbgZuhoajc7MD signed it.
But how does the client *get the valid signatures* of the servers in the first place?
(this is the attack vector most likely to be used)
(this is the attack vector most likely to be used)
Well SSL is a given, but with the signature system I'm proposing, I'm not sure it is even necessary.
The goal is to know that a particular paycode corresponds to a particular invoice AND that the invoice hasn't been modified. If multiple servers are returning identical merchant signatures and they are all returning valid server signatures, whether the certificate is valid doesn't seem to matter. So if you were running a server, you'd simply publish a receiving address and sign all valid invoices with it. Anyone with the ability to mimic your signature also controls your wallet.
Even this, assuming multiple servers are used, isn't enough to divert payment - they need to do this to other servers as well to convince wallets that such invoices are legitimate.
The goal is to know that a particular paycode corresponds to a particular invoice AND that the invoice hasn't been modified. If multiple servers are returning identical merchant signatures and they are all returning valid server signatures, whether the certificate is valid doesn't seem to matter. So if you were running a server, you'd simply publish a receiving address and sign all valid invoices with it. Anyone with the ability to mimic your signature also controls your wallet.
Even this, assuming multiple servers are used, isn't enough to divert payment - they need to do this to other servers as well to convince wallets that such invoices are legitimate.
But again *how are you securing this*?
My guess is via https and the CA system (how else?).
There have been many recent attacks made upon https and the CA system so I would be very wary about promoting the safety of it.
My guess is via https and the CA system (how else?).
There have been many recent attacks made upon https and the CA system so I would be very wary about promoting the safety of it.
Just a quick question - suppose that the server itself also signed the invoice. So when you enter a code, your wallet is presented not only with the signature of the merchant, but also the signature of the paycode server based on a known, static, receiving address. Would such a thing stop the attack?
Now anyone impersonating Nakapay, for example, would also need to control the publicly known Nakapay address.
Same with all the other paycode servers. So the invoice signatures generated by the merchants are all returned identically, but the paycode server signatures all need to match their respective receiving addresses.
Now anyone impersonating Nakapay, for example, would also need to control the publicly known Nakapay address.
Same with all the other paycode servers. So the invoice signatures generated by the merchants are all returned identically, but the paycode server signatures all need to match their respective receiving addresses.
Again - I don't think you have *stopped* the attack vectors but I do wish you the best of luck with this.
My personal opinion is that you should consider "stealth" and how that might be able to be used with your idea.
My personal opinion is that you should consider "stealth" and how that might be able to be used with your idea.
The wallet determines which paycode servers from which to pull invoices. If 4 servers are altering the contents of invoices, there are 2 possibilities. Either all the signatures match, meaning they are all being attacked in the same way at the same time by the same person ... or the signatures are all different, in which case no one is paid because no wallet developer would write his app in such a way that when a paycode is sent, and 5 different signatures are received, a random one is chosen.
Further, a good wallet developer would be picky about which servers he uses. So instead of using the Nakapay server, plus 4 others of unknown origin, he's using 5 servers that are tenuously presumed to be trustworthy.
Further, a good wallet developer would be picky about which servers he uses. So instead of using the Nakapay server, plus 4 others of unknown origin, he's using 5 servers that are tenuously presumed to be trustworthy.
Again you are not handling MITM attacks.
The client may *think* they have 4 valid servers - but they may be actually all be MITM attacks.
How do you *verify* the servers?
The client may *think* they have 4 valid servers - but they may be actually all be MITM attacks.
How do you *verify* the servers?
Further, with the federated paycode server model, they'd need to overwrite the existing invoice on multiple servers simultaneously in order for it to be effective.
An attacker would only need to DOS the other servers such that the attacker's server is the only working server that remains (this is similar to what can happen with Electrum clients that don't do full SPV; the Electrum client does do full SPV but there's at least one client I'm aware of that uses Electrum servers but doesn't do SPV).
This is interesting, but it can easily be written into the logic of the paying wallet that if such a thing were to happen, no one gets paid. For example, suppose that there are 5 paycode servers running. If 4 are unresponsive and one is left - the wallet will know that something is amiss and the wallet simply doesn't allow any payment with this method at all.
With only 6 hex digits it would be way too easy for someone to "mine" an equivalent "address" so I don't see how this can work at all.
IMO QR codes are the best approach by far.
IMO QR codes are the best approach by far.
My thoughts exactly. My 3 year old GPU can generate SHA256 hashes at a rate of about 70M/s. 6 hex digits == 2^24 combinations. 70M / 2^23 (combinations on average to find a collision) equals about 0.1 seconds time to fake a paycode.
The signature doesn't seem to help, either. It only proves that an invoice is signed by someone. Of course if a paycode server were to fake an invoice, they would create a perfectly valid signature signed by themselves.
Maybe, if the invoice and the paycode both covered the exact same set of data, such an attack would be more difficult, but at first glance this doesn't seem very safe from MITM.
It does actually. The paycode itself is derived from the contents of the invoice and generated by the merchant himself. The paycode is then incorporated into the body of the invoice and the entire thing is signed using the receiving address of the merchant.
Further, with the federated paycode server model, they'd need to overwrite the existing invoice on multiple servers simultaneously in order for it to be effective.
An attacker would only need to DOS the other servers such that the attacker's server is the only working server that remains (this is similar to what can happen with Electrum clients that don't do full SPV; the Electrum client does do full SPV but there's at least one client I'm aware of that uses Electrum servers but doesn't do SPV).
The issue is going to be MITM attacks.
You are going to have to rely upon the CA system and OpenSSL (and you might have noticed the various serious issues with that in recent months).
You are going to have to rely upon the CA system and OpenSSL (and you might have noticed the various serious issues with that in recent months).
With only 6 hex digits it would be way too easy for someone to "mine" an equivalent "address" so I don't see how this can work at all.
IMO QR codes are the best approach by far.
IMO QR codes are the best approach by far.
My thoughts exactly. My 3 year old GPU can generate SHA256 hashes at a rate of about 70M/s. 6 hex digits == 2^24 combinations. 70M / 2^23 (combinations on average to find a collision) equals about 0.1 seconds time to fake a paycode.
The signature doesn't seem to help, either. It only proves that an invoice is signed by someone. Of course if a paycode server were to fake an invoice, they would create a perfectly valid signature signed by themselves.
Maybe, if the invoice and the paycode both covered the exact same set of data, such an attack would be more difficult, but at first glance this doesn't seem very safe from MITM.
Jump to: