Joint WG4 / ISA100 Session: ISA 100.11a Security Review

1
Joint WG4 / ISA100 SessionISA 100.11a Security
Review

• Summary of Initial Draft and recent additions /
  enhancements

2

• Jeff Potter Security and IT Integration Manager
• Emerson Process Management Rosemount
• ISA100.11a Security Task Group Chair
• Denis Foo Kune Research Scientist
• Honeywell Labs - Wireless and Embedded Technology
• ISA100.11a Security Task Group Editor

2
3
What is ISA100?

• Family of standards designed from ground up for
  many industrial wireless applications

ISA100 Timeline
Currently Developing
To Develop
Future
Emerging Apps
Process Apps (ISA100.11a)
Discrete Apps Long Distance Apps Location
Tracking Industrial Facility Apps
ISA100 Family of Standards One-Stop
Standardization Designed to Accommodate all Your
Plant Needs
3
4
Alerting and Monitoring are Overwhelming
Candidates for Wireless Systems
Source ISA100 / Control Magazine Survey
4
5
Reliability Security are Critical Factors
Reliability Security Important Topics 66
Data Reliability will affect use of wireless 54
Security will most influence decision
Source ISA100 / Control Magazine Survey
5
6
What is the ISA100.11a Standard?
Working Group Scope

• Define all specifications including security and
  management for wireless devices serving
  application classes 1 through 5 for fixed,
  portable and moving devices.
• Application focus will address performance needs
  for periodic monitoring and process control where
  latencies on the order of 100 ms can be tolerated
  with optional behavior for shorter latency.

An Industrial Automation Standard for Process
Plants
6
7
ISA100.11a Process Focus

• Chemical / Petrochemical direct target based on
  early user involvement
• Fresh / Waste Water recent interest, likely
  applications
• Pharmaceutical some interest but some
  characteristics may not match up
• Others? architecture supports but needs to map
  to existing performance expectations for .11a
• Throughput sample intervals at seconds
• Security off-the-shelf, best practice, AES
  encryption
• Latency 100 ms range
• Reliability 99.9 but trades off latency and
  throughput
• Range about 50m but trades off reliability
• Expanse extensible to a target of 10,000 nodes
  over square mile

An Industrial Automation Standard for Process
Plants
7
8
Key ISA100.11a Attributes

• Non-critical no lives threatened, little
  equipment consequence
• Monitor, alert, control low consequence if
  communication interrupted
• Low Data Rate no video, vibration limited
• Mobility fixed, portable, moving but slowly,
  infrequently
• Very low power 2-5 year battery life on end
  devices
• Latency about 100 ms
• Coexistence with most other standard and
  non-standard devices
• Interoperability with ISA100 standard devices

A Standard for Wireless Field Devices in Scalable
Plant Wide Systems
8
9
ISA100.11a Scope for Release 1

• Provide simple, flexible, and scaleable security
  addressing major industrial threats leveraging
  802.15.4-2006 security
• Security is a major design facet of ISA100.11a
• Includes total life cycle such as configuration,
  operation, maintenance, etc
• Security is considered throughout the whole
  system not just at the Phy layer or MAC sub-layer
• Leveraging security aspects of the IEEE
  802.15.4-2006 standard allows for reduced costs,
  quicker implementations, and a broad consensus of
  security experts

A Standard that is Very Secure!
9
10
ISA100.11a Security What it isnt

• A transmission standard
• Does not deal with data-at-rest
• Does not deal with physical device security
• Does not address issues related to security
  gateway functions at the boundary between an
  ISA100.11a network and a foreign peer network.
• Does address security of ISA100.11a messaging
  that traverses a foreign sub-network.
• Only superficially discusses recommended
  practices in a non-prescriptive fashion (e.g.
  embedded notes)

10
11
Network overview
11
12
Security at DLL and Transport
12
13
Security in the ISA100.11a stack
13
14
Threat Model

• Passive Attacks
• Eavesdropping
• Signal Analysis
• Active Attacks
• Jamming
• Accidental or intentional
• Flooding
• Spoofing
• Substitution, insertion tampering
• Selective retransmission
• Attacks on devices
• Tampering of device logic
• Substitution
• Scavenging/Theft
• Exhaustion of device (Flash, batteryetc)
• Gateway is a juicy target
• Errors
• Hardware
• Software

14
15
TRD Overall Security Design Requirements

