N. Coesel wrote:
At 15:40 17-11-2009 -0700, you wrote:
On Tuesday 17 November 2009 15:33:24 Nico Coesel wrote:
Why is your flash programming routine so large? Only the part that does the
actual flash programming has to be in ram. This is just a few lines of
code. Perhaps you need to split the function in a part that stays in flash
and a small part that does the actual programming.
It's a field update for client-confidential code. The final decryption stage
is done in the programming function.
I would split that function. There is no reason to decrypt from ram.
Agreed.
Actually, it is better to divide security sensitive code in several
functions linked in random order. It makes it more difficult to follow.
The old "security by obscurity" trick, that has /such/ a good reputation?
There is no need to try to "protect" your security code in this way.
You can assume that anyone capable enough and determined enough to break
the microcontroller's flash read blocks, dig out your code, and
disassemble it, is capable of following the code through a convoluted
execution path. The only person that suffers, is the poor sod that must
test, debug and maintain the obfusticated code.
If you think there /is/ a need to protect the security code like this,
you are better off picking a more powerful algorithm or a longer key.
Of course, that doesn't mean you have to advertise your security
algorithm to the world (unless you want to put "3DES" on your marketing
material) - you don't have to go out of your way to make it easy for
/them/. Just don't go out of your way to make it hard for yourself.
