Meaning to put a link for this for a while.

Enjoy:

The attack was a Man-in-the-middle (MIM) attack where smart tactics were employed to even produce errors originally generated at citibank web site.

http://blog.washingtonpost.com/securityfix/2006/07/citibank_phish_spoofs_2factor_1.html : "The site asks for your user name and password, as well as the token-generated key. If you visit the site and enter bogus information to test whether the site is legit -- a tactic used by some security-savvy people -- you might be fooled. That's because this site acts as the "man in the middle" -- it submits data provided by the user to the actual Citibusiness login site. If that data generates an error, so does the phishing site, thus making it look more real"

http://isc.sans.org/diary.php?storyid=1478 : "Overall, two factor authentication will reduce the risk of attacks by raising the effort of the attacker to compromise the accounts, but it might not have the level of security enhancement that some people believed. In the man-in-the-middle attack, the flaw happens due to the lack of verification of the bank's website by the victim, the victim are simply tricked into yielding credentials to a web site without authentication. This is really outside of the protection zone of the extra authentication factor.

To further extend this, two factor authentication also does NOT protect the end host security, a malware (such as keylogger, BHO) could be installed on the client's machine and effectively gather the credential and login on behalf of the victim instead of letting the victim login.

This is a classic problem of "you are only as secure as the weakest link". Two factor authentication is good for secure authentication but does not take care of mutual authentication or endpoint security. From the financial organization perspective, maybe further investment into mutual authentication and ensuring client's computer being free of malware would be necessary to protect the client's online transactions."

