Adequate Encryption?

Go To Last Post
12 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Is there a way to test your encryption method?

I know there are levels of protection, and I'm not real interested in complete lock out. I just want to make it impractical to reverse engineer.

I put a version of TEA in a boot loader so that it fits into a small loader block. It seems to accomplish my goal of scrambling the bits so the data can not be immediately disassembled.

Is there a way to verify it? Is there a place to submit a block of encrypted data and the original data so that it can be verified?

Thanks.

official AVR Consultant
www.veruslogic.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Compile the TEA reference code on a PC, and make sure both codes have the same output with same input. There are only 64-bit blocks so 2^64 combinations, I guess you don't want to try them all?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Some aspects are described here:
http://en.wikipedia.org/wiki/Tin...

I think the best is to use a well known method
that is known to have good properties.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

versus RC4?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
versus RC4?
When I was looking into this about 20 months ago, I didn't happen upon RC4. It looks simple enough that it should compile nice and small.

If I can implement it fully, rather than my modified TEA I'm questioning, then it should answer my concern.

I searched the forum for RC4 and there aren't many supporters of the method. But, if it's good enough for WEP, it should be adequate here.

I just hate the thought of handing over the result of many man hours of development in an unsealed envelope. Let's face it, it's not a high value target.

official AVR Consultant
www.veruslogic.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The biggest reverse engineering problem is the hardware itself. Many attacks focus on the FLASH code inside the microprocessor and if successful, they defeat the most elaborate and secure encryption.

If you want to send data over a public system like the Internet where your AVR hardware is in secure hands at all times, use the best possible encryption you are able to implement.

If your hardware isn't physically secured, just do enough to hopefully make cracking the hardware more expensive and time consuming than writing a new program from scratch.

There are exotic chips available that attempt to make it really expensive to crack the hardware, but you will pay lots of money for each one.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

xtea and xxtea versions of the algorithm have not been cracked yet. I use them to secure PC apps I program, but never used encryption in an AVR yet.

The XBox was cracked because it used tea and its weakness was exploited to gain access to the OS, eventually enabling the hackers to run Linux on the game console.

I found this post regarding rtea
http://defectoscopy.com/forum/viewtopic.php?t=21 interesting in that it looks lighter to use on an AVR. I'm not aware of its weaknesses, but neither will anyone else (unless a crypto pro releases a paper on the topic).

-Raliegh

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Wouldn't you securely send the code over the internet as an encrypted Zip file? Perhaps you are speaking of bootloading via IP across the 'net.

I'd add that you have to think about MOTIVE in hacking microprocessor firmware. A simple mechanism is probably good enough unless your microprocessor is the security solution within an ATM or is in a pacemaker! Or a video game which is a honeypot for students with too little homework.

I downloaded an asm language implementation of AES for an AVR. It's out there if you are truly paranoid.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Using often IJMP, ICALL, LPM will make the disassembling process more difficult ?

George.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

There is no hacking involved if the binary file is sent to a customer that uploads it to the device. Without encoding it some how, you could easily load it into AVR studio and run the debugger on it.

official AVR Consultant
www.veruslogic.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

That is true only as long as you trust your customer not to hack the AVR FLASH memory (assuming you set the memory lock bits and disable unneeded interfaces like JTAG, etc. in the production AVRs). The hacked binary from the AVR FLASH will reveal the bootloader code, the encryption algorithm, the encryption key or keys and your application code. All ready to run on a debugger. If you can afford to enforce it, encrypting your binary distribution probably brings the Digital Millennium Copyright Act into full force here in the U.S.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

gr82bdad wrote:
Is there a way to verify it? Is there a place to submit a block of encrypted data and the original data so that it can be verified?

No. Security is *never* that simple.

You can make claims of security only in a certain context. For example, if an employee leaks out the unencrypted binary, it doesn't matter how strong was the encryption used.

JW