Embedded Linux & Code Security

A little research on Tivo might be informative. Hardware signature checks to keep unauthorized software from running. How the binaries could be secured I don't know...

In FPGAs, configurations can be stored in Flash in an encrypted format that only the FPGA to be configured has the key to . During configuration, the FPGA does the encryption, so even data over the Flash to FPGA channel is secure. How the FPGA keeps it's key secure, I don't remember. Maybe there is an analogue to this in MCU land.

---Matthew Hicks

Whoa. Think about this question for a moment. The underlying question really is "How do I secure an application that's running from external flash memory?". The answer is: you can't without a crypto engine inside the CPU.

If your Linux binary is small enough to fit, with the kernel, inside a single-chip solution, then your answer is already there in the form of whatever code protection bits the chip vendor offers you.

If it isn't, then you will have the same problem regardless of operating system.

Or perhaps with the key stored in the internal flash -- one could encrypt the external flash's version, and it would only be decrypted as it was read into RAM. One would still be susceptible to someone with a logic analyzer, but I doubt you could get away from that at any rate.

Not very good, but you could try using upx on it. The raw binary will not then be subject to searching, disassembly, etc.

The most non-trivial solution that I have seen was storing part of the code in the internal RAM. The code resides there permanently and never gets reloaded; when the device power is off, the RAM is powered from the backup battery. If the cover is opened, the battery is disconnected.

The essence of the problem is not technical. The non technical problem can't be resolved by any technical means.

Vladimir Vassilevsky DSP and Mixed Signal Design Consultant

That's so easy to crack - all you have to do is to figure out where power pins are, and connect external battery. The only non-trivial part of the game was: to find dentist's xray-camera (guess why I needed it?) Been there, done that (~yawn).

The external version may be encrypted but that encrypted one has to be decrypted and stored somewhere for further execution. The obvious place is RAM. Also, the decrypting engine has to run from somewhere, either from RAM as a function BIOS or OS has jumped to or it may be run-in-place from within external flash. In any case an "interceptor" may be put in place to intercept decryption engine or anything else. Here comes special debuggers (similar to SoftICE in Wintel machines) which can stop every cycle of the processor or run full-speed as well with dump-memory and similar facilities. Dump-memory can be used to understand the decryptor, etc. etc.

Therefore, for skilled cracker only "sky is the limit", in another words, there's nothing man can undo the man has done (~or something like that). Or, the name of the game is "the level of sofistication of the author"

For a person with want to protect it's work (and profit) it's obvious that s/he has to have cracker's mind to protect him/herself from crackers.

How? It depends of hardware infrastracture of the embedded Linux system itself, i.e. what is available to the author for his/her IP protection. Since commercial motherboards of today's embedded systems capable of running Linux do not offer too much hardware protection on-board, the author either has to implement significant effort to obfuscate/protect executable (binaries) in form of some encryption/decryption execute-in-RAM-type-of-situation or author has to invest in hardware add-ons, a solution(s) which assists encyption/decryption scheme by obscuring or protecting key(s).

I generaly tend to agree with Tim Wescott idea/solution.

googoolify this

UCAM-CL-TR-630 Technical Report ISSN 1476-2986 Number 630

Semi-invasive attacks A new approach to hardware security analysis Sergei P. Skorobogatov

Martin

Specifically Altera Statrix-II FPGAs have AES 128 decryption and OTP (fuse) non-readable key storage for the configuration bitstream.

So: run Linux on a NIOS soft core in one of these FPGAs. Encrypt the code in flash. Add decryption units with keys to the memory interfaces (or limit yourself to the memory built into the FPGA). The decyption unit and keys are encrypted in the Stratix-II bitstream, so they can't be read.

Even if you were able to read the fuse settings somehow, you would then have to reverse-engineer the undocumented bit-stream format.

I think this is all bad, except for protecting nuclear weapons. There would be no hacked iPhones if its firmware was encrypted this well. Vernor Vinge's _Rainbow's End_ told about a computer engineer who could no longer tinker with hardware due to her invention of a secure hardware environment.

There's really no such thing as total code security, there's just making it difficult and/ or uneconomic to get at the code. When it's cheaper to develop new than to blag, that's the best you can do. I'd suggest potting the board so that the bus is inaccessible, then normal software security techniques to make it difficult to get into the system via the ports without overcoming some ferocious dragon. Perhaps also put a strategically- placed photodiode on the board so that you erase everything if it is run without the potting, and that you don't tell anyone about.

One company I know used to silently trash the calibration table if the wrong password was entered a number of times.

Understood -- ideally my goal would be to make it as hard to get to the code as it would be to reverse-engineer the thing based on it's terminal behavior. If I could get half way there I'd be happy.

I'm leaning toward just encrypting the files on disk, and making sure the decryption (or at least the algorithm) is in the chip's on-board flash.

This makes me think that an ARM-class chip with on-board encryption & decryption of data going out to RAM would be a good thing. I wonder if anyone does it....

You might want to take a look at this:

Vladimir Vassilevsky DSP and Mixed Signal Design Consultant

Nothing's ever completely secure, it just gets more difficult to crack.

A platform depending on an encrypted code memory interface can be vulnerable in many ways. For example, when the code memory interface doesn't also authenticate.

Regards, Marc

Then I have to repeat my suggestion of using upx, free at:

which will also have the advantage of reducing the size of your distributed object code (but not the run time size).