Submission + - Can card transaction be individually protected? (consumerist.com)
way2trivial writes: Dear Ask Slashdot:
I'm reading an article at the consumerist http://consumerist.com/5260257/credit-card-processors-launch-a-new-strategy-to-defeat-theft that says credit card processors are trying to come up with ways to protect card data from theft- largely by securing it into smaller little chunks...
I am a credit card accepting merchant, and know from my interactions with credit card proccessor salesman and technical support that I have a better than average understanding of the means by which credit card transactions move around. After reading that piece I researched a little more more and verified what I thought I knew. For primers see http://en.wikipedia.org/wiki/Credit_card_numbers and http://en.wikipedia.org/wiki/Public-key_cryptography
The question I've been unable to answer for myself is- why not make every individual transaction a secure chunk?? Public key cryptography should enable the possibility of ALL the individual account data to be unreadable from the point of leaving my terminal until it hits the issuing bank. If my credit card terminal contained for each of the the six digit issuer identification numbers (IIN) a public key- why not wrap up the entire rest of the transaction in a public cypher-- send it to my processor- who sends that encrypted packet to the issuing bank, who decodes and sends back an approval with a re-encrypted proof of same... the only thing my processor needs to get paid and pay me is my merchant #, the 6 digit bank that I sent it to, and the dollar amount I ultimately expect to be paid on-- when the reply comes back- my processor knows if it was approved. Any individual interception en route or stored by individual merchants electronically is useless.
The only potential flaw I can think of on my own- is that perhaps as all the original clear messages are of fixed length and format- it may prove easier to decode than a usual message. I don't know enough about the depths of public key methods to know if that simplifies breaking the private keys- but even if so a very long key may solve that.
Can anyone shoot a well reasoned hole through my solution?
I'm reading an article at the consumerist http://consumerist.com/5260257/credit-card-processors-launch-a-new-strategy-to-defeat-theft that says credit card processors are trying to come up with ways to protect card data from theft- largely by securing it into smaller little chunks...
I am a credit card accepting merchant, and know from my interactions with credit card proccessor salesman and technical support that I have a better than average understanding of the means by which credit card transactions move around. After reading that piece I researched a little more more and verified what I thought I knew. For primers see http://en.wikipedia.org/wiki/Credit_card_numbers and http://en.wikipedia.org/wiki/Public-key_cryptography
The question I've been unable to answer for myself is- why not make every individual transaction a secure chunk?? Public key cryptography should enable the possibility of ALL the individual account data to be unreadable from the point of leaving my terminal until it hits the issuing bank. If my credit card terminal contained for each of the the six digit issuer identification numbers (IIN) a public key- why not wrap up the entire rest of the transaction in a public cypher-- send it to my processor- who sends that encrypted packet to the issuing bank, who decodes and sends back an approval with a re-encrypted proof of same... the only thing my processor needs to get paid and pay me is my merchant #, the 6 digit bank that I sent it to, and the dollar amount I ultimately expect to be paid on-- when the reply comes back- my processor knows if it was approved. Any individual interception en route or stored by individual merchants electronically is useless.
The only potential flaw I can think of on my own- is that perhaps as all the original clear messages are of fixed length and format- it may prove easier to decode than a usual message. I don't know enough about the depths of public key methods to know if that simplifies breaking the private keys- but even if so a very long key may solve that.
Can anyone shoot a well reasoned hole through my solution?