Re: Crypto dongles to secure online transactions
Matt Crawford writes: -+--- | Imagine a couple of hundred million devices with updatable | firmware on them, and one or more rogue updates in the wild. So should or should not an embedded system have a remote management interface? If it does not, then a late discovered flaw cannot be fixed without visiting all the embedded systems which is likely to be infeasible both because some will be where you cannot again go and there will be too many of them anyway. If it does have a remote management interface, the opponent of skill focuses on that and, once a break is achieved, will use those self-same management functions to ensure that not only does he retain control over the long interval but, as well, you will be unlikely to know that he is there. This leads to a proposal on what to do about the future: Embedded systems, if having no remote management interface and thus out of reach, are a life form and as the purpose of life is to end, an embedded system without a remote management interface must be so designed as to be certain to die no later than some fixed time. Conversely, an embedded system with a remote management interface must be sufficiently self-protecting that it is capable of refusing a command. Long live HAL, --dan - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: TLS break
Anyone care to give a layman's explanation of the attack? The explanations I have seen assume a detailed knowledge of the way TLS/SSL handle re-negotiation, which is not something that is easy to come by without reading the RFC. (As opposed to the main protocol, where one can find textbook descriptions.) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Crypto dongles to secure online transactions
On 11/10/2009 09:44 AM, Jerry Leichter wrote: Not that this should block the use of devices like the ZTIC! They're still much more secure than the alternatives. But it's important to keep in mind the vulnerabilities we engineer *into* systems at the same time we engineer others *out*. vulnerabilities tend to be proportional to complexity. we had been asked in to consult with small client/server startup that wanted to do payment transactions on their server ... they had also invented this technology called SSL applied to the process. The result is frequently called electronic commerce. The major use/purpose of that SSL in the world today is hiding the account number and other transaction details. somewhat as a result, in the mid-90s we were invited to to participate in the x9a10 financial standard working group which had been given the requirement to preserve the integrity of the financial infrastructure for all retail payments. Part of that was detailed threatvulnerability studies of different payment methods and environments. One of the biggest problems was vulnerability of leaking account number ... since it was trivial for crooks to use it for originating fraudulent transactions ... and at the same time required by millions of business processes around the world. So part of the resulting standard was slightly tweaking the paradigm and eliminating the account number (and transaction details) as a vulnerability (which then also eliminates the major use of SSL in the world today). along the way, i also made semi-facetious comment that i would take a $500 milspec item and aggressively cost reduce it by 2-3 orders of magnitude while making it more secure. Part of the effort effectively worked out getting it close to the EPC RFID technology process (items targeted at replacing UPC barcodes on grocery items at a few cents or less) w/o reducing security. Basically it is all silicon ... which not only reduces a lot of after-FAB vulnerabilities ... but also eliminates the costs of a lot of the post-FAB processing steps (as silicon cost goes to zero, post-FAB processing costs started to dominate). Along with it is the concept of security proportional to risk ... at the issuing authorization end of a transaction ... the security characteristics of the originating components can be evaluated ... in the case of the chip ... the security level of the chip can even be updated in real time as vulnerabilities are identified. This can help decide like a when a few cent item might be needed to be replaced for higher value transactions -- 40+yrs virtualization experience (since Jan68), online at home since Mar1970 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: hedging our bets -- in case SHA-256 turns out to be insecure
On Wed, Nov 11, 2009 at 10:03:45AM +0800, Sandy Harris wrote: C(x) = H1(H1(x) || H2(x)) This requires two hash(x) operations. A naive implementation needs two passes through the data and avoiding that does not appear to be trivial. This is not ideal since you seem very concerned about overheads. If performance is really an issue one could code a combined H1/H2 function which would interleave the operations, which would prevent needing two passes (which _is_ really important since memory and disk latencies are usually the biggest factor in performance). Direct interleaving would also offer better ILP. But even updating both hashes at the same time would prevent needing two full passes; something like the code below would offer much better cache utilization, and would not be at all difficult to implement: while data_left: block = input.read_one_block() h1.compress(block) h2.compress(block) If it was really important, choosing a nonstandard H2 could offer even better performance; for instance let H1=SHA-256 and H2=SHA-~256, where SHA-~256 is precisely SHA-256 but with all of its constants bitwise inverted. One could compute both functions in parallel using SIMD (SSE2, ARM's NEON, etc) [and they could share the message expansion, which is quite costly in SHA-2]. It's not clear from a quick read of the paper Zooko referenced (On the Strength of the Concatenated Hash Combiner when All the Hash Functions are Weak) if this would actually meet the requirements of sufficiently different for the results there to apply, though. What about this construction: C(x) = H1(H2(x) || H3(x)) One trouble with this construction that Zooko's does not have is that it can fail even if H1 is collision resistant due to an inner collision. H3 might be some really cheap fast function invented for the situation. As I recall, the GOST hash just used a sum of input blocks, and that's enough to defeat the multi-block attacks. If it is simple enough, you can code it into your implementation of H2 so you only need one pass. The GOST hash does use the sum of input blocks (as the final input to the compression function) but it has a number of other components; it is actually quite slow compared to modern hashes. -Jack - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Crypto dongles to secure online transactions
On Nov 11, 2009, at 10:36 AM, Matt Crawford wrote: On Nov 10, 2009, at 8:44 AM, Jerry Leichter wrote: Whether or not it can, it demonstrates the hazards of freezing implementations of crypto protocols into ROM: Imagine a world in which there are a couple of hundred million ZTIC's or similar devices fielded - and a significant vulnerability is found in the protocol they speak. Imagine a couple of hundred million devices with updatable firmware on them, and one or more rogue updates in the wild. That's the flip side of the vulnerability - and it's exactly why I did *not* suggest that the fix for vulnerable algorithms frozen into silicon was to make them updatable. Of course, there *are* situations in which that makes sense. If one organization distributes the dongles, they could accept only updates signed by that organization. We have pretty good methods for keeping private keys secret at the enterprise level, so the risks should be manageable. -- Jerry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: TLS break
At Tue, 10 Nov 2009 20:11:50 -0500, d...@geer.org wrote: | | This is the first attack against TLS that I consider to be | the real deal. To really fix it is going to require a change to | all affected clients and servers. Fortunately, Eric Rescorla | has a protocol extension that appears to do the job. | ...silicon... Is the relevant silicon really this unprogrammable? -Ekr - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: hedging our bets -- in case SHA-256 turns out to be insecure
On Nov 11, 2009, at 10:03 AM, Sandy Harris wrote: On 11/8/09, Zooko Wilcox-O'Hearn zo...@zooko.com wrote: Therefore I've been thinking about how to make Tahoe-LAFS robust against the possibility that SHA-256 will turn out to be insecure. NIST are dealing with that via the AHS process. Shouldn't you just use their results? We could use a different hash function ... There are fourteen candidates left in the SHA-3 contest at the moment. Several of them have conservative designs and good performance, but there is always the risk that they will be found to have catastrophic design flaws or that a great advance in hash function cryptanalysis will suddenly show how to crack them. Yes, but there's also a risk that whatever you come up with will turn out to be flawed. I agree. The logic of a unknown flaw being fixed flies in the face of prudent cryptanalysis. If you don't know the flaw, how can do you know you can or have fixed it. What if there is an unknown flaw in the fix? Wrap that again? Turtles all the way down. Putting multiple insecure algorithms together does guarantee a secure one. The only solution that works is a new hash algorithm that is secure against this (and all other) vulnerabilities. It may include SHA 256 as a primitive, but a true fix is fundamentally a new hash algorithm. This process is being worked on by a large number of smart people. I can guarantee you that this kind of construction has been looked at. It is my opinion that putting a bandaid around SHA 256 just in case is not cryptanalysis, it's marketing. Jim P.S. once Sha-3 comes out, your bandaid will look silly. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Crypto dongles to secure online transactions
Ben Laurie benl google.com writes: Anyway, I should mention my own paper on this subject (with Abe Singer) from NSPW 2008, Take The Red Pill _and_ The Blue Pill: http://www.links.org/files/nspw36.pdf In writing on page 2 that you do not need to secure what you put in an Amazon shopping basket until you come to arrange payment and delivery you may be overlooking some things. Amazon's future recommendations are affected by what has been put in your basket; even if removed later. A compromised browser could show false prices and availability so causing you to choose expensive used goods from a crook and not discover cheaper sources. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: TLS break
On Wed, Nov 11, 2009 at 10:57:04AM -0500, Jonathan Katz wrote: Anyone care to give a layman's explanation of the attack? The explanations I have seen assume a detailed knowledge of the way TLS/SSL handle re-negotiation, The re-negotiation handshake does not *commit* both parties in the new handshake to the previous cryptographic state of the TLS connection. If the man in the middle is willing to encrypt/decrypt handshake packets between a client new to the connection, and a server with which the MITM completed an earlier handshake, the MITM can transfer an existing session from himself to the client (victim), after injecting some initial data into the connection. The integrity and confidentiality properties of the origimal MITM-server connection only protect both parties if neither party is willing to compromise those properties by proxying a 3rd party into the session. The new ingredient here, is that the 3rd party can be a victim, who is unaware of the proxying. The victim's handshake with the intended server is proxied into an already established TLS session by the MITM who is privy to the session state. The solution is to *commit* the two parties to a re-negotiation handshake to the previous handshake. -- Viktor. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Crypto dongles to secure online transactions
On Wed, Nov 11, 2009 at 09:42:21PM -0500, Jerry Leichter wrote:
[...]
If one organization distributes the dongles, they could accept
only updates signed by that organization. We have pretty good
methods for keeping private keys secret at the enterprise level,
so the risks should be manageable.
But even then, poor planning for things like key size (a la the
recent Texas Instruments signing key brute-forcing) are going to be
an issue.
--
{ IRL(Jeremy_Stanley); PGP(9E8DFF2E4F5995F8FEADDC5829ABF7441FB84657);
SMTP(fu...@yuggoth.org); IRC(fu...@irc.yuggoth.org#ccl); ICQ(114362511);
AIM(dreadazathoth); YAHOO(crawlingchaoslabs); FINGER(fu...@yuggoth.org);
MUD(fu...@katarsis.mudpy.org:6669); WWW(http://fungi.yuggoth.org/); }
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
ACM Workshop: Searching an Encrypted Cloud
Followup from the workshop: http://www.technologyreview.com/computing/23951/ saqib http://enterprise20.squarespace.com On Thu, Nov 12, 2009 at 1:23 PM, Ali, Saqib docbook@gmail.com wrote: ACM Workshop on November 13th (yes it is Friday the 13th) will cover the the topic of Searching for encrypted data in the Cloud: http://crypto.cs.stonybrook.edu/ccsw09/ http://www.technologyreview.com/computing/23929/?a=f - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
TLS MITM in action
http://www.securegoose.org/ Attacks twitter to post the HTTP auth header in a tweet from the victim... - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: TLS break
On 11 Nov 2009 at 10:57, Jonathan Katz wrote: Anyone care to give a layman's explanation of the attack? The explanations I have seen assume a detailed knowledge of the way TLS/SSL handle re-negotiation, which is not something that is easy to come by without reading the RFC. (As opposed to the main protocol, where one can find textbook descriptions.) I had a hard time with this, too, but this PDF really clarified it for me: http://extendedsubset.com/Renegotiating_TLS_pd.pdf Let me try a layman's explanation (assuming I have it right) We start assuming the attacker can to hijack or MITM the victim's TCP connections. The attacker opens *its*own* TLS connection to the server [so that is now being encrypted by a symmetric key the attacker picked] and sticks some data into the pipe. The victim wants a TLS connection and so begins negotiating one. The attacker just MITM's that as a *renegotiation* with the server for its TLS connection. (that is, the victim thinks they're negotiating a NEW TLS connection, but the attacker proxies that into a *renegotation* on the existing TLS connection). In short order the attacker is frozen out of the connection [since it will then be encrypted by a key picked by the victim], BUT: the victim's data will ride over the TLS connection that the attacker had previously set up and pre-loaded with some data, and so the victim's data *FOLLOWS* the attacker's -- the attacker was able to inject arbitrary data *in*front* of the victim's data. As I understand it, this is only really a vulnerability in situations where a command to do something *precedes* the authentication to enable the command. The obvious place where this happens, of course, is with HTTPS where the command [GET or POST] comes first and the authentication [be it a cookie or form vbls] comes later. /bernie\ -- Bernie Cosell Fantasy Farm Fibers mailto:ber...@fantasyfarm.com Pearisburg, VA -- Too many people, too few sheep -- - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Crypto dongles to secure online transactions
On Wed, Nov 11, 2009 at 9:53 AM, d...@geer.org wrote: Matt Crawford writes: -+--- | Imagine a couple of hundred million devices with updatable | firmware on them, and one or more rogue updates in the wild. So should or should not an embedded system have a remote management interface? If it does not, then a late discovered flaw cannot be fixed without visiting all the embedded systems which is likely to be infeasible both because some will be where you cannot again go and there will be too many of them anyway. If it does have a remote management interface, the opponent of skill focuses on that and, once a break is achieved, will use those self-same management functions to ensure that not only does he retain control over the long interval but, as well, you will be unlikely to know that he is there. This leads to a proposal on what to do about the future: Embedded systems, if having no remote management interface and thus out of reach, are a life form and as the purpose of life is to end, an embedded system without a remote management interface must be so designed as to be certain to die no later than some fixed time. Conversely, an embedded system with a remote management interface must be sufficiently self-protecting that it is capable of refusing a command. Almost every U.S.A. based bank that i have used own several physical branch locations. Maybe your country is different. Disable the service until the customer physically brings in the old hardware to be replaced with a new one to eliminate need for remote management. Our planet has too much electronic garbage to build permanent preprogrammed death. Long live HAL, --dan - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
