I'm building a small server at home, and I'd like to have a sort of "smart" board to control its power. This board will have, at the beginning, to simply turn it on or off (more features will be added later).

This device will be sort of Arduino based (in fact it is a more powerful microcontroller, but I'm using the Arduino environment to program it).

Now, the access to all the network will be provided through VPN from the server, but obviously the switch cannot be accessed only through VPN (since it cannot be reached if the server is off, hence I will not be able to turn it on). So a direct internet access is needed for it.

I wanted to secure the operations, since allowing anyone to turn on and off my server is a bit problematic..

What I thought was using a set of pre-shared symmetric keys (thinking about AES); every time the webpage is loaded the microcontroller sends a seed (for instance the date) and the client, through JavaScript, evaluates a token to be sent along with the request encrypting, for instance, the seed and the request with the key passed in a textbox.

What do you think? Are there simpler solutions already known? How is this problem usually handled?

Please note that HTTPS is not a solution, since implementing it onto a microcontroller is quite hard...

EDIT: since some additional info were asked, here is something more specific:

the board I'm planning to use is a Maple Mini; the processor is a STM32-F103RCBT6 (72 MHz, 120 KB Flash, 20 KB SRAM). I'll be using an ENC28J60 ethernet interface (so no hardware stack).

I will forward a port from my router to it, since I want this functionality to be available from "the outer world"; the interface will be a webpage. If the flash becomes too tight, I can put the page on an external SD card.

  • 3
    HTTPS (or CoAP over DTLS over UDP) on a microcontroller is not necessarily hard. How much code memory and how much RAM does it have? Would you always access it from the same few devices or from anywhere? – Gilles May 21 '17 at 20:10
  • 1
    It's not as much fun as building your own, but I am using several Wemo Insight "smart plugs" in this context and have been basically happy - I haven't been able to get them to work in multiple locations (e.g., all of the smart plugs apparently must be on the same LAN) but other than that they've been working well for awhile now. – gbroiles May 22 '17 at 2:42
  • 1
    @Gilles I added the info directly in the question – frarugi87 May 22 '17 at 7:20
  • 1
    @gbroiles thank you for your contribuition; do you access them directly from the internet or you need an app and to connect to their server? Anyway this is not what I was looking for for this project, but I can keep them in mind for the future – frarugi87 May 22 '17 at 7:33

To authenticate the command coming to your "smart" board, the challenge-response system you propose is suitable:

  1. a remote system R initiate communications with the board B
  2. B generates a time based nonce, and sends it as a challenge
  3. R receives it, and use a secrete key to generate a response. The response must be sent with a command. Ideally, the content of the command must be used to generate the response (response is also a signature for the command).
  4. B use the nonce, command and same secrete key to generate what should have been the response, and check if R response matches

The crypto you pick doesn't really matter, go with something basic like AES 128. The challenge B sends should be time-based, and it must not be possible to get the same challenge twice.

Most importantly: be very very careful on how you code your input parser. This is the main entry for an attacker. The best crypto in the world won't saves you if sending a malformed answer crashes your board or allows remote code execution.

Be conservative, keep your protocol very simple. Use a fuzzer to make sure any invalid stuff is rejected (negative testing). If you don't use a safe language, enable absolutely every checks and warnings your compiler can offer, use static code checker, use dynamics checking tools while you fuzz to check for any overflow or memory leak. Check how your program handles a network overload, use rate limits (eg. 1 challenge every 5 sec max, other attempts are silently ignored) and enforce memory limits. Have a watchdog.

It's a nice challenge to implement such a system, and a good learning opportunity if the consequences of a failure are not critical. Realistically, even the mildest challenge will be enough to stop a script-kiddie or a criminal wanting to do a quick buck, but the absence of attack is no proof that your system is secure. It could be because it's secure... or because nobody really tried. Keep that in mind and prepare a contingency plan.

  • 2
    This is a recipe for implementing the protocol wrong. There aren't enough details to say “here's how it breaks”, but there are many gotchas you don't even mention, such as the many places where encryption isn't enough, you need authenticated encryption; replay attacks; etc. – Gilles May 21 '17 at 20:12
  • @Sylvain Thank you for your reply. Since in the arduino library there is not an HTML parser, I will have to write the decoding myself: this will protect it from the input point of view. As for the last paragraph, no, there is not a real criticity in failure; everything the attacker will be able to do will be turn on the main server or, eventually, turn it off (even if I will be able to turn the server off directly, so I can remove this feature). All the other activities can be handled directly by the server, which should be rather secure (VPN access) – frarugi87 May 22 '17 at 7:27
  • @Gilles can you further expand what you are saying? – frarugi87 May 22 '17 at 7:28
  • @frarugi87 Not in the space of a comment. Designing a cryptographic protocol is hard. TLS is complex for several reasons: there's the weight of backward compatibility, and the fact that it applies in very diverse scenarios, but also that it's hard and the reason it's evolved is in part because even experts got it wrong the first time. – Gilles May 22 '17 at 7:32
  • @Gilles thank you for your contribution. I'll go searching for the TLS history then to expand this – frarugi87 May 22 '17 at 7:36

Your Answer

