Posts made by Anticimex

@lood29 That is correct, assuming the same radio technology is used. Typically, you set up a separate gateway because you want to run a sensor network on a different radio family due to longer distances or similar.

@Yoshu it is possible. When you have two gateways, the networks will be completely isolated so you can run one of them secured while the other is not.
You might need to distinguish the nodes on in your controller by giving them static unique ID:s unless your controller ties the identifiers to each gateway or it might be difficult to determine which mysensors network a node belong to.

@skywatch not really, depending on the algorithm

@Puneit-Thukral yes but for full/specified function, atsha, atmega and any sensor circuitry also need to be operational at that level.

@Puneit-Thukral but will the peripherals still work at that level? No use to lower the BOD if radio/security/sensors stop working at a higher voltage.

Beautiful work

@skywatch that depend on the key size you choose, and how you deploy the implementation (like block chaining and random initialization).
Symmetric ciphers are even quite secure in the quantum world given large enough key sizes.

@skywatch are you implying they recommend AES without an IV or block chaining enhancement? I don't think so

@TheoL AES is not complicated to implement in hardware and the docs suggest they have it but the technical detail is low.

@alexelite they do not, however, state exactly which variant of AES they use. If they do not generate an initialization vector and are not using some block chaining variant, AES is quite weak.

@joaoabs it is not directly signing related anyway. The parent search is not signed (the NREQ messages) as it does not at that point "know" what the signing capabilities of the parent are. But Atmega328p is short on the ram when signing is used so in some situations with signing enabled combined with other features, stack might get trashed due to how the tool chain manages ram VS stack. Typically if ram usage crosses around 70%. But if you are at 50% or below I think signing can be ruled out as a factor here.

@joaoabs I am not at a pc so cannot check the code but it looks like signing configuration has been altered since personalization since it prints TAMPERED.

@Anduril I do not thing there is a limitation as long as the value of the define is in legal c code initializer format. The preprocessor will "paste" your define where it is mentioned so you can search the code for it to see where it is used. I do not recall there being any logic that assume ascii in the define.

@SuperNinja if memory serves me, you only need the simple flag. You can read more in the doxygen site: https://www.mysensors.org/apidocs/group__SecuritySettingGrpPub.html

@Anduril I don't remember actually but just greping on the define should reveal that.

@Anduril yes that should be possible. Just make sure that the nodes that are personalized are configured with the same settings the simple flag enable "under the hood".

@172pilot no, and this is why I have advocated signing over encryption. Signing gives entropy, authenticity and replay protection. It does not give obfuscation but the need for that is lower in my opinion than the other three. Yes, someone could sniff what states your locks are in, but they can also just try the handle to achieve the same thing.

@172pilot without a chip, the key for signing (and encryption) is entirely unprotected. So if your kode is stolen, it is trivial to extract it. And since it is shared on the network, that network is completely compromised until you change the key on all nodes that rely on it (which would be all in the network if encryption is used). Furthermore, in the case of encryption, the signing chip is not involved, so the encryption key is never physically protected.
So signing (with a atsha chip) is the only fully protected communication mechanism.

@NeverDie I would say that combined with signing (preferably hw based) the security solution should be good enough for personal use.
As always, with open source projects, deploying to sensitive environments are every person's own responsibility. To me the biggest issue with the existing signing solution is ease of use and efficiency. Removing the need for personalization and allowing less handshaking would be a good thing. A concept for this can be seen in the github issues tagged with security v3 but alas, time is not a luxury I have for this in recent years. Kids, house and so on takes its toll.
But technically, sha256 and hmac are still strong algorithms. But the shared static key is my biggest concern (which would be solved by ecdh key exchange).

@NeverDie well, post quantum cryptography is already a reality so the introduction of quantum technology won't prevent secrets staying secret if you so desire. But in most cases, the effort of breaking modern algorithms will still be so high it won't be readily doable since if the solution is designed clever enough, timeouts will be involved that force an attacker to derive the necessary keys in a limited time frame which require significant computing power.

@NeverDie it is generally the view that because something is not easily understood by the general public, it does need securing. In other terms; security by obscurity.
To secure something properly, you need to view things from a more paranoid standpoint, assuming someone will actively try to bypass any mechanism put in place to prevent it. And always assume these mechanisms will be constantly challenged. The best approach (in my opinion) is to have as little obfuscation as possible and have the mindset that "even if you can access almost everything, you still cannot hack it".