• It shall be easy to setup, commission and
  configure devices and networks.
• It shall be easy to manage security, including
  support for self-configuration of fully
  self-forming networks.
• Note Security perceived to be difficult will
  be turned off in most cases.
• It shall be easy to join a device to a network
  and, similarly, easy to revoke a device.
• It shall be easy to replace a device, or
  move/reuse it elsewhere within the scope of a
  given user.
• Low overall implementation cost, support
  ease-of-use and ease-of-installation/configuration
  , and support system lifecycle management
  minimizing human intervention, scalability,
  survivability, mobility, and topology changes.

15
16
TRD Additional Security Design Goals

• The architecture shall support an optional
  security mode compatible with worldwide usage.
• The architecture shall be based on security
  building blocks that are well-understood and have
  been subjected to peer review.
• The architecture shall support trust lifecycle
  management, including device commissioning and
  de-commissioning.
• The design shall be adaptable to different trust
  models underlying network operations. This shall
  include, as a minimum, protection against
  outsiders. The design should allow varying
  granularity of protection provided.

16
17
TRD Additional Security Design Goals

• The architecture shall support reconfiguration of
  security to account for changing security
  requirements and policies.
• The architecture shall support modular and
  replaceable security algorithms to facilitate
  future technology upgrades,
• The architecture shall support an optional mode
  where security is active out-of-the-box.
• The design shall support monitoring, auditing,
  and logging of security-related events.

17
18
TRD Additional Requirements

• MAC security can not be disabled in a operational
  secure system.
• Per message integrity combined with per message
  source authentication.
• Receiver must be able to detect that a message
  receipt is significantly delayed from when it was
  sent.
• Receiver must be able to detect loss, duplication
  or reordering of a sequence of messages relative
  to that which was sent.

18
19
TRD DLL and Transport Security

• Secured subnet communication assurances based on
  data link layer enforcement
• Devices can defend against external attack, but
  the complete subnet is vulnerable to compromise
  should any device of the subnet be compromised.
• Secured application communication assurances on a
  per application basis (based on transport layer
  enforcement and optional application specific
  configurations)
• Security is compartmentalized as tightly as
  communications relationships permit to maximally
  protect high-value assets, thus ensuring that
  compromise of a small percentage of devices does
  not render the rest of the security ineffectual.

19
20
TRD Security Management

• It shall be possible to support centralized trust
  management while not precluding decentralized
  trust management.
• It shall be possible for a trust manager to
  provide local and remote key escrow.
• It shall be possible to enforce role-based access
  control (RBAC).
• Note RBAC support is simplified if it includes
  the ability to generate RBAC constraints
  automatically from plant configuration databases
  (where available), based on device classes and
  operational interaction relationships of devices.
• Support for completely distributed trust
  management as a vendor option.

20
21
Key Aspects of ISA100.11a security

• Centralized security manager
• All security processing within ISA100.11a stack
• Hop by hop at DataLink and End-to-end at
  Transport
• PDU processing derived from 802.15.4
• Uses of time in the cryptographic calculations,
  to guarantee freshness
• Application level protection of command frames
  including Commissioning, Join, Session
  establishment and Key update
• Security is on be default, with a no-security
  option
• ISA100.11a security defines join process, session
  establishment and key updates
• Join process, Symmetric and Asymmetric methods
• Role-based access to functions
• E.g. security manager is the only one allowed to
  update keys

22
Technical Overview

• All security processing within ISA100.11a stack
• Hop by hop protection at the Data Link Layer
• End to end sessions at the Transport Layer
• Application level protection of command frames
  including
• Commissioning
• Join
• Session establishment
• Key updates

23
ISA100.11a keys and associated lifetimes
24
Key Policy

• Key type 4 bits
• Global, Master, DLL, Session, Join
• Key usage 4 bits
• Key start time (in seconds) 32 bits
• Key end time delta (in seconds) 24 bits
• Key hard lifetime start time end time delta
• Key soft lifetime 50 of hard lifetime
• Reserved policy 8 bits

25
Crypto Primitives for Security

• Block cipher AES (FIPS 197)
• Mode of Operation CCM (from 802.15.42006)
• Counter mode with CBC MAC
• Nonce non-repeating number
• Hash function Matias-Meyer-Oseas
• Keyed hash function HMAC (FIPS 198)
• Random number generator
• Good entropy source if present
• May be properly seeded PRNG compliant with ANSI
  X9.82 or FIPS 186-3
