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

[Michael StJohns <[e-mail]>]

Hi Akbar -

This comes under the heading of a rat hole question for this discussion 
- sorry.

Basically, the use of public key systems vs whether to use public key 
systems with certificates are separate questions.  In a typical 
relatively closed group control system using public keys, you would 
generate key pairs on the controllers (switches) and provide the bare 
public keys to the actuators to validate control messages.  Since the 
public keys have no life outside of the local domain/group, there's 
really no reason to deal with CAs, certificates et al.

Some designs *may* want to include digital certificates for chaining and 
management of credentials, but again typically, these are closed systems 
that do not/will not/should not depend on public PKI for their security 
guarantees.   And in fact, the form of the digital certificate in these 
types of systems may bear little resemblance to an X.509 certificate 
(e.g. a signed public key blob with a fixed length, fixed fields, fixed 
offset format).

In general, you use public PKI stuff when you want your credentials to 
have somewhat of a global reach.

So - public PKI certificate question + IOT ==>  rat hole for this 
discussion.

Mike


On 11/25/2016 10:52 AM, Rahman, Akbar wrote:
>
> Hi Mike,
>
> Thanks for pointing out all the issues with a symmetric key approach 
> to group communication.  However, can you also give any thoughts on 
> the specific vulnerability to the CA and certificates in the 
> asymmetric key approach for IoT?  After all, there has been some 
> well-known attacks on PKI infrastructure in the last few years such as:
>
> https://en.wikipedia.org/wiki/DigiNotar#Issuance_of_fraudulent_certificates
>
> Do you think it will be better or worse if IoT infrastructure start 
> using certificates on a massive scale?  Or is it outside the scope of 
> IETF standards and more of a deployment and operational issue?
>
> /Akbar
>
>
>
>
> <http://idcc.me/2e6xDgc>
>
> This e-mail is intended only for the use of the individual or entity 
> to which it is addressed, and may contain information that is 
> privileged, confidential and/or otherwise protected from disclosure to 
> anyone other than its intended recipient. Unintended transmission 
> shall not constitute waiver of any privilege or confidentiality 
> obligation. If you received this communication in error, please do not 
> review, copy or distribute it, notify me immediately by email, and 
> delete the original message and any attachments. Unless expressly 
> stated in this e-mail, nothing in this message or any attachment 
> should be construed as a digital or electronic signature.
>
>
> *From:*Ace [mailto:[e-mail]] *On Behalf Of *Michael StJohns
> *Sent:* Wednesday, November 23, 2016 1:22 PM
> *To:* [e-mail]; Rene Struik 
> <[e-mail]>
> *Cc:* [e-mail]
> *Subject:* Re: [Ace] Summary of ACE Group Communication Security 
> Discussion
>
> On 11/17/2016 7:00 PM, [e-mail] 
> <mailto:[e-mail]> wrote:
>
>     Is anyone willing to work on a draft to be ready in advance of the
>     Chicago meeting so we have a concrete proposal for asymmetric keys?
>
>
> I'm just catching up on old mail after getting over a cold.
>
> Mostly, this could be as simple as a two to four paragraph draft:
>
> 1) Use CORE section 5 for message formats. (e.g. public key signed 
> messages) using one of several defined specific set of algorithms 
> (e.g. sha256withecdsa and p256 or something smaller) chosen by the 
> application.
> 2) The authentication bare public key is a configuration item for the 
> end devices and placement is beyond the scope of this draft.
> 3) Tracking of a message ID from (1) to prevent command replay attacks.
> 4) Minimum numbers of controllers (e.g. public keys and actuation 
> events or message ids) that an end system has to track.
>
> (2) could be folded into a draft about configuring end devices.
>
> A more complex model would be:
> 1) Place a root certificate on all end systems via configuration (also 
> out of scope)
> 2) Describe the certification path algorithm (e.g. profile RFC5280)
> 3) Describe how the cert path certificates are carried in CORE section 
> 5 messages.
> 4) plus 3 & 4 above.
> 5) plus how to operate in the presence of clock time.
>
>
>
> Unlike symmetric key systems, there really doesn't need to be a key 
> management/agreement/transport protocol per se.  It's all about a) 
> what constitutes a valid message, and b) what do you do with the valid 
> message once you get it.
>
> An application specific draft would include message formats for things 
> included in a CORE section 5 message (e.g. the specific values for 
> turning on and off lightbulbs or setting their hues or intensity), but 
> that's not really an ACE thing per se.
>
> Mike
>
>
>
>     Thanks,
>
>     Kathleen
>
>     Please excuse typos, sent from handheld device
>
>
>     On Nov 17, 2016, at 11:26 PM, Rene Struik <[e-mail]
>     <mailto:[e-mail]>> wrote:
>
>         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] <mailto:[e-mail]>
>
>                 https://www.ietf.org/mailman/listinfo/ace
>
>
>
>
>             _______________________________________________
>
>             Ace mailing list
>
>             [e-mail] <mailto:[e-mail]>
>
>             https://www.ietf.org/mailman/listinfo/ace
>
>         -- 
>
>         email:[e-mail] <mailto:[e-mail]>  | Skype: rstruik
>
>         cell: [phone] | US: [phone]
>
>         _______________________________________________
>         Ace mailing list
>         [e-mail] <mailto:[e-mail]>
>         https://www.ietf.org/mailman/listinfo/ace
>