Embedded Linux & Code Security

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]]);}

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.

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:


> 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

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