@NeverDie in security engineering it is all about being ahead of the curve. Alas, personally I have not had the time to evolve the security solution further beyond the draft state as seen on github.

@NeverDie remember that mysensors encryption has a static IV so it is repeatable. Two identical messages will also be identical when encrypted. And therefore subject to replay attacks. Only when combined with signing do you get decent grade security.

@bwn I do not think it will if the gateway makes the two transports share the network. As things like encryption is global to each network.
Signing might work if you do it only for specific node id:s and the node id:s are distributed over both networks.

@bwn I don't know exactly how the rs network tie into other networks but in general, if you have two gateways, then each gateway has their own mysensors network and therefore can have two completely different security approaches as the signing/encryption logic applies to the network managed by each gateway.

@TRS-80 well thanks the condensed answer is, use personalization if you can, as that is more private than the simple password flag. And if you plan to use OTA, dualoptiboot is the safest approach to leverage mysensors library features such as signing and encryption.

@Anduril for encryption, the difference is not significant. With personalization, the key is stored in flash/eeprom and without it is defined in your sketch. So, if you personalize, you can publish your sketch without worrying about being compromised. And encryption works transparently with the OTA solution, IF the software that implement OTA is aware of the encryption scheme. That is, the software that configures the radio (in some solutions that is the bootloader) need to configure the appropriate key to the radio hw or driver (depending on radio).
For bootloader based OTA that require personalization unless you recompile the bootloader with the encryption key and make it configure the radio accordingly.

@YuryPol as far as I know, all licenses require some form of documentation. In all cases I know of, this is documented with the license or on the licenses official site.

License documentation required by CERN is missing. Please upload the necessary documentation. See instructions on the forum on open source hardware licensing.

License documentation required by CERN is missing. Please upload the necessary documentation. See instructions on the forum on open source hardware licensing.

@alphaHotel have you checked the memory usage? Too high ram usage can cause stack overflows which can cause all kind of mayhem.

@alphaHotel ok. That could be a bit painful to do signed on batteries.

@alphaHotel it comes down to the frequency of transmission. You can use the simple password flags to rapidly test something.

@alphaHotel signing is intended to solve exactly this problem but perhaps geared more to guard against malicious manipulation of messages. But it would work equally well for messages that unintentionally get modified in transit for any reason.
Encryption would also provide a similar filter for you but has the caveat that you need to enable it on all nodes in the network. The upside of encryption is that it does not require handshaking (at the cost of quality) so it is easier on battery driven nodes and "faster" as sending a message is still just sending a message (as opposed to sending, receiving, sending for signing).

@elcaron I do not have the necessary hardware (or the time) I am afraid. I hope the community can help.

@Technovation good find. I am not familiar with the esp32 implementation of signing though. Not sure who has implemented it as using a TLS API is not anything I have been involved with. But as it is in git, hit blame will probably lead you to which developer to approach

@Anduril Well, its all opensource, so you are free to do whatever you want. Just remember that if you are starting to alter the behaviour and use of the security infrastructure, you could potentially compromise it for yourself and those that use your code.

@Anduril if encrypted the data "cannot" be decoded. The serial is not stored in any firmware. The only exception being a personalizer sketch that will personalize for software signing.
For atsha204a based signing, serial is never stored in sketch, only in runtime.

@Anduril I'd prefer not as the serial is also considered a semi-secret to maintain the integrity of the security infrastructure. It should not be thrown around the network unprotected.

@Anduril that depend on your backend. For software signing the serial is stored in eeprom. For atsha204a it is only readable from the device itself.

@Anduril well, you can always rewrite the personalizer to not use a setup() function.

@Anduril I believe the setup() function is hijacked by the personalizer so radio is not initialized properly, nor is the library.

@Anduril There should not be anytning preventing radio startup when you have personalized a device. Have you looked at the debug output of the node/gateway, and tried with security disabled? Also, remember that the personalization has to be done on all devices that use secure communication, and if you use encryption, all devices in the entire network.

@Anduril that should be doable.

@Anduril hi! I believe @tekka has a OTA bootloader that support signing. I am unsure of there is a combination that support Ota, signing and radio with hw encryption though.

