On Thu, Feb 21, 2008 at 6:41 PM, <[EMAIL PROTECTED]> wrote: > > The paper you mentioned has some info on possible countermeasures. The > > best (IMO) is physically securing your RAM. This seems to fit in best > > with OpenBSD's philosophy, which has never been to put much time into > > thwarting attacks that require physical access to the box -- if you > > have that, there are MANY avenues of attack, most of which don't > > benefit much from immersing components in liquid N_2. > > > > Marti > > Then we could drop the whole encryption framework, or? > Why encrypting OWs? Nobody could crack the PWs if they don't have phisical > access.. why encrypting the HDDs or using IPSec? It's all about "physical > security" so why does OpenBSD care?
Sebastian, First off, I was not trying to be combative. I was trying to be realistic, however, which you clearly are not; IPSec and the encryption framework are all about physical protection? I think not. I am not against the other countermeasures described by these researchers; however, the performace hit of three extra load instructions on every memory location free()'d (as you suggested) would not be trivial, and would mostly be a waste of time; most memory on the 1000's of desktops you have in an enterprise is not storing hyper-sensitive data. I think that applications which are storing crypto keys should take responsibility to overwrite them as soon as practical, though even this wouldn't completely "solve" this problem. As you noted, a modification to free() wouldn't either. However, my point here is that applications can do this FAR more effectively than the OS can, with no drawbacks whatsoever (other than the possibility that something will be overlooked; however, a fault in the kernel would be far more dangerous, and if you can't trust your security developers to take basic precautions, why would you be using their software anyhow?) Security is part of a balancing act, with usability, performance and cost as counterweights. If your organization has 1000's of desktops with sensitive data floating around, you might want to look at taking a more holistic approach to security, and yes, users who let people take ram out of a system seconds after shutting it down should indeed be shot and/or tortured. Cheers, Marti > > I don't think it's that easy and I don't realy angree to your point of > view. From my point of view OpenBSD does a lot to assist to keep things > secure even the physical security was brocken (a thief, a bad admin or > whatever..). > > Of course there many kinds of attack but if somebody shutdowns your box > and reads the infos from your memory there's something we can do about it: > Overwriting.... > > Tell me how to ensure phyiscal security in bigger networks?! Should I > simply shot each user or just torture 'em? :-) > > I don't talk about a 50+ company where you know everybody but more about > 1k+ up to 130k users and more. > > For privacy it would be great to overwrite everything! > But this slows down the whole stuff too... > > Well my oppinion is still: If you modify the libs so that a call of free() > involves a overwriting of the memory all applications would transparently > use it. This would mean there's no need for a kernelpatch wich overwrites > free memory. But what if a application does not use free() before it got > terminated? in this case the informations would still lay around into the > memory.. > > if I'm wrong please correct me.. it's just that a slowdown is needed to > solve this (even partly). > > Kind regards, > Sebastian > > -- Systems Programmer, Principal Electrical & Computer Engineering The University of Arizona [EMAIL PROTECTED]
