> --- In 6..., "jasa.rm" wrote:
>> another suggestion would be to not use the old 1K79X mask set, but
>> some of the new ones that have the errata with Flash&EEPROM
>> programming under Secure state fixed.
>>
>> jasa
>
> But seriously, I would like to know how to actually *choose* the
> maskset. When I ask distributors, they don't even tell me what
I'm
> getting without a choice.
>
Maybe stick to RoHS only parts? These can't be 1K79X, can they?
MC9S12DP256B security
Started by ●August 4, 2006
Reply by ●August 8, 20062006-08-08
Reply by ●August 8, 20062006-08-08
Jean,
My susgestion is to 1) Use the backdoor key to place it in an unsecured state 2) have a "watchdog" type func that if (current tick count - last tick count) >= your preset value then jump to a flash secure func and resecure the flash and abort programing 3)use encryption/compression on the s rec that you download (there are many small/fast routines out there or write your own) 4)Incorprate and seed and key routine that will prevent unwanted unlocking of the part 5)Use a good Win32 encryption/compression (packer) program to protect your WIN32 app or make a special loader hardware that houses a intermeadite encryption. So the way it would work is that the Win32 app would have 1 encryption routine it would load it to the "special hardware" then that hardware would decrypt it and reencrypt it with either a new key or a whole new encyption and then load it over say the Can bus to the 9S12XDP256 and then it would have the makeshift watchdog the will provide the last bit of
securty. It might sound hard but it will be easy. If you need help with any of the above methods get me off list for some code, ect... later Tim
---------------------------------
Yahoo! Music Unlimited - Access over 1 million songs.Try it free.
My susgestion is to 1) Use the backdoor key to place it in an unsecured state 2) have a "watchdog" type func that if (current tick count - last tick count) >= your preset value then jump to a flash secure func and resecure the flash and abort programing 3)use encryption/compression on the s rec that you download (there are many small/fast routines out there or write your own) 4)Incorprate and seed and key routine that will prevent unwanted unlocking of the part 5)Use a good Win32 encryption/compression (packer) program to protect your WIN32 app or make a special loader hardware that houses a intermeadite encryption. So the way it would work is that the Win32 app would have 1 encryption routine it would load it to the "special hardware" then that hardware would decrypt it and reencrypt it with either a new key or a whole new encyption and then load it over say the Can bus to the 9S12XDP256 and then it would have the makeshift watchdog the will provide the last bit of
securty. It might sound hard but it will be easy. If you need help with any of the above methods get me off list for some code, ect... later Tim
---------------------------------
Yahoo! Music Unlimited - Access over 1 million songs.Try it free.
Reply by ●August 8, 20062006-08-08
Tim Milliken wrote:
> My susgestion is to 1) Use the backdoor key to place it in an
> unsecured state 2)
where an intruder can read all the code with a simple BDM interface.
[...]
> securty. It might sound hard but it will be easy. If you need help
No, it's _not_ easy. It might sound easy but its very difficult to
make a _really_ secure loader. There are many pitfalls to avoid, and
one has to be extremly careful.
Jean-Sebastien: don't proceed with the wrong mask sets if you really
need security. Get the correct chips else it is not safe.
Let a person with good crypto knowledge check your bootloader and/or
tell/ask in sci.crypt about your implementation.
Maybe you find some hints for a safe bootloader in the discussions I
had in sci.crypt last year.
Oliver
--
Oliver Betz, Muenchen
> My susgestion is to 1) Use the backdoor key to place it in an
> unsecured state 2)
where an intruder can read all the code with a simple BDM interface.
[...]
> securty. It might sound hard but it will be easy. If you need help
No, it's _not_ easy. It might sound easy but its very difficult to
make a _really_ secure loader. There are many pitfalls to avoid, and
one has to be extremly careful.
Jean-Sebastien: don't proceed with the wrong mask sets if you really
need security. Get the correct chips else it is not safe.
Let a person with good crypto knowledge check your bootloader and/or
tell/ask in sci.crypt about your implementation.
Maybe you find some hints for a safe bootloader in the discussions I
had in sci.crypt last year.
Oliver
--
Oliver Betz, Muenchen
Reply by ●August 8, 20062006-08-08
So what you are telling me is that even without know the crypto that was used
and with no way to get it that you can crack?? I don't think so. Part of my
job is a crypto analyst, what is you job. So many people on the net are experts
at everything till they have to go do it.... He ask my opinion on how to use
that chip and get his job done. I gave it. If he does not want it then that is
fine, as for you either add knowledge to the talk or please stay out. Tim
---------------------------------
Do you Yahoo!?
Everyone is raving about the all-new Yahoo! Mail Beta.
---------------------------------
Do you Yahoo!?
Everyone is raving about the all-new Yahoo! Mail Beta.
Reply by ●August 8, 20062006-08-08
Tim Milliken wrote:
> So what you are telling me is that even without know the crypto that
> was used and with no way to get it that you can crack??
that's the definition of "cracking" an encryption, isn't it? If one
"know the crypto", it's no more breaking ("crack") the encryption.
It's not enough to select the appropriate cipher. So many encryptions
have been compromised because the whole system was designed badly.
> I don't think so. Part of my job is a crypto analyst,
that's no proof that you have good knowledge about it.
> what is you job.
Although this doesn't matter (because it doesn't tell whether I do a
good job): industrial electronic design.
> So many people on the net are experts at everything till they have
> to go do it.... He ask my opinion on how to use that chip and get
> his job done. I gave it.
I pointed out that your advice was unsuitable and dangerous.
> If he does not want it then that is fine, as for you either
> add knowledge to the talk or please stay out. Tim
Hard to comment this politely => EOD for me.
Oliver
--
Oliver Betz, Muenchen
> So what you are telling me is that even without know the crypto that
> was used and with no way to get it that you can crack??
that's the definition of "cracking" an encryption, isn't it? If one
"know the crypto", it's no more breaking ("crack") the encryption.
It's not enough to select the appropriate cipher. So many encryptions
have been compromised because the whole system was designed badly.
> I don't think so. Part of my job is a crypto analyst,
that's no proof that you have good knowledge about it.
> what is you job.
Although this doesn't matter (because it doesn't tell whether I do a
good job): industrial electronic design.
> So many people on the net are experts at everything till they have
> to go do it.... He ask my opinion on how to use that chip and get
> his job done. I gave it.
I pointed out that your advice was unsuitable and dangerous.
> If he does not want it then that is fine, as for you either
> add knowledge to the talk or please stay out. Tim
Hard to comment this politely => EOD for me.
Oliver
--
Oliver Betz, Muenchen
Reply by ●August 9, 20062006-08-09
a) agree, you can not place order for certain specific mask-set
b) but you can still specifed the product number and the product
numbers are different across the mask-sets that are significantly
changed(bug fixes). It is not fully up-to-date but look at
file "MC9S12Dx256x_comparison.pdf" in Files section of this group.
Note that some of the old mask-sets has suffix B or C but the latest
ones do not have any suffix! So just find the appropriate comparing
to your needs.
c) do not use the wrong mask-sets if you need re-programming
capability and secure mode of operation...it is really not safe!
jasa
--- In 6..., "Jefferson Smith"
wrote:
>
> --- In 6..., "jasa.rm" wrote:
> > another suggestion would be to not use the old 1K79X mask set,
but
> > some of the new ones that have the errata with Flash&EEPROM
> > programming under Secure state fixed.
> >
> > jasa
>
> But seriously, I would like to know how to actually *choose* the
> maskset. When I ask distributors, they don't even tell me what I'm
> getting without a choice.
>
b) but you can still specifed the product number and the product
numbers are different across the mask-sets that are significantly
changed(bug fixes). It is not fully up-to-date but look at
file "MC9S12Dx256x_comparison.pdf" in Files section of this group.
Note that some of the old mask-sets has suffix B or C but the latest
ones do not have any suffix! So just find the appropriate comparing
to your needs.
c) do not use the wrong mask-sets if you need re-programming
capability and secure mode of operation...it is really not safe!
jasa
--- In 6..., "Jefferson Smith"
wrote:
>
> --- In 6..., "jasa.rm" wrote:
> > another suggestion would be to not use the old 1K79X mask set,
but
> > some of the new ones that have the errata with Flash&EEPROM
> > programming under Secure state fixed.
> >
> > jasa
>
> But seriously, I would like to know how to actually *choose* the
> maskset. When I ask distributors, they don't even tell me what I'm
> getting without a choice.
>
Reply by ●August 9, 20062006-08-09
>From the datasheet:
BDM is available in all operating modes but must be enabled before
firmware commands are executed.
I think that if the firmware of the micro changes the status from secured to unsecured, at that point the BDM Interface is useless to dump the code.
I done the boot exaxtly like Tim Milliken wrote, and I was no able to connect to the target with the BDM Interface.
Tim Milliken wrote:
>
>> My susgestion is to 1) Use the backdoor key to place it in an
>> unsecured state 2)
>
>where an intruder can read all the code with a simple BDM interface.
>
>[...]
>
>> securty. It might sound hard but it will be easy. If you need help
>
>No, it's _not_ easy. It might sound easy but its very difficult to
>make a _really_ secure loader. There are many pitfalls to avoid, and
>one has to be extremly careful.
>
>Jean-Sebastien: don't proceed with the wrong mask sets if you really
>need security. Get the correct chips else it is not safe.
>
>Let a person with good crypto knowledge check your bootloader and/or
>tell/ask in sci.crypt about your implementation.
>
>Maybe you find some hints for a safe bootloader in the discussions I
>had in sci.crypt last year.
>
>Oliver
>--
>Oliver Betz, Muenchen
BDM is available in all operating modes but must be enabled before
firmware commands are executed.
I think that if the firmware of the micro changes the status from secured to unsecured, at that point the BDM Interface is useless to dump the code.
I done the boot exaxtly like Tim Milliken wrote, and I was no able to connect to the target with the BDM Interface.
Tim Milliken wrote:
>
>> My susgestion is to 1) Use the backdoor key to place it in an
>> unsecured state 2)
>
>where an intruder can read all the code with a simple BDM interface.
>
>[...]
>
>> securty. It might sound hard but it will be easy. If you need help
>
>No, it's _not_ easy. It might sound easy but its very difficult to
>make a _really_ secure loader. There are many pitfalls to avoid, and
>one has to be extremly careful.
>
>Jean-Sebastien: don't proceed with the wrong mask sets if you really
>need security. Get the correct chips else it is not safe.
>
>Let a person with good crypto knowledge check your bootloader and/or
>tell/ask in sci.crypt about your implementation.
>
>Maybe you find some hints for a safe bootloader in the discussions I
>had in sci.crypt last year.
>
>Oliver
>--
>Oliver Betz, Muenchen
Reply by ●August 9, 20062006-08-09
THANK YOU!!!!!!!!
---------------------------------
Do you Yahoo!?
Get on board. You're invited to try the new Yahoo! Mail Beta.
---------------------------------
Do you Yahoo!?
Get on board. You're invited to try the new Yahoo! Mail Beta.
Reply by ●August 9, 20062006-08-09
m...@yahoo.it wrote:
> BDM is available in all operating modes but must be enabled before
> firmware commands are executed.
- You don't need firmware commands to read memory. Hardware commands
are sufficient.
- You can enable BDM firmware via hardware BDM commands.
> I think that if the firmware of the micro changes the status from
> secured to unsecured, at that point the BDM Interface is useless to
> dump the code.
The intention of the backdoor is temporarily unsecuring (think a
moment about the word) a device to allow authorized people debugging.
This wouldn't make much sense if one couldn't access S12 memory in
this state, would it?
> I done the boot exaxtly like Tim Milliken wrote, and I
> was no able to connect to the target with the BDM Interface.
Are you sure that you _really_ unsecured the device, from within
your application, executed from RAM, setting the KEYACC bit?
No word of the key was 0 or 0xffff?
The SEC bits were 1:0 after this procedure (checked by your app and
reported somehow?
Does your debugger actually support "hot attach"?
Could you "hot attach" at all to an unsecured device?
Maybe standard debugger software doesn't support this case very
conveniently, but you shouldn't think it's not possible at all.
That's rather dangerous designing "secure" applications.
Oliver
--
Oliver Betz, Muenchen
> BDM is available in all operating modes but must be enabled before
> firmware commands are executed.
- You don't need firmware commands to read memory. Hardware commands
are sufficient.
- You can enable BDM firmware via hardware BDM commands.
> I think that if the firmware of the micro changes the status from
> secured to unsecured, at that point the BDM Interface is useless to
> dump the code.
The intention of the backdoor is temporarily unsecuring (think a
moment about the word) a device to allow authorized people debugging.
This wouldn't make much sense if one couldn't access S12 memory in
this state, would it?
> I done the boot exaxtly like Tim Milliken wrote, and I
> was no able to connect to the target with the BDM Interface.
Are you sure that you _really_ unsecured the device, from within
your application, executed from RAM, setting the KEYACC bit?
No word of the key was 0 or 0xffff?
The SEC bits were 1:0 after this procedure (checked by your app and
reported somehow?
Does your debugger actually support "hot attach"?
Could you "hot attach" at all to an unsecured device?
Maybe standard debugger software doesn't support this case very
conveniently, but you shouldn't think it's not possible at all.
That's rather dangerous designing "secure" applications.
Oliver
--
Oliver Betz, Muenchen
Reply by ●August 9, 20062006-08-09
I have to admit that if a Backdoor exists, it is for debugging purposes,
thus BDM attachment on secure devices. But since the Flash security does not
work has it was initially specified, then maybe that the Backdoor unsecure
does not work as it is expected, i.e. it may allow flash access to the
resident program but the BDM is still unaccessible.
I am not able to connect to the MCU thorugh BDM when the chip is unsecured
thorugh the Backdoor. Maybe my settings are the problem. Does anyone have
suggestions that would proove Oliver's point?
I am using
BDM Tool - P&E BDM-multilink Parrallel port rev.B
Freescale Codewarrior 4.5
BTW, I can guarantee that my MCU is running unsecured because it is the
condition that I have to meet in order to write Flash or EEPROM.
Was anyone ever able to connect thourgh BDM to a secure HCS12Dx device with
MASK SET 1k79x which was unsecured with the Backdoor access key?
thanks
NOTE: Guys, please, this is an interresting discussion. Everyone's input is
what will help us build better and more secure products. This is exactly why
this forum exists! Please stop personnal attacks. All the inputs are
valuable and make the discussion most interresting.
js
_____
From: 6... [mailto:6...] On Behalf Of
Oliver Betz
Sent: August 9, 2006 10:06 AM
To: 6...
Subject: Re: [68HC12] RE: MC9S12DP256B security
marcogalli80@ yahoo.it wrote:
> BDM is available in all operating modes but must be enabled before
> firmware commands are executed.
- You don't need firmware commands to read memory. Hardware commands
are sufficient.
- You can enable BDM firmware via hardware BDM commands.
> I think that if the firmware of the micro changes the status from
> secured to unsecured, at that point the BDM Interface is useless to
> dump the code.
The intention of the backdoor is temporarily unsecuring (think a
moment about the word) a device to allow authorized people debugging.
This wouldn't make much sense if one couldn't access S12 memory in
this state, would it?
> I done the boot exaxtly like Tim Milliken wrote, and I
> was no able to connect to the target with the BDM Interface.
Are you sure that you _really_ unsecured the device, from within
your application, executed from RAM, setting the KEYACC bit?
No word of the key was 0 or 0xffff?
The SEC bits were 1:0 after this procedure (checked by your app and
reported somehow?
Does your debugger actually support "hot attach"?
Could you "hot attach" at all to an unsecured device?
Maybe standard debugger software doesn't support this case very
conveniently, but you shouldn't think it's not possible at all.
That's rather dangerous designing "secure" applications.
Oliver
--
Oliver Betz, Muenchen
thus BDM attachment on secure devices. But since the Flash security does not
work has it was initially specified, then maybe that the Backdoor unsecure
does not work as it is expected, i.e. it may allow flash access to the
resident program but the BDM is still unaccessible.
I am not able to connect to the MCU thorugh BDM when the chip is unsecured
thorugh the Backdoor. Maybe my settings are the problem. Does anyone have
suggestions that would proove Oliver's point?
I am using
BDM Tool - P&E BDM-multilink Parrallel port rev.B
Freescale Codewarrior 4.5
BTW, I can guarantee that my MCU is running unsecured because it is the
condition that I have to meet in order to write Flash or EEPROM.
Was anyone ever able to connect thourgh BDM to a secure HCS12Dx device with
MASK SET 1k79x which was unsecured with the Backdoor access key?
thanks
NOTE: Guys, please, this is an interresting discussion. Everyone's input is
what will help us build better and more secure products. This is exactly why
this forum exists! Please stop personnal attacks. All the inputs are
valuable and make the discussion most interresting.
js
_____
From: 6... [mailto:6...] On Behalf Of
Oliver Betz
Sent: August 9, 2006 10:06 AM
To: 6...
Subject: Re: [68HC12] RE: MC9S12DP256B security
marcogalli80@ yahoo.it wrote:
> BDM is available in all operating modes but must be enabled before
> firmware commands are executed.
- You don't need firmware commands to read memory. Hardware commands
are sufficient.
- You can enable BDM firmware via hardware BDM commands.
> I think that if the firmware of the micro changes the status from
> secured to unsecured, at that point the BDM Interface is useless to
> dump the code.
The intention of the backdoor is temporarily unsecuring (think a
moment about the word) a device to allow authorized people debugging.
This wouldn't make much sense if one couldn't access S12 memory in
this state, would it?
> I done the boot exaxtly like Tim Milliken wrote, and I
> was no able to connect to the target with the BDM Interface.
Are you sure that you _really_ unsecured the device, from within
your application, executed from RAM, setting the KEYACC bit?
No word of the key was 0 or 0xffff?
The SEC bits were 1:0 after this procedure (checked by your app and
reported somehow?
Does your debugger actually support "hot attach"?
Could you "hot attach" at all to an unsecured device?
Maybe standard debugger software doesn't support this case very
conveniently, but you shouldn't think it's not possible at all.
That's rather dangerous designing "secure" applications.
Oliver
--
Oliver Betz, Muenchen