• Optional ECC (from ANSI X9.63-2001)

25
26
Frame Security Services

• Source authentication
• Integrity during transit
• Encryption
• Replay protection
• Timeliness

27
Frame Security

• Authentication processing always on
• At least 32 bits
• If no security properties desired, use global key
• Use of TAI time in the crypto calculations
• Accurate to the second
• Allows 1024 frames per second
• Key Index for transition during key updates

27
28
Nonce Construction

• EUI-64, 64 bits
• TAI time (up to 1 second), 22 bits
• counters 0-1023 for each second, 10 bits
• Configuration, 8 bits
• Total 104 bits, consistent with CCM

28
29
Importance of Nonces for AES-CCM
29
30
Transport Security

• Secure session defined by end points
• End points are applications within a node
• The source and destination includes the UDP port
  number
• Possibility of multiple sessions between a node
  pair. Flexible.
• Independent key policies for each session
• Key policies cannot be less than global policy
• Reuse DLL security frame format and frame
  processing steps
• Receiver must reconstruct time of packet built at
  sender
• The transport header includes the information
  typically resident in the DLL headers
• Security control 1 octet
• Key index 1 octet
• Time and counter 6 and 10 bits respectively
• Receiver uses its own notion of time to
  reconstruct the remaining 16 bits of time
• 64 second window at most from generation to
  verification

30
31
Device Roles

• Role
• Collection of functions
• Logical Roles used in security
• Security Manager
• System Manager
• Non routing device
• Only the security manager can talk to the
  security management object of a device
• A device can have more than one role
• Represented by a bitmap

Role ID (16 bits)
-----------------------------------------------
System manager 0b0000000000000001
0x0001 Security manager 0b0000000000000010
0x0002 Gateway 0b0000000000000100
0x0004 Backbone router
0b0000000000001000 0x0008 System time source
0b0000000000010000 0x0010 Provisioning
0b0000000000100000 0x0020 Non-routing device
000000000001000000 0x0040 Field router
0b0000000010000000 0x0080 Field device
0b0000000100000000 0x0100 Infrastructure
device 0b0000001000000000 0x0200
31
32
Join Process

• Start conditions
• Symmetric Keys
• A 128-bit join key.
• The EUI-64 of security manager that generated the
  join key.
• Public Keys
• Certificate signed by a Certificate Authority
  trusted by the target ISA100.11a network
• No Security
• The well known, published non-secret 128 bit key
  common to all ISA100.11a networks
• Desired end state
• Shared long-term key between new node and the
  security manager
• New node has the required cryptographic and
  non-cryptographic materials at the DLL to talk to
  its direct neighbors
• The new node has a session with the system
  manager
• Properties
• Protection against replay attacks on join packets
  and aliveness.
• Authenticity.
• Secrecy of the transported keys.

33
Join Process Using Symmetric Keys
33
34
Join Process Using Symmetric Keys
34
35
Public Key - Key Agreement
36
Session Establishment/Key Updates

• Start conditions
• Nodes share a key with the security manager
• Session establishment
• A node requested a session
• The system manager established a session between
  two other nodes
• Key update
• The expiration time (within a preset delta) of a
  key was reached
• A node in a unicast session requested the key to
  be updated
• A node in a multicast/broadcast group left
• The security manager received a command to update
  a key
• Desired end state
• New key is securely deployed to all the nodes in
  a session
• Policies accompanying the key, such as lifetime,
  is properly received
• Properties of the key
• unknown to nodes outside of the session
• guaranteed to be from a known verifiable source
• guaranteed to be fresh
• received in a timely manner

37
Session Establishment / Key Update
37
38
Failure Recovery (Key Transport)
39
Device Phases
40
Provisioning

• The step to provide the required trust and
  network related information to join the target
  network
• Symmetric keys key EUI-64 of security manager
• Optional PKI certificates and whitelist
• Over the air possible disabled by default
  (profiles?)
• Only enabled manually by the end user
• Out of band keys
• Preinstalled keys
• Optional predeployed certificates with whitelists
• Only public identities are passed around

41
Provisioning Method
42
Provisioning Device Lifecycle
43
Provisioning State transition
44
The End
44
45
Extra slides
46
Architecture
Advertising Router
New Node
Security Manager
System Manager
46
47
Interface with DLL
47
48
Interface with Transport
Outgoing processing
Incoming check