UCAIug OpenSG Embeded Systems Security Task Force Update Rohit Khera Secure Device Profile Components Create multiple secure profiles to address disparate device resource characteristics.
Download ReportTranscript UCAIug OpenSG Embeded Systems Security Task Force Update Rohit Khera Secure Device Profile Components Create multiple secure profiles to address disparate device resource characteristics.
UCAIug OpenSG Embeded Systems Security Task Force Update Rohit Khera Secure Device Profile Components Create multiple secure profiles to address disparate device resource characteristics and communication infrastructures across multiple device categories – leverage existing standards / SDOs DEVICE CATEGORIES Sub-Station / Wide Area HAN AAA Infrastructure Distribution Automation AMI Key Management Device Management SECURE DEVICE PROFILES FOR THE ELECTRIC INFRASTRUCTURE Applications Cipher Stack Cryptographic Requirements Cost Based Factors Side Channel Protections Requirements Cryptographic Primitives Cryptographic Operations In scope Management Stack AAA Protocols Config. Mgmt Secure Transport Protocols Cipher Suites Secure Updates MIB/ Sec Taxonomy CryptoAPIs GF Arithmetic Secure Key Gen./ Storage Legend Networking Stack Operating System Secure NVM / RAM Hardware Crypto Acceleration / TRNG Requirements High Level Interface Requirements (eg., C/I/A reqs from NISTIR, AMI-Sec, DMSec etc.) Name Affiliation Email Short Marc Vauclair NXP [email protected] MVU René Struik Struik Security Consultancy [email protected] RST Shrinath Eswarahally Infineon [email protected] SES James Blaisdell Mocana [email protected] JBL Rohit Khera S&C Electric [email protected] RKH Chris Gorog Deloitte [email protected] CGO Wim Nuyts NXP [email protected] WNU Thierry Gouraud NXP [email protected] TGO Mike Ahmadi GraniteKey [email protected] MAH Sadu Bajekal IBM [email protected] SBA Tom Thomassen Symantec [email protected] TTO Daniel Thanos GE [email protected] DTH David Sequino GHS [email protected] DSE Chris Dunn Safenet [email protected] CDU Gib Sorebo SAIC [email protected] GSO Steve Dougherty IBM [email protected] SDO Bora Akyol PNL [email protected] BAK Topic Primary Owner/s Secondary Owner/s Start Date / Status Cryptographic Hardware and Hardware Security SES RST CGO MVU Underway (first draft submitted) All comments included those from Mike A. taken into account. Latest version available on shared drive. Action: request for a specialist review for the hardware security part. Random Number Generation JBL WNU RKH TGO Contribution from James sent and put on the shared drive. Temporarily Wim Nuyts assigned instead of Thierry Gouraud for primary ownership. Subject to change in January. Device Identity and Device Authentication MVU WNU MAH SBA SES TTO CGO Contribution a draft to be expected in January 2011 3rd week Ciphers (refer to NISTIR 7628 Crypto Section) RKH RST DTH Underway Move to device security, already agreed on how to proceed Secure protocols RKH JBL Draft completed and submitted for review by JBL Someone from NXP should join the Secondary owners for review Key Management CGO RST DSE SBA MVU CDU GSO This activity is put on hold waiting for finalization of the CSWG design principles working group on key management. Est. Completion January 31st, 2012 Topic Primary Owner/s Secondary Owner/s Start Date / Status Authorization/Role/Acc ess control/Coarse grain policy SBA OPEN OPEN Compliance and certification MAH MVU Ask Mike to prime the pump when the output from the CSWG TCC testing certification and compliance group is available Use cases SES MVU RKH use cases contributed by SES in draft circulated: request for reviews and more use cases SES will contribute additional uses cases Scope: embedded security use cases Device Mgmt BAK MVU SDO SBA Put on hold as well because we expected that someone from IBM would contribute but they indicated that don’t have the bandwitdh to participate actively Dec 14: Someone from IBM (colleague of SBA) may join. Device Robustness & Resilience DTH CGO Bora recommended the incorporation of that category: put it on hold for the time being, Est. Completion OPEN Approaches for Integrating Secure Hardware Monolithic / Single Die Example – Smart Cards (Cryptographic / Security boundary encompasses the entire system) Advantages – Entire system contained within boundary Dis-Advantages – Low word size (typically 16 bit) and clock rating Co - Processor Advantages – Augment security functions, secure key storage, acceleration, side channel protections etc. Dis-Advantages – Cleartext traverses bus to general purpose MCU? A B Secure Co-processor Secure Bus General Purpose Processor Co-processor Bus General Purpose Processor Encrypted (Security Association) Typical Secure MCU Layout Software Performance on Common Application MCUs (Source: Mocana Corp.) Protocol Overhead IPSec Packet Overhead (Source: Mocana Corp.) header type header size auth ICV size AH 12 12 ESP 8 8 9 25 ESP-AES 8 16 17 41 ESP w/authentication 8 8 9 37 ESP-AES w/authentication 8 16 17 53 ESP_NULL 8 2 22 IP (tunnel) 20 12 12 encryption max encryption trailer TOTAL 24 20 Side Channel Attacks • Multiple Attack Classes – Manipulating, Observing and Semi -Invasive attacks requiring different levels of development effort and resources • Eg. Differential Power Analysis – drawing statistical inferences around power analysis to guess successive bits in a key space by observing gate ‘transition count’ and ‘hamming weight’ leakage – mitigations include dual rail logic and randomization of gate switching • Eg. Timing. Mitigations – constant time algorithms • Also Semi Invasive attacks – such as spiking and glitching • Most Smart Card Chips with EAL 5+ level certifications provide countermeasures against known attacks (typically anywhere in the range of 40 – 55 countermeasures) Draft Requirements – Secure MCUs Accessible Memory Utility accessible memory shall be secure (factory lockable and Utility lockable), programmable and non-volatile during the production processes. IC Security Hardware and software (logical) tamper-resistance. Security/exception sensors such as voltage, frequency, and temperature. A design to prevent unauthorized access via hardware and software security features. Auto detection if tamper attempt is made. Attack Security DFA = Differential Fault Analysis SPA = Simple Power Analysis DPA = Differential Power Analysis DEMA = Differential Electro-Magnetic radiation Analysis Common Criteria, Protection Profiles, Vulnerability Assessment Activities, Side Channel Attacks Electro Static Discharge (ESD) protection Security policy complies with the Common Criteria EAL4+ (ISO/IEC objectives and requirements in a document specified by ISO/IEC 27002. The IC Memory Management shall have: Secure EEPROM/Flash on the same IC Durability (data retention): At least 15-20 years Anti-tearing reading/writing mechanisms The memory shall support a minimum of 500K read/write cycles without failure or performance degradation. UNIQUE IC SERIAL NUMBER Unique IC shall be obtainable by reading the Chip UID Unique serial number shall be stored internally in the IC and not printed on the surface of the IC or IC package Random Number Generator – Schematic View External Interface analog digital noise source algorithmic postprocessing (optional) digitised analog signal (das-random numbers) buffer (optional) internal r.n. external r.n. Ref: Werner Schindler1, Wolfgang Killmann2 Evaluation Criteria for True (Physical) Random Number Generators Used in Cryptographic Applications 1 Bundesamt für Sicherheit in der Informationstechnik (BSI) Bonn, Germany 2 T-Systems ISS GmbH Bonn, Germany Random Number Generation • Proposal to use German Federal Office for Information Security(BSI) functionality Classes for physical random number generators (AIS 31) CLASS P1 Applications (Less sensitive) 1) Challenge Response Protocols 2) Initialization Vectors 3) Seeds for Deterministic Random Number Generators CLASS P2 Applications (Highly sensitive) 1) Signing Key Pairs 2) DSS Signature Generation 3) Random Padding Bits FIPS 140 -2 , NIST SP 800-90 for deterministic random number generation TRNG Testing test aim tot-test shall detect a total breakdown of the noise source startup test shall ensure the functionality of the TRNG on startup online test shall detect deterioration of the quality of random numbers Desirable to detect catastrophic failures in DAS randoms, viz., when entropy/bit = 0, need to model underlying statistical distribution of variable Ref: Werner Schindler1, Wolfgang Killmann2 Evaluation Criteria for True (Physical) Random Number Generators Used in Cryptographic Applications 1 Bundesamt für Sicherheit in der Informationstechnik (BSI) Bonn, Germany 2 T-Systems ISS GmbH Bonn, Germany Device Robustness & Resilience (Outline & Topics) Architectural principles for both hardware and software components; protection and detection of physical device boundaries; defense against denial of service attacks; operational continuity and protocol implementation guidelines • Hardware Principles watchdog timers, interrupt coalescing, virtual memory/memory protection support, thread priorities • Network Communication Interfaces Timing, voltage, temperature, Network interface robustness against: • • DoS conditions (e.g. network flooding) Well-known packet vulnerabilities (e.g. LAND ATTACK) Malformed/Fuzzed Packets from L1 to L7. • • • CPU Resource Conservation All mission critical devices require conservative CPU and memory resource in order to remain resilient against many types of faults and resource exhausting attack Memory and Storage Conservation Battery and Power Conservation • Continuing to Operate Under Adverse Conditions margins Is There Sufficient Granularity in Certification Standards to Certification Cont’Standardsd Address Embedded Security (Eg IEC 62442-2-4)? Select Security Validation & Certification Requirements (Taken from Proposed Certification Standard IEC 62443-2-4). Process Area Certification Requirements Vendor Organizational Processes 1) Vendor should have policies & procedures to support a utility’s security incident response team 2) Vendor should create security policies & standards related to internal processes & enforce these within its organization & subcontractors 3) Vendor should conduct background checks on personnel involved with security development 4) Vendor shall designate a security point of contact for utility customers 5) Vendor shall participate in at least one industry security standards group Vendor Control System Capabilities 1) Vendor should document security requirements around OS hardening, data flows of sensitive information and data retention capabilities 2) Vendor shall document security testing procedures for integrated third party software 3) Vendor shall conduct & document 3rd party security & architecture reviews 4) Vendor shall document protections undertaken to secure communication protocols 5) Vendor system shall support commercial anti-virus or alternative mitigations 6) Vendor shall provide evidence that its systems are checked to be free of malicious code prior to shipping to the customer 7) Vendor should define and document a software patching policy 8) Vendor should provide access to all software patches and service packs relevant to its systems 9) Vendor shall provide tools to audit the security patch status of its systems 10) Vendor shall provide password management functions for its systems 11) Vendor shall provide functions to rotate, protect & encrypt passwords 12) Vendor’s systems shall provide role based access and support for centralized access and policy management 13) Vendor shall be able to generate logs of individual account access activity for a minimum of 90 days 14) Vendor systems shall support utility backup and restore functions 16 Intellectual Property • TF will adopt IETF IPR model • IETF IP position stated in RFC 3979 ‘Intellectual Property Rights in IETF Technology’ • Task force leadership disclaims responsibility for assessments of the intellectual property status of contributions to this effort • Expected that contributions accompanied by IP disclosures explicitly stating whether or not contributed materials contain IP • Contributions without accompanying IP disclosures will be assumed IP encumbered • All contributions will be voted into the spec., IP encumbered items will be flagged as such during time of vote • If IP encumbered technology is voted into spec, its expected that owner provide technology under RAND licensing terms