@MasMat that is my best bet, yes. Slice it all the way down and see if it makes a difference. If there is no difference with and without debug, post the debug output and I can take a look.
Another thing thar can fail is that with signing, messages max out so the odds for NACKs increase, which the signing backend is not tolerant against.

@MasMat signing works. What does not work (very well) is signing with debugging on Atmega328p. That is because memory is running low. The complexity of the library increases which require more ram. At the same time stack usage increases which take up ram in the opposite direction. The build system indicate this by warning that memory usage is high and that stability problems can occur.
When the two ends meet, the Arduino world explodes into unspecified behavior.

Your best bet is to disable debugging and any other features that you can live without if you want to use signing. Especially SW signing (which all the "simple" variants use) cost a lot of ram so if signing is a requirement, go for a atsha204a.

That sounds very plausible. Thanks for pointing out this.
PRs are welcome. I do not currently have the bandwidth to do MySensors development myself.

@kiesel Beware that I believe the 6 leg chip is I2C which is not supported. Only the 3 leg SWI variant is supported.

@kiesel It is a SOT23 if I remember correctly. There are only 3 pins, no pad underneath so soldering should be easy.
Perhaps the copper you see is part of a ground plane? It will not connect to the signing chip in any case.

@encrypt noise sensitivity could be temperature related if the radio runs "hot"

@encrypt 868 MHz is not unique so there could be interference. But yes, decouple the hell out of it. You cannot go overboard with decoupling so if you have the space, go for both electrolythic and ceramic caps. Perhaps even a tantal to try to catch as many frequencies as possible.
Antenna will also help a ton if it is properly matched.

@encrypt for sure, going pcb will give the radio supply a better power signal (just remember to not make the trace too thin).
But as you have had the rig operational for a long time, it might be worth checking other radio channels as well as perhaps some neighbor got some dirty rf toy or similar that mess with the rf environment.

@encrypt the only things that comes to my mind is that your rf environment has shifted slightly or the noise level of the supply to the radio has increased to cause intermittent failure in the transmissions.
You could try to switch channel for the radio and see if it helps? Or measure the stability of the power supply to the radio when the node(s) are communicating.

@idanronen you need signing to ensure the authentencitity of the messages. Encryption only adds obfuscation.

Please provide the documentation required by the CERN Open Hardware License when using said license.

@zen85 I think @tekka implemented some security functionality in his bootloader but I believe it relies on a personalized atsha204a due to size limitations. And does not support encryption. But I might be out of date on that topic.

@zen85 I do not think so as the simple flags are software based and the size available for the bootloader is very limited. And I do not think the bootloader shares library code base with the MySensors functionality in general so some hacking will be involved to make it theoretically supported and extensive optimization to make it practically supported.

@phildefer could you please share what you changed? The security concerned might not be comfortable running a binary with unspecified changes that manages their home automation setup. Especially not a project supposed to be open source.

@alowhum thanks for the shout out it is inspiring to see how the envelope really can be pushed with open source powered hardware and software. Really impressive stuff!

@les great! We'll, the debug flags should not help getting things to work, only provide additional information if it doesn't.
All configuration flags need to be placed prior to any header include directives. Else they will have no effect.
Anyway, glad it worked out in the end.

@les correct, no personalization needed. But with that flag, all nodes in your network need to share it. And memory requirements increase significantly so pay attention to the compiler log regarding warnings on memory use.

@les correct.
Have you checked the troubleshooting section in the docs regarding signibg issues? There is also a more verbose debug flag available.

@les right, but you also write that you were interested in encryption and not signing, so it is not the correct flag in that case. And also, note that you need the same flag on all nodes and gw if you use one that enable encryption.

@les here are all the security related flags documentation.

@les hi! The apidocs should have some hints on how to set it up.

@sharath-b-krishna no, the simple options have all secrets stored in the sketch, so don't put your production code on github if you plan to use that

@alowhum @Sharath-B-Krishna yes, at least if we are talking a single gw setup. It is possible to use two gw:s to have two separate networks. One can be encrypted and the other plain.

@sharath-b-krishna no, as encryption is done in the physical layer while signing is done in the routing layer.
Encryption applies to ALL messages at ALL times so a gw has now way of distinguishing a node that encrypts messages from a node that doesn't.
Signing is done conditionally depending on requirements exchanged between gw and node and also on certain types of messages.
Security is guaranteed by persistent storage on the GW side of nodes that communicate certain signing requirements so rogue nodes cannot just tell the GW to reset the requirements for a node if signing has been enabled at any point in history without physical access to the gw.
Encryption does not do any of this logic as it implies that certain messages has to be exchanged between gw and node which both need to "understand".

