On Wed, Sep 13, 2006 at 10:23:53PM -0400, Vin McLellan wrote: > [... a long message including much of what I can only regard as outright advertising for RSA, irrelevant to the actual technical weakness in the SID800 USB token that Hadmut described, and which Vin's message purportedly disputes. It would be nice if, when confronted with such a "response" in the future, the moderator of this list would return it to its author with the requirement that the marketeering be stripped out before the actual content be forwarded to this list! I have snipped everything irrelevant to my own response. ... ]
> None of these features -- none of the SID800's cryptographic > resources -- were of apparent interest to Mr. Danisch. He ignored > them all when he denounced the SID800 as "vulnerable by design." As well he should have, because they are utterly irrelevant to the genuine design flaw which he pointed out, and which Vin seeks to minimize (by burying it in irelevancies?) here. > What particularly disturbs Mr. D is one option among in the SID800 > SecurID features which allows RSA's local client software to poll and > retrieve a single OTP from the token when the SID800 is plugged into > the PC's USB port. Given the potential for malicious malware to > invade and take control of any Windows PC -- malware that can seize > and misuse both the user's PIN and an OTP fresh from the USB bus -- > it was irresponsible, Danisch suggests, for RSA to make such a option > available to its customers. And so it was. Vin simply handwaves away the fact that if RSA's client software can poll the token and retrieve the current OTP, so can any malicious software running on the host to which the token is attached. It is not correct to suggest that perhaps this could be done only once, when the token were first plugged in to the host system's USB port, because USB *by design* allows the host to cut and restore power to devices under software control, so that the SID800 can, even if it somehow is intended to only allow token retrieval "once upon plug-in and once only" (something Vin seems to imply, but does not directly state) simply be repeatedly tricked into thinking that it has just been plugged in. > In the second version of the SID800 -- an option selectable by local > management pre-purchase, and burnt into the token's USB firmware by > RSA -- the user can select a menu in which he instructs the SecurID > to load one OTP token-code directly into the paste buffer, presumably > for immediate use. Since internal access to the SecurID's OTP via the > USB bus makes it a potential target for "malware or intruders on the > computer," claimed Mr. Danisch, "This is weak by design." I beg to > differ. Effective IT security is about an appropriate balance, not > walls of iron or stone. "Good cooking is about full-bodied flavor, not wire rope or persian kittens"; but let's leave the irrelevant analogy aside and stick to the facts that seem to be discussed here, I suppose. Vin claims that the user "instructs the SecureID to load one OTP token-code directly into the paste buffer". This is a very, very odd claim, because it implies that the user communicates directly with a USB peripheral and "instructs" _the peripheral_ to autonomously "load" a token-code -- some bytes -- into an area in host memory that is used by the host operating system's user interface. We should note that, unlike Firewire, USB *does not include a mechanism by which a peripheral on the bus may initiate a DMA transfer into the memory of the host system that is the master of the bus* so clearly what Vin claims cannot be strictly true. What, then, should we think that it likely means? I think he must mean something like this: "The user instructs the RSA-supplied application code running on the host system to retrieve one token code from the SecureID across the USB bus, and place that retrieved token code into the paste buffer." If that is not what Vin means, I think that he should respond and say exactly what he does mean, in a way that does not make reference to mythical properties that USB peripherals do not have. Now, consider what it means that it is even _possible_ for the RSA- supplied application to retrieve a token code from the SID800 in this way. It means that by, at worst, cutting and restoring power to the USB port in question, malicious software can retrieve *a new, current token code* *any time it wants to do so*. In other words, while, with traditional SecureID tokens, it is possible for malicious software to steal token codes typed by the user into a compromised host system _when the user types them_, and by engaging in a man-in-the-middle scheme impersonate the intended target system to the user _that once_ (since SecureID token codes can not be used twice), this new system does, in fact, open up the gaping new security hole Hamisch claims it does: With this USB-connected token, malicious software on the host can poll the token and retrieve a *new* token-code *any time it wants to*, without the user's intervention and with no need to implement a complex man-in-the-middle attack on the user to avoid the user's notice. > Can this token-code in the paste buffer be misused? Not likely, even > if it is immediately stolen by malware and immediately used for some > nefarious purpose. And here we see that Vin evidently does not understand the nature of the vulnerability RSA has created with their USB-connected token and host software, because he seems to think that the problem is that the software, by design, places a single token-code in the paste buffer; as he notes, malicious software that could steal that code could just as easily steal a code from a traditional SecureID token typed in by the user. But that is not the problem! The problem is that _because there is an interface to poll the token for a code across the USB bus_, malicious software can *repeatedly* steal new token codes *any time it wants to*. This means that it can steal codes when the user is not even attempting to authenticate, and so the SecureID server's traditional countermeasure of denying near-simultaneous attempts to use the same token code becomes *entirely worthless* for there will be no genuing, user-initiated authentication attempt for the attacker's submission of the stolen code to be simultaneous *with*. It seems clear, in fact, that whether RSA has burned the "OTP paste" feature into the token's firmware or not, any USB-connected token that works even remotely like the SecureID token is vulnerable to this kind of attack. As long as token codes can be requested by the host system across the USB bus and are passed back by the token, without the user's intervention, an attacker can use software on the host to steal token codes when the user is *not* present to cause a simultaneous authentication attempt (and thus raise an alarm on the server) and use them, along with a keylogged password, at will. It is noteworthy that a token that requires *any* kind of intervention by the user -- even something as simple as a press of a button on the token which illuminates when the host presents the token-code request -- is invulnerable to such an attack, potentially at a much lower cost in terms of user interface difficulty than the traditional SecureID token where the user's action is to type in the entire token-code by hand. It is regrettable that instead of wasting time (and, evidently, the time of its consultants) trying to handwave away the severe security problem with the SID800 design, RSA does not turn its efforts to the design of tokens which use simpler mechanisms (like the aforementioned button-press) to ensure that the user is present, and thus maintain security while not imposing on the user the onerous requirement of typing in the whole code. > PS. I have been a consultant to RSA for nearly 20 years and my bias > is overt. I beg the indulgence of the List for the length of my comments. Simply to clear the air, I would like to ask Vin to answer the following simple question: did you compose and send your response to Hadmut at the request or suggestion of someone at RSA, or was the idea to send it entirely your own? Thor P.S. I am not and never have been a consultant to, shareholder in, nor employee of, RSA nor any other company in the token or smart-card market. If what I write is emphatic, that is probably because of my intense dislike for long, equivocating messages full of what I can only regard as marketing language, when they appear on technical lists in response to genuine technical contributions. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]