In the above blog entry at sans.org (Handler's diary) Jason mentions that 2 factor authentication is good for secure authentication but does not take care of mutual authentication or endpoint security. This is partly true as it really depends on the 2 factor authentication device being used. Most of the time consumers and enterprises consider one-time-password generating device (such as RSA Secure ID) to be the 2-factor authentication device as they do satisfy the notion "something you know and something you have" but there are 2 factor authentication devices such as smart cards which have lot to offer in terms of end-to-end security and thus are helpful in tackling man-in-the-middle attack.

Handler's diary points out that to fight against MIM mutual authentication is required and this is where smart cards (especially that of current generation where they are capable of getting easily plugged with enterprises following new standards such as Liberty Alliance and WS-*) distinguish themselves from just being the user authentication device and can also perform (even customized) web site/portal/server authentication.

In one of the his article (Authentication : The Pitfall of Two factor authentication) Jason says:
"In the phishing scenario, challenge response type of second factor seems to be problematic to the phishers. However, that really isn't stopping all the attackers. The desperate ones can still leverage Man in the middle type of attack. There are a few ways for man in the middle attacks to work. One is to put up a look-alike malicious site which is basically a proxy to the actual bank's website. When the victim login with proper credentials, the attacker can simply ride on that established online banking session. Notice that even challenge-response type of token would work in this case because the attacker (or the man in the middle) is passively observing the connection between the bank and the victim. The challenge will reach the victim, who will then send in the response. The attack simply proxies the traffic until the session is establish and then sends in the fraud transaction."

I would say that key here is to do all the transactions that need security over 2 way SSL where mutual authentication is required between device (& thus the user) and web server and all communication happens encrypted with a session key negotiated between device and web server. This way session hijacks could be prevented (correct me if I am missing something).

Solution lies in the mutual authentication and communication over secure channel between a smart device (such as smat card) and web server.

Below are the details for the registration for SecureTheWeb context. Registration site also provide forum for posting questions/issues/problems.

Cryptoflex.NET is a smart card platform implementing a subset of ECMA specification for CLR, IL, Metadata and core libraries. This new smart card technology (already deployed in product form in Microsoft for their corporate ID program) allows the creation of both on-card and off-card(client) applications much easier and faster than it has been done before on other smart card platforms. More on the platform and SDK in upcoming posts.

http://projectliberty.org/resources/whitepapers/SIM_Strong_Authentcation_Whitepaper.pdf

"This paper presents an innovative service called SIM strong authentication service that extends the usage of GSM SIM authentication to Internet Web services. The goal of this proof-of-concept is to demonstrate the possibility of implementing innovative service in a heterogeneous environment using Liberty Alliance Federation Standard. Telenor, Axalto, Linus and Oslo University College have implemented a proof-of-concept prototype in Oslo. The architecture is based on a multi-vendor environment where SUN provides the Identity Provider, IBM the Identity Provider and Service Provider Proxy to connect non-Liberty Alliance Service Providers to the system, Lucent Technologies the Radius server and Ulticom the SS7 MAP Authentication Gateway connecting the prototype to the Telenor mobile network. A typical user flow for such a service would be the case of a user browsing on the World Wide Web from home, a customer premise, an Internet café, etc. When trying to access a protected resource such as Webmail, company portal, or bank account, he logs on to the requested secured site simply by placing his mobile phone close by and communicating with his PC via Bluetooth, or using a SIM card-equipped dongle, card reader, or 2G/3G PC card. This service is available anywhere and can support any Internet services. It is ideal for services like Internet Banking, eAdministration or enterprise internal web pages. The SIM strong authentication is both user-friendly and cost efficient, with a low deployment threshold. The technology is also capable of supporting other Smart-Card based identity services such as USIM (UMTS), certificate based schemes (E.g. TLS) and One Time Password schemes (OTP). A demonstration of the SIM based service is being demonstrated at the 3GSM World Congress in Barcelona, February 2006."

Today in keio University, Tokyo, Japan at W3C workshop on Ubiquitous web I gave the talk on device coordination with web applications. The position paper can be found here and presentation is hosted here.

The position is basically to standardize the interface to communicate with the security devices which are network addressable and are discoverable using standard discovery protocols such as UPnP, Bonjour or ZeroConf and are locally connected to the user's machine, from the web page and script from remote web site rendered by browsers.

http://www.ovum.com/news/euronews.asp?id=3636

Key Points:

• Identity management has been the fastest growing security sector, and we are pleased to report good progress in getting acceptance of the Liberty Alliance and SAML 2 standards. 
• Identity management will become even more prominent, but in the enterprise space it will mostly be intra-enterprise, with inter-enterprise initiatives, which are still a couple of years away.
• Much faster development of identity and identification infrastructure in the government sector, both for law enforcement and for accessing public services.

James McGovern recently asked "How should we think about SmartCards within our own infrastructure and how it plays with federated identity?". I have been talking about the demos we have done with Smartcard in Identity management space but never really talked about the essence of using Smartcards in this domain. I take this oppurtunity to try to explain how Smartcard plays a vital role in federated identity.

Identity federation although new to Internet (www) and world of web services, is not a new concept for the Smartcards. Smartcards are the actually the real enabler of biggest network of identity federations world has known till date i.e GSM. It is this small computer which enables the roaming in the GSM network and let us make use of our mobile phones at places where our operators do not have presence. GSM was devised with the core objective of business harmonization - "you can use my network even though your are a subscriber of another network in another country" which required technical harmonization. Problem is that network 1 does not have an account for you and cannot bill you but they can get your and your operator's (network 2) identity from the phone and ask your operator if they will pay the charges. Of course the operator would want a strong proof of if you are you and not somebody who has stolen your account number. Need is to have a strong authentication for eg using shared key cryptographic where there are exactly 2 copies of secret key - one residing in mobile phone and other at operator's end. The figure below illustrate how a basic GSM authentication is done (it is actually more complicated but for simplicity I am giving this example) :

Basically the user's network sends a random number and result after its encryption with shared key to the visiting network and says that if user's phone gives the same encryption result for the random number I will pay the bill. As you can see there is not only a requirement of strong authenitcation but secure storage of shared key (not even accessible to user) and what better technology to use than Smartcard which has the secure, tamper resistant hardware and secure computing capabilities. Computing capabilities are equally important as it is of no use storing the key in Smartcard and giving it to phone for performing cryptographic operation.

Now federated identity for intrenet and intratnet are no different conceptually than the case that I presented. Only the protocols (SAML, WS-Trust etc) used by service providers and identity providers on www are different for obvious reasons. In today's internet the identity of user is of prime interest both to user and to the service provider and hence the need of Strong authentication.

Fortunately various standards like SAML, Liberty, InfoCard/WS-Trust, WS-Federation etc for identity federation respect and understand the usefulness of security devices like Smartcards. All these standards propose the solution to same set of problems in _almost_ same way and differ mostly in wire protocols used. SAML and Liberty has a profiles ECP (Enhanced client proxy) and LECP (Liberty enabled client or proxy) respectively which enables a Smartcard based authentication where as InfoCard (a profile of WS-Trust) treats Smartcard as another Security token service which can generate self issued security tokens.

Other than Strong authentication, secure storage of attributes/credentials and computing capability, mobile nature of Smartcards is an added advantage for user.

Microsoft is betting big on smart cards for its own employees while working to make the technology more palatable for the masses.

Read the full article  by Karen Epper Hoffman at http://redmondmag.com

This week in San Diego we showcased the InfoCard and WS-Trust support by .NET Smartcard which basically hosts the Security Token Service (STS) . This STS generates the RSTR (Request Security token response) with signed SAML Assertion message in response to a RST (Request security token) message [Basic WS-Trust protocol for exchanging security tokens].

Normally as we all know that InfoCard system is part of Avalon/Indigo SDK BETA release (require .NET 2.0) and supports only self issued identity cards but for this demo we created a InfoCard System on .NET 1.1 and used WSE 2.0 SP2 to communicate to the STS hosted in Smart card.

Actually last year at Burton Catayst we did a similar kind of demo which showed hosting WS-Trust STS on Smartcard and implemented active profile of WS-Federation. In this demo we showed how user's identity can be secured stored and managed by Smartcard and can be used by InfoCard System on PC.

Below are some snapshots of the sample application and InfoCard selector GUI on .NET 1.1

1. Smart client application. [ A Service locator ]

2. Authenticate to Smart card.

3. Lookup for Service

4. Select a service

5. InfoCard Selector GUI (created by us, not same as that in Indigo)

6. Select the InfoCard. This GUI locates the InfoCard [Please note here it is the metadata] and show only the non-geeky part :). Data (user attributes) are in Smartcard.

7. Clicking on Show Details retrieve the data stored (corresponding to supported claims in InfoCard selected) in the Smartcard.

8. Clicking on submit sends to STS (in Smartcard) an RST and gets RSTR. Client application extracts the SAML Assertion from RSTR, embeddeds in the Soap Request to http://www.dotnetcard.com/Demos/InfoCard/wstrust-rp1/BlueMonkey.aspx.