Re: key compromise with memory debugger possilbe ?
Oliver Welter wrote: We made a concept for a secure media player and now try to attack it - the openssl related question is: 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 ? After the decryption you end up with a unprotected audio/video stream, correct? Now why should the attacker spend time with finding the key hidden somewhere in the process memory when he can probably more easily capture the decrypted data that you serve him almost right on his table? But as long as he has access to the player process' memory you lost anyway. The only question now is which way to choose to get the unprotected data :-) Just my 2 cents... Michal Ludvig __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: key compromise with memory debugger possilbe ?
Hello Lev, thx for the quick answer 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 ? yes. Are there any preventions against such attacks or has noone ever thought about such an attack ? the problem is: you cannot completely eliminate all possible ways to attack the system. plan for building the system for which the cost of stealing the key would be barely more than expected damage which can possibly occur from breaking the system. that's the golden practical rule. yes of course - you must find the balance between paranoid and necessary ;) Are there any studies or test that have dealt with this issue ? That it is theoretically possible was clear to me, the question meant if it is enough possible for practical relevance - I even can hack a 3des key in a certain amount of time - so there is of course no 100% security... TIA Oliver -- Diese Nachricht wurde digital unterschrieben oliwel's public key: http://www.oliwel.de/oliwel.crt Basiszertifikat: http://www.ldv.ei.tum.de/page72 smime.p7s Description: S/MIME Cryptographic Signature
Re: key compromise with memory debugger possilbe ?
Oliver Welter wrote: Hello Lev, thx for the quick answer 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 ? [skip] plan for building the system for which the cost of stealing the key would be barely more than expected damage which can possibly occur from breaking the system. that's the golden practical rule. yes of course - you must find the balance between paranoid and necessary ;) Are there any studies or test that have dealt with this issue ? That it is theoretically possible was clear to me, the question meant if it is enough possible for practical relevance - I even can hack a 3des key in a certain amount of time - so there is of course no 100% security... this is very trivial. the key is contained clear-text in the memory image of a process (/dev/mem, or whatever). To try to decrypt the data with the key, the simplest case is a brute-force: fetch a memory region at location X, treat it as a key, and try to decrypt an encrypted data. You certainly have to have an algorithm to determine with high probability that decription has succeeded, but it is quite easy for most structured data, including audio formats. The complexity of this task is linear with amount of process memory: for 5 mbyte process the whole process will take certainly less than an hour of average computer. do you really need a study to believe that? -- Lev Walkin [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: key compromise with memory debugger possilbe ?
Lev Walkin wrote: Oliver Welter wrote: Hello Lev, thx for the quick answer 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 ? [skip] plan for building the system for which the cost of stealing the key would be barely more than expected damage which can possibly occur from breaking the system. that's the golden practical rule. yes of course - you must find the balance between paranoid and necessary ;) Are there any studies or test that have dealt with this issue ? That it is theoretically possible was clear to me, the question meant if it is enough possible for practical relevance - I even can hack a 3des key in a certain amount of time - so there is of course no 100% security... this is very trivial. the key is contained clear-text in the memory image of a process (/dev/mem, or whatever). To try to decrypt the data with the key, the simplest case is a brute-force: fetch a memory region at location X, treat it as a key, and try to decrypt an encrypted data. You certainly have to have an algorithm to determine with high probability that decription has succeeded, but it is quite easy for most structured data, including audio formats. The complexity of this task is linear with amount of process memory: for 5 mbyte process the whole process will take certainly less than an hour of average computer. P.S. I am being unfair to a certain extent. Good security-conscious programming provides several techniques to lower the window of opportunity for the attacker to gain the access to this data. For example, it is customary to wipe the key from the memory after it was used to encrypt the data. The anti-swap techniques (mlockall(2)) are also widely used. -- Lev Walkin [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: key compromise with memory debugger possilbe ?
hi Lev, [stuff deleted] this is very trivial. the key is contained clear-text in the memory image of a process (/dev/mem, or whatever). To try to decrypt the data with the key, the simplest case is a brute-force: fetch a memory region at location X, treat it as a key, and try to decrypt an encrypted data. You certainly have to have an algorithm to determine with high probability that decription has succeeded, but it is quite easy for most structured data, including audio formats. The complexity of this task is linear with amount of process memory: for 5 mbyte process the whole process will take certainly less than an hour of average computer. That was the part Im looking for - unfortunatley :( P.S. I am being unfair to a certain extent. Good security-conscious programming provides several techniques to lower the window of opportunity for the attacker to gain the access to this data. For example, it is customary to wipe the key from the memory after it was used to encrypt the data. The anti-swap techniques (mlockall(2)) are also widely used. Hmm, if I want to decrypt a 2 hour movie I have no chance to delete the key before the movie was decrypted, so there is enough time to get it from the memory And I dont need the study for knowing that it is possible - the question is how easy it is and if we can make it more difficult (we have some ideas...) and I just wanted to know if there have been some considerations within the team... One Idea is, not to store the full key but the derived chunks and produce some noise around the parts - so you are unable to read the whole key. Using your approach to try every piece of memory as a key will render unusable because you now must try every combination of three randon pieces of memory - I think this will significantl raise the computing time into infinity ;) Thanks for your opinion Oliver -- Diese Nachricht wurde digital unterschrieben oliwel's public key: http://www.oliwel.de/oliwel.crt Basiszertifikat: http://www.ldv.ei.tum.de/page72 smime.p7s Description: S/MIME Cryptographic Signature
AW: key compromise with memory debugger possilbe ?
For an official statement you may ask the BSI (GISA, German Information Security Agency) for that topic. They support the use of open-source software in the gouvernment and administration an may be can tell something more about vulnerabilities of that kind. Best regards Thomas Beckmann -Ursprüngliche Nachricht- Von: Oliver Welter [mailto:[EMAIL PROTECTED] Gesendet: Freitag, 23. Juli 2004 08:42 An: [EMAIL PROTECTED] Betreff: key compromise with memory debugger possilbe ? Hello List, As I am new here I frist want to introduce myself - I am a scientific employee at Technische Universitaet Muenchen and we do some research on DRM related security mechanisms. We made a concept for a secure media player and now try to attack it - the openssl related question is: 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... best regards Oliver -- Diese Nachricht wurde digital unterschrieben oliwel's public key: http://www.oliwel.de/oliwel.crt Basiszertifikat: http://www.ldv.ei.tum.de/page72 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: key compromise with memory debugger possilbe ?
In message [EMAIL PROTECTED] on Fri, 23 Jul 2004 09:53:08 +0200, Oliver Welter [EMAIL PROTECTED] said: mail One Idea is, not to store the full key but the derived chunks mail and produce some noise around the parts - so you are unable to mail read the whole key. Using your approach to try every piece of mail memory as a key will render unusable because you now must try mail every combination of three randon pieces of memory - I think mail this will significantl raise the computing time into infinity ;) That is an idea, and it does raise the computing time, for the decryption function itself as well, at least as far as I can see right now. OpenSSL doesn't make much effort to lock pages in RAM and doesn't split up the key in parts as you suggest, so the keys are wide open while processing is going on. If you use the EVP interface, all the cipher data is cleaned up with EVP_CIPHER_CTX_cleanup(), basically by being overwritten with random bytes. In all other cases (if the raw, low-level cipher functions are used), it's the application's job to clean up. The easiest thing to do would probably be to do the splitting in chunks that you suggest. The trouble is that all OpenSSL structures are entirely public, which means that any change leads to yet another round of incompatibility and people who're whining about changed APIs and such. Still, it might be worth looking into... Cheers, Richard - Please consider sponsoring my work on free software. See http://www.free.lp.se/sponsoring.html for details. -- Richard Levitte \ Tunnlandsvägen 52 \ [EMAIL PROTECTED] [EMAIL PROTECTED] \ S-168 36 BROMMA \ T: +46-708-26 53 44 \ SWEDEN \ Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED] Member of the OpenSSL development team: http://www.openssl.org/ - A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: key compromise with memory debugger possilbe ?
I think I read something that may help you in the article Playing hide and seek with stored keys by Adi Shamir and Nicko van Someren. The abstract: In this paper we consider the problem of efficiently locating cryptographic keys hidden in gigabytes of data, such as the complete file system of a typical PC. We describe efficient algebraic attacks which can locate secret RSA keys in long bit strings, and more general statistical attacks which can find arbitrary cryptographic keys embedded in large programs. These techniques can be used to apply lunchtime attacks on signature keys used by financial institutes, or to defeat authenticode type mechanisms in software packages. Keywords: Cryptanalysis, lunchtime attacks, RSA, authenticode, key hiding. True it is focus on finding key metarial of filesystems, but nevertheles, it should be a valid approach for memory dumps. You can download it from www.ncipher.com after registration. Hope it helps. Roberto López Navarro Consultor Preventa [mailto:[EMAIL PROTECTED] Tfno: +34 91 806 16 00 Fax: +34 91 806 16 99 SGI Soluciones Globales Internet S.A. [http://www.sgi.es] Isaac Newton nº 11 Tres Cantos (Madrid) 28760 Spain Secure e-Solutions -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Oliver Welter Sent: viernes, 23 de julio de 2004 8:42 To: [EMAIL PROTECTED] Subject: key compromise with memory debugger possilbe ? Hello List, As I am new here I frist want to introduce myself - I am a scientific employee at Technische Universitaet Muenchen and we do some research on DRM related security mechanisms. We made a concept for a secure media player and now try to attack it - the openssl related question is: 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... best regards Oliver -- Diese Nachricht wurde digital unterschrieben oliwel's public key: http://www.oliwel.de/oliwel.crt Basiszertifikat: http://www.ldv.ei.tum.de/page72 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: key compromise with memory debugger possilbe ?
Roberto López Navarro wrote: I think I read something that may help you in the article Playing hide and seek with stored keys by Adi Shamir and Nicko van Someren. The abstract: In this paper we consider the problem of efficiently locating cryptographic keys hidden in gigabytes of data, such as the complete file system of a typical PC. We describe efficient algebraic attacks which can locate secret RSA keys in long bit strings, and more general statistical attacks which can find arbitrary cryptographic keys embedded in large programs. These techniques can be used to apply lunchtime attacks on signature keys used by financial institutes, or to defeat authenticode type mechanisms in software packages. Keywords: Cryptanalysis, lunchtime attacks, RSA, authenticode, key hiding. True it is focus on finding key metarial of filesystems, but nevertheles, it should be a valid approach for memory dumps. You can download it from www.ncipher.com after registration. Whoever reads it, makr sure you realize that locating the key material is vastly different from locating the key material having the piece of encrypted data and posessing the knowledge about the structure of data being encrypted. The last one may be exponentially easier. -- Lev Walkin [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: key compromise with memory debugger possilbe ?
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]
RE: key compromise with memory debugger possilbe ?
As I am new here I frist want to introduce myself - I am a scientific employee at Technische Universitaet Muenchen and we do some research on DRM related security mechanisms. The short answer is that you cannot reliably both grant and deny access to the same entity. We made a concept for a secure media player and now try to attack it - the openssl related question is: What does secure mean? If secure means only authorized users can access the media, then fine. If secure means that the same individuals can both access and not access the same media, ... 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 ? The prevention is this simple -- do not give the key to anyone not authorized to use the media. That's how keys work -- you make sure the people who aren't supposed to access the encrypted item don't have the key. The encryption protects the media from people who *don't* have the key. DS __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
