Tag Info

That link Hristos posted, while possibly useful, certainly doesn't count as "encryption". It's really only "obfuscation". Proper cryptography is notoriously easy to get wrong, even for people who know the math. In response to the original post - what are the attack methods that would let someone get access to the PINs in the EEProm? Surely if they've got ...

You don't want to encrypt passwords (PINs) -- you want to hash them. When someone enters a password, you hash that password, and compare the hash against the stored hash. The advantage to this method (used for over 30 years) is that even if someone gets hold of the source and the hashes, they still can't tell what PINs match the hashes, as long as you ...

Microchip provides ready made encryption library. Typically AES is the most commonly used and available, and I see no reason to use anything else. Due to export restrictions, you will need to contact them directly to obtain the source code.

I have a lot of concerns with this project, so let me brutally honest here. When it comes to cryptography the most dangerous thing is for someone who doesn't know about it to try implementing it. And honestly, you don't know about it. I say that because of your lack of caring about what encryption algorithm is used. I also don't think that you really ...

If you want to use a micro (a small FPGA would work well also) then one with a dedicated peripheral would be good. The STM32F407 series have a cryptographic processor peripheral capable of DES, Triple DES, AES 128, 192 or 256. They also have a dedicated SD card peripheral (for 1, 4 or 8-bit interface) which allows transfer at up to 48MHz. You can grab ...

Having a separate encryption co-processor could be risky. Anyone with a Bus Pirate or logic analyser and physical access can sniff the bus and pluck out the plaintext data. You can mitigate the risk a bit with BGAs and/or epoxy, but the best solution is likely to be a SoC which combines MCU with AES. One approach might be to use a SoC ZigBee chip and ...

In general yes that is possible. For example a guy called Christopher Tarnovsky managed to tap the inner data paths of a Trusted Platform Module. He used acid to remove the encapsulation, rust remover to get rid of some mesh and then managed to probe the circuit and intercept internal communications. Obviously on such a small scale it is a non-trivial ...

First: There are fuses on the chip that can be set to prevent external tools from reading the code off the chip. Look for the protection fuses in your datasheet and/or programmer documentation. It's not perfect, but it protects you from simple attacks. Second: You cannot download firmware securely. The AVR cannot self-program protected areas: ...

I suggest the Microchip TCP stack. Microchip offers a free licensed TCP/IP stack optimized for the PIC18, PIC24, dsPIC and PIC32. Microchip’s TCP/IP stack includes the Secure Sockets Layer (SSL) feature. But it's not free. See below: To comply with US Export Control restrictions, the encryption portion of the SSL module must be purchased ...

Joby pointed me to the CC2430 as a device that can do AES. I went to TIs site intrigued by this and did some research. TI also makes our transceiver for our frequency bands(CC1100) and the new CC1100 merged with an MSP430 for a SoC now has AES-128 built in. This saves us board space and was a planned change already, but this results in full support for ...

As said before, off-chip is risky as its very hard to control the keys and other important information. There are microcontrollers which contain AES accelerators or function tables. The AVR XMEGA has an engine which can do AES fairly quickly (its not super security hardened though, including known power attacks). The aforementioned Stellaris controllers ...

If it's that important and you're particularly worried about competitors stealing your code, take out IP protection on your code segments. You should be looking into this if you're going to try and make money out of a project anyway. Certain elements of code can be either patented (for specific processing methods and novel algorithms) or registered as ...

If the system can be complicated enough to run an operating system, there are plenty of tools and libraries that can do the job. On an embedded Linux system, you can use wget with SSL. On any system with higher level languages like Python or Ruby, the networking library (Python SSL) will support SSL. If you only have access to C, you could write something ...

A much less resource consuming algorithm than AES, specificially for embedded applications, is XTEA. The wiki page gives the source code and you can find test vectors which are used to verify your implementation. You should also consider XXTEA.

Consider these embedded SSL libraries: http://www.yassl.com/yaSSL/Products-cyassl.html http://polarssl.org/ http://www.matrixssl.org/ And maybe http://gitorious.org/tropicssl/ Tropicssl and polarssl originated from http://www.ohloh.net/p/xyssl Tropicssl and xyssl are BSD licensed, whereas as all the others are GPL with an option for a proprietary ...

Nothing is 100% safe. That being said, the time and effort needed to 'crack' a chip can range from trivial to exponentially beyond feasible. I personally like how Microchip summarizes the matter at the beginning of their PIC and dsPIC datasheets (especially the last bullet point - emphasis mine) Note the following details of the code protection feature ...

I hate not answering the question while asking another, but ... Is there some reason why your device is not tamper proof? I've seen push button switches in screw holes implemented 'on the bench' to detect the kind of tampering you are worried about. Then .. here comes the kid with a butane micro torch that manages to get your chip without unscrewing ...

These comments are really spot-on. There's nothing wrong with trying to experiment to learn about encryption, but this isn't really a good project for learning such things. You really want a good textbook and a computer, and as @bigiain says, the math is notoriously easy to get wrong. For a better understanding of how cryptography works and what you're up ...

How do you plan to decode the encrypted PINs, in order to check if the user entered a valid PIN? You'll need to store the decryption key...at which point if the attacker can read your eeprom, he can also read your flash to find the encryption key. Basically rendering your entire encryption completely useless. Also as the other people said, if he already has ...

Here is a method of simple encription in C that could easily be ported to the Arduino. This seems like the easiest way to encrypt data with the arduino's limited resources. -EDIT- To keep the key out of your program you could make half of the PIN the key. This means that your program takes the key half of the PIN to decrypt the encrypted 1/2 PIN stored in ...