Please add the documents required by the CERN license used.

@alowhum the environment known as the arduino IDE

@alowhum the arduino IDE is not very clever and I believe the 20% left when it starts to warn is the % of ram available for the stack. So depending on your sketch, and the libraries you use, the functions you call and the order they are called has an impact in how much stack is claimed and if the stack needs more than what is left of the ram, bad and strange things start to happen.
The 20% is just a PUMA (PUlled out of My Ass) number the arduino folks came up with for what the think is a reasonable stack usage for an average user. And so, if they see that you use more ram after linking your sketch, they think you should be warned that you might get into trouble.

@alowhum I never said there was hw acceleration in atmega328p for encryption. There is hw acceleration for signing with atsha204a. And some radios have hw acceleration for encryption such as rfm69.
I don't recall that I have stated 20% ram for security either. I do not have a % for security at all. But I do recommend you follow the build environments warnings on memory usage where it states stability problems might occur.

@alowhum security v3 will most likely not be less resource intensive. The aim there is to make it more secure and less complicated to use.
However, I am currently in a stage in life where I simply do not have the time to actively work on that so someone else have to look into it, details for the plans are on github, or it has to wait for now.
There is still the option to use hw accelerated signing so atmega328p users at least in theory can still use it. And if you do manage to squeeze out enough ram to avoid the arduino environment to warn about it you should be fine.
If the environment do give warnings on memory usage, it might still work, but that is less guaranteed and light very well lead to crashes.

Please remember that the simple security flags use software implementation for signing (encryption as well unless the radio has native support), so they claim more resources. This is noticible on resource limited devices such as the atmega328p.
Nowadays, running both software encryption and softare signing on atmega328p at the same time is almost doomed to fail due to the heap and stack colliding.

@sundberg84 @mickecarlsson
It is important to remember that MYSX is agnostic from any devices.
Any names in MYSX pins bear no correlation to any device specific pin naming, so D3 and D4 mentioned on pin 9 and 10 has nothing to to with any D3 or D4 on any MCU.
If you look here, you will find that the 'A' and 'D' notation is simply an indicator of the pin function (analog or digital) and it simply increments with the pin number, so the lowest analog or digital pin number in the MYSX connector will start at '1' and then increment as the pin number increments with '2' for the next digital being on pin '6'.
Also note that since some pins are deprecated in MYSX 2.x, MYSX 2.x analog pins starts with 'A3'.

@encrypt great news! Thanks for joining the community and for your troubleshooting. This information will be compiled into the docs for future reference. Happy signing

@encrypt ah, that would indeed explain a lot and especially the tampered indication.
If true, I'll see if I can add that to the troubleshooting section to the documentation.
I was not aware of this fuse.

@encrypt but I still do not get how the bootloader could cause you to get tampered eeprom data.
Unless the fuses also affect eeprom writes of course.

@encrypt sorry no. There is no direct dependency between the security functionality and avr fuses. Atsha communications and some timeouts do expect the clocks to be working at expected rates though so the concept of time is valid. If the core clock is not matching what the preprocessor flags specify (F_CPU) then there could be problems.
Perhaps your device is not really running @8Mhz?

Perhaps you could test running a simple sketch that prints something at a specific pace and match that with a "real" clock. For example printing something every 10s specified by some delay or wait function and measure that that is reasonably accurate.

I would expect that if the MCU is not executing at the speed F_CPU specifies, a thing like delay(10s) would not really delay for 10s.

@encrypt hm ok. Try to enable the MY_SIGNING_SOFT flag. I am on cell phone so I have a hard time reading the logic flow of the code.

@encrypt that sounds very strange to me. The sketch is written to do nothing when left unchanged from git. Just output the current status.

@encrypt you should be able to run it without any local modifications to get it to print the data.

@encrypt normally when this happens, it is the main sketch that writes something to eeprom without taking into consideration what parts of the eeprom the MySensors library reserves for internal use.
Could you try to run the personalizer to write the eeprom, then your main sketch, and after that the personalizer again, but this time, configured to not write any data, just print out what is already there?
Sara should be identical but I strongly suspect it will not be (as the main sketch consider data "tampered").

