[dm-crypt] Mastery Key and RAM burn-in

[dm-crypt] Mastery Key and RAM burn-in

[procmem]

Hi. I've read Gutmann's papers about how data held persistently in DRAM
can cause physical "burn-in" that makes master encryption key recovery
trivial. His suggestion was to makes sure it is re-written/moved around
every few minutes. [1] loop-aes had such a mitigation implemented,
though it unfortunately aids cold boot attack key recovery.[2]

Does dm-crypt have mitigations for this in place?

[1] https://www.cs.jhu.edu/~astubble/600.412/s-c-papers/remanence.pdf

[2] https://www.lorentzcenter.nl/lc/web/2010/383/presentations/Heninger.pdf

Re: [dm-crypt] Mastery Key and RAM burn-in

[Arno Wagner]

Hi,

I would suggest that Gutmann's insights (which were pretty 
good when published) are pretty much outdated 18 years later.
Manufacturing processes have changed and cell stability is
vastly better than it was (or DRAMs would not survive very 
long). It is not clear whether these attacks still work and
how much effort they would be. 

This attack is not a widespread concern in the security 
community these days though. As far as I am aware (correct
me if I am wrong), there is not a single instance where
this attack was used successfully. 

Anyways, this is not a LUKS or dm-Crypt issue. This is an
issue with the kernel crypto services, I believe. loop-AES
is kind of historic and still did its own crypto. That is
not how things work these days.

Regards,
Arno


On Thu, Oct 24, 2019 at 00:23:47 CEST, procmem@riseup.net wrote:
> Hi. I've read Gutmann's papers about how data held persistently in DRAM
> can cause physical "burn-in" that makes master encryption key recovery
> trivial. His suggestion was to makes sure it is re-written/moved around
> every few minutes. [1] loop-aes had such a mitigation implemented,
> though it unfortunately aids cold boot attack key recovery.[2]
> 
> Does dm-crypt have mitigations for this in place?
> 
> [1] https://www.cs.jhu.edu/~astubble/600.412/s-c-papers/remanence.pdf
> 
> [2] https://www.lorentzcenter.nl/lc/web/2010/383/presentations/Heninger.pdf
> 
> 
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> https://www.saout.de/mailman/listinfo/dm-crypt

-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
A good decision is based on knowledge and not on numbers. -- Plato

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier

[dm-crypt] Mastery Key and RAM burn-in

[procmem]

[-- Attachment #1: Type: text/plain, Size: 938 bytes --]

> Hi,
>
> I would suggest that Gutmann's insights (which were pretty 
> good when published) are pretty much outdated 18 years later.
> Manufacturing processes have changed and cell stability is
> vastly better than it was (or DRAMs would not survive very 
> long). It is not clear whether these attacks still work and
> how much effort they would be. 
>
> This attack is not a widespread concern in the security 
> community these days though. As far as I am aware (correct
> me if I am wrong), there is not a single instance where
> this attack was used successfully. 
>
> Anyways, this is not a LUKS or dm-Crypt issue. This is an
> issue with the kernel crypto services, I believe. loop-AES
> is kind of historic and still did its own crypto. That is
> not how things work these days.
>
> Regards,
> Arno
Alright thanks for making it clear. The only instance of a successful
attack was with a machine using SRAM which is antiquated.



[-- Attachment #2: Type: text/html, Size: 1189 bytes --]