2010-10-24 20:44:36     "Securing" files using crypto or something - possible?

2010-10-24 20:44:36     "Securing" files using crypto or something - possible?

Frank Van Hooft (CANADA)

Message: 94978   

This is a bit of an open-ended question, and the answer may be, "no way no how" but it never hurts to ask if anyone has a  bright idea.

The basic premise is: we have a file (created by the BF523 blackfin) sitting in the uclinux RAM filesystem, and it is about to be copied to the SD card. The size of the file is just under 50 kB.

Before we copy it to the card, ideally we'd like to "tag" it in such a way that we know this file was created by the blackfin, and not falsely created on somebody's PC for example. So the thinking is to have the blackfin calculate a "hash" or a "checksum" or something, which we add to the file before copying to the card.  Then some other application at some later point in time can check this "hash" to verify the file is authentic.

Well, that's the idea. I've no idea if such a thing is actually feasible.

I understand the blackfin's lockbox doesn't play well with uclinux. I understand it can play OK in u-boot, although I'd prefer not to have to reboot into u-boot if possible, because getting into u-boot, doing something there, then booting back into uclinux would consume a lot of time.

I guess another idea might be the crypto libraries, but I'm very unclear how they can run "securely" in a uclinux environment.

At the end of the day this does not have to be bulletproof. It is not mission-critical. We do not have this feature right now so clearly we can live without it. But if there's some way to accomplish this in uclinux in a manner which is "difficult" to replicate, I'd love any thoughts or suggestions on how it might be done.

Thanks very much.

QuoteReplyEditDelete

2010-10-25 02:02:28     Re: "Securing" files using crypto or something - possible?

Mike Frysinger (UNITED STATES)

Message: 94979   

what exactly are you trying to protect ?  and from who ?  incorrectly answering those questions leads to errors (protecting the wrong thing, or spending way too much effort).

lockbox is at the extreme end and i doubt you need to go that far.

a checksum is not considered by any stretch of the word to be cryptographic in nature.

once you've answered the first questions, you can easily walk down the path:

- protect the contents or just verify their origin ?  (encrypt the contents or just sign them)

- symmetric or asymmetric encryption / signature ?

- operate on the whole file or just a small hash of it ?

QuoteReplyEditDelete

2010-10-25 11:06:42     Re: "Securing" files using crypto or something - possible?

Frank Van Hooft (CANADA)

Message: 95139   

All we'd like to do is have some way of being able to "prove" the file was created by the blackfin, and not created or modified by somebody sitting at a PC. So we have this data file, and we'd like to make it difficult to edit or falsify that data without that falsification being detected.

We don't need to encrypt the data, we just want to add a signature. The signature would have to be over pretty much the whole file, so that any subsequent editing of the contents of the file would be detectable.

The idea then is that anybody can read the data file, on their PC for example, but we would also be able to provide a utility (eg a Windows utility or a web-based utility) that would allow the file authenticity to be checked, by checking / verifying this signature.

I've no idea about symmetric vs asymmetric signature.

We want to avoid the potential situation where somebody creates a ficticious datafile on their PC, then claims it was generated by our product. Or, the person who takes a valid datafile from our product and then edits it in some way, then claims that edited datafile was created by our product. These are the use-cases where we want to be able to detect tampering of the data.

QuoteReplyEditDelete

2010-10-25 14:51:11     Re: "Securing" files using crypto or something - possible?

Mike Frysinger (UNITED STATES)

Message: 95143   

if someone were to claim the Blackfin created it, what are the ramifications ?  poor support ?  legal action ?  something in between ?  what file sizes are we talking here ?  bytes ?  kibibytes ? mebibytes ?

it sounds like you'll want to do signing with standard public key algos.  gpg should provide you with what you need.

(1) generate a pub/priv key pair using either RSA, ELG, or DSA

(2) install gpg and the priv key onto the Blackfin systems

(3) have the Blackfin system sign the file: gpg --sign foo

(4) export the new foo.gpg to the outside world

(5) install gpg and the pub key with your PC system

(5) have your PC system verify the signature: gpg --verify foo.gpg

(6) have your PC system extract the original contents: gpg --decrypt foo.gpg

any attempt to modify the foo.gpg would prevent the signature from verifying and thus working

i believe the addition of gpg and its required libraries should weigh in at least than 1 MiB of diskspace

while you dont have to worry about people extracting the pub key from your PC system (since they wont be able to regenerate a signature, just verify ones), you do have to worry about people extracting the priv key from the Blackfin system.  this is where further consideration is warranted with regards to attack vectors you wish to prevent.

if you store the priv key in external flash, then anyone who can read the flash will be able to extract it.  that means people who desolder the chip and read it in their own hardware, or just attach probes to the lines, or connect via JTAG.  or people who attack via software and either get your code to expose it or are able to access the system (via a shell) and read it themselves.

if you arent worried about those vectors, then flash storage is OK.  if you are worried about these vectors, then lockbox would be necessary.  the priv key would be burned into the secure section of OTP and a kernel driver would be need to be developed.  i imagine we could assist in this regard, but no promises.  basically the driver would be there just for you to open, feed it some data, and the kernel would take care of putting that data into on-chip memory, going into secure mode, verifying everything, and then exiting.  the file size could potentially complicate this though as you'd have to manually break the file up into small chunks that would each fit completely into on-chip memory.

on the off chance someone did extract the priv key, this would impact all devices also using that priv key.  there are two ways to address this issue: issue a unique set of priv/pub keys to each device (or some number of devices) so as to limit the damage, but then you'd have to have a way of getting all those pub keys shipped with your PC system.  or, use a more complicated signing strategy based on certificates rather than keys.  your company would generate its own certificate as the authority (CA), and then issue a unique certificate to every device.  your PC system would then only need the pub cert of your CA to verify all the devices' certs.  extracting the cert from one device would only impact that one device.

QuoteReplyEditDelete

2010-10-25 15:00:07     Re: "Securing" files using crypto or something - possible?

Mike Frysinger (UNITED STATES)

Message: 95146   

oh, and you'll probably have to do some legal review of the algorithms you use to make sure you're in compliance in terms of possible royalties (due to patents people hold) and crypto-type export restrictions based on the country you're in and countries you'll be doing business in (shipping to).  you wont get any such review or advice from this site.

QuoteReplyEditDelete

2010-10-25 17:52:01     Re: "Securing" files using crypto or something - possible?

Frank Van Hooft (CANADA)

Message: 95153   

That gives me a lot of useful info to think about and research - thanks Mike!