@encrypt
The key here is "!SGN:PER:Tampered".
The security backend checks a checksum of the eeprom data used for security. If it is not valid, it considers data tampered and will not use it. So your eeprom has been corrupted one way or another. Or you use either a really old personalizer or a really old library version.
Edit: not old library. And old library would not care about checksum.

@kimot AES key is stored in eeprom for all radios. It is fetched and loaded to the radio in runtime. Not compiletime.

@encrypt then I am fresh out of alternatives. Have you tried the verbose flag for signing just to see if it is signing/encryption that is causing the problems? Or try using signing / encryption one at a time.
Signing can be set up on a per device/gw basis but encryption has to be configured for all devices (that need to communicate).

@kimot all security secrets are stored in eeprom or in an atsha204a device. Never in the sketch unless you use the simple security option.
Exception being the personalizer sketch for obvious reasons

@encrypt normally when using the arduino IDE it is automatically added when you pick board variant. F_CPU or something like that.

@encrypt hm, usage is not alarmingly high. The only thing that comes to my mind is if your sketch for the bare atmega328p is compiled with the correct frequency specified. Some timing specific code rely on the CPU_FREQ define (note, I am not sure if that name is the correct one) and if that does not reflect the actual clock rate things might not work as expected.

@encrypt what is your memory utilization?

@skywatch just read the docs and you'll be fine

@skywatch always happy to help a fellow "signer"

@snyfir Sorry, my comment was incorrect. The GW does not assign IDs. Your controller does. So it comes down to how your controller reacts to what the GW reports.

@snyfir It might work, but watch out so that you do ensure that nobody can spoof the device ID or somehow trick your GW to reassign the ID to a level where it will not verify the message.

@snyfir Yes, have a look at https://github.com/mysensors/MySensors/blob/master/core/MySigning.cpp#L414
Commenting out that line (and https://github.com/mysensors/MySensors/blob/master/core/MySigning.cpp#L431 if you also use whitelisting) will prevent the GW when configured with MY_SIGNING_WEAK_SECURITY to "downgrade" security settings. Thus, a node that has registered in that it require signatures, will not be able to "undo" that by remote command in the GW.
That should make your lock co-exist securely in your network even when the GW is not requiering signatures from other nodes.
But please note that you still use the weak security flag, so all other GW logic still behaves as before (signed messages will only be required by nodes that require messages themselves and so on).

I have intentianlly left out the option of selecting this operation mode because the security configuration is complex enough as it is and users unfamiliar with the inner workings of the signing backend might end up locking themselves out and having problems getting things working again (resetting EEPROM in your GW will make it loose routing tables and ID assignments as well so it is not something to make a habit out of doing ).

@skywatch yes, that is a perfectly viable option. As they are two separate independent networks they can have distinct configurations and requirements. This also applies to the security.
Much like WLANs.

@snyfir
Hi!
The gateway will require signatures from the keypad since the keypad also require it also with the weak security setting. However, with that setting, a rogue device could spoof and pretend to be your keypad, and then transmit a message to the gw that it no longer require signatures and therefore make the GW relax its requirement from that device until it again indicate it require signatures.

You could add encryption to obfuscate your communication a bit which makes it harder for an attacker to spoof your keypad but that also require you to deploy encryption to the entire network.

You could also hack your gw code so that it makes that particular node irreversibly require signatures from your keypad node but there is currently no "official" way of doing that.

Another hack you could make which is less "hard core" is to adjust the behavior of the weak security flag to never allow "nerfing" security settings for a node.
That is, even with the weak flag set, a gw will never allow a node to stop requiring signed messages.
Or more to the point: the GW will allow a node to set the bit in gw eeprom to indicate that it require the node to send signed messages, but it will never clear it.
The consequence of doing this is that if you at some point want to disable requirement for signatures for a node, you have to manually reset the eeprom flag in the GW.
I don't remember exactly but I think this is the behaviour if you do not set the weak flag because the message to configure signing requirement is in itself not signed. Therefore the default is to accept going to a more secure state but not going back.

Hope this makes things a bit more clear

@flyingdomotic certainly. But I do not have time for MySensors development at the moment, only support. But pull requests are always welcome!

@flyingdomotic yes, it is a known limitation. The signing part cannot handle multiple nonces at once. It is a decision made to be able to support more memory restricted devices as the atmega328p without fragmenting the signing backend.