Re: RSA SecurID SID800 Token vulnerable by design
I wouldn't dispute any of the arguments made in the original or subsequent posts on this topic pointing out that the programmatic interface to the device opens a security hole. But I think it needs to be said that this is only in the environment where trojans, etc., can infiltrate the machine. Acknowledged... this is probably in 99.99% of the applications. But in defense of the product, there are server-to-server type applications that don't involve a human which wouldn't be able to provide this style of two-factor authentication without a programmatic interface. And without hardward-based security solutions for these types of systems, they are vulnerable to compromise of keys and secrets by administrators. With a little physical security and isolation from the types of use that put them at risk for trojans, etc., the security hole under fire doesn't really exist. These systems do gain more security... by providing a device that doesn't allow an administrator to walk away with the secrets. Maybe server-to-server applications weren't really the intended market for this particular product, but the point is that you need to be careful with blanket criticisms. Regards, Paul Zufeldt - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: RSA SecurID SID800 Token vulnerable by design
On 9/15/06, Daniel Carosone [EMAIL PROTECTED] wrote: But let's not also forget that these criticisms apply approximately equally to smart card deployments with readers that lack a dedicated pinpad and signing display. This looks mildly interesting: http://www.projectblackdog.com/product.html I guess it uses an autorun file on Windows; I wonder whether most systems allow you to effectively launch X. The docs say it connects via ethernet over USB, so you're effectively a thin X client. Nice that it's open-source. Good idea, still vulnerable to software surveillance and host OS. No display. This looks more interesting: http://fingergear.com/bio_computer_on_a_stick.php This has a display, a fingerprint reader, runs Linux, has many common apps (office-compatible suite), IM, etc. More relevant to the list, it has a OTP generator, so this is effectively a security token. See: http://fingergear.com/faq1.php#4 Unfortunately, it looks like you can't reimage it without wiping everything, and then you lose the OS. I hope you can get a modifiable OS image and install it just as one would save data to the USB drive, but it could be impossible. The worst cost for these more advanced methods may be in user acceptance: having to type one or more things into the token, and then the response into the computer. A USB connected token could improve on this by transporting the challenge and response, displaying the challenge while leaving the pinpad for authentication and approval. I wonder if the ubiquitous fingerprint reader could replace the need for lots of buttons; controls tend to be the most expensive and fragile part of electronic devices. I wonder why nobody has an open-source cell phone that does voice recognition yet. That would seem to be the ideal solution, wouldn't it? You're already carrying one around, and you have a keypad for dialing (can be used for PIN), LCD panel for output, and if you have a fingerprint reader, enough juice to perform some crypto, and a USB or bluetooth connector (for storage and communication) it'd be perfect. -- On the Internet noone knows you're a dog - except Bruce Schneier. Unix guru for rent or hire -- http://www.lightconsulting.com/~travis/ GPG fingerprint: 9D3F 395A DAC5 5CCC 9066 151D 0A6B 4098 0C55 1484 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: RSA SecurID SID800 Token vulnerable by design
On Thu, Sep 14, 2006 at 02:48:54PM -0400, Leichter, Jerry wrote: | 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 I think this summarizes things nicely. Me too. While less emphatic, my reaction to Vin's post was similar to Thor's.. that it seemed to at least miss, if not bury, this point. But let's not also forget that these criticisms apply approximately equally to smart card deployments with readers that lack a dedicated pinpad and signing display. For better or worse, people use those to unlock the token with a pin entered on the host keyboard, and allow any authentication by any application during a 'session', too. Pressing the button supplies exactly the confirmation of intent that was lost. And further, a token that includes more buttons (specifically, a pinpad for secure entry of the 'know' factor) is vulnerable to fewer attacks, and one that permits a challenge-response factor for specific transaction approval is vulnerable to fewer again (both at a cost). Several vendors have useful offerings of these types. The worst cost for these more advanced methods may be in user acceptance: having to type one or more things into the token, and then the response into the computer. A USB connected token could improve on this by transporting the challenge and response, displaying the challenge while leaving the pinpad for authentication and approval. But the best attribute of tokens is they neither use nor need *any* interface other than a user interface. Therefore: * it works anywhere with any client device, like my phone. I choose my token model and balance user overhead according to my needs. * it is simple to analyse. How would you ensure the above ideal hypothetical USB token really couldn't be subverted over the bus? By the time you've given up that benefit, and done all that analysis, and dealt with platform issues, perhaps you might as well get the proper pinpad smartcard it's starting to sound like, and get proper signatures as well, rather than using a shared-key with the server. -- Dan. pgpotlLAwVOtZ.pgp Description: PGP signature
Re: RSA SecurID SID800 Token vulnerable by design
On Cryptography, and in several other online forums, Hadmut Danisch [EMAIL PROTECTED], a respected German information security analyst, recently published a harsh critique of one optional feature in the SID800, one of the newest of the six SecurID authentication tokens -- some with slightly different form-factors, others with additional security functions -- sold by RSA. It's raised quite a stir, and I'd like to respond. A personal authentication token, by classical definition, must be physical, personal, and difficult to counterfeit. The most popular implementations in computer security move the calculation of a pseudo-random authentication code -- a so-called One-Time Password, or OTP-- off an employee's PC and into a hand-held hardware fob, small enough to be attached to a personal key chain. RSA's mainstay token, the SID700 SecurID -- millions of which are used in over 20,000 enterprise installations worldwide, including many government agencies and financial institutions -- use AES (the US cryptographic standard) to process Current Time and a 128-bit token-specific secret to generate and continuously display a series of 6-8 digit (or alphanumeric) OTP token-codes which change every 60-seconds, and remain valid only for a couple of minutes. In practice, a RSA authentication server can then independently calculate the token-code that is appearing on a specific SecurID at this particular moment; compare that against an OTP submitted by a pre-registered user, and validate a match. RSA, which first introduced the SecurID in 1987, has always insisted on the necessity of two-factor authentication (2FA), where a remote RSA authentication server must validate both a SecurID token-code (evidence of something held) and a user-memorized PIN or password (something known.) A stolen password can be reused indefinitely to masquerade as the legitimate user, often with the victim wholly unaware. A token-generated OTP, valid only briefly, is a far more robust authenticator. With 2FA, if a SecurID is stolen or lost, it still can't be used to obtain illicit access to protected resources without the second secret: the user's memorized PIN or password. The elegant simplicity of the traditional SecurID -- and patents on the mechanism by which the drift in each individual SecurID's internal clock is tracked by the RSA authentication server -- has allowed RSA's time-synched SecurID to dominate the market niche for hand-held OTP authentication devices for 20 years. In a typical installation, anyone seeking to log on to a protected PC or network, or to access restricted online resources, must manually type in the OTP currently displayed on the SecurID -- as well as his memorized PIN or password -- to have his identity and access privileges validated. Network applications handle the combined SecurID pass-code like any long traditional password. The link between the user and the RSA infrastructure is often, but not always, an encrypted VPN channel. That's a local decision. Data exchanges between the RSA agent and RSA authentication server -- which typically means between one of the 350-odd SecurID-aware network applications and the RSA Authentication Manager, using RSA's own protocol -- are always fully encrypted. Mr. Danisch is an admirer of the classic SecurID (SID700), RSA's traditional hand-held token. His ire is directed at one of the two new hybrid SecurID designs that RSA has recently offered in an attempt to respond to new requirements in the boisterous and rapidly-evolving market for what's called strong authentication. With the nascent prospect of a new billion-dollar market in consumer authentication for financial services boosted by US federal regulatory initiatives, RSA announced the SecurID Signing Token, the SID900. The SecurID Signing Token still has a time-synched OTP, but RSA added a keypad and a challenge/response function which successively authenticates the user, the remote server, and a specific financial transaction, before the transaction (e.g., a funds transfer) is executed. On the other side of the market -- where again US laws and federal regulatory initiatives have boosted demand for internal controls and more accountability measures in enterprise IT -- RSA has introduced the SID800, another hybrid SecurID, to meet the requirements of organizations that want to move into a full public key infrastructure (PKI.) The SID800 SecurID is a multi-function authentication and cryptographic device that combines, in a single DPA-resistant token, the mobility and availability of the classic hand-held SecurID, as well as a smart chip that implements v2.1.1 Java tech (essentially a virtual smart card) in a USB format. It looks like a slightly smaller version of the classic SecurID key fob, with a USB plug jutting out at one end. It can carry up to seven X.509 digital certificates for PKI, as well as account information and
Re: RSA SecurID SID800 Token vulnerable by design
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
Re: RSA SecurID SID800 Token vulnerable by design
| 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 I think this summarizes things nicely. Moving to a higher level of abstraction: With a traditional token, if the correct value has been entered, we can reasonably assume intent on the part of the human being in possession of the token to identify himself, and thus take responsibility for some set of actions. With the additional something you know password associated with the token, we can further reasonably assume that the person in possession of the token is in fact the person who has the right to possess that token.* In the case of a software-readable USB token, *neither* assumption is reasonable. The resulting authentication is very different in kind. | 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... Pressing the button supplies exactly the confirmation of intent that was lost. (However, it can't get you to the assumptions about the right person having possession of the token. The fingerprint scanning technologies that one sees in some USB drives today would probably be reasonable for that purpose - not that one has much information about their false positive rates or how hard they really are to attack. I don't know what the costs are, however - low enough for ~$100 drives, maybe not low enough for an ID token.) -- Jerry * Yes, there are attacks that render these assumptions invalid. Nothing is perfect. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: RSA SecurID SID800 Token vulnerable by design
Lance James wrote: Agreed, and since my research is focused on online banking I can see yours and my point, either way, SecurID should not be the only concept for dependence. as i've mentioned serveral times, in the mid-90s, the x9a10 financial standards working group was given the task of preserving the integrity of the financial infrastructure for all retail payments. the result was x9.59 standard http://www.garlic.com/~lynn/x959.html#x959 which specified (end-to-end) authenticated transaction (and a business rule that account numbers used in x9.59 transactions could not be used in non-authenticated transactions) ... recent, related post: http://www.garlic.com/~lynn/aadsm25.htm#24 DDA cards may address the UK ChipPin woes part of the issue was with the actual transactions being signed and running end-to-end ... and account numbers no longer vulnerable to naked exploits ... it was no longer necessary to hide the account number (as countermeasure to prevent fraudulent replay attack transactions). http://www.garlic.com/~lynn/subpubkey.html#harvest the issue then became end-point attacks; either the originating end-point or the authorizing end-point. most infrastructure have had the authorizing end-points pretty well armored for some time. that primarily leaves vulnerabilities at the originating end-point. part of the EU finread terminal work was to close off some of the originating end-point vulnerabilities. http://www.garlic.com/~lynn/subpubkey.html#finread basically an independent, secure token terminal with its own display and key-entry. the transactions is forwarded from the end-point to the finread terminal ... the finread terminal displays a summary of the transaction details ... and passes it to the token for digital signing. any pin-entry (for two-factor authentication ... token something you have and pin-entry something you know) is performed at the finread terminal (minimizing any pin evesdropping and associated pin replay attack exploits). while session encryption is useful for confidentiality and privacy of the operations ... a lot of existing session encryption is primarily because existing transactions don't have end-to-end armored authentication ... leaving various pieces of information involved in the actual transaction naked and vulnerable to various kinds of replay attacks. the x9.59 standards approach was to provide end-to-end armoring of the actual transactions ... eliminating numerous kinds of replay vulnerabilities and some of the man-in-the-middle attacks http://www.garlic.com/~lynn/subpubkey.html#mitm ... independent of any possible use of authentication for session purposes note that while it isn't part of the x9.59 standard ... the standard was carefully crafted such that end-point environments like the EU finread would be allowed to also sign transactions. the issue is that the responsible authorization end-point frequently will be doing risk assessment (especially involving financial transactions). it is easy to see that a eu finread terminal provides a much higher integrity digital signing environment that many personal computers (for instance, virus software than log the entered pin and replay it to a connected hardware token w/o the person's knowledge) ... it is useful to have some knowledge about the transaction originating environment when doing risk assessment. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: RSA SecurID SID800 Token vulnerable by design
Hadmut Danisch wrote: Hi, I recently tested an RSA SecurID SID800 Token http://www.rsasecurity.com/products/securid/datasheets/SID800_DS_0205.pdf The token is bundled with some windows software designed to make user's life easier. Interestingly, this software provides a function which directly copies the current token code into the cut-and-paste buffer, when the token is plugged in into USB. This is weak by design. The security of these tokens is based on what RSA calls two-factor user authentication: It takes both a secret (PIN) and the time-dependend Token-Code to authenticate. The security of the Token-Code depends on the assumption that the token is resistant against malware or intruders on the computer used for communication (web browser, VPN client,...). Hi Hadmut, Another problem from what I see with Malware that steals data is the formgrabbing and on event logging of data. Malware can detect if SecureID is being used based on targeted events, example: Say HSBC (Hypothetical example, not targeting HSBC) has two-factor logins in place, the problem with this is that it is vulnerable to session riding and trojan-in-the-middle attacks anyway, because the minute the user logs in, the malware could launder money out (unless transaction auth is in place, which in most cases it's not), or they could pharm the user with a fake website that resolves as HSBC but they go in within the time frame of that token being valid and have access. Either way, however you cut it, SecureID/Two-Factor User auth is not protected against malware, period. However, if the Token Code can be read over the USB bus, this assumption does not hold. A single attack on the PC where the token is plugged in would compromise both the PIN (e.g. with a keylogger) and the token itself (e.g. writing a daemon which continuously polls the token and forwards the token in real time to a remote attacker. Ironically this could make an attack even easier: If some malware simultaneously monitors the token and the keyboard, it is much easier to detect that the keystrokes are actually related to some login procedure: Whenever the 6-digit token code appears in the keyboard or cut-and-paste input stream, you can be pretty sure that in a sliding window of about the last 100-200 keystrokes both the PIN and the address of the server to login is contained. Makes it really easy to automatically detect secrets in the input stream. Thus, two different authentication methods are together weaker than each single one. regards Hadmut - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] -- Best Regards, Lance James Secure Science Corp. http://www.securescience.net - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: RSA SecurID SID800 Token vulnerable by design
Hi Lance, On Fri, Sep 08, 2006 at 10:26:45AM -0700, Lance James wrote: Another problem from what I see with Malware that steals data is the formgrabbing and on event logging of data. Malware can detect if SecureID is being used based on targeted events, example: Say HSBC (Hypothetical example, not targeting HSBC) has two-factor logins in place, the problem with this is that it is vulnerable to session riding and trojan-in-the-middle attacks anyway, because the minute the user logs in, the malware could launder money out (unless transaction auth is in place, which in most cases it's not), or they could pharm the user with a fake website that resolves as HSBC but they go in within the time frame of that token being valid and have access. Either way, however you cut it, SecureID/Two-Factor User auth is not protected against malware, period. Partly agreed. These kinds of attacks I usually teach in my workshops. However, in all of these cases the attacker has to be online in the moment you are logging in and you experience any failure, e.g. can't login or something like that. But with the SID800 malware could silently sit in the background and pass token codes to the attacker even if you do not login at this moment. E.g. it could wait until you have logged in (or out) and grap the next token code. Furthermore, the attack you described presumes that the attacker knows where you want to login. But when you could use the current token code as an indicator for searching login data in the input stream, then you can find new places to login, e.g. your company VPN access point. While the attack you describe is more important for banking, the USB attack is more against company logins. regards Hadmut - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: RSA SecurID SID800 Token vulnerable by design
Hadmut Danisch wrote: Hi Lance, On Fri, Sep 08, 2006 at 10:26:45AM -0700, Lance James wrote: Another problem from what I see with Malware that steals data is the formgrabbing and on event logging of data. Malware can detect if SecureID is being used based on targeted events, example: Say HSBC (Hypothetical example, not targeting HSBC) has two-factor logins in place, the problem with this is that it is vulnerable to session riding and trojan-in-the-middle attacks anyway, because the minute the user logs in, the malware could launder money out (unless transaction auth is in place, which in most cases it's not), or they could pharm the user with a fake website that resolves as HSBC but they go in within the time frame of that token being valid and have access. Either way, however you cut it, SecureID/Two-Factor User auth is not protected against malware, period. Partly agreed. These kinds of attacks I usually teach in my workshops. However, in all of these cases the attacker has to be online in the moment you are logging in and you experience any failure, e.g. can't login or something like that. But with the SID800 malware could silently sit in the background and pass token codes to the attacker even if you do not login at this moment. E.g. it could wait until you have logged in (or out) and grap the next token code. Furthermore, the attack you described presumes that the attacker knows where you want to login. But when you could use the current token code as an indicator for searching login data in the input stream, then you can find new places to login, e.g. your company VPN access point. While the attack you describe is more important for banking, the USB attack is more against company logins. Agreed, and since my research is focused on online banking I can see yours and my point, either way, SecurID should not be the only concept for dependence. regards Hadmut -- Best Regards, Lance James Secure Science Corp. http://www.securescience.net - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: RSA SecurID SID800 Token vulnerable by design
One can have a lot of fun with key-wielding tokens, especially on Windows. See: J. Marchesini, S.W. Smith, M. Zhao. Keyjacking: the Surprising Insecurity of Client-side SSL. Computers and Security. 4 (2): 109-123. March 2005. http://www.cs.dartmouth.edu/~sws/pubs/msz05.pdf --Sean Sean W. Smith [EMAIL PROTECTED] www.cs.dartmouth.edu/~sws/ Department of Computer Science, Dartmouth College, Hanover NH USA - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
