1 / 31

Practical and Secure PCM Memories via Online Attack Detection

Practical and Secure PCM Memories via Online Attack Detection. Moinuddin Qureshi Luis Lastras, Michele Franceschini, John Karidis IBM T. J. Watson Research Center, Yorktown Heights, NY. Birthday Paradox Attack.

nelly
Download Presentation

Practical and Secure PCM Memories via Online Attack Detection

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Practical and Secure PCM Memories via Online Attack Detection Moinuddin Qureshi Luis Lastras, Michele Franceschini, John Karidis IBM T. J. Watson Research Center, Yorktown Heights, NY WEST-2010

  2. Birthday Paradox Attack We thank Andre Seznec for pointing the Birthday Paradox Attack (BPA) vulnerability for Start-Gap In the paper, we first prove that for our RBSG scheme, BPA causes at-most 2x reduction in lifetime compared to Repeat Address Attack (RAA) Lifetime under attack : ~1-2 months Here we introduce an adaptive-RBSG scheme which extends the life to years under all analyzed attacks

  3. The Assumptions in Security Studies • No other application running except attack • Attack goes undetected for months/years • OS maintains mapping of pages for entire duration • Possible to write a line to memory at full speed Other things that can help: • Significant spare lines needed for PCM anyway • Legal actions for minimizing warranty fraud

  4. What we need … Security: Lifetime under attacks should be in the range of years. Typical solution: Table based with RandSwap[Ben-Aroya et al.’06, Seznec’10] We would like to have security for free (or almost free)

  5. Key insight Table based methods make all applications pay high overhead to handle (infrequent) attacks: High overhead okay for attacks, not otherwise Wear leveling algorithms move lines at a particular rate. This rate determines: write overhead & robustness under attacks Trade-off: rate must be low to reduce overhead and high for robustness If we can identify attack-like patterns, then have slower rate for typical apps and faster for attacks: best of both worlds

  6. Our proposal: Adaptive Wear Leveling PCM Based Main Memory Wear Leveling Algorithm WRITE.ADDR Online Attack Detector (OAD) RateControl OAD controls the rate of movement based on properties of the memory write stream

  7. Outline • Introduction • Background on Start-Gap • Anatomy of Attacks • Practical Attack Detector • Adaptive Start-Gap • Summary and Discussions

  8. GAP  Start-Gap Wear Leveling Two registers (Start & Gap) + 1 line (GapLine) to support movement. Move GapLine every G writes to memory. START 0 A 1 B 2 C 3 D 4 PCMAddr = (Start+Addr); (PCMAddr >= Gap) PCMAddr++) Storage overhead: less than 8 bytes (GapLine taken from spares) Write overhead: One extra write every G writes  1% (G=100) Randomized address space to avoid “hot region” and predictability

  9. Terminology N= Number of Lines in Memory G= Gap Movement Interval (Writes per Gap movement) E= Endurance per each line LVF= Max writes to same address before line gets moved Line Vulnerability Factor (LVF): N*G If (LVF > E) Repeated writes to a line causes line failure In general we want (LVF << E), say LVF=E/8 (not enough) Therefore, G= (E/8N), which means G=1/16 (if N=2E) But we want G>=100 to limit write overhead to less than 1%

  10. Effective LVF But we write to several other lines between writes to same line Intra Write Distance (d):Num writes betweentwo writes to the same line If (d>1), the line vulnerability factor reduces Effective LVF (d) = ELVF(d) = (N*G)/d For ELVF=E/8  G=(E.d)/(8N) Typically, d>>1K, which means G=128 easy for typical apps

  11. Likelihood of Repeat Writes To show that d>>1K, we conducted the following experiment DRAM cache: 32MB, 8-way LRU, normal indexing Keep track of most recent “w” writes to memory Probability of hit in most recent “w” writes to memory Likelihood of hit in most recent 1K entries is less than one in a million

  12. Outline • Introduction • Background on Start-Gap • Anatomy of Attacks • Practical Attack Detector • Adaptive Start-Gap • Summary and Discussions

  13. Requirements for Attack For an attack to successfully cause failure, it must: Write to a few lines (otherwise d>1K) Repeatedly for at-least a few million times At a fairly high write bandwidth We can exploit properties (1) and (2) for online attack detection.

  14. Canonical Form of Attacks Generalized RAA Stealth-Mode Attack SMA-like attacks are most challenging to detect

  15. Typical Apps vs. Attacks Easy to differentiate attacks by measuring hit rate of 1K entry window But too much hardware and power. Window searched on each access.

  16. Outline • Introduction • Background on Start-Gap • Anatomy of Attacks • Practical Attack Detector • Adaptive Start-Gap • Summary and Discussions

  17. Practical Attack Detector (PAD) We are interested in measuring hit rate of a relatively small window (1K) This can be approximated by a small stack and insert with prob “p” A D D R HitCounter (16-bit) + + WriteCounter (16-bit) On each access, the stack is checked, WriteCounter incremented On a hit, the replacement info of entry is updated, HitCounter incremented On a miss, with a probability p, the insert the address in the stack When WriteCounter reaches max, hit rate is calculated, both counters halved We conservatively calculate the distance (d) = 1/hitrate

  18. Effectiveness of PAD PAD can monitor different window sizes, depending on the insert probability (p) We assume a 16-entry stack with p=1/256 PAD can accurately estimate the distance (d) for SMA

  19. Characteristics of PAD • Programmable and accurate for distances within window • Low detection latency (32K writes) • Pardons infrequent hits in window (must hit several times) • Decaying effect on hit rate  attack not easily forgotten • Handles multiple attacks  reports worst-case d • Low hardware cost (68 bytes) and non-intrusive • PAD is off the critical path, distance calculation every 32K writes

  20. Outline • Introduction • Background on Start-Gap • Anatomy of Attacks • Practical Attack Detector • Adaptive Start-Gap • Summary and Discussions

  21. Adaptive Start-Gap Key insight: Make Gap Movement Interval (G) a function of distance (d) To ensure < E/8 writes occur to a given line before the line is moved: G = For typical apps, d>>1K, which means G=128 For repeat address attack (RAA), d=1, which means G=1/16 if (N=2E) Slow (but not a problem, as it is an attack, not using the cache) But useful writes reduced to less than 1/16.

  22. Adaptive Region-Based Start-Gap Key insight: Divide memory into regions (num regions = num banks) With “r” banks, number of lines in each bank becomes N/r Therefore, to ensure < E/8 writes occur before the line is moved: For N=2E and r=16 G = G = Thus, even under RAA, one line moves every demand write Each bank has its own start-gap and attack detection circuit (68 bytes) Total storage overhead of aRBSG: 16*(4+4+68) = 1216 bytes

  23. Results for GRAA Generalized Repeat Address Attack (GRAA) on n lines. N=226, E=225, Banks=Regions=16, TimeToWriteOneLine=1 µ second Lifetime remains constant at 4 years. Useful writes from 50% to 98%

  24. Handling BPA Effectiveness of BPA bounded by “Buckets and Balls” problem Assume attacker knows which line maps to which bank Number of buckets (B)=4M 8 months ELVF of E/8 not enough, need ELVF of E/64 for ~50% demand writes

  25. Extensions for Handling BPA Move gap 8 times faster to ensure ELVF of E/64 G = G 8 Avoid 8x write overhead: Under attack ensure >= 8 demand entries in WRQ before writing. This ensure dmin = 8. Worst-case overhead: one “extra” write per demand write With ELVF=E/64, 37% of demand writes + 37% “extra” writes. Lifetime: 74% of 4 years (~3 years) [Without any spare lines]

  26. Generalized SMA: “Fooling” the detector SMA tries to trick PAD by hiding 1 attack line in random writes SMA is easy to detect but GSMA much harder to detect. < Avg. Detection Period > Avg. Retention Period k small enough that attack line does not enter PAD (k<1/p) n large enough that PAD forgets about the line if inserted (n>NumEntries/p) For our setup k<256 and n>256*16  n> 4096

  27. Lifetime under GSMA k={1,2,4,8,16,32,64,128,256} x n={1K,2K,4K,8K,16K,32K,64K,128K} For the worst-case attack under LRU, distance calc. off by 8x If distance calc off by 8x this means ELVF of E/8 instead of E/64 If attack was at full speed: Lifetime of 8 months GSMA inherently slow (8K/128 64x slow): Lifetime ~2.2 years

  28. Comparison Possible to get security for free … Well, almost free

  29. Outline • Introduction • Background on Start-Gap • Anatomy of Attacks • Practical Attack Detector • Adaptive Start-Gap • Summary and Discussions

  30. Summary • Security: We want lifetime in range of year(s) under attacks • We propose to decouple: attack detection and corrective actions • We propose simple and accurate attack detector (68 bytes) • We propose Adaptive RBSG that keeps write overhead for typical apps to < 1% and provides years of lifetime under attacks • Attack detection can be used for other corrective actions:slow down service, inform OS, swap page, inform sys admin • Attack detection also applicable to other wear leveling algorithms • Beta version: Work in progress (other attacks, theoretical analysis)

  31. Other Extensions (not evaluated yet) • Pagemode can be supported securely as well by: Randomizing at page granularity Having a GAP-PAGE instead of a GAP-LINE Rotating lines within page using a static randomizer: F(start,addr) • Make it harder for attacker to devise attacks. For example, randomize the index of DRAM cache This will also prevent typical apps showing attack-like patterns ToMemory Addr Last Level Cache Rand InvRand

More Related