Hello all, This is the deal: 2 identical controllers of type C167CS. The requirement is that one product cannot be used without the other, so I devised a simple authentication protocol:
R(n) = ( (A * R(n-1) + C) mod M)
is computed on both products, where R(n) is an 32 bit integer, and A = 1366, C = 150889, M = 714025 the seed R(n-1) is selected by assigning the clock value to it. The clock value is added or subtracted from the constants A, C and M depending if it is add or not. One product sends the clock value and the selected offset over a CAN bus and the other reconstructs the answer and sends it back. If the answers match - product is authenticated. I wrote the code about 2 weeks ago, tested it and checked in. But today, the same code did not function anymore. I managed to get it to work, but only after making the following modifications: * working with constants that limit the range of the intermediate results to 16 bit width. * remove the modulus operator.
I also encounter problems with comparing two 32 bit integers. I had to compare these numbers in 2 stages, 16 bits each. I admit that I did not thoroughly check the generated assembly. Can you offer an explanation? How come it worked over the course of several hours and then - not anymore? (for clarity: the product's answers did not agree anymore). Are all the assumptions of all moderns computing false :-) ?
You're aware that whatever security by obscurity your little protocol might have had is null and void now that you've posted it here, right?
the seed R(n-1) is selected by assigning the clock value to it. The clock value is added or subtracted from the constants A, C and M depending if it is add or not.
You're not making terribly much sense there. What do you use that "clock" for: the (inappropriately named) R(n-1), or for fudging the parameters? Or were you actually telling us that you used this same number for both things? If you were, that can't be good.
One product sends the clock value and the selected offset
What clock value is that? I.e. counted how, at what granularity?
Oh, and what offset is that, and why does it need sending?
How come it worked over the course of several hours and then - not anymore?
Possibly because your implementation can't handle large values of that "clock" of yours, but your original tests didn't run long enough to reach sufficiently large numbers.
Since you failed to show any actual source code I'll have to guess: you implicitly expected computations on 16-bit numbers to yield a 32-bit result. Well, sorry, C doesn't work that way.
Hans, Thanks for your reply. I will try answer all you comments:
as long as you know anything about the product (maybe it a a washing machine that can dial a mobile :-) ) - it's cool...
the seen, or R(n-1), is assigned the clock value.
here I meant that the product that requires the presence of the other sens 2 bytes over the CAN bus: the seed or R(n-1), and another number which is used to decrease or increase the constants value. I thought it would make the entire thing a little less predictable. the clock is the processor clock, which ticks at 12MHz.
Possibly because your implementation can't handle large values of that "clock" of yours, but your original tests didn't run long enough to reach sufficiently large numbers. I don't this is the case as the authentication occurs immediately after startup. This used to work without a problem when the data types involved with "unsigned long" and the constants were much larger.
Since you failed to show any actual source code I'll have to guess: you implicitly expected computations on 16-bit numbers to yield a 32-bit result. Well, sorry, C doesn't work that way. as I stated, all the variables involved were 32 bit wide.
Any ideas?
Hans, I calculated the expected result by hand. However, both controller calculated it wrong...!
you wrote: Since you failed to show any actual source code I'll have to guess: you implicitly expected computations on 16-bit numbers to yield a 32-bit result. Well, sorry, C doesn't work that way.
Where is the danger exactly? Maybe it is too late but I don't see the problem here...?
I meant of course: as long as you know nothing about...
Nobody but you has any chance to see the problem, as you haven't shown any source code yet.
Show compilable source code, a couple of inputs numbers, and a detailed explanation of what you think the result should be, and people can find out what's wrong with it.
Hans, I will do that on Monday. I don't have access to SVN from home...
I thought it would make the entire thing a little less predictable.
Sorry, but that's not gonna do. I think it was Knuth himself who stated that pseudo-randomly designing a pseudo-random number generator (which is what you're doing) has a negligible probability of yielding a good one.