UCAIug OpenSG Embedded Systems Security Task Force Update

1. UCAIug OpenSG Embedded Systems Security Task Force Update Rohit Khera

2. Requirements Secure Transport Protocols High Level Interface Requirements (eg., C/I/A reqs from NISTIR, AMI-Sec, DM-Sec etc.) Cryptographic Requirements Cipher Suites Cost Based Factors 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 AAA Infrastructure Key Management Device Management SECURE DEVICE PROFILES FOR THE ELECTRIC INFRASTRUCTURE Applications Cipher Stack Networking Stack Management Stack Requirements AAA Protocols Config. Mgmt Cryptographic Primitives Secure Updates Side Channel Protections MIB/ Sec Taxonomy Cryptographic Operations CryptoAPIs GF Arithmetic Operating System Secure NVM / RAM Secure Key Gen./ Storage Hardware Legend Crypto Acceleration / TRNG In scope

6. Typical Secure MCU Layout

7. Secure Co-processor Secure Co-processor General Purpose Processor General Purpose Processor Bus Bus 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 Encrypted (Security Association)

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

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

10. US Dept. Of Commerce Export Controls Note: 5A002 does not control any of the following. However, these items are instead controlled under 5A992: (a) Smart cards and smart card `readers/writers' as follows: (1) A smart card or an electronically readable personal document ( e.g., token coin, e-passport) that meets any of the following: a. The cryptographic capability is restricted for use in equipment or systems excluded from 5A002 by Note 4 in Category 5—Part 2 or entries (b) to (i) of this Note, and cannot be reprogrammed for any other use; or b. Having all of the following: 1. It is specially designed and limited to allow protection of `personal data' stored within; 2. Has been, or can only be, personalized for public or commercial transactions or individual identification; and 3. Where the cryptographic capability is not user-accessible; Technical Note: `Personal data' includes any data specific to a particular person or entity, such as the amount of money stored and data necessary for authentication. (2) `Readers/writers' specially designed or modified, and limited, for items specified by (a)(1) of this Note; Technical Note: `Readers/writers' include equipment that communicates with smart cards or electronically readable documents through a network. 5A992 is controlled only for Anti-Terrorism (AT), no special license or exception required.

11. Software Performance on Common Application MCUs

12. Protocol Overhead (e.g. IPSec) • Packet Overhead

13. Ciphers – Focus Purely on Key Lengths • US -- NIST SP 800-56a, NIST 800-131

14. analog digital External Interface algorithmic postprocessing buffer (optional) (optional) external r.n. internal r.n. digitised analog signal (das-random numbers) Random Number Generator – Schematic View noise source 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

15. 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) • Challenge Response Protocols • Initialization Vectors • Seeds for Deterministic Random Number Generators CLASS P2 Applications (Highly sensitive) • Signing Key Pairs • DSS Signature Generation • Random Padding Bits • FIPS 140 -2 , NIST SP 800-90 for deterministic random number generation

16. 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 test aim TRNG Testing 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

17. 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 margins 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

18. Certification Cont’Standardsd Is There Sufficient Granularity in Certification Standards to Address Embedded Security (Eg IEC 62442-2-4)? Select Security Validation & Certification Requirements (Taken from Proposed Certification Standard IEC 62443-2-4).

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

20. Organization & Contact Info Co -Chair • Rohit Khera Sharepoint http://osgug.ucaiug.org/utilisec/embedded/default.aspx • Email Reflector – 'OPENSG-SGSEC-EMBSYSSEC-TF@SMARTGRIDLISTSERV.ORG' Bi-Weekly Co-ordination and status calls