Joint WG4 / ISA100 Session: ISA 100.11a Security Review

1. Joint WG4 / ISA100 Session:ISA 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? 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. Working Group Scope 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 isn’t… 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, battery…etc) • Gateway is a juicy target • Errors • Hardware • Software • Human 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.4:2006) • 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. 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

28. Importance of Nonces for AES-CCM* 29

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

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

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

32. Join Process Using Symmetric Keys 33

33. Join Process Using Symmetric Keys 34

34. Public Key - Key Agreement

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

36. Session Establishment / Key Update 37

37. Failure Recovery (Key Transport)

38. Device Phases

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

40. Provisioning – Method

41. Provisioning – Device Lifecycle

42. Provisioning – State transition

43. The End 44

44. Extra slides

45. Architecture SP100.11a New Node Advertising Router System Manager Security Manager 46

46. Interface with DLL 47

47. Interface with Transport Outgoing processing Incoming check