Minutes 6TiSCH Security conf call, Tue February 24, 2015, 9-10am EST #

• note taker: Rene Struik
• discussion material (referenced in minutes): no posted material, although link to discussed chip set included in minutes

Attendance

1. Pascal Thubert
2. Giuseppe Piro
3. Michael Richardson
4. Thomas Watteyne
5. Malisa Vucinic
6. Rene Struik

Agenda

The suggested updated agenda was approved, after striking out item #3 (on time latency aspects). As Suggested agenda:

1. administrativia {agenda bashing/minutes}
2. implementation aspects (w/ HW considerations)
3. time latency aspects (continuation)
4. AOB

Minutes

The minutes of the previous 6TiSCH security conference call (Tue February 17, 2015) still have to be approved.

Implementation aspects (w/ HW considerations)

• RS discussed some hardware aspects of the CC2538 System on a Chip (Texas Instruments), to the extent this pertains to implementation of public-key crypto operations. {The reason to look at this chipset was that this was presumably representative for the target space 6TiSCH is after.} Some observations: (a) This particular chip supports prime curves in so-called short-Weierstrass form (22.1.3.4.6); (b) where points are represented in affine format; (c) Some operations seem to take variable-time, e.g., modular inversion (22.1.4.4); (d) time latency for scalar multiplication using the NIST curve P-256 is roughly 1/6 second.
• RS remarked that time latencies indicated in the data sheet re-confirm the assessment that communication time latencies due to TSCH are expected to be more important than computational time latencies (same assessment as in 6TiSCH security call of Feb 17, 2015). Here, one should note that a joining node has to perform two scalar multiplications (to compute the ephemeral public key, respectively the shared Diffie-Hellman key) and might have to verify some signatures (which, with ECDSA, take roughly time equivalent to two scalar multiplications [without tricks]). MR noted that constant-time operations might add some additional time, due to, e.g., injection of random clock delays in the computation path. RS confirmed (upon question by ThW) that figures discussed reflect so-called perfect forward secrecy (aka "PFS"). GP noted that he and his group were conducting some security implementation experiments, although they currently focused on regular security tasks (outside the realm of join operations).
• RS noted that the choice of curve might impact whether hardware support is available. As an example, if one would use some of the curves CFRG is currently debating, these would not be supported [with this chipset]. On a general note, most smart grid architectural documents mandate the use of NIST curve P-256 (which also allow FIPS validation), so are expected to stay. He suggested this may be a prudent choice for 6TiSCH security as well. Notwithstanding this, of course, designing with algorithm agility in mind would be required.

AOB

• Architecture document. PTh noted that there were a few comments related to draft-ietf-6tisch-tsch-05 that pertained to security and suggested further discussion via the mailing list.
• Rechartering. 6TiSCH is expected to recharter just after the IETF-92 meeting in Dallas (March 2015). He invited everyone to give some thought to a paragraph on security that could end up with this revised charter and, possibly, include some documents.