ucaiug opensg embeded systems security task force update
DESCRIPTION
UCAIug OpenSG Embeded Systems Security Task Force Update. Rohit Khera. 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. - PowerPoint PPT PresentationTRANSCRIPT
UCAIug OpenSG Embeded Systems Security Task Force
Update
Rohit Khera
HANSub-Station / Wide Area
Distribution Automation
AMI
DEVICE CATEGORIES
Secure Device Profile Components
SECURE DEVICE PROFILES FOR THE ELECTRIC INFRASTRUCTURE
AAA Infrastructure Key Management
Operating System
Cipher Stack Networking StackRequirements
Cipher Suites
Legend
In scope
Secure Transport Protocols
Cryptographic Requirements
Cost Based Factors
Requirements
High Level Interface Requirements
(eg., C/I/A reqs from NISTIR, AMI-Sec, DM-Sec etc.)
Device Management
Applications
CryptoAPIs
Hardware
GF Arithmetic
Cryptographic Operations
Cryptographic Primitives
Sid
e C
hann
el P
rote
ctio
ns
Create multiple secure profiles to address disparate device resource characteristics and communication infrastructures across multiple device categories – leverage existing standards / SDOs
AAA Protocols
Secure Key Gen./ Storage
Secure NVM / RAM
Crypto Acceleration / TRNG
Management Stack
MIB/ Sec Taxonomy
Config. Mgmt
Secure Updates
Topic Primary Owner/s
Secondary Owner/s
Start Date / Status Est. Completion
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
JBLWNU
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
January 31st, 2012
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.
Topic Primary Owner/s
Secondary Owner/s
Start Date / Status Est. Completion
Authorization/Role/Access control/Coarse grain policy
SBA OPEN 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,
Approaches for Integrating Secure HardwareMonolithic / Single Die
Example – Smart Cards (Cryptographic / Security boundary encompasses the entire system)
Advantages – Entire system contained within boundaryDis-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?
Secure
Co-processor
General Purpose Processor
BusSecure
Co-processor
General Purpose Processor
Bus
A B
Encrypted (Security Association)
Typical Secure MCU Layout
Software Performance on Common Application MCUs
(Source: Mocana Corp.)
Protocol Overhead header type header size auth ICV size encryption max encryption
trailerTOTAL
AH 12 12 24
ESP 8 8 9 25
ESP-AES 8 16 17 41
ESP w/authentication
8 12 8 9 37
ESP-AES w/authentication
8 16 17 53
ESP_NULL 8 12 2 22
IP (tunnel) 20 20
IPSec Packet Overhead (Source: Mocana Corp.)
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)
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 SecurityDFA = Differential Fault AnalysisSPA = Simple Power AnalysisDPA = Differential Power AnalysisDEMA = Differential Electro-Magnetic radiation AnalysisCommon Criteria, Protection Profiles, Vulnerability Assessment Activities, Side Channel AttacksElectro Static Discharge (ESD) protectionSecurity 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 ICDurability (data retention): At least 15-20 yearsAnti-tearing reading/writing mechanismsThe memory shall support a minimum of 500K read/write cycles without failure or performance degradation.UNIQUE IC SERIAL NUMBERUnique 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
Draft Requirements – Secure MCUs
Random Number Generator – Schematic View
digitisedanalog signal(das-random numbers)
internal r.n.
algorithmicpostprocessing
(optional)
noisesource
analog digital
external r.n.
External Interface
buffer
(optional)
Ref: Werner Schindler1, Wolfgang Killmann2
Evaluation Criteria for True (Physical) Random Number Generators Used in Cryptographic Applications1 Bundesamt für Sicherheit in der Informationstechnik (BSI) Bonn, Germany2 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 Protocols2)Initialization Vectors3)Seeds for Deterministic Random Number GeneratorsCLASS P2 Applications (Highly sensitive)1)Signing Key Pairs2)DSS Signature Generation3)Random Padding Bits
FIPS 140 -2 , NIST SP 800-90 for deterministic random number generation
TRNG Testingtest aim
shall detect a total breakdown of the noise source tot-test
shall ensure the functionality of the TRNG on startup
startup test
shall detectdeterioration of the quality of randomnumbers
online test
Ref: Werner Schindler1, Wolfgang Killmann2
Evaluation Criteria for True (Physical) Random Number Generators Used in Cryptographic Applications1 Bundesamt für Sicherheit in der Informationstechnik (BSI) Bonn, Germany2 T-Systems ISS GmbH Bonn, Germany
Desirable to detect catastrophic failures in DAS randoms, viz., when entropy/bit = 0, need to model underlying statistical distribution of variable
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 InterfacesTiming, 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 ConservationAll 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
16
Certification Cont’Standardsd
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 customers5) 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 reviews4) Vendor shall document protections undertaken to secure communication protocols5) Vendor system shall support commercial anti-virus or alternative mitigations6) Vendor shall provide evidence that its systems are checked to be free of malicious
code prior to shipping to the customer7) Vendor should define and document a software patching policy8) Vendor should provide access to all software patches and service packs relevant to its
systems9) Vendor shall provide tools to audit the security patch status of its systems10) Vendor shall provide password management functions for its systems11) Vendor shall provide functions to rotate, protect & encrypt passwords12) Vendor’s systems shall provide role based access and support for centralized access
and policy management13) 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
Is There Sufficient Granularity in Certification Standards to Address Embedded Security (Eg IEC 62442-2-4)?
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