Re: Some questions about cryptsetup 1.6.x

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Feb 12, 2014 at 17:29:40 CET, Matthias Schniedermeyer wrote:
> On 12.02.2014 16:57, Arno Wagner wrote:
> > On Wed, Feb 12, 2014 at 16:04:08 CET, Matthias Schniedermeyer wrote:
> 
> DRAM is in effect a little capacitor, it takes a little time for the 
> charge to fade. 
> 
> There was an article a few years back that said that modern DRAM 
> actually got better at holding that charge. And that (or a separate) 
> article further said that the time gets extended when a specific cell 
> holds a particular charge for a long time.
> 
> > Have a citation? 
> 
> Unfortunatly no.

So lets keep that as "myth". The SRAM attenuation has been 
known for a long, long time, I heard about it first when I studied
cryptology 25 years ago, but for DRAM I have never heard of it.
 
I suspect it would have to happen in the cell transistor, not the 
capacitor.  And then it will be far, far less pronounced than in 
SRAM as that transistor is unpowered most of the time, quite unlike
SRAM. It is only a pretty weak effect even there. 

> > > For e.g. loop-AES contains a mitigation for that. If you activate the 
> > > option it holds 2 sets of keys in RAM. One is the "actual" key, the 
> > > other one is (AFAIR) with it's bit inverted and then it bit-invertes and 
> > > switches the sets in regular intervals. So that none of the 2 locations 
> > > actually falls into the "long term" category. In the hope that when you 
> > > switch of power (to memory) the keys fade fast enough to not be 
> > > recoverable (or at least with sufficient severe loss of bits).
> > > 
> > > 
> > > Cold-Boot is a slight variation of this, where you try to use the actual 
> > 
> > It actually is something completely different, as the RAM stays powered
> > and modern DRAM is self-refresing. You are confusing two different things
> > here.
> 
> The basic "attack vector" is getting ahold of the memory contents.

With that reasoning, all attacks are the same...

Beware of abstracting away necessary detail.

> With cold boot you try to do that "inline" (RAM still plugged in).
> In the "rip out" case it's "out-of-line" (RAM in another device).
> 
> So i personally see little difference, both require protection against 
> physical access to the computer. Only what an attacker can do if s/he 
> gets ahold of the physical computer is slightly different and they 
> ce be tried in order (cold-boot, then "rip out").

"Cold boot" could be possible over the net, via IPMI, for example.
Freeze&remove is not.
 
> > > computer itself for the dump. You can (try to) mitigate using the 
> > > computer for dumping the memory, so an attacker has to revert to "rip 
> > > out". But if unsucessful the memory can be dumped with only a neglient 
> > > amount of bit-loss. (You have to store & execute a programm in some way. 
> > > So you have to overwrite at least a little bit of memory)
> > > 
> > > IIRC there was a description of a mitigation technique that "pin"s the 
> > > key in L1 (and/or L2) cache without it being stored in RAM.
> > 
> > That would be really bad. L1/L2 cache is SRAM and that does suffer
> > from changes when values are stored long-term.
> 
> The theory is that after the CPU is reset (Cold-boot) or switched off 
> (rip-out) you have no way of getting ahold of the cache contents.

Nonsense. Just power the CPU up in debug mode and read its cache contents. 
And you can try as often as you like as this is a physical change in the 
SRAM cells you are trying to detect. It does not go away when power is gone
or when you write other data into the cells. 

I think you are still not clear on what we are discussing here:
We have two different effects:

1. RAM cells keep their state a little while after power is gone.
   In SRAM this is due to parasitic capacitors in the cells and
   can be very short (microseconds). In DRAM it is due to the data 
   actually being stored in capacitors and they keep their charge 
   for seconds to minutes after they are not refreshed anymore. 
   In fact, DRAM cells are not powered in normal operation, only
   during read, write or refresh of that particular cell.
   SRAM cells are.

2. Carrying a specific bit value for a long time changes  
   an SRAM memory cell physically in a way that can be detected and that
   does mot go away (unless being overwritten with another pattern 
   that stays in there very long). It is rather unclear
   whether the same happen for DRAM and for DRAM it is very hard to 
   detect. For SRAM, ideally you just power it up and the attenuated
   cells come up with the bits they held for so long. 

Having the key in main menory means having it in DRAM. Having it
in the CPU cache means having it in SRAM, and in a very specific
location in addition, which strikes me as exceedingly stupid given
that SRAM cell attenuation is a known phenomenon.

It also degrades system performance.
 
> DRAM is easy, they have a standard connector (assuming a standard PC) 
> and building a device where you connect the DRAM and that then copies 
> the contents is relativly easy. At least for a qualified attacker.
> 
> Building a device that dumps the contents of a CPU should be quite 
> difficult and as an "active" component the CPU can't be simply read. 

You obvisouly have never heard of things like JTAG. I am sorry,
but I strongly suggest you read up on technology before making 
any more nonsensical claims. Also note the difference I pointed
out above.

Arno
-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@xxxxxxxxxxx
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
_______________________________________________
dm-crypt mailing list
dm-crypt@xxxxxxxx
http://www.saout.de/mailman/listinfo/dm-crypt




[Index of Archives]     [Device Mapper Devel]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Packaging]     [Fedora SELinux]     [Yosemite News]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux