All I offered a use case late last year. The thread subject was: AllJoyn Root CA & Device Certificates I have pasted a portion of that thread below. It is worth going into the mail archives and reading the related messages to get the inputs from others.
From:[email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Markham, Tom Sent: Tuesday, October 27, 2015 11:05 AM To: [email protected]<mailto:[email protected]<mailto:[email protected]%3cmailto:[email protected]>>; [email protected]<mailto:[email protected]<mailto:[email protected]%3cmailto:[email protected]>>; [email protected]<mailto:[email protected]<mailto:[email protected]%3cmailto:[email protected]>>; [email protected]<mailto:[email protected]<mailto:[email protected]%3cmailto:[email protected]>>; [email protected]<mailto:[email protected]<mailto:[email protected]%3cmailto:[email protected]>> Subject: Re: [Allseen-core] [Allseen-ssc] AllJoyn Root CA & Device Certificates First , I apologize that my other responsibilities prevent me from spending as much time working Allseen/AllJoyn as it deserves and as I would like. I have been following this thread. Greg Z wrote: "- All of this is just a thought experiment if manufacturers aren't on board, willing to do the extra work, and see these extra costs as providing value. We shouldn't use any AllJoyn resources until they weigh in." Honeywell would benefit from having an AllSeen/AllJoyn ROT. Being able to verify the manufacturer, make, model, and serial number of a device has value in many of the environments we operate in. [DT] Can you given an example? (The examples below don’t appear to me to require verifying manufacturer, etc.) Here are two items of concern which cut across multiple use cases. These highlight why Honeywell needs a RoT and the associated support. · Increased liability for failure. Many IoT devices have a relatively low impact if they fail. (e.g. light bulbs and TVs). However, Honeywell produces products which could lead to serious consequences if they fail (CO detectors, smoke detectors and home security systems). Our potential liability is high and thus demands that we take steps to minimize the risk of failure due to poor security. [DT] Agree, but if I understand the above scenario it just requires AlLJoyn security, it does not require an AlLSeen ROT. In normal AllJoyn security, the owner of the device or network is the ROT. Can you elaborate on what additional value an AllSeen ROT would have over-and-above the normal AllJoyn security model where the owner is the ROT? Just trying to understand not pushing back. [TRM > ] The Rot enables automation and validation of the onboarding process. If the onboarding process is manual then there is an increased risk of human error. We must consider the case of an untrained homeowner who may not have read the user manual for a device before joining it to their network. Let’s dig into a (long) concrete example. A homeowner buys a Vendor_X home security panel which includes intrusion detection (door sensors, motion detectors, etc.) and fire alarm. http://www.security.honeywell.com/hsc/products/intruder-detection-systems/control-panel/fire-burglary/<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.security.honeywell.com%2fhsc%2fproducts%2fintruder-detection-systems%2fcontrol-panel%2ffire-burglary%2f&data=01%7c01%7cgregz%40microsoft.com%7c327b52da6bf8432db56308d2df2d619f%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=BPmijDMxbNDUkejdAGMCDwTeSPqpk%2fqYfLBM0DQFPoA%3d<http://www.security.honeywell.com/hsc/products/intruder-detection-systems/control-panel/fire-burglary/%3chttps:/na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.security.honeywell.com%2fhsc%2fproducts%2fintruder-detection-systems%2fcontrol-panel%2ffire-burglary%2f&data=01%7c01%7cgregz%40microsoft.com%7c327b52da6bf8432db56308d2df2d619f%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=BPmijDMxbNDUkejdAGMCDwTeSPqpk%2fqYfLBM0DQFPoA%3d>> These panels receive a sensor input from a local fire or smoke sensor and send the alarm to an alarm monitoring center (A.K.A. central station). The alarm monitoring center then contacts the local fire department. The DIY homeowner buys a smoke detector off the internet which claims to work with Vendor_X fire-burglary panels. In fact the device is not certified to work with the Vendor_X panel but the DIY homeowner does not know this. Unfortunately, there are counterfeit products sold over the internet. The fire-burglary panel is able to validate smoke detectors from Vendor_X because both the panel and smoke detector have a common Vendor_X root. However, if there is no common ROT, then the panel does not have an automated, authenticated means of determining if the smoke detector is what it claims to be. The homeowner, using a manual process completes the installation of the smoke detector. Sometime later there is a fire in the home. The system (smoke detector & panel) fails to detect the fire and contact the monitoring center. The homeowner’s child dies in the fire. The home owner sues Vendor_X. Did Vendor_X take “reasonable care” to ensure that the smoke detector would work with the panel? If there is a common RoT then the panel has the ability to check the device certificate in the smoke detector and accept or reject the smoke detector. The chance of human error is eliminated when the panel can use a common RoT to automatically validate the smoke detector. If public key technology is available in 2015 to address this issue and Vendor_X does not use a common RoT, what is the Vendor_X liability? What will the jury decide? · Scalable secure commissioning: Honeywell (and other vendors) need to consider the labor and risk of human error in large deployments. For example, consider the commissioning of a new apartment building having 100 units, with each unit having 4 smoke detectors. All of these are networked to a central building fire panel. What method of commissioning (claiming or On-boarding) these 400 smoke detectors would allow the installer to reliably and cost effectively register these devices with the building’s central fire panel? One could imagine taking pictures of bar codes on 400 nearly identical smoke detector boxes and manually maintaining the associations. Alternatively, one could imagine an automated PKI assisted mobile device application which incorporates claiming and commissioning the devices in a manner which is approved by the fire marshal. Many buildings (and homes) will contain devices from multiple vendors. Having an AllSeen RoT enables (but does not guarantee) a secure and scalable commissioning process. [DT] Again, I didn’t follow what additional value an AllSeen ROT would have over-and-above the normal AllJoyn security model where the owner is the ROT. Can you elaborate? [TRM > ] Once the device has been brought into the owner’s network the owner’s RoT and associated security mechanisms can provide a lot of security protection. The threat the AllSeen wide RoT addresses is protecting the owner from joining an “incorrect” device to the network in a multi-vendor environment. The device may be incorrect because it is the wrong model or because it is a counterfeit. The AllSeen RoT provides value to the owner by giving the owner the ability to automatically and with confidence perform onboarding. I encourage the group to think not just about the use cases and devices of today but imagine the world 5-10 years from now. Consider the issues we are facing today in migrating from IPv4 to IPv6 because we did not anticipate the scale of the network. If we do not provide the option today for vendors to participate in an AllSeen/AllJoyn wide PKI, then we may find that we hit a wall in terms of scalability, trust and automation. What if AllSeen has an optional RoT? Vendors who value automation, reduced human error and management of risk can choose to participate by having their vendor CA signed by the RoT. Vendors selling low risk products (e.g. light bulbs) may choose to sell devices not traceable to the RoT. The person or process doing the onboarding then has the option of deciding the level of risk appropriate for their environment. Bottom line - Honeywell does see real value in a having a globally verifiable "certificate". Tom Markham From: Brian Witten [mailto:[email protected]] Sent: Tuesday, February 09, 2016 5:26 PM To: Swinson, Ken <[email protected]> Cc: [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; Markham, Tom <[email protected]>; [email protected]; Damon Kachur <[email protected]> Subject: Re: [Allseen-core] Security 2.0 status, and proposals for improvements Hi Ken, Sadly I've been too distracted with the day job. I know that Honeywell and CableLabs and Symantec are all aligned on the merits and need for Device Certificates managed by a responsible CA. However, I'm stepping into international travel, and won't really be back until Feb 22. Perhaps a good next step is for me to set up a call for that last week of February? Alternatively, if many of you will be at the RSA Conference, I could book a room for many of us to meet f2f there, and dial in the others? Thank You Either Way - Best, Brian On Feb 09, 2016, at 11:56 AM, "Swinson, Ken" <[email protected]<mailto:[email protected]>> wrote: I do not have a business case to drive the mfg/device certificate use but I am willing to assist with documenting the use cases if someone steps forward to drive it. I’m concerned that those who expressed interest are assuming that functionality is in place when it isn’t. I’m looking forward to your proposal for the manifest changes. From: Daniel Mihai [mailto:[email protected]] Sent: Monday, February 08, 2016 6:28 PM To: Swinson, Ken; Lioy, Marcello; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Cc: [email protected]<mailto:[email protected]>; Dominique Chanet (QEO LLC); Josh Spain; [email protected]<mailto:[email protected]> Subject: RE: [Allseen-core] Security 2.0 status, and proposals for improvements Thanks for the feedback Ken! Some thoughts below: From: Swinson, Ken [mailto:[email protected]] Sent: Monday, February 8, 2016 3:04 PM To: Daniel Mihai <[email protected]<mailto:[email protected]>>; Lioy, Marcello <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Cc: [email protected]<mailto:[email protected]>; Dominique Chanet (QEO LLC) <[email protected]<mailto:[email protected]>>; Josh Spain <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> Subject: RE: [Allseen-core] Security 2.0 status, and proposals for improvements Dan, Thanks for the list, Has device certificates dropped from the active discussions? I suspect code changes would be desirable regardless of the decision to move forward with a single root CA or multiple root CAs selected by individual OEMs. [DM] This one is currently not on my radar at all. Please bring it up in the Core WG meetings if it’s important. See inline for other comments. Ken From: Daniel Mihai [mailto:[email protected]] Sent: Friday, February 05, 2016 2:11 PM To: Lioy, Marcello; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Cc: [email protected]<mailto:[email protected]>; Dominique Chanet (QEO LLC); Swinson, Ken; Josh Spain; [email protected]<mailto:[email protected]> Subject: RE: [Allseen-core] Security 2.0 status, and proposals for improvements This is the current high-level wish list of improvements that we are investigating at MSFT. It is still unclear how many and when we’ll be able to implement them. 1. Add new Manifest format, more granular, as I proposed in the attached email. - Also consider removing the support for the problematic 15.09 Manifest format [kens] I need clarification on what you are proposing. Is it as Phil summarized in the e-mail you attached? In which case then more granular refers to segmenting the manifest? The 15.09 manifest should not be supported if it is replaced. [DM] We will share our detailed proposal as soon as possible. We are currently reviewing one such proposal in our team – stay tuned. 2. Add XML-based public methods for Policy, Manifest, Manifest Template. - Consider removing the current public methods, if they are superseded by the new methods [kens] I agree with removing superseded methods that would fall under the developer preview for sec 2 3. Add StartManagement + EndManagement methods, called by a Security Manager to notify the target app that its Security settings are about to change. [kens] I’ll reply to your later email on the topic. 4. Add public C APIs corresponding to the most useful public C++ methods. 5. Significant changes to the implementation of the Key Store – to address ASACORE-2661, ASACORE-2664, and other shortcomings. 6. Make it easier to share a single Key Store between two processes running on a single machine. [kens] This should include making it easy for a security manager to determine that the key store is shared so that it can construct policies and manifests. [DM] Agreed that would be a worthy goal. Let’s see how close we can get to that goal in 16.04. We’ll provide our detailed proposal as soon as we can. 7. Add a new SPEKE auth mechanism – similar but better than the current PSK. 8. Introduce the concept of “Recommended Security Level”. For example: - Manufacturer of an “org.Contoso.GunSafe” device might want to recommend that interface as accessible just to “Privileged” users - Manufacturer of an “org.Contoso.WirelessSpeaker” device might want to recommend that interface as “NonPrivileged” - Manufacturer of an “org.Contoso.LightSwitch” device might want to recommend that interface as “Unauthenticated” [kens] I like it. Consider mapping the recommendation to the peer types for consistency. [DM] Peer types would definitely be used by the Security Manager behind the scenes, to implement the Security Levels mentioned above: “Unauthenticated” maps well to PEER_ALL. I look at a particular implementation of Security Manager as having more flexibility when it wants to implement “NonPrivileged” and/or “Privileged” Levels. For example, we’re currently still debating in our team if we want to use just PEER_FROM_CERTIFICATE_AUTHORITY, or just PEER_WITH_MEMBERSHIP, or a combination of these two, for our particular scenarios. Each of these choices seems to have advantages and disadvantages. 9. Investigate the numerous active JIRA tickets related to Security and fix those that the Core WG decides are important. If anyone has questions or other kind of feedback, please speak up. Dan -----Original Message----- From: Lioy, Marcello [mailto:[email protected]] Sent: Thursday, February 4, 2016 11:39 AM To: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Cc: Daniel Mihai <[email protected]<mailto:[email protected]>> Subject: RE: [Allseen-core] Security 2.0 status There are some changes being proposed, however, I think it is developer API changes rather than the interface definitions on the wire. I have CC'ed Dan Mihai who is driving the updates to Security 2.0. He can correct or elaborate as appropriate. -----Original Message----- From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of [email protected]<mailto:[email protected]> Sent: Monday, January 25, 2016 2:08 AM To: [email protected]<mailto:[email protected]> Subject: [Allseen-core] Security 2.0 status Hi everyone, Is it possible to release the latest 15.09(a)-related Security 2.0 HLD ? As both the https://na01.safelinks.protection.outlook.com/?url=allseenalliance.org&data=01%7c01%7cDaniel.Mihai%40microsoft.com%7c1761def47b9b40ff54da08d32d9adcb0%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=8t3KSB3ksxrk%2fFOPp7gcPWW%2btMdZsmovppbK0g3%2fwzQ%3d documentation and wiki seem to point to out-of-date documents. Also, is the production-grade 16.04 Security 2.0 roadmap decided upon (e.g. things like interface description servers and like) ? Thanks, Ondrej T _______________________________________________ Allseen-core mailing list [email protected]<mailto:[email protected]> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2flists.allseenalliance.org%2fmailman%2flistinfo%2fallseen-core&data=01%7c01%7cDaniel.Mihai%40microsoft.com%7c1761def47b9b40ff54da08d32d9adcb0%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=%2fZzxaUmnFC9opwKhE%2bnozXKB04TnGNL3Kxw%2bn3FtYtM%3d
_______________________________________________ Allseen-core mailing list [email protected] https://lists.allseenalliance.org/mailman/listinfo/allseen-core
