How to protect data on CF (reverse engineering)

Take a look on this situation: My company made some new device with very new technology on it. We use for example some SoC with x86 CPU and boot Linux from CF. Everybody (with very simple method) could copy our solution (just reading flash disk). How to protecting the product from this sort of hacking (reverse engineering)? The solution where flash could be read only by CPU (hardware or software)?

Thank you for reading.

--
Pawel Huchla
email: Pawel dot Huchla at hpnet dot pl
Reply to
HPmaster
Loading thread data ...

  1. If the CPU can read it, the cracker can also.
  2. It is against the ethics of the Linux community to attempt to hide your code. It may be also against the GPL. Please select another base system before starting hiding.
--
Tauno Voipio
tauno voipio (at) iki fi
 Click to see the full signature
Reply to
Tauno Voipio

That's why we have copyright laws.

Reply to
Jim Stewart

example some

could copy

A simple way that I have seen in the past is to scramble the data lines leading to the CF interface. Your software must then properly scramble commands to the CF card, but the data pretty much goes out and is returned without problems. If a reverse-engineer has access only to the CF card, he will find very unusual data on the card.

If the reverse engineer has access to the hardware, he can probably figure out the unscrambling algorithm to convert the data on the card. At best this is just a very simple form of encryption and would require only a short while for a competitor to break. If the engineer knows the contents of a Linux boot record, breaking the scrambling becomes pretty simple.

A more complex encryption algorithm and some unique markers in the code may be a more effective deterrent---but enforcing a copyright on the code requires interacting with lawyers.

IN the long run, the best solution is probably ensure that the cost to the customer, when balanced with your company's reputation and service policies, tilts the balance in your favor. Not always an easy task with mass-market products.

Mark Borgerson

Reply to
Mark Borgerson

I would agree with point 2. Why are you trying to hide GPLd software. You are required to give the source away. If you rely on encryption, you still cann't prevent a bitter employee from exposing your deception. At the very least, all GPL'd code in the system must be made available.

Regarding point 1, if your CPU has a unique ID and you have the loopAES system, you could use the CPU ID as salt/seed for the AES key. The CF device would be encoded via loopAES.

All of this code would have to reside in "UN-probable" memory. The CPU ID has to be erased when tamper measures are detected. Dallas and Atmel have some secure processors that would help with this.

Having hardware that issues "random" memory accesses can also confuse an attacker.

I would modify Tauno's one.

  1. If the CPU can read it and the cracker can probe everything in the CPU and the memory, then the cracker can also read it.

If you can keep anything secret (a key), it can be encrypted and would be very difficult to break. Some obvious stumbling blocks are having a file system with known files (eg. /etc/passwd, etc.). If an attacker knows the plain text, it is much easier to brute force.

You can make the "ID" unique to each CPU and have to re-encrypt the image for each CPU. You can use a common key; once broke, all systems will be compromised.

The main use for this would be to protect data and not code IMHO.

fwiw, Bill Pringlemeir.

--
I work hard because millions on welfare depend on me.
Reply to
Bill Pringlemeir

One can have binary only modules, or binary only executables, but hiding the entire system is sure to piss off some folks. Whether they will do anything is a question of how successful the product becomes. The prototype case is the Linksys WRT54G, I believe. Those really interested in the device would not let Linksys alone until they fully complied with the GPL. Enforcement of the GPL was a function of its success.

Proprietary code can be hidden courtesy of the LGPL, and by using tainted binary only modules for the kernel. Understanding these issues would be prudent before proceeding.

Excessive paranoia and GPL and Linux do not mix well.

Reply to
Bryan Hackney

1) No chance. 2) If it's a clever solution, you should be proud of it and spread the word instead of hiding it.

-Michael

Reply to
Michael Schnell

For Prventing cracking of CF card data - A very complex hardware encryption integrated with a complex hardware decryption method is good !! Even, Many complex encryption algorithms have been cracked today. So, better ensure constant R&D in security and upgrading the algorithms !!

karthik bala guru

Reply to
bluekarthik

Copyright + China = 0

Reply to
Bryan Hackney

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.