Tim Wescott wrote:
> Paul Burke wrote:
>> Tim Wescott wrote:
>>
>>> A quick web search did not lead to joy:
>>>
>>> What to folks do about securing their code in an embedded Linux
>>> system? How does one keep one's binaries from being accessible
>>> to anyone who gets their hands one one's board?
>>>
>>> Pointers?  Links to tutorials?  Books?
>>
>> There's really no such thing as total code security, there's just
>> making it difficult and/ or uneconomic to get at the code.
> 
> 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.
> 
>> 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.
> 
> 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....

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

   <http://www.upx.sf.net>

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

-- 
 Chuck F (cbfalconer at maineline dot net)
   <http://cbfalconer.home.att.net>
   Try the download section.



-- 
Posted via a free Usenet account from http://www.teranews.com

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

Tim Wescott wrote:


> 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:

http://www.analog.com/processors/blackfin/lockboxSecureTechnology.html


Vladimir Vassilevsky
DSP and Mixed Signal Design Consultant
http://www.abvolt.com

On Mon, 12 Nov 2007 08:43:48 +0000, Paul Burke wrote:

> Tim Wescott wrote:
>> A quick web search did not lead to joy:
>> 
>> What to folks do about securing their code in an embedded Linux system? 
>> How does one keep one's binaries from being accessible to anyone who gets
>> their hands one one's board?
>> 
>> Pointers?  Links to tutorials?  Books?
> 
> There's really no such thing as total code security, there's just making 
> it difficult and/ or uneconomic to get at the code.

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.

> 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.

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....

-- 
Tim Wescott
Control systems and communications consulting
http://www.wescottdesign.com

Need to learn how to apply control theory in your embedded system?
"Applied Control Theory for Embedded Systems" by Tim Wescott
Elsevier/Newnes, http://www.wescottdesign.com/actfes/actfes.html

Tim Wescott wrote:
> A quick web search did not lead to joy:
> 
> What to folks do about securing their code in an embedded Linux system? 
> How does one keep one's binaries from being accessible to anyone who gets
> their hands one one's board?
> 
> Pointers?  Links to tutorials?  Books?

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.

In article <b66e6525cd1c8c9f136acf9d755@news.ks.uiuc.edu>,
Matthew Hicks  <mdhicks2@uiuc.edu> wrote:
>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.

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.
-- 
/*  jhallen@world.std.com AB1GO */                        /* Joseph H. Allen */
int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
+r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2
]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}

On Fri, 09 Nov 2007 22:06:41 -0600, in comp.arch.embedded Tim Wescott
<tim@seemywebsite.com> wrote:

>A quick web search did not lead to joy:
>
>What to folks do about securing their code in an embedded Linux system? 
>How does one keep one's binaries from being accessible to anyone who gets
>their hands one one's board?
>
>Pointers?  Links to tutorials?  Books?
>
>Thanks.
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

> 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.
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.

-- 
      =^.^=
StoneThrower

"To invent, you need an imagination and a pile of junk."
Thomas Alva Edison



"Tim Wescott" <tim@seemywebsite.com> wrote in message 
news:B7KdnTDZ1pXYwajanZ2dnUVZ_oDinZ2d@web-ster.com...
> On Fri, 09 Nov 2007 20:29:46 -0800, larwe wrote:
>
>> On Nov 9, 11:06 pm, Tim Wescott <t...@seemywebsite.com> wrote:
>>
>>> What to folks do about securing their code in an embedded Linux system?
>>
>> 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.
>
> -- 
> Tim Wescott
> Control systems and communications consulting
> http://www.wescottdesign.com
>
> Need to learn how to apply control theory in your embedded system?
> "Applied Control Theory for Embedded Systems" by Tim Wescott
> Elsevier/Newnes, http://www.wescottdesign.com/actfes/actfes.html 

> 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.
>

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).

-- 
      =^.^=
StoneThrower

"To invent, you need an imagination and a pile of junk."
Thomas Alva Edison 

Tim Wescott wrote:

> What to folks do about securing their code in an embedded Linux system? 
> How does one keep one's binaries from being accessible to anyone who gets
> their hands one one's board?
> 

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
http://www.abvolt.com