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]]);}
Embedded Linux & Code Security
Started by ●November 10, 2007
Reply by ●November 10, 20072007-11-10
Reply by ●November 12, 20072007-11-12
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.
Reply by ●November 12, 20072007-11-12
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
Reply by ●November 12, 20072007-11-12
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
Reply by ●November 12, 20072007-11-12
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
Reply by ●November 12, 20072007-11-12
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