How to protect data on CF (reverse engineering)

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
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

Re: How to protect data on CF (reverse engineering)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

HPmaster wrote:
Quoted text here. Click to load it

Sorry, but reading the contents of a readable device is hardly "reverse
engineering" at this level.

Quoted text here. Click to load it

Even your "exposure" is just you flash disk being read only by CPU. There's no
difference at the hardware level between a user entering a cp command or the
system loading a program to be run; at the hardware, both are a series of reads
to the device, and are indistinguishable from each other.

To me, you have two challanges:
1) prevent unauthorized access to the raw data, and
2) prevent the modeling of your component ("reverse engineering")

You could encrypt the contents of the flash disk, and include a hardware
decryption mechanism in the system. This would prevent unauthorized accesses
from determining the contents of your flash disk (they'd see the encrypted
contents, but not have a way to decrypt it) while still permitting the hardware
to work with the data. Use hardware encryption so as to slow down hacking of the
decryptor component (you can't prevent it, but you can make it expensive).

As for preventing "reverse engineering", Outside of making the product (system
/and/ flash disk) one big monolithic component, it's unlikely that you'll be
able to prevent "reverse engineering". The best you can do is make it expensive.


Quoted text here. Click to load it

- --
Lew Pitcher
IT Specialist, Enterprise Data Systems,
Enterprise Technology Solutions, TD Bank Financial Group

(Opinions expressed are my own, not my employers')
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)

iD8DBQFCNe9qagVFX4UWr64RApZHAKDWY8Y8DOKL6FfF7thBeU0lTP2UqACffXlL
ziiSdPTBeOKQzaDTtV+v4PI=
CD%fH
-----END PGP SIGNATURE-----

Re: How to protect data on CF (reverse engineering)
Quoted text here. Click to load it

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


Re: How to protect data on CF (reverse engineering)

Quoted text here. Click to load it



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.

Re: How to protect data on CF (reverse engineering)
Quoted text here. Click to load it

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.

Re: How to protect data on CF (reverse engineering)
Quoted text here. Click to load it

That's why we have copyright laws.


Re: How to protect data on CF (reverse engineering)
Quoted text here. Click to load it

Copyright + China = 0


Re: How to protect data on CF (reverse engineering)
Quoted text here. Click to load it
example some
Quoted text here. Click to load it
could copy
Quoted text here. Click to load it

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


Re: How to protect data on CF (reverse engineering)
Quoted text here. Click to load it


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

Re: How to protect data on CF (reverse engineering)
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


Site Timeline