Steffen Peter, Oliver Stecklina, Peter Langend ö rfer

1. An Engineering Approach for Secure and SafeWireless Sensor and Actuator Networks for Industrial Automation Systems Steffen Peter, Oliver Stecklina, Peter Langendörfer

2. Outline • Motivation • Introduction development flow • System analysis • Mapping process • Conclusions

3. Realflex project (2008-2010) Water works Biogas facility Roboter cell large distance,public networks Standards, existent architecture Small latency, dependability wireless architecture for industrial automation

4. Waterworks scenario

5. Today’s way of handling security • Shield network and define that it is secure not realistic in wireless networks • Enable “sort of miracle” security layer mostly not right solution • Patch security where a hole is assumed often not efficient all threads considered? • Proper design of security solutions expensive and time-consuming

6. Proposed development flow

7. System Analysis • Break it down • Find atomic flows of information  Data flow graph with dependencies • Analyze each processing step separately • What are the requirements for this step? • Ignore dependencies at this stage • Resolve dependencies • Requirements resolve over data flow

8. Example • Control pumps based on measured flow and pressure values • Uplink • Sensors on the field PLC • Wireless connection to the Ethernet access point • Downlink • PLCpumps • Wireless connection to the Ethernet access point • High integrity requirement U p l i n k D o w n l i n k sensor AP pump AP PLC

9. Security properties • Concealment / Secrecy • Integrity • Availability • Authentication • Authorization • Accountability • Non-Repudiation Security requirementsvector

10. Security Metric An algorithm belongs to class c if it resists all attacks from attacker groups smaller than c.  Requirement Vector = <(0…3)7>

11. Proposed development flow

12. Mapping Process

13. What to do if drawer is empty? • Find a solution from scratch • State of the art • Good solution • Not efficient • Look in neighborhood • Find close solutions • Analyze & solve the differences

14. Waterworks Example • Security: • Strong integrity • Environment: • open field, short range wireless (802.15.4) • One message every 30 seconds • Dependability: • node life time min. one month • 400mJ/operation -Information integrity >99.9999%  1/1 million

15. Waterworks Example (2) • Assumed no direct solution found • Neighborhood: wired environment • Security requirements fulfilled by protected environment • Information integrity realized with CRC we have no protected environment, but CRC is fine adapt dependencies (information integrity solved) • How to realize protected environment • Mapping tells us AES OFB is solution (message integrity due to pair-wise shared keys)  Test against other requirements: too high energy consumption

16. Waterworks Example (3) • Problem message overhead • 16 bit message + 20 bit CRC encrypted with 128 bit AES • Solution: take one AES key for 3 messages • 40 bit ciphertext • Still security of 128 bit AES OFB • Information integrity as in wired environment • Dependency requirements fulfilled

17. Conclusions • Suitable security and safety needs consideration of • Environment • Dependability requirements • Security requirements • Huge complexity, expensive development flow • Proposed semi-formal engineering methodology is a first answer • Requirements and potential solutions are cataloged as result of a formal analysis process • Allows reproducible problems and reusability of answers • Mapping process as efficient way to integrate applications • Fuzzy requirements (environment) still biggest challenge for a full automatic integration process

18. Thank You Questions? peter@ihp-microelectronics.com