Re: [Ace] Summary of ACE Group Communication Security Discussion

[Rene Struik <[e-mail]>]

Dear colleagues:

Just a reminder re perceived technical hurdles for using signatures:
a) time latency of signing:
One can pre-compute ephemeral signing keys, so as to reduce online key 
computation to a few finite field multiplies.
Please see my email to the list of July 26, 2016: 
https://mailarchive.ietf.org/arch/msg/ace/iEb0XnAIMAB_V3I8LjMFQRj1Fe0
b): further speed-ups/tricks, etc:
One can try and be smarter by clever implementations.
Please see my email to the list of July 21, 2016: 
https://mailarchive.ietf.org/arch/msg/ace/iI58mT_DDzKImL1LP_bUQ7TzooI

This seems to take the time latency argument away. The only other 
technical hurdles I can see are
(i) signature size {is 64B too much?};
(ii) cost of public key crypto implementations {quite some small, nifty 
designs out there (NaCl etc.}.

As to (i) - one should view signature sizes in perspective: as an 
example, key sizes in the key pre-distribution scheme HIMMO (as promoted 
by Philips) has key sizes of 6.25 kB and up, according to Table 3 of the 
paper that massages parameters to thwart new attacks on their scheme, 
see http://eprint.iacr.org/2016/152.

So, security arguments that favor asymmetric solutions aside, there also 
do not seem to be too many other objections that would hold in the world 
anno 2016 {except for "sunk investment" arguments", but that is a 
corporate mindset issue}.

On 11/17/2016 12:50 AM, Michael StJohns wrote:
> On 11/16/2016 9:08 AM, Kepeng Li wrote:
>>
>> Hello all,
>>
>> We had a long discussion about group communication security topic 
>> since the previous F2F meeting.
>>
>> Hannes and I have tried to make a summary about the discussion as 
>> follows:
>>
>> ·       The solution needs to define both, symmetric and an 
>> asymmetric group key solution.
>>
>
> There is no case (absent hardware mitigation) in which a symmetric 
> group key solution can be made secure/safe and no one has made an 
> offer of proof that they can make it secure.    I've asked repeatedly 
> - no one has come forward with more than "oh we can lock the symmetric 
> key stuff in a corner and make sure it isn't used for anything important".
>
>
> Given the recent attacks on the internet by IOT botnets, there is a 
> further consideration that should be undertaken - whether the 
> symmetric group key solution applied to 10s of 1000s of IOT devices is 
> an active threat to the rest of the internet (e.g. enabling DDOS, 
> cyber physical issues, etc)?
>
> The multiparty (group) symmetric key solution is only wanted for a 
> single corner of the solution space - low latency, no cost systems.  
> E.g. lightbulbs.  Given there is a worked example of the insecurity of 
> multiparty symmetric key systems (e.g. the attack on the symmetric 
> signing key of the HUE lights), I'm unclear why anyone at all would 
> think that pursuing a known bad solution in the IETF is a good idea.
>
>> ·       The security consideration section needs to explain under 
>> what circumstances what solution is appropriate.
>>
>
> Security consideration sections generally only address the threat *to* 
> the system from security choices.  In this case, symmetric key group 
> comms reduces down to the same security analysis you would use with 
> shared default passwords across 1000s of devices. An IOT security 
> consideration section in the future probably needs to address the 
> threat *FROM* the IOT solution to the broader internet.
>
> Mike
>
>
>> If this is not accurate, please let us know.
>>
>> Kind Regards
>> Kepeng & Hannes
>>
>> BTW: it is a pity that I can't attend this meeting due to personal 
>> reasons, and hope you all have a nice meeting in Seoul!
>>
>>
>>
>> _______________________________________________
>> Ace mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ace
>
>
>
>
> _______________________________________________
> Ace mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ace


-- 
email: [e-mail] | Skype: rstruik
cell: [phone] | US: [phone]