AES 128 with external chip/module ?
Paul_Dlk
Posts: 19
Hi,
I have a prop application that reads a block of 'encrypted' data from an Sd card. The propeller then decrypts this data. The encryption scheme is very simple as the data is of nominal value and was only meant to prevent a casual onlooker from seeing the data.
However the project is developing and the 'value' of the data is now increasing and I therefore have to employ a stronger encryption method. I know very little about encryption methods and I know less about the maths used for encryption.
Is there a chip/module that can receive, via I2C or SPI, a small block block of encrypted data (10 to 20 characters) and decrypt it using a key that is securely burnt into the chip and send it back to the prop.
I believe that the best encryption method is AES 128 (or 192, 256), is this correct?
Paul
Post Edited (Paul_Dlk) : 6/20/2010 12:13:10 PM GMT
I have a prop application that reads a block of 'encrypted' data from an Sd card. The propeller then decrypts this data. The encryption scheme is very simple as the data is of nominal value and was only meant to prevent a casual onlooker from seeing the data.
However the project is developing and the 'value' of the data is now increasing and I therefore have to employ a stronger encryption method. I know very little about encryption methods and I know less about the maths used for encryption.
Is there a chip/module that can receive, via I2C or SPI, a small block block of encrypted data (10 to 20 characters) and decrypt it using a key that is securely burnt into the chip and send it back to the prop.
I believe that the best encryption method is AES 128 (or 192, 256), is this correct?
Paul
Post Edited (Paul_Dlk) : 6/20/2010 12:13:10 PM GMT
Comments
Paul
Put the encryption algorithm on there with the key all locked away behind the code protection fuses. Transfer data in and out via I2C, SPI, UART whatever.
As for the algorithm, that depends how secure you want to be, how fast it needs to be and how big the available code space is.
The RC4 algorithm for example is quite small and simple and will fit in small AVR/PICs. RC4 is used in WEP and SSL. Read about RC4 here en.wikipedia.org/wiki/RC4 which also has an example implementation in C.
Also on wikipedia you will find the TEA and XTEA algorithms both are small and there are C code implementations. en.wikipedia.org/wiki/Tiny_Encryption_Algorithm and en.wikipedia.org/wiki/XTEA.
Bear in mind in mind that a lot of the security of any algorithm can be compromised by poor implementations, WEP for example.
You might have to say more about your requirement. For example does the user, that you don't want to be able read the data, have physical access to the Prop/crypto hardware? If so then he has access to the decrypted data stream anyway.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I'll look into the PIC option although I have practically zero experience with the PIC and I have to get something done pretty soon. I was hoping that an off the shelf solution might be available.
I will do some research on encryption for the PIC and how i might get data into it and out of it.
Paul
I have done some work with some of the Maxim products that are designed for secure storage. I have interfaced these with the Prop, and have implemented X509 certificate storage and signing. Check out the information on their website. www.maxim-ic.com/datasheet/index.mvp/id/4982
is there any other chip that can provide a strong encryption engine that is easy to integrate with a propeller?
Paul
http://datasheets.maxim-ic.com/en/ds/DS2460.pdf
Looks to be the full data sheet.
Jim
thats the 'Abridged Version'
Thanks anyway
In that case why not put the decryption algorithm and keys on the Prop itself?
Use Catalina, ICC or even my Zog interpreter to run the decryption code compiled from C source.
There is an example of the Prop running the xxtea algorithm compiled from the C code you find on wikipedia in the Zog project. I'm sure Catalina will compile that for the Prop and have it running as well and faster.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
yes the plain text ends up on the prop, and is promptly printed for all to see.
The data is currently encrypted on a pc/server using a very simple homespun algorithm. The result is transmitted via the internet and stored on an SD card. and placed in the end product containing the prop. The prop reads off blocks of data (8 to 16 bytes at a time), decrypts it and sends to a printer.
My problem is that the encryption is not strong enough to send via the internet. I need to use AES 128 or stronger and I need to keep the keys secret, therefore I can't store it on the props eeprom.
I thought that there might be a hardware solution which contains the key and can:
A) sit between the SD card and the prop and decrypt the data in real time from the SD card
OR
Paul
Depending on your level of paranoia, the actual threat risk and the value of the data there are many solutions.
Personally I would not be hung up on the "strength" of any particular encryption algorithm. There are many ways secure systems have been broken and data sucked out of them without actually cracking the algorithm used. Don't forget that in your application the keys are in the hands of whoever is using this device even if they are hiding inside some chip.
I would be inclined to put the decryption code and the keys into a PIC or AVR hiding in the FLASH and EEPROM respectively. Use the program security fuses.
I'd go for the xxtea algorithm.
You might want to arrange for the possibility to change the keys if you expect to have physical access some times.
Have a look at the simple project for SD cards that you could adapt for this job. Just pump the data out of there to the Prop for printing etc. www.captain.at/electronic-atmega-mmc.php
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en537998
It should run on the smallest PIC24 (14-pin). You have to be in a country approved by the USA to buy it.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Leon Heller
Amateur radio callsign: G1HSM
Post Edited (Leon) : 7/12/2010 1:55:07 AM GMT
Thanks
Paul
I've downloaded it. Their system knows that I'm in the UK, rather than Cuba or Iran. You aren't somewhere like that, are you?
The code builds OK with the C30 compiler, the actual AES code is written in assembler. I should be able to test it with the simulator.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Leon Heller
Amateur radio callsign: G1HSM
Post Edited (Leon) : 7/12/2010 9:35:36 AM GMT
It says it's C++ but it's plain C really. It's not optimized for speed but that may not be an issue. It also supports 192 and 256 bit keys!
Terms of use may be an issue, best to ask about that.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Leon Heller
Amateur radio callsign: G1HSM
Post Edited (Leon) : 7/12/2010 10:08:24 AM GMT
no, I'm a close neighbour, Ireland. Seems good so far. How do you see the system working?
A) Would the prop read the encrypted data in blocks, send it to the PIC and then read it back from the PIC?
Or
I would prefer the first method, as we could design a small addon board with the PIC chip and any required components on it. I have a 6 way connector with +5V, +3.3v, Gnd and three I/O pins (non consecutive).
Please bear in mind that my knowledge of encryption is next to zero.
!) What else would be involved in implementing the full system, that is the software for the PC to encrypt using a public key?
2) Also can the PIC securely store a secret key that I can set and possibly change but nobody else can access?
I've only been involved with encryption techniques once, when I worked for Racal Comms. We were using the then new MoD crypto, Pritchel, in a new radio system, and I was quite heavily involved with it, but it was a long time ago and I've forgotten everything about it.
Key distribution is something we'll have to look into.
The PIC can easily store a secret key. The only problem is that 16-bit PICs don't have on-chip EEPROM, so it will have to be held in an external EEPROM, which might compromise security. If it doesn't change very often it could be held in flash. I could use a different PIC with on-chip EEPROM, of course.
It might be a good idea to take this off the forum, and communicate directly. You can get my email address from my profile.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Leon Heller
Amateur radio callsign: G1HSM
Post Edited (Leon) : 7/12/2010 1:35:36 PM GMT
Holding keys in flash perhaps if the thing can be re-flashed whilst at the same time preventing others from reading the FLASH.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.