The firmware was reversed by cybernet. He found that the license check was based on ECDSA. The Elliptic Curve implementation was from MIRACL. He then wrote a tool that took the serial number and options + license key and ran the same verification steps to show if the license was correct or not.
This piqued my interest, so I got involved. Read up on Elliptic Curves and gathered the necessary tools. One of the first paths I tried was to check if they were as stupid as Sony, ie. instead of using a random number, they always used the same value, which was how the PS3 security was broken.
Reason why I wanted to check this, was that the MIRACL library only contains a pseudo random number generator, which is seeded by asking the users for a 9 digit seed. If Rigol was lazy, they might have used the same value each time... worth checking out.
However, for this I needed 2 valid license codes, which was a problem...
So I forgot about that and started looking to trying to solve the elliptic curve discrete logarithm problem. I didn't expect to get very far, I mean.. what would be the chance of Rigol screwing up their Elliptic Curve implementation? Right?!
Well it seems the odds were in my favour :-)
After entering all the curve params in a ECDLP Solver, I was greeted with the private key value in less than a second!!
Now here's the weird thing... the values they used are suspiciously similar to a crackme on the net.
To double check my finding, I used the ecsign from the MIRACL SDK to generate a new signature for a fake serial number. Converted the signature values to the license code format, then ran it through cybernet's tool to see if the license was accepted. The last line of the output says it all:
License Key is VALID
Anyway it was a fun challenge and I learned quite a lot about Elliptic Curves from it.
5 comments:
Hi,
I was wondering if you could tell me how you mapped the numbers in cybernet's riglol.c to the values in the used by ECDLP?
He calls two of the numbers he got from his decompilation, prime1 and prime2 but prime 2 is anything but prime according Mathematica.
Just trying to grok what the fundamental Rigol screwup was here. I understand that generating keys using the same nonce can allow regeneration of the key but you ECDLP did its magic with only the parameters in the code if I'm understanding this right.
I'm way over my head here so be kind if my ignorance is showing. Just really curious how Rigol could have been so mistaken. I have a suspicion that $5000 thrown Bruce Schneier's would have been money well spent. Glad they didn't from my POV.
I can just barely understand the RSA encryption methods and this ECC stuff apparently is so hard that Schneier, in Applied Crytography, just passes on it saying it's too complicated for his intended audience.
Thanks for your thoughts,
John
prime2 is indeed not a prime number. That value is the order (AKA variable q in the miracl sources).
When you're trying to redo this, you also need to take care that some of the ECC params are in compressed form. The compressed form needs an additional parameter, the least significant bit, to 'uncompress'. Miracl's epoint_set will do the uncompress if the 1st and 2nd parameter are identical, the 3rd parameter has to be the LSB then.
As for the real problem, they didn't really goof up the ECC part as far as I know now, but the problem is that they used too small a key size. 56 bit ECC just isn't secure enough, but I guess it was a trade off, since a larger key would also mean more digits to input.
Thanks for the explanation!
Impressive work on your part to figure this out.
I'll play around with the MIRACL package and see if I can duplicate your results. I'll twiddle the Rigol parameter choices a bit and see if the ECDLP can solve it as quickly.
Did you use ECDLP Solver v0.2a?
Cybernet was thinking that a 56bit key would take months to crack. ECC keys are supposed to be good because they produce much smaller keys than RSA with comparable security.
That the ECDLP Solver broke the security in less than a second makes me wonder if there isn't something else wrong with the Rigol parameter selection.
The license key is normally only entered one time. Whether it is 30, 60 or even 90 characters long shouldn't be that big a deal. I think Rigol screwed up by thinking they were just too clever to require an evaluation by a well regarded professional in the field. One thing Schneier makes abundantly clear is that software security analysis is very difficult.
Looking forward to some fun playing with this. Mostly I want to get some idea of how ECC works - it looks like a mapping between points on a closed curve and a curved line via a straight line projected from a point at infinity behind the closed curve. I'll have to read Bauer's explanation again.
I did use ECDLP Solver yes and ECCTOOL (by readyu).
Maybe this will put the keysize a bit in perspective:
http://lacal.epfl.ch/112bit_prime
http://www.keylength.com/
And if they would have people enter a 90 character string, they would have a support nightmare on their hands because of people mistyping the stuff all the time!
That's also the reason why you won't find characters like 0, 1, I, O in the string.
As for ECC articles that I found useful:
http://www.johannes-bauer.com/compsci/ecc/
http://www.dkrypt.com/home/ecc
Why don't they generate the key using the serial number and email it as a text file attachment. Purchaser copies it to a thumb drive and installs it that way? Key size can be as large as necessary for security. Same method for field personnel installing trial keys. On screen entry! Hokey Smokes Bullwinkle!
Post a Comment