h a l f b a k e r yactual product may differ from illustration
add, search, annotate, link, view, overview, recent, by name, random
news, help, about, links, report a problem
browse anonymously,
or get an account
and write.
register,
|
|
|
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'.
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_function
There'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.jpeg
is my command. [Voice, Jun 12 2012]
Please log in.
If you're not logged in,
you can see what this page
looks like, but you will
not be able to add anything.
Annotation:
|
| |
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. |
|
| |
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. |
|
| |
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. |
|
| |
//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. |
|
| |
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. |
|
| |
//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. |
|
| |
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. |
|
| |
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. |
|
| |
//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? |
|
| |
// 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. |
|
| |
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). |
|
| |
// 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! |
|
| |
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. |
|
| |
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. |
|
| |
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. |
|
| |
Well, if yours would actually work as advertised, that
would mark a drastic dissimilarity to mine. |
|
| |
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). |
|
| |
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. |
|
| |
//[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. |
|
| |
//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. |
|
| |
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. |
|
| |
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. |
|
| |
//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. |
|
| |
Read the entire card, destroying it. Make a new card
with identical data. How can this be prevented? |
|
| |
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. |
|
| |
//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. |
|
| |
One-time pad. It's an antiquated encryption method. |
|
| |
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) |
|
| |