Encryption Algorithm
in [Embedded]
|
From: Marc Ramsey on 18 Feb 2005 17:46 Guy Macon wrote: > There are two algorithms that are suitable for this, AES and RC4. > AES requires less RAM, RC4 requires less ROM and is a lot easier > for an embedded systems programmer to understand. Do a web search > on [ AES cipher ], [ RC4 Rivest ] and [ ciphersaber ]. Look into TEA (Tiny Encryption Algorithm), I've found that it suits small embedded systems rather nicely: http://www.simonshepherd.supanet.com/tea.htm Marc
From: Wim Ton on 19 Feb 2005 03:57 > [known plaintext attack for executables] > > >Executables have a lot of redundancy. (An Intel .exe can be zipped to 35% of > >the original) > >Most executables have pedictable parts, like the startup code and push/pop > >everything > > Maybe message strings are worst if not runtime descrambled (which > would cause annoying coding). Startup code must not be known (for > example, I don't use the startup code provided by the compiler > manufacturer). push/pop sequences are short. After all, the positions > of all these code portions are unknown, therefore a noticeable part of > the code has to be tested - likely much more than twice the length of > the LFSR possible with known plaintext at known position. You can also encrypt only the interesting parts of the program (the code segment I suppose) as the strings will be known anyway by someone who observes the working of the products. Saves time as well. > >The key of a LFSR is the initial condition. > > And the polynomial. There is not much scope to vary the polynomal, as only a few polynomals produce maximum length cycles. Wim
From: Oliver Betz on 19 Feb 2005 05:18 Guy Macon <http://www.guymacon.com/> wrote: [field updates done by "untrusted" people] >Got it. That will work. Is your hardware such that the untrusted >people doing the field updates can overwrite the key inside the >contoller? I think not if you write the updating code - which you Exactly. Maybe I keep the option to update also the loader part, but usually it will be protected. >would have to do anyway to add encryption. > >Take a look at my post about AES, RC4 and ciphersaber. Let me know >if any of it doesn't make sense. I will have a look at them, and also TEA suggested by Marc Ramsey. [copied from other posting] >I also suggest posting the code in sci.crypt before using it - but >make sure it is correct before swimming with the sharks! That was the intention <g>. >BTW, roughly how much RAM, ROM, and cycles can you afford to use >up during the update? (the RAM can be used for other things The main goal till now was to make a very efficient loader for the Motorola/Freescale HCS12. That means small footprint, little restrictions for the application, no specific host requirements (simple terminal program), fast transfer, 7bit data (e-mail). Therefore I send BASE64 encoded lines at 115200bits/s without handshake (the serial port is polled during the Flash programming periods). At 24MHz bus clock, one byte is transferred in approx. 2000 cycles. I have to look how much is available for key generation. In the current implementation, I have little RAM and code space because the whole loader is copied to 2k RAM. This way I can simply reprogram the _whole_ memory (including the loader itself). Space for two 32 bit LFSRs, IIRC. For a stronger encryption, I likely had to change this. Since small HCS12 derivatives have only one Flash block, there is always the Flash programming time where no Flash is readable. Therefore the receive routine and buffer always must reside in RAM. The decryption could stay in Flash, but then can use only the transmission time minus Flash programming time. So if I want stronger encryption, I probably had to slow down the process. Either by using a slower transfer rate, or by decrypting after transfer. It's important to find the right trade-off between security and cost. As long as the product is not widely known and/or subject to "just for fun" attacks, the decryption (plus reverse engineering of the code) doesn't need to be more expensive than re-writing the application itself or breaking the protection of the microcontroller (no clue how secure the HCS12 is). Oliver -- Oliver Betz, Muenchen (oliverbetz.de)
From: Oliver Betz on 19 Feb 2005 05:19 "Wim Ton" <wimton(a)blueyonder.co.uk> wrote: [where to find known plaintext] >You can also encrypt only the interesting parts of the program (the code >segment I suppose) as the strings will be known anyway by someone who good idea! >> >The key of a LFSR is the initial condition. >> >> And the polynomial. > >There is not much scope to vary the polynomal, as only a few polynomals >produce maximum length cycles. I don't remember numbers for larger polynomials, but there were 2048 or 4096 16 bit max. length polynomials. Oliver -- Oliver Betz, Muenchen (oliverbetz.de)
First
|
Prev
|
Pages: 1 2 3 4 5 Prev: Keil C51/ 8051 port of uIP v0.9 TCP/IP stack. Next: TCP/IP stack for GPRS |