Developer needed for Encryption problem - Forgot to mention that I'm willing to

Paul_Dlk

Hi Guys,
I have a problem!

My current application processes one of a number of files stored on an SD card.

Currently these files are created and encrypted on a PC using my own low strength home brew encryption algorithm and stored on the SD card.

The prop selects one of these files and reads small blocks of data (10 to 20 bytes) sequentially from the file, decrypts it and sends it to a printer. The data only needs to be encrypted until it comes off the SD card.

This is working fine BUT I need to implement a stronger, possibly certified, encryption scheme and this is my problem. I believe AES 128 would be the most appropriate encryption scheme

After many weeks/months of research and trying to figure out how to achieve this I am really no further along.

I can 'think' of a number ways of implementing this but do not have the knowledge or indeed the time to do this and as such I am looking to hire someone to help me with this.

Some possible methods, all using a special secure chip of some sort which holds the private key :

1) Have the data from the SD card decrypted in real time using a specialised chip and forwarded to the prop.
2) Read the data from the SD card using the prop, send it to an external chip which decrypts it and sends it back to the prop via SPI/I2C/1 wire etc
3) Read the complete file from the SD card in blocks, decrypt it using an external chip and store it in RAM, and then read the file from RAM sequentially as if it were on the SD card.

I believe that the simplest way of achieving my goal is to have a small addon board. I have practically no knowledge of PIC/AVR or any other microcontroller (the Prop spoiled me ).

Is there anybody who has done something similar to this before or who believes that they can design and code a solution for me, for a negotiated fee?



Regards
Paul

Post Edited (Paul_Dlk) : 7/11/2010 3:12:37 PM GMT

tonyp12

Do you really need that strenght of enryption?
If you use a external chip it would be easy to sniff (steal) the data by probing the data line.
Even if it is done internally on the prop,· putting it in debug mode and do a ram dump it would reveal the plain text.
It could even reveal the AES-Key used.

But here is some ideas, someone could use it to base·a prop propgram on.
http://edipermadi.wordpress.com/2008/01/21/implementing-aes-using-pic16f84/

C++ example of decryption
http://www.hoozi.com/post/neqd5/advanced-encryption-standard-aes-implementation-in-c-c-with-comments-part-2-decryption

Some simple homebrew, with XOR (with a selfmodifing·number) and some bit shifting
should put the avarage user out of your secret data.

Post Edited (tonyp12) : 7/11/2010 5:40:04 PM GMT

Leon

AES can be implemented in software, C source code is available. You might not have enough memory on the Propeller for it, though.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Leon Heller
Amateur radio callsign: G1HSM

Post Edited (Leon) : 7/11/2010 5:30:11 PM GMT

fezmonkey

When you read the data from SD and decrypt it in RAM, can't anyone read the data from RAM now? Also, your prop code is loaded from EEPROM so anyone can read it and figure out what is your key!

Paul_Dlk

Thanks all for the replies. I may not have explained it properly, so hopefully the following requirements describe what I need:

1 The data only needs to be encrypted whilst its on the SD card.

2 I want the secret key to be held on a secure chip.

3 I want this secure chip to perform the decryption and send the unencrypted data to the prop. At this stage, I don't mind somebody sniffing the data as its actually printed out for all to see mmediately.

Therefore as the key and the decryption algorithm are on the one silicon chip, the secret key is never exposed for someone to see.

Paul

Leon

See my post on your other thread.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Leon Heller
Amateur radio callsign: G1HSM

heater

So in a nutshell the usage scenario is:

1) Someone, the "sender", places encrypted data from a PC onto an SD card.
2) SD card is delivered to someone else, the "receiver".
3) The receiver reads the encrypted data via the Prop + decrypter chip and prints it.
4) Only the sender should have access to the keys thus preventing anyone else reading the data from the SD in transit or from "spoofing" fake data onto SD cards.

Right ?

Nice project, shame I have no time to help with it.

I'm not sure what yo meant by "certified encryption scheme". Who would certify such a thing and for what purpose? For sure governments and such will approve equipment for various classes of secure use. Generally they will want to review and have tested the entire finished product, hardware, software everything. They would also want traceability in it's manufacture. It would be a very expensive procedure.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

Paul_Dlk

Probably 'certified encryption scheme' is a bit misleading, probably more 'recognised encryption scheme' in that it is recognised as being secure.

pullmoll

You generally need two things for such a scenario:
a) an asymmetric encryption scheme like RSA or DH for a key.
b) a symmetric scheme like AES-CBC to encrypt the data.

The downside is that in this scenario the receiver needs to know the secret key, the sender needs the receiver's public key to encrypt the data. There is no (easy) way to securely hide a secret key in a Propeller or external chips, because as soon as you access it one way or another, the key is no longer secret. The Propeller has no final fuse to protect some internal (E)EPROM area against reading like some other µCs have it.

There may be external chips where the key is stored inside and where no one can extract it (except by perhaps decapping the chip). I think the TPM chips used in newer PCs could do such things. I haven't worked with them yet, just read the 1.1 specification a couple of years ago.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pullmoll's Propeller Projects

Post Edited (pullmoll) : 7/12/2010 11:54:39 AM GMT

heater

Whether you want to use an asymmetric system to exchange keys or not rather depends on what you want to do and how convenient you want it. I have worked on wireless systems for the military and the police forces where the keys were placed into mobile radio units at some secure "base station" location. Then the radios then go out into the field for use. At some regular interval they are back at the base station for a battery recharge and possible key update.

In all this discussion I have been assuming that the code in whatever chip is used is protected from reading or writing by code protect fuses. Further that any EEPROM used by that code to store keys is also protected from outside observation by said fuses. i.e. only the running code in the chip can change the keys when commanded to do so. It matters not if the code itself is readable by outsiders as we should assume the algorithm is known and only the keys need be in a black hole.

How often you update the keys and how you actually get new keys to the receiving end is a matter of balancing ones paranoia against inconvenience and expense. I have seen it done by using keys on magnetic swipe cards delivered by courier. Of course in this case there is the SD card slot available.

This all depends on how much you trust the guy who has the decrypter/printer unit in his hands. After all as Pullmoll says if the data is worth enough he can get the chip de-potted and get some one to probe what's inside.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

soshimo

IFF works very similarly. The codes are produced daily and uploaded to each aircrafts transponder. You can implement a similar scheme if you want, but the problem is that your encryption will only be as strong as your weakest link. You can use 1024 bit signature keys with the latest 3DES symmetrical algorithms but an enterprising person could figure out a way to sniff the bits after they have been decrypted. There are sophisticated devices which measure changes in magnetic fields and can read logic without even being connected to the device.

You have to ask yourself if what you are protecting is worth the cost it will take to protect, because protection is never cheap and has to be extended throughout the life of the data. Encrypting on an SD card and decrypting while reading just isn't enough. It's like putting 5 deadbolts on your metal reinforced front door but leaving your back door wide open.

Since we have a rule at work that when you criticize you should always follow up with a suggestion, I thought I would share my suggestion. It only took me a day to come up with it [noparse]:)[/noparse]. The best way to keep your data encrypted is to use byte code and a virtual machine. You can read encrypted byte code (which will make reverse engineering very difficult) and decode it in memory and feed the decoded byte code into the vm. Yes it will be slow, but you can probably utilize extra cogs as a sort of prefetch cache. As long as you don't expose those signals anywhere you should have the maximum protection.

This increases cost and complexity, of course, as you now need to write a VM and a byte code generator which isn't trivial. Protection isn't cheap though [noparse]:)[/noparse]

Post Edited (soshimo) : 7/14/2010 3:54:35 AM GMT