From: Andy Schroder <info@AndySchroder•com>
To: Eric Voskuil <eric@voskuil•org>,
bitcoin-development@lists•sourceforge.net
Subject: Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback
Date: Tue, 24 Feb 2015 17:50:46 -0500 [thread overview]
Message-ID: <54ED0046.3030906@AndySchroder.com> (raw)
In-Reply-To: <54ECF7DB.3060607@voskuil.org>
[-- Attachment #1: Type: text/plain, Size: 3576 bytes --]
We can change "resource" to "Session ID" if you want.
I think the URL scheme should be:
bitcoin:[address]?r=bt:<mac>&s=<PublicKey>
But when connecting to the mac, the client indicates the SessionID in
the header, and as you say, SessionID is derived in some way from PublicKey.
This is a slightly different format than both of your suggestions below,
but seems to make more sense based on what you said in your entire
message. The other thing is it can be used with more protocols without
taking up more space in the URL.
However, by loosing the h= parameter, I think we are now loosing some
benefit it brought to https based connections if the customer doesn't
want to use bluetooth. Right?
Also, you talk about a new public key (and session ID) for each tap. I
guess I'm wondering about this though. If the public key is compromised
on the first tap, isn't their payment request already compromised?
Since we are securing everything, can we change the message header
format from what Schildbach's bitcoin wallet implements to something
more consistent? Maybe we can create a new UUID for this secure service
so Schildbach's bitcoin wallet can still maintain backwards compatibility.
Andy Schroder
On 02/24/2015 05:14 PM, Eric Voskuil wrote:
>> * Add a "s=" parameter that uses a unique public key for each session.
>> This public key identifies the payee to the payer and payer to the
>> payee.
> This would be the simple model, which just tacks on another parameter to
> the bitcoin URL:
>
> bitcoin:[address]?bt=<mac>&s=<key>
>
> But we should also look at the more flexible "r#" approach from your
> existing TBIPs, which would yield:
>
> bitcoin:[address]?r=bt:<mac>/<key>
>
> and incorporate the "payment_url" list.
>
>> * Use a base58 encoding to save space and reduce the character set
>> slightly.
> :)
>
>> * Get rid of the resource? If a terminal is accepting payment from
>> multiple customers simultaneously, it should be smart enough to
>> distinguish between customers based on the public key they are
>> encrypting the data with. Is this approach feasible?
> Yes, it is not necessary on the URL. But an id is useful in helping the
> BT terminal identify the session without having to try all of its
> outstanding keys until it finds one that works.
>
> I proposed that the resource name ("session id" may be a better name) be
> deterministically derived from the session key. Given the design change
> to pass an EC public key it would need to be derived from that key (not
> from the session key because the receiver would not have a copy before
> decrypting the first BT message). So any function on the public key that
> reduces it to a smaller length, fixed width should be fine. Hashing it
> first may be better as is prevents disclosure of any bits of the public
> key, which should be treated as a secret during the session.
>
>> * When you said a new public key for each tap, do you see that as
>> every single tap, or do you consider multiple taps from the same
>> customer the same tap?
> Yes, since there would be no other way to distinguish between customers
> in some scenarios and this is the safest approach. We certainly won't
> run out of numbers, and unused sessions can be discarded based on any
> number of criteria, including discarding all but the most recent. That
> may may be sufficient for your vending machines given there's little if
> any call for parallelism.
>
> e
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 555 bytes --]
next prev parent reply other threads:[~2015-02-24 22:50 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-22 19:08 Jan Vornberger
2015-02-22 22:37 ` Andy Schroder
2015-02-22 23:06 ` Eric Voskuil
2015-02-22 23:32 ` Andy Schroder
2015-02-23 0:05 ` Eric Voskuil
2015-02-23 1:02 ` Andreas Schildbach
2015-02-23 7:36 ` Andy Schroder
2015-02-23 9:13 ` Natanael
2015-02-23 9:40 ` Eric Voskuil
2015-02-24 2:55 ` Eric Voskuil
2015-02-24 5:53 ` Andy Schroder
2015-02-24 11:28 ` Eric Voskuil
2015-02-24 19:49 ` Andy Schroder
2015-02-24 22:14 ` Eric Voskuil
2015-02-24 22:50 ` Andy Schroder [this message]
2015-02-25 2:09 ` Eric Voskuil
2015-02-28 9:46 ` Andy Schroder
2015-02-23 9:49 ` Andreas Schildbach
2015-02-23 10:08 ` Eric Voskuil
2015-02-23 10:58 ` Mike Hearn
2015-02-23 11:58 ` Andreas Schildbach
2015-02-23 12:18 ` Mike Hearn
2015-02-23 12:30 ` Andreas Schildbach
2015-02-23 23:00 ` Eric Voskuil
2015-02-23 23:11 ` Mike Hearn
2015-02-24 0:10 ` Eric Voskuil
2015-02-24 10:41 ` Mike Hearn
2015-02-26 12:30 ` Andreas Schildbach
2015-03-03 0:54 ` Eric Voskuil
2015-02-23 0:58 ` Andreas Schildbach
2015-02-23 15:09 ` Jan Vornberger
2015-02-23 16:59 ` Mike Hearn
2015-02-23 19:56 ` Jan Vornberger
2015-02-23 20:31 ` Mike Hearn
2015-02-24 6:14 ` Andy Schroder
2015-02-24 15:41 ` Jan Vornberger
2015-02-26 12:37 ` Andreas Schildbach
2015-02-22 22:39 ` Eric Voskuil
2015-02-22 22:48 ` Eric Voskuil
2015-02-22 23:35 ` Andy Schroder
2015-02-23 0:46 ` Eric Voskuil
2015-02-23 1:05 ` Andreas Schildbach
2015-02-23 1:55 ` Aaron Voisine
2015-02-23 0:48 ` Andreas Schildbach
[not found] <54ED2F34.8090704@voskuil.org>
[not found] ` <54ED3150.4020800@AndySchroder.com>
[not found] ` <54ED7D8B.5070903@schildbach.de>
2015-02-25 9:20 ` Eric Voskuil
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=54ED0046.3030906@AndySchroder.com \
--to=info@andyschroder$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=eric@voskuil$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox