> 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? 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
