चूँकि Linux 6.9 आया, LUKS suspend ने मेमोरी से disk-encryption keys मिटाना बंद कर दिया

मूल लेख ↗ Hacker News चर्चा ↗

रिग्रेशन की प्रकृति

  • Linux 6.9 के बाद से, cryptsetup luksSuspend suspend पर LUKS वॉल्यूम keys को RAM से भरोसेमंद तरीके से मिटाना बंद कर दिया, जबकि resume पर users से अब भी उनका passphrase पूछा जा रहा था।
  • यह bug kernel keyring की lifetime में हुए बदलाव से उपजा: thread keyring में संग्रहीत keys से अपेक्षा थी कि thread के exit करते ही वे गायब हो जाएँगी, लेकिन ऐसा होना बंद हो गया, जिससे volume key की एक अतिरिक्त copy kernel memory में रह गई।
  • इससे वे systems, जो सोचते थे कि वे suspend पर “extra secure” हैं, अपेक्षा से कम secure हो गए, जबकि वे सामान्य रूप से काम करते हुए दिख रहे थे।

Suspend बनाम hibernate और threat model

  • Suspend-to-RAM: RAM (disk keys सहित) powered रहती है; ज़्यादातर systems LUKS keys साफ नहीं करते, इसलिए disk encryption मुख्यतः powered-off या हटाई गई disks की रक्षा करती है।
  • Hibernate-to-disk: RAM contents (keys सहित) encrypted swap/image में लिख दिए जाते हैं और RAM power off हो जाती है; resume पर users फिर से passphrase दर्ज करते हैं।
  • कुछ लोगों का तर्क है कि केवल hibernate (या हमेशा power off करना) ही cold-boot attacks से अर्थपूर्ण सुरक्षा देता है; अन्य लोग ध्यान दिलाते हैं कि attack की व्यावहारिकता threat model पर बहुत निर्भर करती है।

Cold boot और physical access

  • Suspended, locked laptop तक physical access होने पर attackers यह कर सकते हैं:
    • Cold-boot attacks करना (custom OS में तेज़ी से reboot करना, या RAM को freeze करके transfer करना)।
    • खराब तरीके से configured systems पर DMA या समान techniques का उपयोग करना।
  • कई comments इस बात पर ज़ोर देते हैं कि यह मुख्यतः high-value या state-level targets के लिए प्रासंगिक है, सामान्य चोरों के लिए नहीं।

Workarounds और mitigations

  • चर्चा में सुझाए गए mitigations:
    • Suspend की बजाय hibernation का उपयोग करें; कुछ Fedora users suspend timeout के बाद auto-hibernate करते हैं।
    • उपलब्ध होने पर CPU memory encryption (Intel/AMD features) सक्षम करें, हालांकि यह मुख्यतः physical RAM attacks के विरुद्ध मदद करता है, keys के logical misuse के विरुद्ध नहीं।
    • EFI/TPM features जैसे MemoryOverwriteRequest का उपयोग करें ताकि reboot पर RAM wipe हो जाए।

Scope और distro specifics

  • luksSuspend cryptsetup में upstream है; Debian ने suspend से इसे जोड़ने वाला integration जोड़ा, और बताया गया कि यह approach अन्य distros में भी port किया गया।
  • यह regression उन configurations को प्रभावित करता है जो luksSuspend semantics पर निर्भर थीं, न कि stock “बस suspend” setups को।

तुलनाएँ और व्यापक सुरक्षा themes

  • BitLocker, FileVault, LUKS, और VeraCrypt की लंबी तुलना:
    • Enterprises को BitLocker की manageability पसंद है, खासकर TPM+PIN और key escrow के साथ।
    • Privacy-minded users proprietary encryption और cloud key escrow को लेकर सावधान रहते हैं।
  • कई comments यह उजागर करते हैं कि:
    • Open source अधिक auditable है, लेकिन अपने आप audited नहीं होता।
    • Robust integration tests की कमी ने इस regression को संभव बनाया; dedicated test जोड़ना वास्तविक long-term fix माना जा रहा है।