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