[e-gold-list] AxiomaticTokenizer - Increased payment security with one time tokens

[Patrick J Kobly]

Good start.  'tis important to be thinking about stuff that's 
implementable in mobile / low computing power devices...

First rule of crypto: don't roll your own.

There are pure JavaScript implementations of RSA... 
(http://www.ohdave.com/rsa/ is one, 
http://www-cs-students.stanford.edu/~tjw/jsbn/rsa.html is another)

I am not a cryptanalyst, but on an initial scan, I would not use this 
protocol to secure anything related to money.

Just a couple thoughts...

- Because your salt (you call it a seed) is static, the "shared secret" 
is vulnerable to pre-computation attacks.
- This doesn't really matter, because the step of converting to a 
"shared secret" does not add any further security over just storing the 
passphrase and using that as a key in the MAC- given the pass-phrase, an 
attacker can generate the shared secret, and the passphrase itself is 
not used in the authentication of the messages.  The passphrase just 
provides a simple mnemonic to communicate the shared secret.
- This will likely be vulnerable to replay attacks, regardless of the 
presence of a timestamp.  Because the spend token generator is on a 
disconnected machine, its time will not likely be synched close enough 
to the payment processor's to have a tight TTL.  Further, because of the 
transcription time required for the user to copy the token from the 
screen, the TTL of the message would have to be even wider.  This could 
be partially remediated by adding a random nonce, checked for uniqueness 
over TTL by the payment processor, or by preventing multiple spends in 
the TTL timespan by the user

...

PK

George Hara wrote:
> (This is an interesting idea which could be used by service providers,
> if only just as a starting point. No special hardware required.)
>
>  Increased payment security with one time tokens
>   
It is probably unwise to use the phrase "one time" with respect to this 
scheme.  This implementation is a MAC (message authentication code)

http://en.wikipedia.org/wiki/Message_authentication_code

And is unrelated to a one-time pad

http://en.wikipedia.org/wiki/One-time_pad

Which would also be implementable on a small device, though requiring 
significant storage, and similar key exchange problems.

Incidentally, because both of these are symmetric schemes, neither 
provides for non-repudiation - the payment processor cannot prove that 
the spend was authorized, as it would be able to in a digital signature 
approach.

> In order to send a token to the service to make a payment, you can
> simply copy it from the display of the computer which generated it to
> the computer which is connected to the Internet, or you can use a memory
> card to transfer it between the two computers.
>   
How does the system you use to generate spend tokens get the information 
(spend-specific) that it needs to build the token?
> However, in order for the service to be able to known that a token it
> receives was indeed generated by you, both you and it need to know a
> secret, called shared secret. You can generate a token in order to send
> your shared secret to the service, but this time it's in the clear, so
> anyone who can intercept it, can steal all your money.
>   
This scheme allows, among other things, for replay attacks by either the 
receiver or a MITM.
> To protect yourself against such possible events, you always have to
> send your shared secret from a computer which is free of malicious
> applications. Since you can never be sure of this, it's possible to
> split the shared secret in two parts and send each part, to the service,
> from a different computer. As long as the two parts are not intercepted
> by a thief and linked together, your money is safe.   
That's a pretty big if.  And it breaks the "password-equivalent only 
ever exists on a non-connected computer" assumption.  It also doesn't 
protect against exploitation of the payment processor (who needs a full 
copy of either your passphrase or the shared secret [which are 
equivalents] online, in order to process payments)


Better way to do it is with a scheme that doesn't require you to reveal 
secrets to anyone.

PK