The Ka-ching Project

[Norway]

The goal of the Ka-ching project is to make NFC payments with Bitcoin Cash (BCH) as convenient as possible with reasonable security.

Ka-ching is an open source project.


Github repository: https://github.com/NorwayGH/Ka-ching
Website: Ka-ching.info
Email: admin@ka-ching.info


Picture this: You pay for your goods by holding your ring against the NFC POS terminal in a store. Ka-ching! You have now paid with Bitcoin Cash.

It’s all about making a great UX. Better than contactless creditcards without PIN, or mobile payments.

A contactless creditcard has to be dug out of your pocket or handbag and put back after use. You have to keep it in a geeky, shielded wallet if you want to protect yourself from digital pickpockets. You can not choose the limits for how much you can pay without a PIN code.

Phones are equally clumsy. You have to keep them charged, dig them out of a pocket or handbag and put them back after use.

With a Ka-ching rubber bracelet or ring, you can go straight from a swim in the ocean to the beach bar and buy a beer.


Security
Bitcoin experts are trained in thinking about extreme security. Therefore, it can be difficult to start thinking about reasonable security. The Ka-ching will have a button that needs to be pushed during the transaction. This is to prevent digital pickpockets to steal your funds. In the case of a ring, the button will probably be on the back side of the ring, letting you hold it in with your thumb. Or the button is under the flexible NFC antenna, so you can push it against a surface to activate.

Ka-ching is not push. It's pull. Or semi-pull? Hard to define. But you hand over your total funds to the merchant and ask him to take as much as you have agreed on. Some trust is involved.

But what if someone steal your ring? Well, thieves steal gold rings. And phones. And creditcards. And cash. But people still use them. Maybe you take off jewelry or an expensive watch in a rough neighbourhood at night, or keep your handbag closer in a bar. Key words: Reasonable security.

You are not supposed to have a lot of money on your Ka-ching. Just enough for everyday shopping. And if you pair your Ka-ching with your phone, you can auto-refund at a level of your choice.

Ka-ching is inspired by Peter Rizun’s SigSafe project. And it can be used the same way as SigSafe. You can use the Ka-ching to have a multisig vault on your phone. And you may re-fund your Ka-ching from that vault. The two concepts work great together in the same phone app!

A Ka-ching device will be able to send and receive money straight out of the box. But it will work even better if you pair it with your phone. After pairing, you will get notifications on your phone about how much money the merchant took from you. And if you lose your phone, your Ka-ching or both, you can recover everything (vault included) with a twelve word seed backup.


Form Factor
Ka-ching is a tiny NFC antenna and micro controller. No need for battery! Waterproof! Cheap! It’s open source, so everyone can make them. And designers can get creative and put them in jewelry, bracelets, rings, inside jacket sleeves, at the end of a zinger, on handbag straps, inside your gloves, on headset cables, you name it!


Protocol
A Ka-ching device is able to do all the things mentioned and more with just a few simple rules:

- Send it’s public key or address or xpub key. (TBD. Input from you, please!)

- Sign transactions given to it with it’s stored private keys and return the signed transaction.

- Overwrite private keys with new private keys. (When you “pair” it with your phone, you will generate new keys from the seed, transfer funds to a new address and overwrite the old keys with new.)


For all this to work, we need to specify the Ka-ching protocol and convince POS terminal makers like Ingenico all over the world to add some new software to their existing hardware.

I will lead this project, but I will not be the developer, as I haven’t coded in many years.

Make some noise in the comments below if you think this is a great idea or a security nightmare.

Let’s kick some butt in the payments space!


Background:
@Peter R 's video about SigSafe:

How small an NFC chip is today (video down on the page).
https://www.adafruit.com/product/2800

[THIS FIRST POST WILL BE EDITED CONTINOUSLY AS THE PROJECT DEVELOPS]​

 

[Bagatell]

Well the automotive industry is moving in a keyless direction..

http://gear.landrover.com/me/en/discovery/interior/function-technology/lr091580-activity-key-wristband/

