yes. you have a lot of options, and as always with security, you can make something that looks like it works (e.g. stuff is encrypted, and your commands execute) but is alas, ultimately, is insecure. Here is a paraphrased version of my work on a recent project regarding similar concerns:
all things considered, I would prefer to do it this way:
* public key in your netduino app
* private key on your systems that generate the command that needs to be authenticated
* your command-issuing system signs the command, ideally with a nonce or sequence number to prevent replay attacks
this should be secure so long as your command-issuing systems protect their private key correctly (and so long as their aren't bugs in your impl to exploit!), and disregarding DOS attacks (which are a separate class of threat anyway). end of story.
fly in that ointment is that netduino doesn't have any crypto in the firmware, so you have to add crypto in managed code. OK, not the end of the world, and I personally recommend the BouncyCastle crypto lib -- it's reputable, the license is good, and you can pluck out the modules you want with a few hours effort.
fly in that ointment is that the netmf will go TU on large constant data arrays (like s-boxes for symmetric algos), and it's just too much stuff for all the bignum calcs that you need for the asymmetric crypto. this last part is a pretty big deal because it means you are going to have to use symmetric encryption methods, and that means key management -- yuck.
so, what I did was use a HMAC-SHA1 with a random per-device shared-secret key that I put on SD. This functions as a signature algorithm, but using symmetric methods. I stock pregenerated SD cards containing profiles, and just get the rest of the hardware as-needed. When deploying, the key is loaded into my (trusted) backend systems that generate the commands, and the SD is stuck into the unit. I have online and offline systems; the online systems use timestamps to avoid replay attacks (they are constantly synchronized with the backend), and the offline systems use a sequence number scheme to do similar. Using the SD card isn't that big of a deal for me since I have plenty of other non-secure config and log storage needs anyway.
I really do not like this arrangement at all, but that's as good as it gets without assymmetric crypto. Also, don't be tempted to use any onboard device info for your shared secret key (like mac, or even chip serial number). The key must be random (or at least not not derivable solely from device data. an acid test is: if the netduino can generate the secret key without some additional data somehow injected onto it, then so can anyone else, and you are insecure).
Also, because the shared secret is on the SD, which is removable, this is a significant weakness. But my units are in a locked enclosure, and I mostly mitigate that with some revocation capability and logging to detect fraud. But that stuff all depends on the design of the rest of the system, and you may or may not have those luxuries. But as they say, there is no security without physical security. If someone can diddle with the wires going to your unit then all the crypto in the world doesn't matter.
But to truly be good, you really need assymmetric crypto. Then almost all of this goes away, and you are just left with securing trust. But we don't have it right now, alas...
-dave
p.s. and of course security is a continuum. if you just want to exclude silliness, but not a motivated adversary, then even non-secure things help. For instance, I got tired of dictionary attacks on my servers. Just moving my SSH port off the default took the attack level to narily zero. Secure approach? Not at all. Quieted attack rate? Oh, youbetcha. So a valuable action nonetheless....
Answered
