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