https://senturionkey.com/

Good luck with this!

 

[Tom Zander]

This might be exciting. Any update?

 

[Norway]

@Tom Zander
I don't have much of an update now. I'll try to get some code out at some point. I'll keep you updated.

 

[Norway]

A creative guy in Tokyo (Richard) suggested this attack:
A sneaky employee makes your device sign two transactions. One for the shop, and one for himself. The transaction for the shop is broadcasted at once. But his private transaction is broadcasted later to remove the connection between the transaction and the shop.

I haven't gotten started with writing the initial code yet (waiting for a possible code donor), so I don't really know how the life cycle in a NFC powered microchip is. But I assume it's like a normal computer. If you take the battery out of and back into a phone or unplug and replug a computer without battery, the program starts from the top. So you basicaly have to allow just one signing per reboot.

We have to be aware of this exploit in the development.

Thanks, Richard!

(BTW He also envisioned how you could have a pressure activated implant in your fingertip without losing the sensitivity of your fingertip skin.)

 

[Tom Zander]

@Norway I sent you an email on the admin address you posted, did you get that? I don't have any other addresses of yours.

I like the attack, creating thinking. Thats useful. I think its not very hard to make sure that only one transaction can get signed every 10 seconds or so.


Ideally you have some sort of indicator, like a led, which blinks after signing.
Then you have to press a little button to turn off the led and maybe press the button and the thing will only listen for signing for 3 minutes after you pressed it, avoiding "accidental" signings.

 

[Norway]

@Tom Zander
Thanks for the heads up on the email. I have made it forward to my regular email now. A response is on the way.

Yes, I think it should be pretty easy to stop this two-sig-attack now that we are aware of it.

I don't think it should have a led if this can be avoided. If you have paired it with your phone, you may hear a sound from your phone or a nice buzz in your pocket. You will also get a receipt of the transaction on your phone you can check if you want to.

I don't think it can keep track of time, as it has only electricity when held in the inductive field from the active nfc device. And I don't think it's needed if we can use a one-boot-one-signing approach.

 

[Richard3]

Hi Norway and friends. This is such a cool project and I had lots of fun chatting about it in Tokyo.

My background on this is that I've been looking for an open-source POS terminal (hardware and software) capable of taking crypto that I can recommend to merchants to make the brick-and-mortar BCH payment experience better. I haven't found one so I'm thinking of starting a project, which would obviously be quite complimentary to Ka-ching. I'm hoping to meet the MiniPOS creator at the BCH conf in London in a few weeks and see what his thoughts are, and I'm going to message some local NFC experts and see if I can get them to come along too. I also bought a Poynt dev kit so will see what that's capable of.

An important part of all this is the application later protocol for the air interface. Knowing as little as I do about NFC my guess is there are roughly three options (or phases):

1. Non-standardised proof-of-concept. Terminal sends an unsigned tx or a bitcoincash URI with amount parameter. Device responds with signed transaction. Simple encoding right on top of NDEF. This could be done with a dev kit like a rasberry pi / arduino or maybe even a smartphone but it would not be interoperable.

2. Narrowly (BCH only) standardised interface such Bitcoin Payment Protocol (BIP70) exchange. This could become the basis of something interoperable but would require the merchant to select BCH or at least BIP70 / "cryptocurrency" on the terminal as opposed to contactless credit/debit card. For Ka-ching (no internet connection) I'm not sure if BIP70 allows the device (customer) to pass the signed tx to the terminal (merchant) for relay instead of doing the broadcast itself. This would be nice to solve anyway so that non-internet connected mobile devices could make payments.

3. Find or develop an extensible and interoperable standard that would allows merchants to enter just the amount, then the terminal presents a single request but containing multiple options, thus leaving it to the customer to tap a credit/debit card (EMV standard), Ka-ching (BIP70) or mobile device with BCH or another cryptocurrency.

 

[asdeideas]

It looks really good. Is it totally safe?

 

[Norway]

@asdeideas
No, it's not totally safe. Nothing is. People can steal your gold ring.

