This is a credit card containing a small single-function chip and miniscule power source. Every card is assigned a unique 128- or 256-bit one-time key that changes according to a simple Riemann formula every time a transaction is made. Unless the data archives of the credit card company are hacked from the inside (unlikely at best), it will be practically unbreakable. It will be totally immune to phreaking or skimming, since the phreaker would have the information stored on the card at the time it was surreptitiously scanned, but without the 'pad' written into the hard memory of the card itself and the corresponding pad in the company's database, they would have no way of determining the correct key when the card number was challenged during an illicit transaction process.
With [Voice]'s help, I've come up with a way to make online or telephone transactions using the OTP Card: the card also features an LCD that shows the card's 16-digit number. When a special button is pushed, the display changes to a 12-digit key generated by the same formula, but compiled from four 3-digit groups chosen (via a variant function* of the same Reimann formula) from different sectors the current key. You type/read the card number, expiration date, etc., then you press the button and type/read the 12-digit key. If it matches the key provided by the company's computer, the transaction is confirmed.
The only way to illicitly use this card is to physically steal it. Give me time to read a few calculus books, and I'll come up with a plan to foil that, too.
*I'm 38.4% certain that 'variant function' is a valid term, but it might be pure hooey cuz I don't know from math.
This 'bake comes to you courtesy of [Voice], who suggested that I should post it, and was inspired by [hippo]'s post 'New symbol to communicate the strength of encryption'.-- Alterother, Jun 11 2012 Something very similar http://www.fahad.co...ord-otp-credit.html[bigsleep] brought this to my attention literally seconds after I posted this idea, but I'm leaving my 'bake up because it's not quite the same thing. $5 says it doesn't use a Zeta-function formula to generate the pads [Alterother, Jun 11 2012] Riemann Zeta-Function Wiki http://en.wikipedia...emann_zeta_functionThere's no 'practical applications' section that talks about encryption; I learned about it during a visit to Bletchley Park [Alterother, Jun 12 2012] Your wish http://images.sodah...nswer_2_xlarge.jpegis my command. [Voice, Jun 12 2012] I was imagining a card storing and using randomly generated and prematched OTP data. I'm not sure what advantage your proposed method would provide.-- Voice, Jun 11 2012 That is the method I'm proposing, only the 'pads' change every time they get used, just like analog one-time pads, but done automatically.
Sometimes I have trouble explaining ideas that fall outside of my areas of in-depth education.-- Alterother, Jun 11 2012 I'm not clear on what your card actually does.
Basically, a one time pad is 'proper' random data, which is used only once.
If you're generating each transaction code from the previous value, then what you have is not a one time pad, but a seed. This wouldn't have the guaranteed security features of a OTP. In particular, if a hacker could read the contents of the chip at one point, they would be able to generate future states.
Alternatively, if you generate a number of codes (using a true random number generator), then your credit card will have a limited number of goes before requiring replacement (or recharging with new OTPs). Furthermore, if a hacker could read the chip contents, they'd be able to spoof the remaining transactions.-- Loris, Jun 12 2012 //a unique 128- or 256-bit one-time key that changes according to a simple Reimann formula every time a transaction is made//
So it's not a one-time key, but a stream cypher that uses a "simple Riemann formula" to generate a keystream.
I hope your "simple Riemann formula" has been adequately studied by cryptanalysts.-- Wrongfellow, Jun 12 2012 It has; in fact, it was a fascination of the father of modern cryptanalysis, Alan Turing. As I've already stated, my mathematical understanding is limited and thus I am unable explain the nuts and bolts <link>, but the Riemann Zeta-function is a set of formulas that (amongst many other things) can be used to generate _nearly_ random numbers in a way that can only be predicted if you know the value of the original integers. Without those key numbers, the specific algorithm cannot be reconstructed. According to the assistant curator at Bletchley Park, who told me all about it one afternoon a couple of years ago, Zeta-function encryption remains unbroken to this day (or at least as of July 2009), and is used by many governments and corporations to encrypt supersecret data. So why not apply it to credit cards?
Stream-cypher is actually a better description in some ways. I called it a one-time key because every card and corresponding account must have a unique set of matching integers in order to complete the key, and those sets change each time.
This may not be a very good idea, especially since I'm drawing on subject material I know very little about. It was just something I decided to run up the flagpole.-- Alterother, Jun 12 2012 //Zeta-function encryption remains unbroken to this day, and is used by many governments and corporations to encrypt supersecret data.//
Got a reference for this?
The number 1 Google hit for "zeta function encryption" contains a couple of choice quotes like //no modern cryptographer of any stature would think of making anything like the system that I have just described// and //I can assure you that many readers of fiction underestimate just how much of a novel's content is simply made up.//
There are many relationships between the Riemann zeta function and various forms of _public-key_ crypto - but no deterministic mathematical function will ever satisfy the requirements for the OTP to be unbreakable - it only works with _truly random_ data which is used _exactly once_ and then discarded.-- Wrongfellow, Jun 12 2012 I'm looking for a reference to cite which backs up my word-of-mouth education from a credible source.
As I said, [The Alterother] pulling up a chair in the Halfbakery's Math Department is like a guppy swimming with the sharks.
//I can assure you that many readers of fiction underestimate just how much of a novel's content is simply made up.//
I assume that quote is a reference to Neal Stephenson's 'Cryptonomicon'. Great book, but not my source material. I'm not just a reader of fiction, I'm also a writer of it, and I'll tell you now that I can weave a convincing tapestry of elaboration from a single strand of fact.
If I can't find anything to cite, I'll come back and tip my king.-- Alterother, Jun 12 2012 Okay, I am wrong after all. A little bit of reading has filled in the three-year-old blanks in my addled memory.
What I was told about was actually the RSA Cryptosystem and how extrapolation of Alan Turing's original application of the Riemann Zeta-function to cryptography resulted in the prime number field generation formula that cracked RSA--last year. The nice lady at Bletchley was explaining that people were using Riemann to attack RSA in 2009, and that she didn't think it could be done.
I concede. Let the mockery begin, please.-- Alterother, Jun 12 2012 //I concede. Let the mockery begin, please.//
That's kind of backwards isn't it? After you've admitted that you were wrong, no mockery can occur.
Suppose you are crap at something. Random examples : batting in a ball-game, playing chess, reverse parking. Somehow you become good at it. Can anyone reasonably continue to tease you for being crap at it?-- Loris, Jun 12 2012 // Classic OTP works on an explicit challenge - "Give me the 149th number from the pad". //
That's why I suggested a formula such as Riemann to select a pseudorandom integer which is then used to pick the elements of the current pad from the 128- or 256-bit key (which will have also just changed according to the algorithm), but, sadly, my whole premise was flawed due to my limited knowledge and mistaken memory--I was confusing Riemann with RSA because the origin of my knowledge of both was a single conversation involving the relationship of the two.
This all really goes to show that, as I knew from the outset, I should stick to topics that I am well-versed in, such as structural fabrication, WWII history, indoor horticulture, rhinoceros husbandry, world-class bullshitting, English grammar and its permissible misuse, and high-tech firearms, just to name a few.
Still, I enjoy dabbling a bit.-- Alterother, Jun 12 2012 Programmers at national labs such as Livermore use something like this every time they log into their computer accounts. The electronic card generates a new password every time, which the computer recognizes by using some algorithm. Its probably not provably completely secure, but its the best they've got. So your idea is good, and good and baked, but the ingredients are unknown (to me at least).-- sqeaketh the wheel, Jun 12 2012 // After you've admitted that you were wrong, no mockery can occur. //
The hell it can't! I can still be mocked for having been wrong in the first place, especially since I went to such great lengths to be wrong. I can also be mocked for having assumed that I was right, and for posting an idea based on fundamentals I have virtually no understanding of. This idea is ripe for mockery, and I take it as a personal insult that everyone has been so kind and understanding about it!
I demand to be mocked, dammit!-- Alterother, Jun 12 2012 When you mock yourself so completely as you just did, it takes all the fun out of it. Of course no one is mocking you. Don't you know anything about social interaction? How dense can you get? You should avoid discussions of subject like mockery, about which you apparently know nothing, and stick to subjects where you at least have poorly remembered second hand knowledge ... like cryptography.-- scad mientist, Jun 12 2012 But, as mentioned above, the idea was not wrong. I mock you for claiming to be wrong when you were in fact right, and not being able to recognize it.-- sqeaketh the wheel, Jun 12 2012 Dammit. Good idea. I tried to submit an almost identical idea, but based on a LCD readout with a one time pad based on a clock, where the number changes hourly.
But this is too similar, so I withdrew mine.-- Kansan101, Jul 31 2013 Well, if yours would actually work as advertised, that would mark a drastic dissimilarity to mine.-- Alterother, Jul 31 2013 Given the density of modern data storage, it would be relatively simple for a card to carry a true OTP data set on it that would last the life of the card.
However, there are still a couple of problems with this approach. It would only work for swiped transactions, unless the card also had a readout that could show a code string for on-line or non- swiped entry.
Second, and I feel the most critical, is that OTP encryption is only secure if the encoding and decoding copies of the pad are secure. This is usually done by making sure that only two copies exist, and neither copy is exposed to the outside world. Given that the credit card company is going to have to handle millions of transactions a day, and given the historical record of such companies in protecting such data, I have my doubts that they would be able to maintain such tight control. (Not saying it's impossible, a very tight low level link that was only capable of passing the credit card number and the code one way, and a single digit encoded yes/no the other could probably be made secure enough from outside attacks, but even there social engineering attacks would be iffy).-- MechE, Jul 31 2013 In that vein, what we need is "write once read once", or WORO memory. This would protect from skimming reasonably well.[1]. If data from a OTP-card using such memory were read, it couldn't be read again. So fraud would be detected at the first card-usage[3] after the card is skimmed - whether or not any purchases have taken place using that data.
[1] We can assume that the banks store of data is as secure as is financially appropriate for the bank[2]. [2] This may not be as secure as would be desirable for the customer, but we needn't concern ourselves with that here. [3] This needn't be a secure transaction - a freely read/writable counter would be enough to check that the bank and card copies agreed.-- Loris, Jul 31 2013 //[1] We can assume that the banks store of data is as secure as is financially appropriate for the bank//
That's actually the one I have issue with. Yes, the bank keeps it's accounts and such secure, but the credit card processor is required to be accessible to thousands or millions of merchants on a regular basis. It just can't be kept as tightly.-- MechE, Jul 31 2013 //Yes, the bank keeps it's accounts and such secure, but the credit card processor is required to be accessible to thousands or millions of merchants on a regular basis. It just can't be kept as tightly.//
That's okay for our purposes, because the merchant device doesn't need to validate the data - it just needs to form a secure conduit to the bank.
Card is inserted, and protocol handshaking performed. Bank says - fetch code position xxxxxx Card reader fetches this data from the card. (Card supplies it and trashes that position) Card reader passes this to the bank Bank checks data is correct, and tells the reader.-- Loris, Aug 01 2013 Handshake is malformed, whereby attacker gains access to the hard drive, allowing skimming of the complete bank record by way of traditional read/write.
Or- Card reader is compromised, such that each request strips out the complete code from the card or at least a significant block, allowing multiple purchases per at a later point.-- MechE, Aug 01 2013 None of that would help with internet purchases.
A clock, a one time pad that reads out on a embedded LCD. The bank has a matching pad, and a synchronized clock.
The bank would allow an old code for a couple of minutes after it expires, to account for delays.
The user can type out the number on the pin pad in stores too.
In every transaction, on the web or at the store, the regular card number is used, followed with the 3 digit code- in place of the printed code on the back of the card.
The bank verifies both numbers and OKs the transaction.-- Kansan101, Aug 01 2013 //Handshake is malformed, whereby attacker gains access to the hard drive, allowing skimming of the complete bank record by way of traditional read/write.//
But my point was that the bank doesn't ever have to reveal the data. Given that there's no need to reveal the one-time transaction codes there shouldn't be a pathway to access them from outside. If there's a bug which reveals all the bank's internal data then the bank just plain isn't secure under any system. However, the bank could also store its copy of the transaction codes on WORO memory. Then if the data was ripped it wouldn't be very useful. How reassuring this is depends on how trustworthy the bank is.
//Or- Card reader is compromised, such that each request strips out the complete code from the card or at least a significant block, allowing multiple purchases per at a later point.//
Yes. Except that I covered this in my previous post. It would be detected the next time the card was used. If the card had an externally visible transaction count you could check it had been incremented only once if the transaction is done in-view. Of course, that would probably be hackable if the card was taken away from you for a length of time.-- Loris, Aug 01 2013 Read the entire card, destroying it. Make a new card with identical data. How can this be prevented?-- Voice, Apr 16 2014 Did I get here too late to engage in mocking? Is there such a thing as retroactive mockery?
Not that I'd want to discourage somebody from posting an idea regarding a subject that they are not fully conversant with - in my house that's referred to as " the Norman explanation ", which gets you close and gives you the basic idea but requires you to follow up with research if you need to build, defend or attack one.-- normzone, Apr 17 2014 //Read the entire card, destroying it. Make a new card with identical data. How can this be prevented?//
For this to be a viable attack within in the card system, the user's card would have to be replaced with the counterfeit without them noticing the switch. I suppose that this is reasonable - the customer may not pay close attention, and a scanner/printer could probably make a decent likeness quickly in the near future. If the card is entirely 'eaten' by the machine then this card exchange attack becomes a possibility.
The attacker could then make arbitrary transactions at any point in the future, provided they knew how many transactions the victim had made in the mean-time. Of course since the victim has a counterfeit card we must assume that it can collude with the attacker - perhaps sending and receiving information wirelessly. We can't trust it at all - it could be told to skip transactions and continue to work, so the victim would be none the wiser.
It seems to me that the way to avoid that mess would be to make the transactions irreversable once committed. If the chip doesn't give out the OTPs directly, but rather a secure hash of it with bank-supplied salt[1], then the attacker can't copy the data to clone the card[2]. Presumably cards already do something like that with their secret data.
[1] A random number generated and supplied by the bank at the point of transaction. [2] At least, not economically, with current levels of technology.-- Loris, Apr 17 2014 1pad or ipad-- popbottle, Apr 23 2014 One-time pad. It's an antiquated encryption method.-- Alterother, Apr 23 2014 It's not antiquated, in fact it's still in common use, although the pad is likely to be a write once/read once digital source.
It's the only method that is completely secure from any sort of cracking method. (With the exception of the pad itself being compromised)-- MechE, Apr 23 2014 random, halfbakery