1 |
On 10/5/07, Hans-Werner Hilse <hilse@×××.de> wrote: |
2 |
> > So, my eternal question, is it realistic for the "lost" RAM data to be |
3 |
> > recovered? That is, after system shutdown, does the data still |
4 |
> > physically reside on the RAM and can someone with a decent technology |
5 |
> > and know-how recover it? In other words, is this a serious breach in |
6 |
> > any encrypted system? |
7 |
> |
8 |
> No, it isn't. Well, I didn't had the full circuit design of today's |
9 |
> DRAMs in mind, and yes, since there's the resistor, the capacitor will |
10 |
> lose its load (very) soon (/me scratches his head, wasn't there |
11 |
> something asymptotically in that graph? But in any way, it would be a |
12 |
> difference of very few electrons on the sides of the capacitor) -- |
13 |
> that's not a security breach. |
14 |
> |
15 |
> But: We are talking about _powering_ _off_ the DRAM. You are talking |
16 |
> about shutting down. That might be two different things and completely |
17 |
> depend on hardware design. Make shure that RAM's gonna get powered off |
18 |
> and you're save. So pulling the plug should give you a warm good |
19 |
> feeling in that regard. Doing a "sudo halt", however, _might_ have |
20 |
> other consequences and we cannot make a general assumption on that. |
21 |
> Even pulling the plug might have problems: There's such thing as |
22 |
> battery-buffered RAM (although I think they've used it mainly in the |
23 |
> pre-Flash era). |
24 |
> |
25 |
> The thing is: You never can guarantee security, that's absolutely |
26 |
> impossible (well, of course you can, but you would automatically be |
27 |
> wrong). You can do all your best, but that's about it. Having security |
28 |
> is a thing you can falsify, but never verify, since theorys can't be |
29 |
> verified without dogmas (and there are no accepted dogmas that would |
30 |
> help here). |
31 |
|
32 |
Thank you for your answer, Hans. This is more or less the information |
33 |
that I was looking for. |
34 |
|
35 |
So, on a laptop, after "halt"-ing the system, one should make sure to |
36 |
remove the battery and also pull the plug from the outlet. As far as I |
37 |
understand, this should more or less take care of the data stored in |
38 |
the RAM, _or_ give you the feeling that you did your best. If one |
39 |
enjoys being paranoid, one may also run "smem" on system shutdown. All |
40 |
this, of course, needs to be in combination with _at least_ an |
41 |
encrypted swap and tmpfs mounted on /tmp. |
42 |
|
43 |
One last reserve that I have towards this scheme is the information in |
44 |
the man page of smem (part of the secure-delete package, suite of |
45 |
utilities written by van Hauser from THC [ |
46 |
http://freeworld.thc.org/releases.php ]): |
47 |
"smem is designed to delete data which may lie still in your memory (RAM) |
48 |
in a secure manner which can not be recovered by thiefs, law enforcement |
49 |
or other threats. |
50 |
|
51 |
Note that with the new SDRAMs, data will not wither away but will be kept |
52 |
static - it is easy to extract the necessary information! |
53 |
The wipe algorythm is based on the paper "Secure Deletion of Data from |
54 |
Magnetic and Solid-State Memory" presented at the 6th Usenix Security |
55 |
Symposium by Peter Gutmann, one of the leading civilian cryptographers." |
56 |
|
57 |
This is either a very efficient advertising campaign for his utility, |
58 |
or he actually knows what he is talking about. For one part, the paper |
59 |
[ http://www.cs.auckland.ac.nz/~pgut001/pubs/secure_del.html ] |
60 |
dedicates two chapters to the data kept in the RAM. However, |
61 |
considering that the paper is dated 1996, and the secure-delete man |
62 |
page was last updated in 2003, there is also the possibility that this |
63 |
information is outdated. |
64 |
|
65 |
Again, thanks all for their input. Regards, |
66 |
Liviu |
67 |
-- |
68 |
gentoo-user@g.o mailing list |