On July 23, 2004 02:42 am, Oliver Welter wrote: > We use openssl to en/decrypt data with 3des - is it possible to > retrieve the used key while running a de/encryption via a memory > debugger or something similar ? Are there any preventions against such > attacks or has noone ever thought about such an attack ? > > I would appreciate any hints on related studys, documents, etc...
They all say more or less the same thing, even in the "ncipher inside(tm)" research that was quoted somewhere else in the thread, which is - if your threat-model includes access to the memory of the running process, then you're essentially hosed. Playing hide and seek with your key material or cleartext inside memory is a losing battle. Those who can do as they wish with your process memory can presumably track your code too, and so any hide-and-seek logic can be laid bare given sufficient motivation on the part of the attacker. This is (fortunately:-) the inherent lost cause of "secure" media - if everything required to decrypt a "secure" data stream into something that will make sense to our ears is contained in a system under my control, I can sandbox it, capture it, watch it, scan it, hack it, change it, as well as any other verbs you can think of pertaining to reverse engineering. The "solution" (if it's a problem that needs one) is to ensure that this logic doesn't execute in an environment under my control, in which case complexity arguments about how "hard" it is to break are pointless. The problem reduces to a boolean. If your perceived threats include network attacks, rogue processes, or multi-user systems, then privilege separation on top of a solid (and maintained) OS is your best hope. Ie. if user "beenhacked" can't attach to a process running as "hasntbeenhacked", then the memory scanning issue goes away. If he *can* attach to such a process, then "hasntbeenhacked" has been hacked after all. This property of privilege separation helps you build up diverse complex systems with security boundaries between the components (the same argument used to flog HKM hardware), and yet also explains why media/content distributors will continue to lose their rights jihad against system owners. IIRC, Bruce Schneier had another spiel on the technical futility of DRM in a recent cryptogram, which you might find useful w.r.t. technical arguments. The subject has been debated endlessly on numerous forums, you shouldn't have difficulty dredging up more commentary. But w.r.t. openssl, nothing out of the ordinary should be expected with respect to openssl's "protection" against these issues - it's not a question about correctness of the implementation (which *does* relate to openssl) but rather of the system and run-time environment (a probem it would be futile for openssl to address). It's a piece of rope, you can put it to any use you know a knot for ... Cheers, Geoff -- Geoff Thorpe [EMAIL PROTECTED] http://www.geoffthorpe.net/ ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
