Netduino home hardware projects downloads community

Jump to content

The Netduino forums have been replaced by new forums at This site has been preserved for archival purposes only and the ability to make new accounts or posts has been turned off.

Security for remote commands over the network

network Ethernet WiFi NP2 commands security

  • Please log in to reply
2 replies to this topic

#1 Mj. Logan

Mj. Logan

    New Member

  • Members
  • Pip
  • 4 posts

Posted 18 June 2013 - 06:29 PM

Hello, guys!


I'm designing a project that is intended to send commands to a NP2 from a central control over the network (Ethernet or WiFi). I know there could be some security issues, specially in WiFi scenarios, when somebody on the newtork who knows the commands list can potentially send unwanted commands to NP2.


Have you guys tried to accomplish something like this before? Maybe some pattern could fit a NP2 environment, in order to have some security on sending remote commands.
Any ideas (with or without code pieces) would be very appreciated :^)
Thanks in advance!


#2 ziggurat29


    Advanced Member

  • Members
  • PipPipPip
  • 244 posts

Posted 18 June 2013 - 08:58 PM

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...




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....

#3 Mj. Logan

Mj. Logan

    New Member

  • Members
  • Pip
  • 4 posts

Posted 18 June 2013 - 10:43 PM

Hi, ziggurat29, thank you very much for your reply. It's a very good insight, really sounds like an acceptable security plan for the matters of what I have in mind. Good to hear from somebody who dealt with those problems before. I thought about some issues you pointed here, and got to almost the same conclusion. If I find something interesting along the way, I'll be glad to share.


Thanks again.

Also tagged with one or more of these keywords: network, Ethernet, WiFi, NP2, commands, security

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users

home    hardware    projects    downloads    community    where to buy    contact Copyright © 2016 Wilderness Labs Inc.  |  Legal   |   CC BY-SA
This webpage is licensed under a Creative Commons Attribution-ShareAlike License.