1 / 19

Improving Cost,

Performance, and Security of. Improving Cost,. Memory Encryption and Authentication. Chenyu Yan , Brian Rogers § , Daniel Englender, Yan Solihin § , Milos Prvulovic. Secure Architecture. Secure Processor. Processor Core. Cache. Crypto Engine. Trusted Domain. UnTrusted Domain. ??.

page
Télécharger la présentation

Improving Cost,

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. Performance, and Security of Improving Cost, Memory Encryption and Authentication Chenyu Yan, Brian Rogers§, Daniel Englender, Yan Solihin§, Milos Prvulovic

  2. Secure Architecture Secure Processor Processor Core Cache Crypto Engine Trusted Domain UnTrusted Domain ?? Main Memory (Encrypted Data & Auth Tag) • Copy and Tamper Resistant environment • Existing schemes: >20% performance overhead

  3. Contributions • Split counters • Smaller counters (better caching, less space overhead) • Reduce re-encryption work, off critical path • Use Galois/Counter Mode (GCM) • Overlap most authentication work with memory latency • Provide precise authentication w/ little perf. overhead • Improved security • Solve pitfall in counter mode encryption

  4. Outline • Background • Split Counter Mode Encryption • Counter Mode Encryption • Split Counters • Memory Authentication with GCM • A Security Pitfall and Solution • Evaluation • Conclusion

  5. Counter Mode Encryption • One-time Pad (Vernam Cipher) cipher = plain XOR random pad plain = cipherXOR random pad • OTP has been proven to be unbreakable when properly deployed • Truly random and used only once • A common and effective construction: pseudo-random number generation by AES pad = AESencryptk(seed)

  6. Counter Cache Miss Counter Mode Encryption (Cont.) 128 bit Seed Init. Vector Address Counter Spatial Uniqueness Temporal Uniqueness App/Process Uniqueness Data Cache Counter Cache AES Main Memory

  7. Minor Counters (7bit x 64) ▪▪▪▪▪▪ 64bit Encryption Page (64 blocks) Major Counter ▪▪▪▪▪▪ 64byte counter cache line Split Counters • Counter size dilemma • Large counters: avoid counter overflow and re-encryption • Small counters: counter hit rate↑, space overhead↓ • Counter = Major Counter | Minor Counter • Major Counter • Shared by all data blocks in an encryption page • Does not overflow for millennia (64 bit) • Minor Counter • Per-block counter for recording individual counter growth • Overflow needs to re-encrypt the page, not the whole application • Stored together in a counter cache line

  8. Outline • Background • Split Counter Mode Encryption • Memory Authentication with GCM • A Security Pitfall and Solution • Evaluation • Conclusion

  9. Galois Counter Mode • Authenticated Encryption Mode • McGrew and Viega, 2005 • Counter mode encryption coupled with pad-based authentication • Can be pipelined and parallelized • Pre-compute pad • When ciphertext arrives, MAC quickly generated

  10. multH multH Authenticated Encryption/Decryption AIV|Addr1|Counter EIV|Addr1|Counter EIV|Addr2|Counter 128 bit 128 bit 128 bit AESK AESK AESK Plaintext 1 Plaintext 2 128 bit 128 bit Ciphertext 1 Ciphertext 2 128 bit 128 bit GHASH 128 bit Auth Tag H = AESencryptK(0)

  11. Outline • Background • Split Counter Mode Encryption • Memory Authentication with GCM • A Security Pitfall and Solution • Counter Replay Attack • Protect Counter Integrity • Evaluation • Conclusion

  12. WB Counter Replay Attack • Data confidentiality doesn’t require counter secrecy • Counters are stored unencrypted in memory • Unauthorized modification to counters in memory • Leads to counter replayswhich undermine the one-time premise Data Cache Memory Ciphertext Information PAD 125 Counter Cache … … 125 125 124

  13. Protect Counter Integrity • Data and Counter Merkle Tree

  14. Outline • Background • Split Counter Mode Encryption • Memory Authentication with GCM • Data and Counter Integrity Issues • Evaluation • Conclusion

  15. Counter Mode Encryption Performance • Improvement over 64-bit monolithic counters due to • More counters fit in same-size counter cache • Less bandwidth to fetch smaller counters • Split counters: 1% perf. overhead w/ 32kB cache • Includes overhead of page re-encryptions Counter Cache Size

  16. GCM Authentication Performance • GCM authentication performs well even under the highest security requirement • SHA-1 authentication degrades performance dramatically with higher security requirement Security

  17. Overall Performance • 5% performance overhead for memory encryption and authentication with GCM and split counters

  18. Conclusions • Split counters • Improve counter caching • Reduce counter storage overhead • Remove re-encryption glitches, allow optimization • GCM • Large reduction of authentication overheads • Complements counter-mode encryption naturally • Protect counter integrity to keep data safe • Negligible performance impact • Reduce perf. overhead from 20% to 5%

  19. Questions Email: cyan@cc.gatech.edu Georgia Tech § NC STATE UNIVERSITY

More Related