Hi all, this is an attempt to summarize the discussions around the group communication security topic from the ACE meeting yesterday. Please correct me if I am wrong.
The concern is the following: How can we ensure that a compromised IoT device, which is part of a multicast group, is unable to trigger actions at other nodes? The underlying assumption is that one can use the obtained group key to then trigger actions that such a device would normally not be able to do. Here is an example: Imagine a luminare A that belongs to a group that consists of a light switch and other luminaires. Luminare A gets compromised and is not able to issue on/off commands to other luminaires in that group. Normally, only the light switch would issue such commands. The story then continues that such a compromised luminare would then also be able to issue commands to a door lock. So far, so good. Here is the disagreement. Some folks in the group believe that in order to disallow a compromised luminare to have such a functionality we need to introduce source authentication. So, instead of using symmetric group keys we would be using digital signatures and the luminaires in our example would then verify whether the command came from a light switch. Some other folks, including myself, believe that we would not just use the group key to determine the authorization decision but would instead rely on the authorization mechanism to prevent larger harm. This means that a compromised luminare would indeed turn on and off other luminaires in the group but they would not be able to successfully send commands to a door lock since those would (a) not use group communication and (b) if they use group communication then that would require an interaction with the authorization server to first obtain a different group key for such an interaction. Most likely there is no need for a luminare to obtain a group key for communicating with a door lock. As a way forward it was suggested to explore the use of digital signatures and to make use of some of the more recent developments done in the CFRG. So, if a researcher has free cycles please contribute your thoughts on this subject. What we would like to know is the following: * How large would a message be when we use some command (like a CoAP packet) with an application layer digital signature (e.g., using COSE) using ECC? We are particularly interested in the verification operation. * What is the performance impact on processors in the M-class category? * What are the implications for power consumption? Here is my initial impression regarding the second aspect from a performance analysis I ran on an LPC1768. It took 458 msec to do a verify computation with optimization enabled* for a secp256r1 curve. The LPC 1768 demo board uses a ARM Cortex-M3 CPU running at 96MHz. I also did a performance test with the STM DISCO-F746NG, which uses a Cortex-M7 CPU running at 216 MHz. For the ECDSA secp256r1 verify operation it took 10, 205 msec. No hardware speedup or assembly optimizations were used in these tests. I believe we would need something that accomplishes the verify operation in about 150 msec to meet the delay budget we have since the verify operation is not the only processing task. Ciao Hannes *: Optimizations in this case means: - NIST Optimization Utilizes special structure of NIST chosen curves. Appendix 1 of http://csrc.nist.gov/groups/ST/toolkit/documents/dss/NISTReCur.pdf Longer version in FIPS PUB 186-4: http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf - Fixed Point Optimization: Pre-computes points, as described in https://eprint.iacr.org/2004/342.pdf - Window: Technique for more efficient exponentiation Sliding window technique described in https://en.wikipedia.org/wiki/Exponentiation_by_squaring
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
