Browser-based firmware generator
-
Disclaimer: This is a proof-of-concept. It doesn't work. Things will change, and will break. In fact, I'm sure many things are broken right now. It would be pretty stupid to use this for anything important. I'm just putting this in the public to gauge interest. You have been warned.
Link to the firmware generator.
If you are like me, you want to put approximately half a million MySensors nodes around the house. You've probably already built the first few nodes, so it feels like you are most of the way there. You love the soldering and the building. However, the coding isn't exactly fun. It requires reading through docs, then trying and failing, and rinse and repeat until you get it right.
This tool doesn't solve that problem yet, but it aims to. It aims to provide a simple browser-based UI for configuring your network, and then generating the firmware for the node automatically, using whatever's the best-practice for writing the firmware. This tool writes your code for you!
The good:
- You don't have to write code! This web page does it for you!
- Security built in by default.
- Uses the awesome NodeManager by @user2684 under the hood.
- The web-page, once loaded, works completely offline. You do not need an Internet connection to use this tool! (Try it!)
- No sign up, no registration. In fact, there's no server, or no central database. Your data doesn't even leave your browser.
- There's no server, so there's no network communication and everything's local, so it's blazing fast!
- That bears repeating: The firmware is generated inside your browser, without using any cloud that will rain down on you. Isn't it awesome what browsers can do these days?
The bad:
- Needs a pretty modern browser. Tested on Chrome and Firefox. Untested on IE.
- Doesn't work on mobile devices (yet). Might work in Chrome/Android, but it's untested. Other browsers would need a server-side component to get them to behave.
- I have Google Analytics on the site, just to gawk at some graphs. All GA data is anonymous.
The ugly:
- Well, it looks ugly.
- The code it generates hasn't been tested. This is just a proof of concept. DO NOT depend on this.
- The code, especially the security bits, require review. In fact, I'm pretty sure I've done it wrong.
- They say, 'if you aren't ashamed of it, you've released too late'. I'm definitely releasing too early.
With that summary out of the way, I'd love it if you could poke around and let me know what you think. You don't need to download or install anything - it's just a web page - so just click the link above. I'm trying to gauge interest in the community for this, to decide if it's worth pursuing.
Would you like me to spend time on making this better?
The icon to download firmware is on the top-right of the page, and you can see it on the pages for either the nodes you create, or on the page for the gateway. You can create nodes by selecting your network in the left hand side navigation, and clicking on the
+icon at the top right of the page.The firmware is downloaded as a zip, which contains a SecurityPersonalizer with your security settings, and the main sketch which runs on your node. Currently, the firmware might not even compile.
Hope this gives an idea of what I have in mind, even if it doesn't actually work.
All manner of suggestions and feedback is welcome.
-
Wow, great job @rakeshpai! Just took a quick tour and it looks really easy to use.
And as you took the good decision to make it a pure js project, we can easily deploy on mysensors.org when you feel ready.
-
Cool stuff!
Might I suggest a checkbox for marking a node as ATSAH204 HW signing capable? Then it won't use a customized device id. And you can then generate a personalizer that fits ATSHA204.Btw, what browser requirements are there? I am trying to download the zips but they all appear empty.
Also, a slight typo on the nodes and gateways security settings. It says "Device key" and "An 18 digit hex number used for encryption". But I think you mean the 9-byte "Device ID" (AKA serial number). It is not used for encryption, it is used for whitelisting.
-
Thanks, @hek and @Anticimex.
I could add the ATSHA if there's interest. I haven't looked into it yet, and haven't used it, which is why I'm only doing software signing at the moment. If there's interest for it, I'll definitely add it. I'll need to understand how it can be made such that just flashing the SecurityPersonalizer will do everything automatically, so that the user doesn't have to interfere with it.
Which browser are you using? I've only tested this in Firefox and Chrome on Ubuntu (though the OS shouldn't matter). I haven't tested this on IE. I'm certain it doesn't work on any iOS browser, because of browser limitations. (Limitations can be worked around by using a server.) It might work on Chrome Android, but I don't have access to an Android to test.
The library I'm using for creating the zip is here: https://stuk.github.io/jszip/ Can you please tell me if their example works for you in your browser?
Thanks for the catch about the 9-byte device id. I'm also certain that the two other strings I'm using is wrong:
For the HMAC: "A 64 digit hex number used for signing messages"
For the AES: "A 32 digit hex number used for encryption"
If you could help me phrase these correctly, I'll push an update with all three corrections. Thanks. -
Thanks, @hek and @Anticimex.
I could add the ATSHA if there's interest. I haven't looked into it yet, and haven't used it, which is why I'm only doing software signing at the moment. If there's interest for it, I'll definitely add it. I'll need to understand how it can be made such that just flashing the SecurityPersonalizer will do everything automatically, so that the user doesn't have to interfere with it.
Which browser are you using? I've only tested this in Firefox and Chrome on Ubuntu (though the OS shouldn't matter). I haven't tested this on IE. I'm certain it doesn't work on any iOS browser, because of browser limitations. (Limitations can be worked around by using a server.) It might work on Chrome Android, but I don't have access to an Android to test.
The library I'm using for creating the zip is here: https://stuk.github.io/jszip/ Can you please tell me if their example works for you in your browser?
Thanks for the catch about the 9-byte device id. I'm also certain that the two other strings I'm using is wrong:
For the HMAC: "A 64 digit hex number used for signing messages"
For the AES: "A 32 digit hex number used for encryption"
If you could help me phrase these correctly, I'll push an update with all three corrections. Thanks.@rakeshpai I am assuming you generate for the beta track? Personalization is vastly different between stable and development branches right now.
On development, personalizing process using software or ATSHA is more or less identical.
But for ATSHA you cannot fully automate it, as the personalizer will output the device serial in that case (which is the only way you can obtain it). So at the very least, you have to execute it once to see the serial number of the device.I am on windows 7 (right now) on Chrome Version 58.0.3029.110.
For the HMAC and AES keys, you are spot on, no need to change anything there :)
-
Incredible, good job!
What do you mean bu that though
@rakeshpai said in Browser-based firmware generator:
It doesn't work.
From my perspective it does work ;)
-
@rakeshpai I am assuming you generate for the beta track? Personalization is vastly different between stable and development branches right now.
On development, personalizing process using software or ATSHA is more or less identical.
But for ATSHA you cannot fully automate it, as the personalizer will output the device serial in that case (which is the only way you can obtain it). So at the very least, you have to execute it once to see the serial number of the device.I am on windows 7 (right now) on Chrome Version 58.0.3029.110.
For the HMAC and AES keys, you are spot on, no need to change anything there :)
@Anticimex Thanks for the text fix. I've pushed an update with the device ID change.
General note about getting the latest version: You'll need to refresh once, wait for a bit and refresh a second time to see the latest changes. Alternatively, you can force a hard-refresh, usually by pressing Ctrl+F5 or Ctrl+R. I'll make this experience smoother in some time, but please bear with it for now. This extra refresh is because of the offline support.
I'm on Chrome 58 too. Very strange that you see empty zips. Did the example here https://stuk.github.io/jszip/ work for you?
-
Incredible, good job!
What do you mean bu that though
@rakeshpai said in Browser-based firmware generator:
It doesn't work.
From my perspective it does work ;)
@pansen Thanks! It only appears to work. A few examples I tried also compiled successfully. However, I haven't checked every scenario yet. Besides, I haven't even actually run any of the code on an Arduino yet. I'm almost certain I've done something wrong. You know how it is - it's never right the first time. Hence the 'It doesn't work' :)
-
@Anticimex Thanks for the text fix. I've pushed an update with the device ID change.
General note about getting the latest version: You'll need to refresh once, wait for a bit and refresh a second time to see the latest changes. Alternatively, you can force a hard-refresh, usually by pressing Ctrl+F5 or Ctrl+R. I'll make this experience smoother in some time, but please bear with it for now. This extra refresh is because of the offline support.
I'm on Chrome 58 too. Very strange that you see empty zips. Did the example here https://stuk.github.io/jszip/ work for you?
@rakeshpai The example worked fine. I forced a reload. Then I trashed my old "project" and clicked "Create a network" followed immediately by the download button without touching any settings. Still an empty zip though.
-
@Anticimex Thanks for the text fix. I've pushed an update with the device ID change.
General note about getting the latest version: You'll need to refresh once, wait for a bit and refresh a second time to see the latest changes. Alternatively, you can force a hard-refresh, usually by pressing Ctrl+F5 or Ctrl+R. I'll make this experience smoother in some time, but please bear with it for now. This extra refresh is because of the offline support.
I'm on Chrome 58 too. Very strange that you see empty zips. Did the example here https://stuk.github.io/jszip/ work for you?
@rakeshpai I should mention that when I look at the zip, it is quite big (235KB) but when I open it from a explorer window it appear empty. If I try another tool like 7-zip, it opens. But the root folder is "_" and I suspect windows does not like that. Under that folder the gateway code is. So I think it is just a bug in the directory tree fabrication which is windows zip incompatible.
Do you feel secure today? No? Start requiring some signatures and feel better tomorrow ;)
-
@rakeshpai I should mention that when I look at the zip, it is quite big (235KB) but when I open it from a explorer window it appear empty. If I try another tool like 7-zip, it opens. But the root folder is "_" and I suspect windows does not like that. Under that folder the gateway code is. So I think it is just a bug in the directory tree fabrication which is windows zip incompatible.
@Anticimex Ah, that makes sense. Based on this, I've rolled out an update. I don't have a Windows box to test, so I'd be awesome if you could have a look once again. Don't forget to do the double-refresh or the hard-refresh I mentioned above.
-
@Anticimex Ah, that makes sense. Based on this, I've rolled out an update. I don't have a Windows box to test, so I'd be awesome if you could have a look once again. Don't forget to do the double-refresh or the hard-refresh I mentioned above.
@rakeshpai Works just fine now. Great work! :+1:
-
Also, it looks like you generate the beta-personalizer, so just switching to PERSONALIZE_ATSHA204A instead of PERSONALIZE_SOFT should do the trick. If you decide to add the ATSHA "checkbox" option that is.
The only other change needed would be to set the appropriate signing flags and requirement flags. I could not see that you enable any such in the gateway it generated. Only encryption. So no signing functionality would be enabled. -
Yes, the browser downloads the SecurityPersonaliser from the development branch of GitHub. The choice of the development branch was accidental ;) but if that's the way things are headed, I'd rather stick with it.
There's very few modifications made to the personalizer. The changes are made here. Basically, the three keys are set, and PERSONALIZE_SOFT is defined. I say this just so that there are multiple eye-balls looking at the code. :)
I haven't worked with ATSHA, and I don't forsee myself doing so soon, so I'll need to understand the process before I make changes. If I understand correctly, I won't need to generate a device ID at all. The user will have to download and flash the personalizer on the arduino, and optionally (if they want whitelisting) read the generated key from the serial output. Is that correct?
I realise now that I haven't thought about adding whitelisting features to this yet. If you have any suggestions about how this can be made easy to use, preferably to the point of being an entirely transparent process, that would be awesome. Meanwhile I'll keep staring at your article on signing, hoping to soak more of it in. :)
Yes, I also haven't added any of the signing defines. That's why I have the huge disclaimers. :) Here's what I glean at the moment, please correct me if I'm wrong:
#define MY_SIGNING_SOFT // or MY_SIGNING_ATSHA204 #define MY_SIGNING_SOFT_RANDOMSEED_PIN 7 // or MY_SIGNING_ATSHA204_PIN 4 #define MY_SIGNING_REQUEST_SIGNATURES // optional whitelisting #include <MySensors.h>Is this correct? Thanks for looking at this.
-
Yes, the browser downloads the SecurityPersonaliser from the development branch of GitHub. The choice of the development branch was accidental ;) but if that's the way things are headed, I'd rather stick with it.
There's very few modifications made to the personalizer. The changes are made here. Basically, the three keys are set, and PERSONALIZE_SOFT is defined. I say this just so that there are multiple eye-balls looking at the code. :)
I haven't worked with ATSHA, and I don't forsee myself doing so soon, so I'll need to understand the process before I make changes. If I understand correctly, I won't need to generate a device ID at all. The user will have to download and flash the personalizer on the arduino, and optionally (if they want whitelisting) read the generated key from the serial output. Is that correct?
I realise now that I haven't thought about adding whitelisting features to this yet. If you have any suggestions about how this can be made easy to use, preferably to the point of being an entirely transparent process, that would be awesome. Meanwhile I'll keep staring at your article on signing, hoping to soak more of it in. :)
Yes, I also haven't added any of the signing defines. That's why I have the huge disclaimers. :) Here's what I glean at the moment, please correct me if I'm wrong:
#define MY_SIGNING_SOFT // or MY_SIGNING_ATSHA204 #define MY_SIGNING_SOFT_RANDOMSEED_PIN 7 // or MY_SIGNING_ATSHA204_PIN 4 #define MY_SIGNING_REQUEST_SIGNATURES // optional whitelisting #include <MySensors.h>Is this correct? Thanks for looking at this.
@rakeshpai
So far so good.
Yes, you don't need a device ID for atsha. It already has one.
The process of personalization is identical for the rest. Only the PERSONALIZE_SOFT flag has to be replaced.For whitelisting, you will have to somehow collect all nodes ID:s (therefore these should be statically set and not assigned during runtime) as well as the device ID of all nodes. Then you can fabricate a whitelist for the GW (or node) in question.
I think in addition to that, it would be prudent if the whitelist could be customized. So that you actually get a list of all the nodes from which you just can pick/check the nodes you want in the whitelist of a particular node (or GW).In it's simplest form, only the GW would have a whitelist, as the GW is "trusted", and the nodes are not.
It is only in very rare occasions that a node would need to speak signed messages directly to another node, and I also don't see a usecase for a node having to use a whitelist to trust a GW.
The message is already signed with a preshared key so a "rogue" GW should not be able to communicate as it wouldn't know the key. But in case someone stole a node, and turned it into a GW this might still be desired to have. But you would probably notice a second GW showing up and starting talking to your nodes :)The pins (random seed and atsha204) probably need to be customizable in the UI as it is HW dependent.
-
Yes, the browser downloads the SecurityPersonaliser from the development branch of GitHub. The choice of the development branch was accidental ;) but if that's the way things are headed, I'd rather stick with it.
There's very few modifications made to the personalizer. The changes are made here. Basically, the three keys are set, and PERSONALIZE_SOFT is defined. I say this just so that there are multiple eye-balls looking at the code. :)
I haven't worked with ATSHA, and I don't forsee myself doing so soon, so I'll need to understand the process before I make changes. If I understand correctly, I won't need to generate a device ID at all. The user will have to download and flash the personalizer on the arduino, and optionally (if they want whitelisting) read the generated key from the serial output. Is that correct?
I realise now that I haven't thought about adding whitelisting features to this yet. If you have any suggestions about how this can be made easy to use, preferably to the point of being an entirely transparent process, that would be awesome. Meanwhile I'll keep staring at your article on signing, hoping to soak more of it in. :)
Yes, I also haven't added any of the signing defines. That's why I have the huge disclaimers. :) Here's what I glean at the moment, please correct me if I'm wrong:
#define MY_SIGNING_SOFT // or MY_SIGNING_ATSHA204 #define MY_SIGNING_SOFT_RANDOMSEED_PIN 7 // or MY_SIGNING_ATSHA204_PIN 4 #define MY_SIGNING_REQUEST_SIGNATURES // optional whitelisting #include <MySensors.h>Is this correct? Thanks for looking at this.
Thanks for the comments, @Anticimex. I've now deployed a new build with the signing changes we discussed about, without the whitelisting. You can choose ATSHA or SoftSigning, and can specify the signing pin. You'll need to refresh and delete your existing network for the changes to take affect.
Sorry about the trouble with refreshing and deleting. I'll smooth out this experience once this has more users.
Regarding whitelists, I must add, if there's interest, I would like to develop a browser extension to flash the device directly from the site. If we have a browser extension that could talk to the device, we could read the key off serial. If we combine that with instructions to flash the gateway last, we might have simplified whitelist creation.
Also, I was hoping that if a user specifies that the node isn't battery operated, it would be configured to run as a repeater. I'm not sure how whitelists would work in such a scenario.
As an aside: The flash-directly-from-the-browser thing would require a server-side thing to do compilation - can't run avr-gcc in the browser yet. (Someone should port avr-gcc to llvm, so I can run it as WebAssembly in the browser! Very soon, I'm sure. :))
-
Nice but are you sure that "security signing" is enabled? In sources I've found only
#define MY_RF24_ENABLE_ENCRYPTIONnot
#define MY_SIGNING_ATSHA204
#define MY_SIGNING_REQUEST_SIGNATURES@bilbolodz I just updated the UI. Please do a hard-refresh (ctrl+r in chrome), delete your existing network, and try again.
In general, you shouldn't trust the output code yet. I haven't even run it on an arduino yet. The idea is just to give you a feel for the goals of the app, and find out if people find this useful/interesting.
Bugs reports are definitely welcome though. A comment on this thread works just fine.
-
Thanks for the comments, @Anticimex. I've now deployed a new build with the signing changes we discussed about, without the whitelisting. You can choose ATSHA or SoftSigning, and can specify the signing pin. You'll need to refresh and delete your existing network for the changes to take affect.
Sorry about the trouble with refreshing and deleting. I'll smooth out this experience once this has more users.
Regarding whitelists, I must add, if there's interest, I would like to develop a browser extension to flash the device directly from the site. If we have a browser extension that could talk to the device, we could read the key off serial. If we combine that with instructions to flash the gateway last, we might have simplified whitelist creation.
Also, I was hoping that if a user specifies that the node isn't battery operated, it would be configured to run as a repeater. I'm not sure how whitelists would work in such a scenario.
As an aside: The flash-directly-from-the-browser thing would require a server-side thing to do compilation - can't run avr-gcc in the browser yet. (Someone should port avr-gcc to llvm, so I can run it as WebAssembly in the browser! Very soon, I'm sure. :))
@rakeshpai Great!
Repeaters are completely signing agnostic. If they receive a signed message not addressed to them, they just forward it as is. So they don't need to carry whitelist entries to validate messages that are not directed directly to them. -
Thanks for the comments, @Anticimex. I've now deployed a new build with the signing changes we discussed about, without the whitelisting. You can choose ATSHA or SoftSigning, and can specify the signing pin. You'll need to refresh and delete your existing network for the changes to take affect.
Sorry about the trouble with refreshing and deleting. I'll smooth out this experience once this has more users.
Regarding whitelists, I must add, if there's interest, I would like to develop a browser extension to flash the device directly from the site. If we have a browser extension that could talk to the device, we could read the key off serial. If we combine that with instructions to flash the gateway last, we might have simplified whitelist creation.
Also, I was hoping that if a user specifies that the node isn't battery operated, it would be configured to run as a repeater. I'm not sure how whitelists would work in such a scenario.
As an aside: The flash-directly-from-the-browser thing would require a server-side thing to do compilation - can't run avr-gcc in the browser yet. (Someone should port avr-gcc to llvm, so I can run it as WebAssembly in the browser! Very soon, I'm sure. :))
@rakeshpai Looks good with the ATSHA option. One thing to consider is that we have "official" HW that comes predefined (the SenseBender GW for examples). Currently, it seem your tool (which is incomplete, I know) only seem to support AVR boards from looking at the pin options. At some point, you could perhams have a HW device list to pick from to specify what kind of HW the gw or node execute on. And in the case of the SenseBender GW (there could be others) the ATSHA pin is already set by the Arduino environment and should not be overridden by user config. Consider this just FYI right now. The tool looks really promising for people uncomfortable with modifying code.
