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?
Any means of security is security by obscurity by definition. All
protections schemes come down to hiding a secret (obscurity). Whether its a
key, a secret algorithm, etc.
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.
You could have several seperate C files for several functions. Hash.c,
decrypt.c, encrypt.c. No problem at all to maintain.
Nico Coesel
