Chris.blog

Blog, etc.

View My GitHub Profile

29 August 2020

Alexa for wake on lan

by Chris

I grabbed a couple of amazon echo devices last week and I’ve been exploring the possible uses a little in my spare time. One thing I wanted to set up was the ability to turn on my PC with a voice command - there are some “skills” (Alexa apps) that can do this, but I’m sceptical of their security and how well they’re likely to work in the long run, so I wanted to see about having my own more general solution.

I had 2 broad requirements for my solution. Firstly, that I prefer to use free & open-source tools where possible, especially for personal projects that I may not revisit for years. I can generally rely on simple, open solutions continuing to work without relying on any particular company to keep things running. Obviously Alexa is a very locked-down and proprietary system, so I wanted to keep as much of my solution outside of it as possible, so that I can reuse it with other assistants or systems if possible.

Secondly, security. Since anything involving Alexa is going to involve transport over the internet, I need to make sure whatever functions I expose are well secured.

So, my solution ended up looking like this: setting up collection auth

  1. Alexa triggers a skill using ‘IFTTT’, a third party that offers a whole bunch of glue between different services, proprietary and open. So already, I’ve broken my first requirement - sadly I couldn’t find a way to have Alexa make an HTTP request directly, save possibly by developing my own skill. In mitigation, I can only hope that this step is simple to replace if needed, and I can hope that given the simplicity of the requirement, there will at least be a replacement available in the case IFTTT no longer makes this functionality available.

  2. IFTTT performs a POST to a specific URL over HTTPS, with the body including a token used to validate the request. In this way we can make sure arbitrary requests to the URL don’t trigger the functionality (achieving security), and HTTPS keeps the token a secret. If IFTTT is compromised the token could be leaked, but this doesn’t appear to be avoidable.

  3. A listening web server (using Spring Boot for my convenience since I’m very familiar with it) receives the request, validates the token, and then sends the UDP packet on to my PC. Since I prefer not to expose too much stuff from my LAN to the internet, the web server performs the request over SSH to a server inside my LAN - this way I don’t need anything extra exposed externally, just the well-secured SSH server I already had available. It also lets me set up a user with very restricted permissions for a little more security.

This solution ended up being slightly more complex than I’d imagined, but since most of the steps are simple and rely on very basic and open technology, I expect it to be a low-maintenance and long-lived approach.

tags: engineering - iot

Posts