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. -- 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
Embedded Linux & Code Security
Started by ●November 10, 2007
Reply by ●November 10, 20072007-11-10
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?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...
Reply by ●November 10, 20072007-11-10
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> 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. > > 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 10, 20072007-11-10
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.
Reply by ●November 10, 20072007-11-10
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.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. -- 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 10, 20072007-11-10
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?Not very good, but you could try using upx on it. The raw binary will not then be subject to searching, disassembly, etc. <http://upx.sf.net> -- 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
Reply by ●November 10, 20072007-11-10
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
Reply by ●November 10, 20072007-11-10
> 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
Reply by ●November 10, 20072007-11-10
> 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
Reply by ●November 10, 20072007-11-10
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
