Re: MintChip launched by Royal Canadian Mint

Well, as Chris Cook apparently already
materialized himself with the question,
yes, it's him, although it's his supposed
cryptography expert (unknown to me) who has
apparently raised the issue really.

So in fact it has been raised publicly it seems :)


The only thing I can think of is that HTTPS is end to end
for one connection, and does not cover multiple disparate connections.
(transaction request/ transaction response).

So he may mean that the transaction integrity spanning different
connections might be problematic.

To me this sounds a bit related to the problem of long-running transactions,
which are not completed in one HTTPS request/response cycle.

For example, how to rollback transactions which are not finished,
what to do with a second identical issued transaction if the first hasn't
been
fully processed yet. etc.

Hope this helps
cheers

2012/4/15 Manu Sporny <msporny@digitalbazaar.com>

> On 04/15/2012 01:29 PM, Fabio Barone wrote:
>
>> Someone (apparently crypto expert) commented like this:
>>
>> "This is a step in the right direction, but there is a problem: it
>> uses https".
>>
>
> What is it about HTTPS that is problematic?
>
>
>  "The transaction request is digitally signed by the agent according
>> to the Request Signature Algorithm using a private key associated
>> with the public key that was previously registered with the authority
>> according to the Vendor Registration Algorithm."
>>
>
> This is true.
>
>
>  "The transaction request is sent to the authority of the agent via an
>> HTTPS connection. The HTTPS protocol MUST be used for transmission of
>> the request and retrieval of the response to prevent replay
>> attacks."
>>
>
> This is also true. Keep in mind that the request is digitally signed by
> the requester, which includes a timestamp and potentially a nonce
> (although, that's not in the current algorithm because we believe that
> HTTPS will provide replay protection against the message). Even in the
> event that the message is compromised via HTTPS, the damage is
> time-fenced to plus-or-minus X seconds from the timestamp (so the danger
> of a replay attack is only possible for a certain number of seconds). If
> we wanted to include a nonce, we could, but then we'd be duplicating
> what HTTPS already does.
>
>
>  " Ug. Dead. you can't expect HTTPS to protect your transaction
>> integrity, the tx must stand alone"s?
>>
>
> This is where I lose the commenter's train of thought. I don't know what
> the commenter means by "protect your transaction integrity" and "the tx
> must stand alone". Is there any chance that we could get clarification
> on the definitions the commenter is making?
>
> PaySwarm /transaction requests/ depend on HTTPS to prevent replay
> attacks when there is a danger of one. However, the transaction itself
> is digitally signed from end-to-end. Also, keep in mind that this is for
> automatic purchases. The commenter may be referring to the problem that
> 'network perspectives' solves, but I can't be sure until they say that
> they're concerned about rogue certificate signing authorities.
>
> PaySwarm transactions do "stand alone" in the sense that once they're
> signed by the PaySwarm Authority, they can be verified by anyone. It
> just so happens that we're using HTTP and HTTPS as the transport
> mechanism, however, any other secure transport mechanism will work as well.
>
>  Thoughts?
>>
>
> Is this person Chris Cook? We had a brief exchange on Twitter:
>
> @cjenscook: "Payswarm: generic micropayments. My guru on matters crypto
> says "Can't expect HTTPS to protect transaction integrity." payswarm.com"
> @manusporny: "@cjenscook PaySwarm doesn't depend on HTTPS to protect
> integrity - it uses digital signatures: http://ow.ly/agqGG #payswarm"
>
> Link to the conversation:
>   https://twitter.com/#!/**manusporny/status/**190842511764365312<https://twitter.com/#%21/manusporny/status/190842511764365312>
>
> In any case, it would be good if that commenter could raise the issue
> publicly - as if this is truly a security vulnerability, we will change
> the spec in a heartbeat to ensure that we're not doing something stupid. :)
>
>
> -- manu
>
> --
> Manu Sporny (skype: msporny, twitter: manusporny)
> President/CEO - Digital Bazaar, Inc.
> blog: PaySwarm Website for Developers Launched
> http://digitalbazaar.com/2012/**02/22/new-payswarm-alpha/<http://digitalbazaar.com/2012/02/22/new-payswarm-alpha/>
>