I'm writing some FLASH programming code, and now I have reached final
step of securing the microcontroller. Unsecured microcontroller has
lower bits of byte at 0xff0e equal to 0bxxxxxx10. Now if I want to
secure it, I have to write something different there. Because LSB is
already zeroed, there are two possibilities: one is to first erase it
and then program to something != 0bxxxxxx10, second possibility is to
program bit #1 to 0, thus zeroing both these bits, but that's cumulative
programming which is not allowed, according to the docs.
So my question is: why unsecured state requires byte at 0xff0e to have
such specific value different that erased state ? Why was it designed
this way ? Why "all erased" FLASH is considered "secured"
state ?
I have new parts straight from Freescale, they all have byte at 0xff0e
in unsecured state (so the FLASH is not clear, although rest of the
flash is 0xff). If I want to change the security byte, I now have to
erase the flash first, to fully respect prohibition of cumulative
programming. It's not the problem to erase it of course once more, but
why is it designed this way ? I would consider the part straight from
factory in unsecured state as "erased", but it's not.
I also tried cumulative programming and it works, but due to official
prohibition of such practices I expect it to have negative impact on
overall flash condition, true ?
Regards,
--
Michal Konieczny
mk@mk@....
HCS12 flash security and cumulative programming
Started by ●October 4, 2005
Reply by ●October 4, 20052005-10-04
Michal,
From what little I know about reverse engineering practices, I would
guess that the most secure setting for $ff0e is 0bxxxxxx01. That way,
an attacker will have to erase one bit and program the other, which is
more difficult than doing only one of those tasks.
Why doesn't Freescale have 0bxxxxxx11 be "unsecured"? It's probably
because there's a way for an attacker to make the HC12 think both bits
are 1. It could be something like playing with the CPU voltage, or
it could be something like taking the top off the chip and using a UV
laser to erase the bits. Since 11 means "secured", erasing both bits
(or playing with the voltage to make them falsely read back as 11)
still leaves the attacker having to figure out how to erase the other
bit to get the chip unsecured.
It's likely that the documentation contains a recommendation somewhere
about the ideal value for the security bits. The old HC12s I work with
don't have security bits, so I haven't had reason to look into it.
On Tue, Oct 04, 2005 at 01:04:48PM +0200, Michal Konieczny wrote:
> I also tried cumulative programming and it works, but due to official
> prohibition of such practices I expect it to have negative impact on
> overall flash condition, true ?
Speculating a bit, it might reduce the margin of the programming, which
ultimately reduces the lifetime of the program: the time until the flash
"forgets". In extreme cases, it might even make the cell read back
unreliably 0 or 1. The difference might only show up at extremes of
temperature and voltage. It's also possible that cumulative programming
increases the rate of damage to the transistors caused by programming,
perhaps because the unchanged bits are overprogrammed. That would reduce
the number of programming cycles the flash can accomodate before it fails.
If this is the latter, you might be willing to tolerate the damage if
you plan to program the flash only once. If it is the former (reduced
margin), it's something to avoid even once. Besides, if the most secure
setting is indeed 0bxxxxxx01, you need to erase and reprogram the whole
word anyway.
Stephen
--
Stephen Trier
Technical Development Lab
Cleveland FES Center
sct@sct@...
From what little I know about reverse engineering practices, I would
guess that the most secure setting for $ff0e is 0bxxxxxx01. That way,
an attacker will have to erase one bit and program the other, which is
more difficult than doing only one of those tasks.
Why doesn't Freescale have 0bxxxxxx11 be "unsecured"? It's probably
because there's a way for an attacker to make the HC12 think both bits
are 1. It could be something like playing with the CPU voltage, or
it could be something like taking the top off the chip and using a UV
laser to erase the bits. Since 11 means "secured", erasing both bits
(or playing with the voltage to make them falsely read back as 11)
still leaves the attacker having to figure out how to erase the other
bit to get the chip unsecured.
It's likely that the documentation contains a recommendation somewhere
about the ideal value for the security bits. The old HC12s I work with
don't have security bits, so I haven't had reason to look into it.
On Tue, Oct 04, 2005 at 01:04:48PM +0200, Michal Konieczny wrote:
> I also tried cumulative programming and it works, but due to official
> prohibition of such practices I expect it to have negative impact on
> overall flash condition, true ?
Speculating a bit, it might reduce the margin of the programming, which
ultimately reduces the lifetime of the program: the time until the flash
"forgets". In extreme cases, it might even make the cell read back
unreliably 0 or 1. The difference might only show up at extremes of
temperature and voltage. It's also possible that cumulative programming
increases the rate of damage to the transistors caused by programming,
perhaps because the unchanged bits are overprogrammed. That would reduce
the number of programming cycles the flash can accomodate before it fails.
If this is the latter, you might be willing to tolerate the damage if
you plan to program the flash only once. If it is the former (reduced
margin), it's something to avoid even once. Besides, if the most secure
setting is indeed 0bxxxxxx01, you need to erase and reprogram the whole
word anyway.
Stephen
--
Stephen Trier
Technical Development Lab
Cleveland FES Center
sct@sct@...
Reply by ●October 4, 20052005-10-04
>>From what little I know about reverse engineering practices, I
would
> guess that the most secure setting for $ff0e is 0bxxxxxx01. That way,
> an attacker will have to erase one bit and program the other, which is
> more difficult than doing only one of those tasks.
Indeed, it's suggested to secure the chip by changing 0bxxxxxx10 into
0bxxxxxx01. I must admit I didn't think about reverse engineering risk
and such bit pattern is yet another hurdle in front of cracker.
Regards,
--
Michal Konieczny
mk@mk@....
> guess that the most secure setting for $ff0e is 0bxxxxxx01. That way,
> an attacker will have to erase one bit and program the other, which is
> more difficult than doing only one of those tasks.
Indeed, it's suggested to secure the chip by changing 0bxxxxxx10 into
0bxxxxxx01. I must admit I didn't think about reverse engineering risk
and such bit pattern is yet another hurdle in front of cracker.
Regards,
--
Michal Konieczny
mk@mk@....
