Joint Session SG Security / OpenHAN SG Security WG Chair: Darren Reece Highfill

Slides:



Advertisements
Similar presentations
RPKI Standards Activity Geoff Huston APNIC February 2010.
Advertisements

Open Interconnect Consortium Introduction for oneM2M
David Grochocki et al.  Lures Potential attackers  Smartmeters do two way communication  Millions of Meters has to be replaced  Serious damages just.
Policy interoperability in electronic signatures Andreas Mitrakas EESSI International event, Rome, 7 April 2003.
Authenticated Validity for M2M devices IEEE Presentation Submission Template (Rev. 9) Document Number: IEEE S802.16p-11/0251 Date Submitted:
A responsibility based model EDG CA Managers Meeting June 13, 2003.
ESign-Online Digital Signature Service February 2015 Controller of Certifying Authorities Department of Electronics and Information Technology Ministry.
PKI in US Higher Education TAGPMA Meeting, March 2006 Rio De Janeiro, Brazil.
DGC Paris Community Authorization Service (CAS) and EDG Presentation by the Globus CAS team & Peter Kunszt, WP2.
COEN 351: E-Commerce Security Public Key Infrastructure Assessment and Accreditation.
Advanced Metering Infrastructure AMI Security Roadmap April 13, 2007.
Using Cryptographic ICs For Security and Product Management Misconceptions about security Network and system security Key Management The Business of Security.
An Operational Perspective on BGP Security Geoff Huston GROW WG IETF 63 August 2005.
Presented by Xiaoping Yu Cryptography and PKI Cosc 513 Operating System Presentation Presented to Dr. Mort Anvari.
Asper School of Business University of Manitoba Systems Analysis & Design Instructor: Bob Travica System interfaces Updated: November 2014.
1 CS 194: Distributed Systems Security Scott Shenker and Ion Stoica Computer Science Division Department of Electrical Engineering and Computer Sciences.
CAMP - June 4-6, Copyright Statement Copyright Robert J. Brentrup and Mark J. Franklin This work is the intellectual property of the authors.
Wolfgang Schneider NSI: A Client-Server-Model for PKI Services.
NUAGA May 22,  IT Specialist, Utah Department of Technology Services (DTS)  Assigned to Department of Alcoholic Beverage Control  PCI Professional.
Best Practices in Deploying a PKI Solution BIEN Nguyen Thanh Product Consultant – M.Tech Vietnam
Trust Anchor Management Problem Statement 69 th IETF Trust Anchor Management BOF Carl Wallace.
Introduction to Secure Messaging The Open Group Messaging Forum April 30, 2003.
NENA Development Conference | October 2014 | Orlando, Florida Security Certificates Between i3 ESInet’s and FE’s Nate Wilcox Emergicom, LLC Brian Rosen.
DICOM Security Lawrence Tarbox, Ph.D. Chair, WG 14 Mallinckrodt Institute of Radiology Washington University in St. Louis School of Medicine.
General Key Management Guidance. Key Management Policy  Governs the lifecycle for the keying material  Hope to minimize additional required documentation.
HIT Standards Committee Privacy and Security Workgroup: Initial Reactions Dixie Baker, SAIC Steven Findlay, Consumers Union June 23, 2009.
Chapter 9: Using and Managing Keys Security+ Guide to Network Security Fundamentals Second Edition.
DOCUMENT #: GSC15-GTSC8-06 FOR: Presentation SOURCE: ATIS AGENDA ITEM: GTSC8; 4.2 CONTACT(S): Art Reilly ATIS Cybersecurity.
Proposal for device identification PAR. Scope Unique per-device identifiers (DevID) Method or methods for authenticating that device is bound to that.
Secure Credential Manager Claes Nilsson - Sony Ericsson
1 Smart Grid Cyber Security Annabelle Lee Senior Cyber Security Strategist Computer Security Division National Institute of Standards and Technology June.
HEPKI-PAG Policy Activities Group David L. Wasley University of California.
出處 :2010 2nd International Conference on Signal Processing Systems (ICSPS) 作者 :Zhidong Shen 、 Qiang Tong 演講者 : 碩研資管一甲 吳俊逸.
SOA-39: Securing Your SOA Francois Martel Principal Solution Engineer Mitigating Security Risks of a De-coupled Infrastructure.
PAWS: Security Considerations Yizhuang WU, Yang CUI PAWS WG
Security Many secure IT systems are like a house with a locked front door but with a side window open -somebody.
Enhanced Storage Architecture
Leveraging Campus Authentication for Grid Scalability Jim Jokl Marty Humphrey University of Virginia Internet2 Meeting April 2004.
CaGrid 2.0 Security Prototype 1. Goals Prototype some proposed security solutions – Ensure interoperability across programming models – Ensure interoperability.
Security fundamentals Topic 5 Using a Public Key Infrastructure.
Need for Security Control access to servicesControl access to services Ensure confidentialityEnsure confidentiality Guard against attacksGuard against.
Latest Strategies for IT Security Margaret Myers Principal Director, Deputy CIO United States Department of Defense North American Day 2006.
DICOM Security Andrei Leontiev, Dynamic Imaging Presentation prepared by: Lawrence Tarbox, Ph.D. Chair, WG 14 Mallinckrodt Institute of Radiology Washington.
SECURITY REQUIREMENTS AND MANAGEMENT: Presentation By: Guillermo Dijk.
Doc.: IEEE /0098r0 Submission July 2010 Alex Reznik, et. al. (InterDigital)Slide Security Procedures Notice: This document has been.
By Ramesh Mannava.  Overview  Introduction  10 secure software engineering topics  Agile development with security development activities  Conclusion.
Doc.: IEEE /1145r1 Submission August WG Slide 1 Mutual Authentication Date: Authors: Slide 1.
Project Information. Contact Information Project Being Developed.
DM Collaboration – OMA & BBF: Deployment Scenarios Group Name: WG5 - MAS Source: Tim Carey, ALU, Meeting Date:
1© Copyright 2012 EMC Corporation. All rights reserved. Next Generation Authentication Bring Your Own security impact Tim Dumas – Technology Consultant.
The Future Digital Identity Landscape in Europe Timothée Mangenot, chairman 14th of December, 2015 ACSIEL partners day.
Principles Identified - UK DfT -
Trust Anchor Management Problem Statement
Security Working Group
Global Standards Collaboration (GSC) GSC-15
S/MIME T ANANDHAN.
IEEE MEDIA INDEPENDENT HANDOVER DCN:
OpenID Enhanced Authentication Profile (EAP) Working Group
Discussion on the Scope of TR- Trust Management in oneM2M
Security Protection Goals
Security in ebXML Messaging
Securing the Internet of Things: Key Insights and Best Practices Across the Industry Theresa Bui Revon IoT Cloud Strategy.
Agenda retrospective - B. Aboba Lunch
AMI Security Roadmap April 13, 2007.
Web Information Systems Engineering (WISE)
Reinhard Scholl, GTSC-7 Chairman
ETSI Contribution to 3rd Meeting of EC Expert Group on RRS
draft-moran-suit-architecture-03
Presentation transcript:

Joint Session SG Security / OpenHAN SG Security WG Chair: Darren Reece Highfill

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

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)

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

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).

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)

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

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