It's reasonably safe.

 

[Thomas Bakketun]

The activation button is important for this wallet. It has to be small, cheap, durable, waterproof and reliable. Is it possible to achieve all these properties?

 

[Tom Zander]

My background on this is that I've been looking for an open-source POS terminal (hardware and software) capable of taking crypto that I can recommend to merchants to make the brick-and-mortar BCH payment experience better.

There are a couple now.

The minipos one is great for smaller companies. The getting-started time is really good, just slightly worse than using your private phone wallet.
The downside is that there is trust involved, which for businesses translates into risk. This risk will be ok for low number of payments and thus small companies.

I started one as part of Flowee, called "Flowee Cashier". It is an open source project based on Qt, so you can deploy it to almost any sort of hardware. The UI is written in QML which is javascript based and as such clients can likely find someone easy to tweak it for their personal style (company logo, tablet form factor etc).
The main difference here is that Flowee Cashier requires a Flowee the Hub running, which has the requirements of a full node. As such this is for the larger companies and larger volumes as the cost is higher but the risk (the trust in external parties) is practically zero.

I've managed to put in double-spend notifications in the hub, the Cashier app will soon display them on screen.

 

[Norway]

So this is what the program on the Ka-ching device will look like:

1. Read the local private key.
2. Generate the public key.
3. Send the public key over NFC.
4. Wait for one of two events.

5. Event I: A payment.

• The device receives a transaction.
• The device signs the transaction.
• The device sends the signed transaction.

6. Event II: New private key

• The device receives a new private key.
• The device overwrites the old private key with the new.

And that's it!

It will be more complicated programming on the NFC terminal side (mostly "traditional" wallet stuff). But the Ka-ching device AND the Ka-ching protocol will be as simple as described above.

 

[Norway]

I will explain how this simple program and protocol above unleash the sexy power of Ka-ching:

- To receive money, you just have to go to line 3 in my "program". The counter party sends to that public key.

- To send money, see line 5. The receipiant of money will publish the signed transaction if he wants the money, right?

- To pair your Ka-ching with your phone (This is a little more tricky, but not very tricky):

1. The phone generates a new private key like most wallets does. This key can restore absolutely everything if you lose your phone, Ka-ching device or lose both at the same time!

2. Prompt user to make a 12 word backup seed.

