[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.

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.
>  Let's say you have an account with an online payment service. The
>  classical way for you to make a payment is to log into your account
>  using an account name and a password; note that the password is always
>  the same, unless you change it.
>
> If there are malicious applications in the computer which you use to log
> into your account, they can intercept your login information and they
> can later steal all your money from that account. This can happen
> because your password is always the same.
>
> One time tokens change exactly this. Such tokens are different every
> time you make a payment. If the tokens are generated on a computer which
> is not connected any communication network, the passphrase you have to
> use to generate them can not be intercepted by malicious applications.
>   

> 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)
> If your online payment service accepts one time tokens, you can use a
> small application, AxiomaticTokenizer, to generate your tokens. This is
> written in HTML and JavaScript. Download it on your computer by
> right-clicking here (
> http://www.gardenerofthoughts.org/ideas/emoney/axiomatictokenizer.htm )
> and choosing "Save link as". Then just click on that file to open it in
> your web-browser and use it.
>
> The user interface of AxiomaticTokenizer is small because it was
> specifically designed to run on mobile devices. Unfortunately, not all
> mobile web-browsers support all the necessary JavaScript.
>
>  Detailed protocol at
>  http://www.gardenerofthoughts.org/ideas/emoney/tokens.htm
>
>
> ---
> You are currently subscribed to e-gold-list as: e-gold-list at kobly.com
> To unsubscribe send a blank email to leave-e-gold-list-512001C at talk.e-gold.com
>
> Use e-gold's Secure Randomized Keyboard (SRK) when accessing your e-gold account(s) via the web and shopping cart interfaces to help thwart keystroke loggers and common viruses.
> _______________________________________________
> E-gold-list mailing list
> E-gold-list at kobly.com
> http://www.kobly.com/mailman/listinfo/e-gold-list
>
>
>