Encryption Algorithm

Why encrypt then? Why not just store whatever you were planning to encrypt in this internal, more or less "protected" memory? The result is the same.

--
Guy Macon
Reply to
Guy Macon
Loading thread data ...
[known plaintext attack for executables]

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.

And the polynomial.

A brute force attack is always possible but can be made enough expensive, I guess.

Oliver

--
Oliver Betz, Muenchen (oliverbetz.de)
Reply to
Oliver Betz
[...]

as I wrote: field updates. Done by "untrusted" people.

The result is certainly the same, but the method is not feasible since I can't access the controller "in the field".

Oliver

--
Oliver Betz, Muenchen (oliverbetz.de)
Reply to
Oliver Betz

With the key already in the micro? That would work against someone reading the downloadable/installable file. Not a bad idea.

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

I also suggest posting the code in sci.crypt before using it - but make sure it is correct before swimming with the sharks!

(If anyone thinks that the encryption.decryption code should be kept secret, please search on [ security obscurity cryptography ].)

--
Guy Macon
Reply to
Guy Macon

Make the key 128 bits that you downloaded from hotbits and it will always be too expensive - the universe is too small and too young to do the computation in. Make it 256 bits and it will be too hard to ever do squared. That's only 32 bytes of ROM to hold your key. but its 2^256 (roughly 10^77) guesses to do a brute force attack.

--
Guy Macon
Reply to
Guy Macon

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

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 afterwards, of course, and flash will work as RAM for the algos I am talking about - with the usual speed penalty).

--
Guy Macon
Reply to
Guy Macon

Look into TEA (Tiny Encryption Algorithm), I've found that it suits small embedded systems rather nicely:

formatting link

Marc

Reply to
Marc Ramsey

of

push/pop

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.

There is not much scope to vary the polynomal, as only a few polynomals produce maximum length cycles.

Wim

Reply to
Wim Ton
[field updates done by "untrusted" people]

Exactly. Maybe I keep the option to update also the loader part, but usually it will be protected.

I will have a look at them, and also TEA suggested by Marc Ramsey.

[copied from other posting]

That was the intention .

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)
Reply to
Oliver Betz
[where to find known plaintext]

good idea!

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)
Reply to
Oliver Betz

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.