Your SlideShare is downloading. ×
Secure Proactive Recovery- a Hardware Based Mission Assurance Scheme
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Secure Proactive Recovery- a Hardware Based Mission Assurance Scheme

486
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
486
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
4
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 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. Outline Performance analysis Motivation Threat model System design Conclusion Structure
  • 3. Motivation
    • Mission assurance
    • Goals
      • Survivability
        • Security
        • Fault tolerance
        • Low cost (Time overhead)
        • Adaptation and evolution
      • Feasibility study
      • Long running applications
      • Prevention  Detection  Recovery
      • Hardware-based
      • Smart defender
  • 4. Outline Performance analysis Motivation Threat model System design Conclusion Structure
  • 5. Threat Model
  • 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
  • 7. Outline Performance analysis Motivation Threat model System design Conclusion Structure
  • 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. Hardware Signature Generation System reg IDS
  • 10. Outline Performance analysis Motivation Threat model System design Conclusion Structure
  • 11. Performance Analysis
    • Cases
      • Case 1: S ystems 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]
  • 12. Results
  • 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. Results
  • 15. Results
  • 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. Outline Performance analysis Motivation Threat model System design Conclusion 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
  • 19.
    • Thank You !!
  • 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]
  • 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
  • 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
  • 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)
  • 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
  • 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  > 3 t
      • 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
  • 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

×