Secure Proactive Recovery –  a Hardware Based Mission Assurance Scheme 6 th  International Conference on Information Warfa...
Outline Performance analysis Motivation Threat model System design Conclusion Structure
Motivation <ul><li>Mission assurance </li></ul><ul><li>Goals </li></ul><ul><ul><li>Survivability </li></ul></ul><ul><ul><u...
Outline Performance analysis Motivation Threat model System design Conclusion Structure
Threat Model
The Quiet Invader <ul><li>Smart attacker </li></ul><ul><ul><li>Make decisions to maximize the potential of achieving their...
Outline Performance analysis Motivation Threat model System design Conclusion Structure
Coordinator Replica 1 Replica 2 Replica 3 Replica n Workload Workload Workload Workload Workload Replica 3 R R R R Periodi...
Hardware Signature Generation System reg IDS
Outline Performance analysis Motivation Threat model System design Conclusion Structure
Performance Analysis <ul><li>Cases </li></ul><ul><ul><li>Case 1: S ystems with no checkpointing </li></ul></ul><ul><ul><li...
Results
Results Table 1:  Execution Times (in hours) for the Scimark workloads across three cases Table : Execution times (in hour...
Results
Results
Results Table : Approximate optimal checkpoint interval values and their corresponding  workload execution times for LU (C...
Outline Performance analysis Motivation Threat model System design Conclusion Structure
Conclusion <ul><li>Low cost solution to secure proactive recovery </li></ul><ul><li>Mission survivability </li></ul><ul><l...
<ul><li>Thank You !! </li></ul>
DFT <ul><li>Design for test  </li></ul><ul><ul><li>Process that incorporates rules and techniques in product design to mak...
Boundary Scan <ul><li>Boundary scan is a special type of scan path with a register added at every I/O pin on a device </li...
DLX <ul><li>RISC (Reduced instruction set computing)processor architecture designed </li></ul><ul><li>cleaned up and simpl...
Hardware Signature <ul><li>Loading signature into scan cells  </li></ul><ul><ul><li>We inserted a multiplexer before each ...
Survivability <ul><li>Mission: </li></ul><ul><ul><li>A set of a very high level requirements or goals. </li></ul></ul><ul>...
Byzantine Fault-tolerance <ul><li>Byzantine fault : An arbitrary fault that occurs during the execution of an algorithm by...
TPM <ul><li>Trusted Platform Module </li></ul><ul><ul><li>Secure cryptoprocessor that can store cryptographic keys that pr...
Upcoming SlideShare
Loading in …5
×

Secure Proactive Recovery- a Hardware Based Mission Assurance Scheme

723 views

Published on

Published in: Education, Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
723
On SlideShare
0
From Embeds
0
Number of Embeds
174
Actions
Shares
0
Downloads
5
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Secure Proactive Recovery- a Hardware Based Mission Assurance Scheme

  1. 1. Secure Proactive Recovery – a Hardware Based Mission Assurance Scheme 6 th  International Conference on Information Warfare and Security, 2011 Ruchika Mehresh 1 Shambhu J. Upadhyaya 1 Kevin Kwiat 2 [email_address] [email_address] [email_address] 1 Department of Computer Science and Engineering, State University of New York at Buffalo, NY, USA 2 Air Force Research Laboratory, Rome, NY, USA Research Supported in Part by ITT Grant No. 200821J and NSF Grant No. DUE-0802062
  2. 2. Outline Performance analysis Motivation Threat model System design Conclusion Structure
  3. 3. Motivation <ul><li>Mission assurance </li></ul><ul><li>Goals </li></ul><ul><ul><li>Survivability </li></ul></ul><ul><ul><ul><li>Security </li></ul></ul></ul><ul><ul><ul><li>Fault tolerance </li></ul></ul></ul><ul><ul><ul><li>Low cost (Time overhead) </li></ul></ul></ul><ul><ul><ul><li>Adaptation and evolution </li></ul></ul></ul><ul><ul><li>Feasibility study </li></ul></ul><ul><ul><li>Long running applications </li></ul></ul><ul><ul><li>Prevention  Detection  Recovery </li></ul></ul><ul><ul><li>Hardware-based </li></ul></ul><ul><ul><li>Smart defender </li></ul></ul>
  4. 4. Outline Performance analysis Motivation Threat model System design Conclusion Structure
  5. 5. Threat Model
  6. 6. The Quiet Invader <ul><li>Smart attacker </li></ul><ul><ul><li>Make decisions to maximize the potential of achieving their objectives based on dynamic information </li></ul></ul><ul><li>Quiet invader </li></ul><ul><ul><li>Camouflages to buy more time </li></ul></ul><ul><ul><li>Plan to attack mission during critical stage (Why?) </li></ul></ul><ul><ul><li>Example: </li></ul></ul><ul><ul><ul><li>Long running countdown for a space shuttle launch that runs for several hours </li></ul></ul></ul>
  7. 7. Outline Performance analysis Motivation Threat model System design Conclusion Structure
  8. 8. Coordinator Replica 1 Replica 2 Replica 3 Replica n Workload Workload Workload Workload Workload Replica 3 R R R R Periodic checkpoint Hardware Signature Periodic checkpoint Hardware Signature H C H C H C H C Periodic checkpoint Hardware Signature Periodic checkpoint Hardware Signature Periodic checkpoint Hardware Signature
  9. 9. Hardware Signature Generation System reg IDS
  10. 10. Outline Performance analysis Motivation Threat model System design Conclusion Structure
  11. 11. Performance Analysis <ul><li>Cases </li></ul><ul><ul><li>Case 1: S ystems with no checkpointing </li></ul></ul><ul><ul><li>Case 2: Systems with checkpointing, no failures/attacks </li></ul></ul><ul><ul><li>Case 3: Systems with checkpointing, failures/attacks </li></ul></ul><ul><li>Workload </li></ul><ul><ul><li>Java SciMark 2.0 benchmark workloads: FFT, SOR, Sparse, LU </li></ul></ul><ul><li>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] </li></ul>
  12. 12. Results
  13. 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 FFT LU SOR Sparse Case 1 3421.09 222.69 13.6562 23.9479 Case 2 3477.46 226.36 13.8811 24.3426 Case 3 (M=10) 3824.63 249.08 15.2026 26.7313 Case 3 (M=25) 3593.39 233.83 13.8811 24.3426
  14. 14. Results
  15. 15. Results
  16. 16. Results Table : Approximate optimal checkpoint interval values and their corresponding workload execution times for LU (Case 3) at different values of M M=5 M=10 M=15 M=25 Optimal Checkpoint Interval (hours) 0.3 0.5 0.65 0.95 Execution Times(hours) 248.97 241.57 238.16 235.06
  17. 17. Outline Performance analysis Motivation Threat model System design Conclusion Structure
  18. 18. Conclusion <ul><li>Low cost solution to secure proactive recovery </li></ul><ul><li>Mission survivability </li></ul><ul><li>Utilized redundant hardware </li></ul><ul><li>Small overhead in absence of failures </li></ul><ul><ul><li>Effective preventive measure </li></ul></ul><ul><li>Future work </li></ul><ul><ul><li>To evaluate this scheme for a distributed system </li></ul></ul>
  19. 19. <ul><li>Thank You !! </li></ul>
  20. 20. DFT <ul><li>Design for test </li></ul><ul><ul><li>Process that incorporates rules and techniques in product design to make testing easier. </li></ul></ul><ul><ul><li>Testing aspects </li></ul></ul><ul><ul><ul><li>Control </li></ul></ul></ul><ul><ul><ul><li>Observation </li></ul></ul></ul><ul><li>IEEE Std 1149.1 </li></ul><ul><ul><li>Allows test instructions and data to be serially loaded into a device </li></ul></ul><ul><ul><li>Enables subsequent test results to be serially read out. </li></ul></ul><ul><li>[Source: IEEE Std 1149.1 (JTAG) Testability Primer  A technical presentation on Design-for-Test centered on JTAG and Boundary Scan] </li></ul>
  21. 21. Boundary Scan <ul><li>Boundary scan is a special type of scan path with a register added at every I/O pin on a device </li></ul><ul><li>Hardware signature of a replica can be stored in the flip flops of the boundary scan chain around a processor </li></ul><ul><li>Our simulation centered around a boundary scan inserted DLX processor </li></ul>
  22. 22. DLX <ul><li>RISC (Reduced instruction set computing)processor architecture designed </li></ul><ul><li>cleaned up and simplified MIPS processor, with a simple 32-bit load/store architecture </li></ul><ul><li>Verilog code for the boundary scan inserted DLX processor is elaborated in cadence RTL compiler </li></ul>
  23. 23. Hardware Signature <ul><li>Loading signature into scan cells </li></ul><ul><ul><li>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. </li></ul></ul><ul><ul><li>Depending on the select line either the test data or the signature is latched into the flip flops of the scan cells. </li></ul></ul><ul><ul><li>To read signature out we have to serially shift the bits from the flip flops onto the output (IEEE 1149.1) </li></ul></ul>
  24. 24. Survivability <ul><li>Mission: </li></ul><ul><ul><li>A set of a very high level requirements or goals. </li></ul></ul><ul><ul><li>Not limited to military settings </li></ul></ul><ul><li>Survivability </li></ul><ul><ul><li>Capability of a system to fulfill its mission in a timely manner in presence of attacks, failures, or accidents. </li></ul></ul><ul><ul><li>Reaction and recovery must be successful, whether the cause is ever determined or not. </li></ul></ul><ul><li>Reference : Ellison, R.J.; Fisher, D.A.; Linger, R.C.; Lipson, H.F.; Longstaff, T.A.; Mead, N.R.; , &quot;Survivability: protecting your critical systems,&quot;  Internet Computing, IEEE  , vol.3, no.6, pp.55-63, Nov/Dec 1999 </li></ul>
  25. 25. Byzantine Fault-tolerance <ul><li>Byzantine fault : An arbitrary fault that occurs during the execution of an algorithm by a distributed system </li></ul><ul><ul><li>Omission failures e.g., crash failures, failing to receive a request </li></ul></ul><ul><ul><li>Commission failures e.g., processing a request incorrectly </li></ul></ul><ul><li>Classical solutions:   n  > 3 t </li></ul><ul><ul><li>Where, n is the total number of processes in the system </li></ul></ul><ul><ul><li>t is the number of faulty processes </li></ul></ul><ul><li>Our case </li></ul><ul><ul><li>Centralized system </li></ul></ul><ul><ul><li>Majority vote: n>2t </li></ul></ul>
  26. 26. TPM <ul><li>Trusted Platform Module </li></ul><ul><ul><li>Secure cryptoprocessor that can store cryptographic keys that protect information </li></ul></ul><ul><ul><li>Sealed storage, Remote Attestation </li></ul></ul><ul><li>Privacy issues </li></ul><ul><li>Feasibility study </li></ul><ul><li>Can use alternatives such as active attestation by Nexus </li></ul>

×