--- In 68HC12@68HC..., "Michael Huslig" <mhuslig@k...>
wrote:
>
> Doron,
>
> If the programmer of a secured normal single-chip application never
> references external memory, how can a hacker inject some data?
I see Doron is looking at a different issue in that case. If the
hacker can begin execution by starting up in expanded mode. Of cours
you are not suggesting that be possible.
Doron hasn't at all addressed you latest explanation how the bus would
only be used for data. Doron, you've got to think outside the box :)
Personally, I think if they did design some easy way to allow enabling
the external bus, then there would be more easy ways you don't know
about to force it into executing code.
Then, the best way is if there was an extra limitation implementation
while secured, suggested by Zoltan, that the bus did not physically
allow instruction fetches from the external bus. I guess I haven't
thought enough before about the difference between program fetch and
data fetch.
I think Freescale just hasn't though enough about it either. Then my
only fear is how much it would cost to get them to think about it.
MC9S12DG256 secure mode and external bus
Started by ●December 31, 2005
Reply by ●January 3, 20062006-01-03
Reply by ●January 3, 20062006-01-03
--- In 68HC12@68HC..., Zoltán Kócsi <zoltan@b...>
wrote:
> Considering that the bus interface sits between the internal bus and
> the external bus, it is not necessarily an illusion. The bus
Actually your explanation makes more sense to me than mine, but it
doesn't seem to solve the real problem of why it's not possible. > FLASH, then unless you have a programming error it would never try
"programming error" is the real reason, as I understand it, why they
don't enable it. And of course, they are not trying to compete with
cheaper MCU, but claim to be better than them.
So what I've heard was that there were ways discovered after
production that induced errors, toggled specific (or even random)
bits, etc. which allowed the hackers to gain control. That is what
Freescale was trying to avoid.
I think the best idea, however, is being able to allow data accesses
and not program fetch while secured, except I don't know what that
would involve.
> Considering that the bus interface sits between the internal bus and
> the external bus, it is not necessarily an illusion. The bus
Actually your explanation makes more sense to me than mine, but it
doesn't seem to solve the real problem of why it's not possible. > FLASH, then unless you have a programming error it would never try
"programming error" is the real reason, as I understand it, why they
don't enable it. And of course, they are not trying to compete with
cheaper MCU, but claim to be better than them.
So what I've heard was that there were ways discovered after
production that induced errors, toggled specific (or even random)
bits, etc. which allowed the hackers to gain control. That is what
Freescale was trying to avoid.
I think the best idea, however, is being able to allow data accesses
and not program fetch while secured, except I don't know what that
would involve.
Reply by ●January 4, 20062006-01-04
"Jefferson Smith" <imajeff84663@imaj...> wrote:
[...]
> > FLASH, then unless you have a programming error it would never try
>
> "programming error" is the real reason, as I understand it, why they
it could be forced also by applying illegal signals to mcu pins, e.g.
short clock or reset pulses, over-/undervoltage...
Only a "no execute" hardware for external memory would be safe.
Oliver
--
Oliver Betz, Muenchen
[...]
> > FLASH, then unless you have a programming error it would never try
>
> "programming error" is the real reason, as I understand it, why they
it could be forced also by applying illegal signals to mcu pins, e.g.
short clock or reset pulses, over-/undervoltage...
Only a "no execute" hardware for external memory would be safe.
Oliver
--
Oliver Betz, Muenchen
Reply by ●January 4, 20062006-01-04
--- In 68HC12@68HC..., "Oliver Betz" <list_ob@g...>
wrote:
> it could be forced also by applying illegal signals to mcu pins, e.g.
> short clock or reset pulses, over-/undervoltage...
>
> Only a "no execute" hardware for external memory would be safe.
>
> Oliver
Doron suggested that S12X might solve the problem. Can anyone say if
you can use external i/o on S12X when secured?
> it could be forced also by applying illegal signals to mcu pins, e.g.
> short clock or reset pulses, over-/undervoltage...
>
> Only a "no execute" hardware for external memory would be safe.
>
> Oliver
Doron suggested that S12X might solve the problem. Can anyone say if
you can use external i/o on S12X when secured?
Reply by ●January 4, 20062006-01-04
At 19:52 04/01/2006 +0000, you wrote:
>Doron suggested that S12X might solve the problem. Can anyone say if
>you can use external i/o on S12X when secured?
Let be more accurate here:
I said that the S12X external bus is much more robust and convenient to use
compared to the HCS12 external bus (much better and easier to meet
bus-timing, voltage levels compatible with memory devices, and no need for
any glue logic to interface to external memory).
Regarding security, the S12X does have similar implementation as the HCS12
- it automatically disables the internal Flash when the part is secured and
operates in Expanded mode. So the answer to your specific question is: No,
the S12X does not resolve this particular problem.
Hope this helps,
Doron
Nohau
HC12 In-Circuit Emulators
www.nohau.com/emul12pc.html
>Doron suggested that S12X might solve the problem. Can anyone say if
>you can use external i/o on S12X when secured?
Let be more accurate here:
I said that the S12X external bus is much more robust and convenient to use
compared to the HCS12 external bus (much better and easier to meet
bus-timing, voltage levels compatible with memory devices, and no need for
any glue logic to interface to external memory).
Regarding security, the S12X does have similar implementation as the HCS12
- it automatically disables the internal Flash when the part is secured and
operates in Expanded mode. So the answer to your specific question is: No,
the S12X does not resolve this particular problem.
Hope this helps,
Doron
Nohau
HC12 In-Circuit Emulators
www.nohau.com/emul12pc.html
Reply by ●January 4, 20062006-01-04
--- In 68HC12@68HC..., Doron Fael <doronf@n...> wrote:
> Let be more accurate here:
...
> - it automatically disables the internal Flash when the part is
secured and
> operates in Expanded mode. So the answer to your specific question
is: No,
> the S12X does not resolve this particular problem.
Good explanation, thanks. I really meant you were indirectly implying
that it was possible, but didn't think you were saying that it could
do it. I was at least hoping there was something I didn't know was
improved with security, but I already knew about things you mentioned.
Thanks, --jeffs
> Let be more accurate here:
...
> - it automatically disables the internal Flash when the part is
secured and
> operates in Expanded mode. So the answer to your specific question
is: No,
> the S12X does not resolve this particular problem.
Good explanation, thanks. I really meant you were indirectly implying
that it was possible, but didn't think you were saying that it could
do it. I was at least hoping there was something I didn't know was
improved with security, but I already knew about things you mentioned.
Thanks, --jeffs
