1. Joint Session SG Security / OpenHAN SG Security WG Chair: Darren Reece Highfill darren@utilisec.org

2. Agenda ObjectivesObjectives –Is the document ready for release? Have we adequately addressed security for the current industry environment?Have we adequately addressed security for the current industry environment? Do any remaining security issues need to be addressed now, or do they become future enhancements?Do any remaining security issues need to be addressed now, or do they become future enhancements? –What are the remaining security issues? Issues for joint discussionIssues for joint discussion –Threat Model –Certificates and Root CA’s

3. Threat Model Proposal (Robert Cragie): Compliment impact assessment in HAN SRS Appendix with a threat modelProposal (Robert Cragie): Compliment impact assessment in HAN SRS Appendix with a threat model –The type of devices which may be potential targets for compromise –The environment for each device –Ingress points on a device –Potential adversaries –Potential attacks –Motivations for an attack –Manifestation of an attack on a device –Scaling of attacks (attacking many devices using the same fundamental attack, e.g. drive-by attack)

4. Augmented Impact Assessment Proposal (Robert Cragie): Extend the existing impact assessment in the HAN SRS AppendixProposal (Robert Cragie): Extend the existing impact assessment in the HAN SRS Appendix –Impact of an attack on a device itself (in what way the device becomes compromised) –Impact of an attack on a device's environment (in what way the device's cooperating devices becomes compromised) –Impact of an attack on the system (in what way the system becomes compromised) –Severity of resulting compromise due to an attack –Operational mitigation based on one or more compromised devices

5. Certificates and Root Certificate Authorities Proposal (GraniteKey): 1.A mechanism to set the root(s) of trust for mutual authentication is required – and must be clearly defined. (e.g. root certificate, or root key). The requirements are different for the Meter side vs. the HAN (e.g. consumer) device side. 2.Any entity issuing identity must clearly document their policy for issuing identity and how the root is used to provide the credentials (e.g. in PKI, this is referred to as a CPS – Certificate Practices Statement).

6. Certificates and Root Certificate Authorities Proposal (GraniteKey): 3.A trust chain for delegation should be allowed: a)It should contain no more than 1 level (e.g. the root of trust can issue a “sub-root certificate”) which can be used to conduct the authentication. This “sub-root” may NOT issue another “sub-root” b)“sub-roots” do not need to be secured and are generally presented during the authentication sequence. (e.g. if a sub-root was used to issue identity to a device, that sub-root credential can be sent to the remote entity during the authentication sequence)

7. Certificates and Root Certificate Authorities Proposal (GraniteKey): 4.Meter (for authenticating HAN devices) a)The Utility (or meter manufacturer) identifies which vendors are authorized to connect to the HAN via the ESI and thus which roots will be provided in the meter. b)The root(s) of trust are to be embedded in the meter firmware as a table, and should be protected using the same mechanism that is used to ensure firmware integrity. c)Optional: The table can be updated by using the same mechanism to securely update the firmware

8. Certificates and Root Certificate Authorities Proposal (GraniteKey): 5.HAN device (for authenticating meter) a)The consumer device manufacturer identifies which meters or utilities are valid to connect to and thus which roots will be provided in the device. b)The root(s) of trust are embedded in the device firmware. The robustness and flexibility (for updates) is not as critical as the meters, but should be at the same level of security as the device firmware. c)The root(s) of trust can be set during provisioning / shipment, but must be at the same level of security/integrity as the firmware. d)Optional: The ability to update these roots of trust are to be defined by the vendors, but must be at the same (or higher) level of security as any firmware updates. e)The root(s) of trust cannot be changed by the user