1. Secure Proactive Recovery – a Hardware Based Mission Assurance Scheme 1 6 th International Conference on Information Warfare and Security, 2011

2. Outline Performance analysis Motivation Threat model System design Conclusion Structure 2

3. Motivation Mission assurance Goals – Survivability Security Fault tolerance Low cost (Time overhead) Adaptation and evolution – Feasibility study – Long running applications 3 Prevention  Detection  Recovery Hardware-based Smart defender

4. Outline Performance analysis Motivation Threat model System design Conclusion 4 Structure

5. Threat Model 5 Time diversity Spatial diversity Reactive recovery Proactive recovery Byzantine fault tolerance

6. The Quiet Invader Smart attacker – Make decisions to maximize the potential of achieving their objectives based on dynamic information Quiet invader – Camouflages to buy more time – Plan to attack mission during critical stage (Why?) – Example: Long running countdown for a space shuttle launch that runs for several hours 6

7. Outline Performance analysis Motivation Threat model System design Conclusion 7 Structure

8. Coordinator Replica 1 Replica 2 Replica 3 Replica n Workload H H C C H H C C H H C C H H C C Replica 3 R R R R R R R R Periodic checkpoint Hardware Signature Periodic checkpoint Hardware Signature Periodic checkpoint Hardware Signature Periodic checkpoint Hardware Signature Periodic checkpoint Hardware Signature 8

9. Hardware Signature Generation 9 System reg IDS

10. Outline Performance analysis Motivation Threat model System design Conclusion 10 Structure

11. Performance Analysis Cases – Case 1: Systems with no checkpointing – Case 2: Systems with checkpointing, no failures/attacks – Case 3: Systems with checkpointing, failures/attacks Workload – Java SciMark 2.0 benchmark workloads: FFT, SOR, Sparse, LU Multi-step simulation based evaluation approach [ Reference: Mehresh, R., Upadhyaya, S. and Kwiat, K. (2010) “A Multi-Step Simulation Approach Toward Fault Tolerant system Evaluation”, Third International Workshop on Dependable Network Computing and Mobile Systems, October] 11

12. Results 12

13. Results Table 1: Execution Times (in hours) for the Scimark workloads across three cases Table : Execution times (in hours) for the Scimark workloads for the three cases 13

14. Results 14

15. Results 15

16. Results 16 Table : Approximate optimal checkpoint interval values and their corresponding workload execution times for LU (Case 3) at different values of M

17. Outline Performance analysis Motivation Threat model System design Conclusion 17 Structure

18. Conclusion Low cost solution to secure proactive recovery Mission survivability Utilized redundant hardware Small overhead in absence of failures – Effective preventive measure Future work – To evaluate this scheme for a distributed system 18

19. Thank You !! 19

20. DFT Design for test – Process that incorporates rules and techniques in product design to make testing easier. – Testing aspects Control Observation IEEE Std 1149.1 – Allows test instructions and data to be serially loaded into a device – Enables subsequent test results to be serially read out. [Source: IEEE Std 1149.1 (JTAG) Testability Primer A technical presentation on Design-for-Test centered on JTAG and Boundary Scan]IEEE Std 1149.1 (JTAG) Testability Primer 20

21. Boundary Scan Boundary scan is a special type of scan path with a register added at every I/O pin on a device Hardware signature of a replica can be stored in the flip flops of the boundary scan chain around a processor Our simulation centered around a boundary scan inserted DLX processor 21

22. DLX RISC (Reduced instruction set computing)processor architecture designed cleaned up and simplified MIPS processor, with a simple 32-bit load/store architecture Verilog code for the boundary scan inserted DLX processor is elaborated in cadence RTL compiler 22

23. Hardware Signature Loading signature into scan cells – We inserted a multiplexer before each cell, which has one of the inputs as test data input (TDI) and the other from the 32 bit signature vector. – Depending on the select line either the test data or the signature is latched into the flip flops of the scan cells. – To read signature out we have to serially shift the bits from the flip flops onto the output (IEEE 1149.1) 23

24. Survivability Mission: – A set of a very high level requirements or goals. – Not limited to military settings Survivability – Capability of a system to fulfill its mission in a timely manner in presence of attacks, failures, or accidents. – Reaction and recovery must be successful, whether the cause is ever determined or not. Reference : Ellison, R.J.; Fisher, D.A.; Linger, R.C.; Lipson, H.F.; Longstaff, T.A.; Mead, N.R.;, "Survivability: protecting your critical systems," Internet Computing, IEEE, vol.3, no.6, pp.55-63, Nov/Dec 1999 24

25. Byzantine Fault-tolerance Byzantine fault : An arbitrary fault that occurs during the execution of an algorithm by a distributed system – Omission failures e.g., crash failures, failing to receive a request – Commission failures e.g., processing a request incorrectly Classical solutions: n > 3t – Where, n is the total number of processes in the system – t is the number of faulty processes Our case – Centralized system – Majority vote: n>2t 25

26. TPM Trusted Platform Module – Secure cryptoprocessor that can store cryptographic keys that protect information – Sealed storage, Remote Attestation Privacy issues Feasibility study Can use alternatives such as active attestation by Nexus 26