|
Posted by Bruce Barnett on February 14, 2005, 5:08 pm
If you were Registered and logged in, you could reply and use other advanced thread options
Some people have asked me for help in securing their application code
in embedded devices from the threat of reverse engineering. I was
looking for some papers/sites that discuss approaches, good and bad,
to address this issue.
This system is attached to a network, so it can get encrypted data
over a wire.
They are interested in options other than using a secure
microprocessor with password protected memory. I'm not sure what the
issues are.
I'm still gathering requirements, but perhaps someone can point me to
commercial solutions, web pages, hack sites, lessons learned,
do's and don'ts, etc.
Thanks
I realize that any system can be defeated, especially if you have
physical access. Some are harder to defeat than others.
SRAM vs. FLASH memory for instance.
--
Sending unsolicited commercial e-mail to this account incurs a fee of
$500 per message, and acknowledges the legality of this contract.
|
|
Posted by Chris Hills on February 14, 2005, 5:18 pm
If you were Registered and logged in, you could reply and use other advanced thread options
>
>Some people have asked me for help in securing their application code
>in embedded devices from the threat of reverse engineering. I was
>looking for some papers/sites that discuss approaches, good and bad,
>to address this issue.
>
>This system is attached to a network, so it can get encrypted data
>over a wire.
>
>They are interested in options other than using a secure
>microprocessor with password protected memory. I'm not sure what the
>issues are.
>
>I'm still gathering requirements, but perhaps someone can point me to
>commercial solutions, web pages, hack sites, lessons learned,
>do's and don'ts, etc.
>
>Thanks
>
>I realize that any system can be defeated, especially if you have
>physical access. Some are harder to defeat than others.
>SRAM vs. FLASH memory for instance.
Use a single chip MCU system with lock bits. Many MCU have them.
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/\
/\/\/ chris@phaedsys.org www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
|
|
Posted by Vadim Borshchev on February 14, 2005, 5:45 pm
If you were Registered and logged in, you could reply and use other advanced thread options
> I realize that any system can be defeated, especially if you have
> physical access.
Indeed. Hope these links might be of interest:
http://www.cl.cam.ac.uk/~sps32/mcu_lock.html
http://www.xenatera.com/bunnie/proj/anatak/xboxmod.html
|
|
Posted by Wim Ton on February 14, 2005, 5:50 pm
If you were Registered and logged in, you could reply and use other advanced thread options
>
> Some people have asked me for help in securing their application code
> in embedded devices from the threat of reverse engineering. I was
> looking for some papers/sites that discuss approaches, good and bad,
> to address this issue.
>
> This system is attached to a network, so it can get encrypted data
> over a wire.
>
> They are interested in options other than using a secure
> microprocessor with password protected memory. I'm not sure what the
> issues are.
>
> I'm still gathering requirements, but perhaps someone can point me to
> commercial solutions, web pages, hack sites, lessons learned,
> do's and don'ts, etc.
>
> Thanks
>
> I realize that any system can be defeated, especially if you have
> physical access. Some are harder to defeat than others.
> SRAM vs. FLASH memory for instance.
See the work of Ross Anderson and Marcus Kuhn about reverse engineering.
Atmel and Maxim-Dallas (among others) have some extra secure processors, and
for even higher security you may think of smartcards, as these are specialy
designed to withstand reverse engineering (with varying degrees of success)
Wim
|
|
Posted by Nicholas O. Lindan on February 14, 2005, 10:27 pm
If you were Registered and logged in, you could reply and use other advanced thread options
> Some people have asked me for help in securing their application code
> in embedded devices from the threat of reverse engineering.
This issue comes up frequently with naive clients. Clients are often
convinced the product developed for them is worth uncounted riches
when in reality it is worth no more than it would cost to have a
college student write a virgin copy of the software from scratch.
The most successful companies publish the source code for their
products. Published schematics are SOP for h/p^H^H^HAgilent, IBM,
Tektronix, consumer products etc. etc. etc..
Even if this is a secure application the product should be designed
such that knowing the circuit and the algorithm one should not be
able to crack the encrypted data.
If another firm can produce a 'Chinese copy' and take the market
the problem is manufacturing, product quality, product pricing,
distribution, service .... everywhere _but_ intellectual property.
--
Nicholas O. Lindan, Cleveland, Ohio
Consulting Engineer: Electronics; Informatics; Photonics.
To reply, remove spaces: n o lindan at ix . netcom . com
psst.. want to buy an f-stop timer? nolindan.com/da/fstop/
|
| Similar Threads | Posted | | Disable devices in code | May 4, 2006, 4:39 pm |
| Call for Papers on Embedded Cryptographic Systems | September 7, 2005, 6:58 am |
| Blackberry Devices - Security | August 13, 2004, 11:28 am |
| Secure Network Devices | June 19, 2007, 7:22 am |
| Securing the database from the DBA | March 30, 2004, 7:51 am |
| Securing tcp data | November 10, 2005, 2:51 pm |
| One-Stop Security HArdware Devices | July 30, 2005, 3:45 pm |
| restrict CDROM AND OTHER REMOVABLE DEVICES | June 29, 2006, 1:38 am |
| Securing network from laptops | July 23, 2005, 3:44 pm |
| So why don't we use full disk encryption on all mobile devices? | October 12, 2006, 10:56 pm |
|
XML site map