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:[email protected]] *On Behalf Of *Michael StJohns
*Sent:* Wednesday, November 23, 2016 1:22 PM
*To:* [email protected]; Rene Struik
<[email protected]>
*Cc:* [email protected]
*Subject:* Re: [Ace] Summary of ACE Group Communication Security
Discussion
On 11/17/2016 7:00 PM, [email protected]
<mailto:[email protected]> 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 <[email protected]
<mailto:[email protected]>> 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
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/ace
_______________________________________________
Ace mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/ace
--
email:[email protected] <mailto:[email protected]> | Skype:
rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363
_______________________________________________
Ace mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/ace
_______________________________________________
Ace mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ace
