Re: A89: The logic behing signined and unsigned programs!
[Prev][Next][Index][Thread]
Re: A89: The logic behing signined and unsigned programs!
> Oh, I'm not saying you COULD sell it to people, unless they are stupid
> and haven't noticed the presence of linkports on their calcs, I'm just
> saying it is LEGAL to. And as for encrypted, piracy-protected
> programs... if you have both the ROM that checks the software and the
> software being checked, I don't see how you could stop a determined
> hacker from figuring out the key. It's gotta be there somewhere in one
> form or another if it is checking its validity, else how would it check
> it? Or at least that's how it seems to me.
- A determined hacker in the given situation can crack the copy
protection because he can alter the FLASH by other means
(i.e. soldering iron).
- The determined cracker can *not* get the key:
The public key algorithm works by having two keys. A third number is
generated using the two keys. One key and the common number is used to
encrypt the message. Some clever usage of modulo arithmetics results a
way to decode the message using the other key and the common number.
You can *not* decode the message with the key you encoded it with, you
need the *other* key.
Now the trick is, that the common number is generated from the keys in
such a way that it is computationally very complex to find a key if
you only know the common number and the other key.
Therefore, you publish the common number and one of the keys and that
will be your public key. You keep the other key secret, this is your
private key. Therefore, when somebody wants to send you a secret
message, they encode it with your public key and send it to
you. Everyone can see it but they can't decode it because they don't
have the private key. You are the only one who can read the message.
When you want to sign something so that the given thing can not be
changed, it works the other way around:
- Get the thing.
- Calculate a hash using some key, a value which will change wildly
for the smallest change in the thing
- Encript the hash value with your private key and attach this to the
thing.
Then, when you want to verify the autenticity of the thing you decode
the hash key and the result, using the key you calculate the hash and
compare to the result. If there's a mismatch, then the thing was
tampered with.
If you want to be sure that the thing only runs a machine with a
certain serial number, then you use the serial number as the hash key
and only encode the hash result. If the machine hashes the thing with
its own serial no and the result doesn't match with the encoded hash
value, it rejects the program.
Regards,
Zoltan
References: