One can argue whether this leads to a vulnerability in practice, but the TinySec paper specifically lists semantic security as a goal, and also (mistakenly) claims that CBC is semantically secure as long as IV-reuse does not occur.

Let me make a few points and please, do dispute them. I am very interested in your opinion.

1. One thing is your paper and completely different is how people understand security in sensor networks based on TinyOS. TinySec is the only widely known mechanism / library that may provide cryptographic protection. My analysis is not that much about theory but about security engineering.

2. I believe that many people do not realise that there may be a problem once TinySec is used. I tried to show some problems that are related to the use of a single common key - assuming that the attacker does not get hold of that key! (Something quite unusual for research in sensor networks.)

3. You did not try to solve key management - quite understandably - but the problem does not disappear and one has to deal with it somehow. Your paper says “…implementation is included in the current TinyOS public release and is available for routine use as well.” (what key management will be deployed in “routine use”?). I cannot see a way how pairwise keys could be used in dynamic multi-hop networks at all - more realistic solution is to use end-to-end keys.

4. You rightly say that your library was for Mica2 motes but even there, I’m missing support for replay protection and for multi-hop routing in general. It seems to me that decision not to check IV of incoming frames and not to use counter for unencrypted frames was done in favour of lower overhead and not security and I’m not sure it was the right decision. TinySec does check MAC and offers result of this test to the application. Could this be done with IV/counters? I think that yes. I am also tempted to say, given 2. and 3., that “routine use” has been let down a bit.

5. Let the application do the difficult stuff? I do not see a strong reason for this because TinySec brings in serious limitations for crypto protection in the form of short IVs and MACs. Beside that, TinySec does not allow replays as the counter value in the IV is incremented with each new sent message. Iang also says about SDP1 “[there is] dosage of advice on how to watch each of these [freshness indicators]…” but the same cannot be done with TinySec because the IV is not exported with the message out of the module - application can not do anything even if it wanted to.

6. I do think that TinySec has been a great think - as an academic work at least. The problem is that it has become a commonly used mechanism and as such, the engineering issues became even more important than ideas - the weakest link was not only shifted somewhere else but also blurred a bit.

Also, I’m confused by your analysis a bit. It seems to implicitly assume TinySec is being used with the TinyOS packet format designed for the 802.15.4 radio. TinySec was designed for Mica2 motes, which used a different packet format. We never proposed using TinySec with the 802.15.4 radio stack or the newer packet format. See the paper for the Mica2 TinyOS packet format.

Please let me know if I’ve misinterpreted any of your work.

The main problem is that all of the classical cryptography suggestions have implementation-side weaknesses. In short, one answer is an implementation-robust solution. We chose to embed into the IV an incrementing counter, a time, and a random. As well, logically, there is a session number in the IV. Then, there is a dosage of advice on how to watch each of these in the implementation in order to get a balance between architectural issues and a decent IV.

The ball is in the implementor’s court: e.g., if keeping an incrementing counter is unlikely because of needs for atomic storage, you can skip it, but keep the time and random elements.