Re: OK, shall we savage another security solution?
Leichter, Jerry wrote: ... If you think about this in general terms, we're at the point where we can avoid having to trust the CPU, memory, disks, programs, OS, etc., in the borrowed box, except to the degree that they give us access to the screen and keyboard. (The problem of securing connections that go through a hostile intermediary we know how to solve.) The keyboard problem is intractable, though it would certainly be a step forward if at least security information didn't go through there. This could be done either by having a small data entry mechanism on the secure device itself, or by using some kind of challenge/response (an LCD on the device supplies a random value - not readable in any way by the connected machine - that you combine with your password before typing it in.) Maybe HDMI will actually have some use in providing a secure path to the screen? (Unlikely, unfortunately.) Would it not be possible to solve the keyboard problem by allowing a keyboard (e.g. USB) to be plugged directly into the device? Nicholas -- Salkyns, Great Canfield, Takeley, Bishop's Stortford CM22 6SX, UK Phone 01279 870285(+44 1279 870285) Mobile 07715 419728(+44 7715 419728) PGP public key ID: 0x899DD7FF. Fingerprint: 5248 1320 B42E 84FC 1E8B A9E6 0912 AE66 899D D7FF - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Scare tactic?
On 19 September 2007 22:01, Nash Foster wrote: http://labs.musecurity.com/2007/09/18/widespread-dh-implementation-weakness/ Any actual cryptographers care to comment on this? IANAAC. I don't feel qualified to judge. Nor do I, but I'll have a go anyway. Any errors are all my own work. AIUI, the weakness is that if you control one end of the DH exchange, you can force a weak key to be selected for the subsequent encrypted exchange that an external observer can easily guess. I would summarize the main findings as: If you are one participant in a DH key exchange, it is possible for you to reveal the agreed-upon shared secret. If you pwn an IKE server, you can decrypt and read all the traffic it is exchanging with peers. The clients of that server won't know that it's giving up all their data. Whether you do it by forcing the implementation to choose a weak key, or by just revealing the information that in each situation you already have under your control, seems to me like a mere technicality. I can't envisage any situation under which this would actually *increase* your exposure. However it is an implementation flaw and should be addressed just for the sake of tying up loose ends and doing things properly. cheers, DaveK -- Can't think of a witty .sigline today - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Scare tactic?
On Sep 19, 2007, at 5:01 PM, Nash Foster wrote: Any actual cryptographers care to comment on this? I don't feel qualified to judge. If the affected software is doing DH with a malicious/compromised peer, the peer can make it arrive at a predictable secret -- which would be known to some passive listener. But hey, if the peer is malicious or compromised to begin with, it could just as well do DH normally and explicitly send the secret to the listener when it's done. Not much to see here. -- Ivan Krstić [EMAIL PROTECTED] | http://radian.org - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Scare tactic?
Nash Foster wrote: http://labs.musecurity.com/2007/09/18/widespread-dh-implementation-weakness/ Any actual cryptographers care to comment on this? I don't feel qualified to judge. It seems to me that the requirement cited: Entity i cannot be coerced into sharing a key with entity j without i’s knowledge, ie, when i believes the key is shared with some entity l != j. is generally impossible to achieve in practice. Which is lucky: otherwise DRM would work. To address their particular complaint, one of the two parties must cooperate with the passive attacker to cause key leakage. If they are prepared to cooperate then they can leak the key anyway, and no amount of testing of public keys will prevent this. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.links.org/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Scare tactic?
On Wed, Sep 19, 2007 at 02:01:13PM -0700, Nash Foster wrote: http://labs.musecurity.com/2007/09/18/widespread-dh-implementation-weakness/ Any actual cryptographers care to comment on this? I don't feel qualified to judge. I am not a cryptographer, but the article appears silly. First the verification algorithm as stated is wrong: * Verify that 2 = K_a = p - 2 * Verify that (K_a)^g = 1 (mod p) The first condition is correct, but the second is not, that g should be a q, where q is a large prime divisor of p-1 and g is chosen so that the order of g mod p is q. The correct second test just verifies that K_a is an element of order q (true for all non-trivial powers of g). Even with the verification algorithm K_a can still be equal to a small power of g, which the passive eavesdropper can quickly brute-force. In fact the entire threat model is broken, because if Alice wants Eve to be able to crack Alice's key exchange with Bob, Alice can just send Eve her secret exponent. Why waste time with weak exponents that Bob may be able to detect if he so choses? So verification of the peer exponent has nothing to do with Allice colluding with passive eavesdroppers. Rather the issue is small-subgroup attacks, which are of interest in some cases (and not applicable in others). http://tools.ietf.org/html/rfc2785 Have not looked at IKE closely enough to comment on whether small subgroups are a concern in that context. -- /\ ASCII RIBBON NOTICE: If received in error, \ / CAMPAIGN Victor Duchovni please destroy and notify X AGAINST IT Security, sender. Sender does not waive / \ HTML MAILMorgan Stanley confidentiality or privilege, and use is prohibited. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Scare tactic?
On 9/19/07, Nash Foster [EMAIL PROTECTED] wrote: http://labs.musecurity.com/2007/09/18/widespread-dh-implementation-weakness/ Any actual cryptographers care to comment on this? I don't feel qualified to judge. It's a real (old) vulnerability in DH, but I don't think it applies here. If you want to expose the cleartext of your IPsec traffic, you can just send a copy to the observer. It makes mitm easier on unauthenticated links, but that's not a new exposure of any kind. From the article: There are a number of real-world scenarios where an unknown key-share completely undermines the legitimacy of networking infrastructure which is designed to provide high security. Funny how they didn't provide any details. -- Taral [EMAIL PROTECTED] Please let me know if there's any further trouble I can give you. -- Unknown - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Scare tactic?
On Wed, 19 Sep 2007, Nash Foster wrote: Any actual cryptographers care to comment on this? I don't feel qualified to judge. Not a single IKE implementation [...] were validating the Diffie-Hellman public keys that I sent. There are many ways to use DH key-agreement. The one described on the page is as follows: both A and B generate random values, exponentiate, exchange results, and derive the same value. In this case there is no point validating the `public key' A receives from B: if B colludes with an attacker (and generates the key belonging to a small subgroup), then B can as well tell the final secret to the attacker. The attack would make sense if it allows B to learn a long-term secret of A, but if the `private keys' are randomly generated on each exchange, then this problem does not exist. -- Regards, ASK - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Scare tactic?
Peter Gutmann wrote: Nash Foster [EMAIL PROTECTED] writes: http://labs.musecurity.com/2007/09/18/widespread-dh-implementation-weakness/ Any actual cryptographers care to comment on this? I don't feel qualified to judge. It's quite possible that many implementations do this. When the Mozilla folks changed their code a year or two back to reject RSA keys with an exponent of one (which in itself means that they'd been accepting those keys for years), a number of certs broke because CAs were issuing exponent-one keys, which in turn means that many other implementations that never complained about these certs were freely accepting them. Windows CryptoAPI, for example, still allows exponent-one keys as a by-design feature to allow the export of wrapped keys in plaintext form. So it's quite believable that a number of DH implementations allow bad key parameter values, and that this has been going on for years. (Even the level of validation discussed on the web page doesn't help entirely, FIPS 186 provides extra parameters that you can use for checking the key (p,q,g) while the still widely-used PKCS #3 doesn't (p,g), so even just using PKCS #3 rather than FIPS 186 is a problem). I wrote a series of articles on the problem of not verifying padding with small-exponent RSA. In the conclusion, it listed a number of well-known attacks against other public key systems, including small subgroup confinement. http://www.matasano.com/log/528/rsa-signature-forgery-explained-with-nate-lawson-part-vi/ The author of the Mu article does not list all the verification steps needed, and even seems to infer that the values g and p are negotiated between the two parties. This would be a bad idea, versus choosing a set of values that were pre-verified. This type of attack was even discussed in the realm of IPSEC back in 1997: http://www.vpnc.org/ietf-ipsec/97.ipsec/msg00629.html All this attack allows is for one side of a DH exchange to intentionally downgrade the security, but there's no reason one of them couldn't just publish the secure derived value AFTER completing the entire exchange. Or, publish their secret exponent. If this is not authenticated DH, then you have other problems. -- Nate - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: OK, shall we savage another security solution?
| If you think about this in general terms, we're at the point where we | can avoid having to trust the CPU, memory, disks, programs, OS, etc., | in the borrowed box, except to the degree that they give us access to | the screen and keyboard. (The problem of securing connections that | go through a hostile intermediary we know how to solve.) The keyboard | problem is intractable, though it would certainly be a step forward | if at least security information didn't go through there. This could | be done either by having a small data entry mechanism on the secure | device itself, or by using some kind of challenge/response (an LCD | on the device supplies a random value - not readable in any way by | the connected machine - that you combine with your password before | typing it in.) Maybe HDMI will actually have some use in providing | a secure path to the screen? (Unlikely, unfortunately.) | | Would it not be possible to solve the keyboard problem by allowing a | keyboard (e.g. USB) to be plugged directly into the device? Perhaps. Public systems usually don't have unpluggable keyboards. If I have to carry my own, I'm well on my way to just having my own portable system (which may be the way things end up anyway). -- Jerry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: OK, shall we savage another security solution?
On 20/09/2007, Nicholas Bohm [EMAIL PROTECTED] wrote: Would it not be possible to solve the keyboard problem by allowing a keyboard (e.g. USB) to be plugged directly into the device? Evidian (former Bull Soft) built such a gizmo. I think this is this: http://www.wcm.bull.com/internet/pr/rend.jsp?DocId=122881lang=en - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Scare tactic?
Ben Laurie wrote, On 21/9/07 1:34 AM: It seems to me that the requirement cited: Entity i cannot be coerced into sharing a key with entity j without i’s knowledge, ie, when i believes the key is shared with some entity l != j. The without i's knowledge part is critical to the argument, as the author is assuming that entity i is monitoring all of entity j's channels of communication and either entity j has no communication of any kind outside of that used for the DH protocol with entity i, or else entity i would be able to recognize whether any other communication with anyone is a revelation of the secret session key that entity i is sharing with entity j. Note that entity i would even have to be sure that entity j is not using any side channels such as variations in the timing of response packets during the subsequent encrypted session to communicate with a colluding passive attacker who is eavesdropping. That is an awfully impractical constraint on the threat model, which makes this issue moot in practice. Sidney Markowitz http://www.sidney.com - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
