Hi JB, thanx for your feedback.
I understand that everything can be reverse engineered but the point is a question of effort, mounting a compact flash card and inspecting the contents is definitely easyier than exploiting buffer overflows or dump memory.
We're not selling a device, we're just offering a service and by contract the customer doesnt have the rights to open or modify the device (which is our property).
Said that I figure out that there's not an effective way of securing our proprietary applications.
Thanx again for your feedback.
Best,
nettie
Jan-Benedict Glaw wrote:
On Sat, 2004-09-18 02:33:57 +0200, nettie <nettie@xxxxxxxxxx> wrote in message <414B8275.5080100@xxxxxxxxxx>:
I'm actively looking for a way to encrypt the data stored in the compact flash to preevent possible reverse engineering of the custom applications and also to preevent 3rd party modification and related services abusing.
:-)
Anything that can be moved into main memory (for execution) can be exchanged, reverse engineered and, if needed, altered, too.
The fisr problem I encounter is realted to the password storage, considering that the embedded device will not have keyboard, serial console and that it will be installed in an hostile/untrusted environment. If I store it in the compact flash someone will be able to read it and as said before the human input is not an option.
Correct. But as I said, that's pretty much a conceptual problem. ...and to be honest: I for one prefer having control over the devices I use!
The only non-crypto solution I found is redesign the whole bootstrapping architecture, build a light/intelligent that will boot download from our servers to ram the real kernel, a cramfs image containing the preconfigured applications and tools, pivot the root and kexec to the fresh downlaoded full featured kernel.
For sure, there'll be an easy way to intercept that. I think about embedded device's debugging interface and the like.
Don't waste your time here. Just accept that you won't be able to make that bullet-proof...
I'm sorry for the non-crypto related informations of my last sentence but I wanted to make a clear picture of what I'm trying to achieve, maybe this could be useful for someone else working on a similar project.
Well, I don't think that it'll work at all, I think it's a bad idea and I think that most open/free source developers won't really like to see or support work-in-progress in that direction, with the possible exception of detecting proprietary programs being started.
MfG, JBG
- Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/
