Browser-based firmware generator
-
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.
-
Noted. Right now, the user will have to specify the ATSHA pin correctly for the SenseBender, so I guess it's not the end of the world, but I understand that it can be made easier.
There's actually a little bit of an understanding of the board already - if you choose an ESP8266 gateway and decide to add sensors to it, you'll see pin numbers matching the ESP8266's pinout. That's pin configuration in a different sense though. Let me think about how I can incorporate this.
Thanks for the kind words. :)
-
Noted. Right now, the user will have to specify the ATSHA pin correctly for the SenseBender, so I guess it's not the end of the world, but I understand that it can be made easier.
There's actually a little bit of an understanding of the board already - if you choose an ESP8266 gateway and decide to add sensors to it, you'll see pin numbers matching the ESP8266's pinout. That's pin configuration in a different sense though. Let me think about how I can incorporate this.
Thanks for the kind words. :)
@rakeshpai ah, ok. But the list of pins does not really make sense for the SenseBender gw since it is based on SAMD and not AVR.