3. The phone reads the public key of the device (let's assume it has money).

4. The phone creates a transaction that sends all the money from the old public address to the new, and sends it to the device.

5. The phone receives the signed transaction and broadcast it.

6. The phone ask you to tap your device for the second time against the phone and overwrites the old private key with the new one. (After checking it's now empty.)

You now have a phone wallet that can do all of these things:

- Give notifications (beep/buzz), receipts and history log for all Ka-ching transactions.

- Recover a lost Ka-ching with the seed.

- Have a multisig vault where the phone doesn't store one of the 2 of 2 multisig keys like Peters SigSafe.

- Have a traditional phone wallet that may also refund the Ka-ching automatically.

- Have easy refund-from-vault where you just tap your device to your phone to refill it.
[doublepost=1523971718][/doublepost]Note: The phone wallet will use a hieracical deterministic (HD) scheme to create all private keys, for the vaults, traditional phone wallets (single sig, private key stored on the phone) and any Ka-ching you pair it with.

 

[Norway]

Path forward:
After we have a working prototype and a video of how awesome it is, I will reach out to to Bitcoin.com and other wallets to get Ka-ching integrated in their wallets.

I will reach out to Bitpay, and I hope their relationship with Ingenico, the largest POS terminal producer in the world, is still active.

As I'm trying to establish a protocol, I might reach out to the Bitcoin Cash Fund for help with graphic presentations, videos etc.
[doublepost=1523974043,1523973169][/doublepost]I should probably start or be part of a company creating and selling these tiny NFC devices dirt cheap on Internet, and we should probably have the chips custom made for this purpose.

The reason for this, is to make them accessible in an early phase. But I welcome competition, it's open software and open hardware. Anyone can make them.

 

[Tom Zander]

The device sings the transaction.

Do you include loud-speakers? Or just a 3.5mm jack?

Anyway, love the typo.

The device overwrites the old private key with the new.

I think this is too simplistic since it can loose your funds still locked in that private key.

Ideally you have two "secrets" on the device. One is the private key and one is a device-specific secret. Like a pin, just not that trivial to hack.
When you pair with the device you need to read the manual and copy the factory-default PIN into your phone app and set it to a new one that from then on is the only one that can replace the private keys.

 

[Norway]

@Tom Zander
Lol, fixing typo now!
[doublepost=1523983173][/doublepost]And finally, some push back on the security model! Thank you, @Tom Zander !

A bad person or bad software program can always take or erase your money as long as you hold down the activation button.

Don't write software on the phone/NFC POS terminal that does that!

The phone should always check if the public key (address) is empty before it overwrites. Software that fails at this, will not be used by people in the long run.

Your idea about a static factory pin and static private key will just strengthen the attack from a malicious factory worker. If you pair it with your phone, you remove this attack vector and get a lot more security.

Less is more

EDIT: If you pair it with your phone by moving funds and overwriting the old private key with a new one that you have backed up with a seed, you remove this attack vector and get a lot more security.

EDIT2: Sorry @Tom Zander , you didn't say that the private key should be static. Still, I don't think people should have to keep a piece of paper (manual) to perform these tasks. If you control the button, you control the Ka-ching. It may be more demanding to write good software (like checking the public key's funds before overwriting) but this should be easy for the user. Not the developers.

 

[Tom Zander]

I have some problems with your security model.

1. the phone generates the private key. This begs the question why you have an air-gapped device that signs. Best to make the phone generate some randomness and then the ka-ching creates the private key so you can be certain nobody knows it.
   I'm not entirely sure why you want to do seed backups. Are you sure thats a required feature? It makes the user experience a LOT worse.
   
2. I don't like the idea that having physical access allows me to destroy the money on the ring, mostly undetectable by the owner (i.e. different than physically destroying it).
3. I don't like that you have to pair with the device. That again gives special privileges to some online device that can be hacked.

My suggestion with regards to a pin is that it makes your device really yours. Just like an iphone can't be formatted and given a new user-id, your kaching can't either anymore.
The idea was indeed not a static pin, that is just to get you started. You need to set your own pin or else it will refuse to create new private keys (and thus be perfectly trackable on the blockchain).

As said, I don't think you should pair. And you should not make the phone create your private key. Because both of those undermine the benefits of it being an off-the-internet hardware wallet.
Any phone or generic NFC device should be able to be used to interact with the ring. No phone should be special and have more rights. I honestly don't see why you need that anyway.

I would invite you to think about real world usecases that this will be used for. And even more which it will not be meant for.
For instance if you decide that this is only for daily payments then you should ask, do I really ever expect so much money on the address that I need a backup of the private key? Afterall, I expect a ring is harder to "misplace" than a wallet and most people have no issues carrying around a bunch of bills in their wallet.
[doublepost=1523986257][/doublepost]

As I'm trying to establish a protocol, I might reach out to the Bitcoin Cash Fund for help with graphic presentations, videos etc.

Can you explain how a protocol needs videos?

I actually expect we can make it work with just minor modifications to bip 70, basically adding the NFC pairing, which needs to be tested before written up.

 

[Norway]

Again @Tom Zander , I enjoy your push back. This means a lot more to me than the cheap "likes" (but I enjoy them too, he he). And coming from you, they mean even more.

Initially, I wrote this:

Bitcoin experts are trained in thinking about extreme security. Therefore, it can be difficult to start thinking about reasonable security. The Ka-ching will have a button that needs to be pushed during the transaction.

And I think you might be the typical bitcoin expert I have in mind here.

1. We have to compare this to current phone wallets like Bitcoin.com's wallet and Trezor. I think the key generation procedure is a hell of a lot better on Trezor compared to Bitcoin.com wallet in terms of how the seed is comunicated. As McAffee pointed out, let's assume that your phone is taking a screenshot of your seed words.

The "vault" I'm describing in the Ka-ching-system is vulnerable to this attack. So it's worse security than Trezor.

The SigSafe approach, will make the vault better than a Bitcoin.com wallet (1 of 2 keys are not stored on the phone), but not as good as Trezor. It's still vulnerable to (systematic and patient) screenshot attacks.

The entropy and randomness issue is not really related to what I have described. I think it could be a problem how both Trezor and Bitcoin.com wallet does this today (I might very well be wrong here), but I think it's solved in a good way by www.bitaddress.org. Let the user draw random lines on their phone to generate entropy.

2. Well, that's how it is. Anyone with access to the button on your ring and a phone to sweep it can take EVERYTHING! It's a fundamental premise. See my quote above. (And if you have paired it with your phone, like most people should do, you will get a notification about it happening). Your biggest problem in this scenario should be that somebody just steal your phone.

3. You don't have to pair it with your phone! Pairing will give you these advantages compared to not doing it:
- Your "own" private key and backup seed. (Vulnerable to screenshot attacks by NSA and Samsung employees.)
- Defence against dishonest people in the manufacturing process of the Ka-ching.
- Direct alerts of the transaction on your phone. Note that a malicious merchant/shop employee doesn't know if you have paired your Ka-ching or not. Will he risk his job?
- Full recovery if you lose phone and/or Ka-ching device.
- Multi sig vault on your phone. (1 of 2 keys not stored on your phone.)


You don't want to make this "yours" like an iPhone. Think of it as a vessel that just carry your everyday cash (+extra functions). Like a leather wallet for cash.

No NFC device is special here. If you hold down the button, any NFC device can take everything. Pairing doesn't give exclusive rights regarding spending of funds or the right to change the private kye on the device. I'm sorry if I haven't made that clear at this point. I know I don't express all the context I assume people should know, and I will try to get better at this.

The usecase is everyday payments, with an upgraded vault security compared to Bitcoin.com's wallet. (Protects against phone hacks that access private keys like SigSafe did. But not against screenshot attacs in the seed generation and recovery phases.)

In fact, Ka-ching combined with the vault (SigSafe) function is a very sweet and elegant combo! But you need a Trezor or something else for high amounts.

Ha ha, a video is not good for specifying a protocol. But it can be a powerful tool to establish one. To show people why it's a good idea with this protocol.
[doublepost=1523991041][/doublepost]Regarding BIP 70, I think it all can be done on the phone/POS Terminal side. Ka-ching is just a dumb, blind signing device.

EDIT: In fact, I think Ka-ching does what BIP 70 does natively. It just signs a transaction and gives the transaction to the payment processor so they can do whatever they want with it. Like checking if everything is OK before it hits the blockchain.

 

[Tom Zander]

> We have to compare this to current phone wallets like Bitcoin.com's wallet and Trezor.

I hope you can challange the status-quo more than that.

You set out to create a 100% hardware wallet and the first thing you do is remove most of the benefits of this by making an internet connected device create the private keys.

You have an awesome idea that has practically zero user interface (learning curve extremely flat) and you then go and make seeds, backups, phone apps and lots of complex stuff.



> And I think you might be the typical bitcoin expert I have in mind here.


I'm arguing for no backups and a once in a lifetime re-pin (which addresses the trusting the hardware-makers issue). Are you sure that my suggestions are those of an overexcited expert? I don't let you off the hook that easy, the proposals I made will have the effect to make the user interface dead-easy. Saying I'm an bitcoin-expert is a weird defence.
[doublepost=1523993635][/doublepost]

You don't want to make this "yours" like an iPhone. Think of it as a vessel that just carry your everyday cash (+extra functions). Like a leather wallet for cash.

Where this comparison falls down is that I can ask you to send me a payment and instead of taking your money I overwrite your private key. Your design makes a normal action and a destructive action have 100% the same user interface and priviledge levels (a botton press). Thats going to cause people pain.