Conceptual security question
-
During the latest test I performed with signing I realized that I overlooked one point and its consequences.
I would like to get a clear picture of things are supposed to work and what is required to get some decent security in place.
So far all my nodes are using signatures. What I fully understood now, is that the sensor node triggers whether he requires signatures or not.
As a consequence, an attacker could re-use an existing node id, configure it to not using security and start a conversation with my gateway and since with my controller who is agnostic to signatures.I could imagine that with a proper inclusion process - which I am not using until now - could close that whole. Since I am not using inclusion so far, I do not know how it works. Will the use of inclusion ensure that everytime a node presents itself, the gateway needs to be in inclusion mode? Or is this something the controller needs to take care of?
-
I imagine that whitelisting the node in question would prohibit it from start using unsigned messages without updating the whitelist at the gateway.
-
@martinhjelmare said:
I imagine that whitelisting the node in question would prohibit it from start using unsigned messages without updating the whitelist at the gateway.
Since the whitelist includes the serial, this would for sure prevent the "attach" I described. However, as far as I know the whitelist sits compiled in the gateway code which is pretty secure but very hard to extend and maintain.
-
Yes, I believe so. Security will always come at a usability cost. But I would probably not whitelist all nodes, only the ones that are exposed to being stolen or play a very important role from a security perspective, eg part of an alarm system or similar.
-
@martinhjelmare said:
Yes, I believe so. Security will always come at a usability cost. But I would probably not whitelist all nodes, only the ones that are exposed to being stolen or play a very important role from a security perspective, eg part of an alarm system or similar.
I agree with you that security comes with a cost. However, that does not mean that you automatically sacrifice usability. Btw, my scenario is not about stolen nodes, it is about an attacker coming into reach of your network and just presenting an existing node without use of signing.
I coud imagine that whitelisting could be done dynamically. In order to include a sensor into the network a kind of inclusion (may we have that already, I do not know how inclusion right now works) needs to be active. If inclusion is active a node will be included into the whitelist. Since the start of inclusion requires physical access to the gateway this could be pretty secure, assuming that physical access deemed to be secure.
-
From what I have understood, nodes decide that messages to them must be signed.
So a door lock would typically require signed messages.
The attacker can certainly introduce a fake door lock into your network, and that fake door lock could open without requiring signatures. But unless the attacker fools you into physically replacing your door lock with the fake lock, you will still be safe.
The attacker can introduce a fake "open door switch" node that doesn't send signatures. But since your real door lock still requires signatures, your real lock will refuse to open even if the fake node sends an unsigned message to your door lock.
So I think you are trying to protect yourself against an attack model that doesn't exist.
@Anticimex will probably correct me if I am wrong
-
@mfalkvidd said:
From what I have understood, nodes decide that messages to them must be signed.
So a door lock would typically require signed messages.
The attacker can certainly introduce a fake door lock into your network, and that fake door lock could open without requiring signatures. But unless the attacker fools you into physically replacing your door lock with the fake lock, you will still be safe.
The attacker can introduce a fake "open door switch" node that doesn't send signatures. But since your real door lock still requires signatures, your real lock will refuse to open even if the fake node sends an unsigned message to your door lock.
So I think you are trying to protect yourself against an attack model that doesn't exist.
@Anticimex will probably correct me if I am wrong
@mfalkvidd The scenario I was thinking about - and probably it is too far fetched - is let's say a PIR which would trigger an alarm. If an attacker would have a non-signing PIR which uses the same node-id as the real one. The fake one sends 0. The real one would still be there but could be jammed while the fake one is still sending...
Ok....while writing that and reflecting on it I agree that my scenario is highly theoretical and as long as the "attacked" node cannot be just "replaced" rather unrealistic.
-
Regarding inclusion mode, that is something that has to be supported by the controller. Pushing a button on the gateway can send a command to the controller to activate inclusion mode. So yes, this could be used to enhance security, in combination with signing, I guess. You would protect yourself from adding new nodes without your intention. Signing would make sure that all nodes are who they say they are.
-
@tomkxy I wouldn't call jamming unrealistic. Jamming a radio signal is pretty easy.
-
@mfalkvidd said:
@tomkxy I wouldn't call jamming unrealistic. Jamming a radio signal is pretty easy.
Yes, I am aware that jamming a radio signal is not that difficult. What I wanted to say is that the overall scenario might be doable but it is much too complicated. It would be much easier to jam the whole radio network in which case signing makes no difference.
-
Generally, the concept of signing is to define a node as a trustworthy one. That is, you trust your node is really yours and has not been tampered with. There can always be a case when someone steals your node and reprogram it. That attack scenario is difficult to protect from. However, to counter that to some extent, I have implemented the concept of whitelisting, where each node will have a unique identifier which is salted into the signature. It is therefore protected from OTA sniffing and semi-"secret".
Should your secure node be stolen and be target for manipulation and later reinsertion, you can use whitelisting to filter out that node (and only allow nodes you still trust). As the unique identifier of your other nodes are unknown to the attacker, chances are still somehwat low that the attacker will be able to guess the identifier of another of your secure nodes (it is nine bytes long). And for nodes that are left open to theft, I would also recommend to use ATSHA for signing, as that will prevent the attacker from obtaining your HMAC key since that is the key that protects your entire signing network. Loose that, and you are left open to attack, and whitelisting alone is then a weak defence.
-
@Anticimex Did you every think about making the whitelisting feature more dynamic. What I mean is pushing the inclusion mode or however it is called to the gateway. Only when the gateway is in this "inclusion" mode it will add new sensors being presented to it into the whitelist. From my point of view this would increase usability of the whitelisting feature quite significantly without sacrificing security. In its given form, I think whitelisting is practical usable only in a static scenario where your sensor network is defined and is not expected to change a lot.
Why do I think security would not be sacrificed: In order to activate "inclusion" at the gateway you need physical access to it. So as long as access to the gateway is physically secured overall security is not really negatively impacted (apart from the time window where the gateway is in inclusion mode).
Just my thoughts. What do you think?
-
@tomkxy i don't like that because it is difficult to protect the semi secret information whitelisting is based on. If the details circulated on the networks, they can be sniffed and that neutralized the whole idea of whitelisting. The concept of whitelisting is entirely based on the assumption that a node has some unique aspect only known to the owner. If that information is disclosed to other parts of the system they can potentially be left open to attack.
-
@Anticimex Ok. I have to admit I do not know enough about how whitelisting actual works and in particular on what info it is based. I somehow assumed that in combination with signatures a node which has been once whitelisted can send messages (including whatever id is required to identify him on the whitelist) to the gateway ensuring that those messages cannot be tampered with or faked by a non "authorized" node. So that even an attacker know about the id he cannot make use of it unless he has access to the shared key.
-
@tomkxy The concept of whitelisting I have developed is to protect from the case when someone actually obtained your key. Typically by stealing a node with a personalized ATSHA onboard or even one with soft signing.
According to Atmel, it is not possible to extract the HMAC key from an ATSHA but it is from a software based node.
For this reason, my recommendation is to never use soft signing for nodes "outside".
Now, although it is not considered possible to extract the HMAC key from an ATSHA, the attacker can still use it as it is already personalized for you. So he can just flash whatever and be able to send valid signatures.
However, if you enforce whitelisting on your network, then the receiver of signed messages has to keep a list where each node is listed, and with each node a unique serial. That serial is salted into the signature by the sender and therefore not sniffable. But the attacker will be able to determine the serial from the node stolen. But using that info, he will not be able to deduce the serial of other nodes in the system that you also have decided to accept. So if you detect that a node has been stolen, you remove it from your whitelist, and the attacker will then have to guess both the nodeId and the serial of a node in your whitelist table. The nodeId can be sniffed, but the serial cannot. And therefore I do not under any circumstance allow the serial to be easily accessible by any means.
