Tuesday, March 22, 2005, 7:06 AM

Stump the CIO

There is a question that involves the mainstream that most CIOs don't seem to have an answer to. Here's how I tee it up:
Do you agree with what Bill Gates say that passwords are not good enough and need to be replaced? (See Gates predicts death of the password and Gates explains Microsoft security push.)

If so, what is your plan to move your IT systems away from passwords?
The problem is that today's second factor authentication (2FA) systems require tokens integrated to the backend servers and applications. The result of this strategy is two major problems (which I believe are insurmountable, given the current approach of backend integration):

(1) Token Proliforation. For two bucks more a month, AOL gives you a token to strengthen your access to AOL. Your company gives you a token to get into the VPN. E*trade gives you a token to secure your trading. EBay gives you one. Your bank gives you one. Pretty soon, you're a walking pocket full of tokens.

(2) Backend Integration. The reason the traditional identity management products (in SSO, PKI, directory consolidation, provisioining, etc.) hasn't taken root fully across most enterprises is that they the products require backend integration. This is not a winning strategy as you would have to integrate with every app to achieve true enterprise-wide control. Here's how the math would go ... if you have 500 applications in your company, and you're very good and can integrate one app every week into your IdM system (integrate, test, deploy ... to live users), it will take you, what?, TEN YEARS! to finish the job? And this doesn't even take into account that there are apps that are from ASPs (application service providers), for which you have no access to the backend. (BTW, what happens if your CEO goes out and merges your company with another?) So, after the ten years, you introduce the 2FA integration project to begin moving away from passwords. Right. And they'll be world peace.

Perhaps as Bruce Schneier suggested (in The Failure of Two-Factor Authentication) 2FA doesn't work, so why bother? I don't happen to agree with Schneier (... but that's my next blog topic ...). If 2FA is needed, and a backend integration strategy is not the right one, then how do we get there? How do we move away from passwords? It puzzles me that the industry has not yet developed some sense of where this needs to go.

Friday, March 18, 2005, 11:02 PM

Secure Transaction Tokens

Bruce Schneier's post on The Failure of Two-Factor Authentication prompted me to write down a few of the ideas that I had been toying with.

Schneier asserts that two-factor authentication won't make a difference to reducing cyber-attacks on remote authentication over the Internet -- because both the man-in-the-middle attack and the Trojan attack are possible attack modes. I agree that these attack modes are possible given certain assumptions about the types of the second authentication factor. However, I believe that it is possible to construct a token that can ensure secure transactions across the Internet.

Moreover, Schneier did not have to go into the study of attack modes to show that secure authentications (or any technical guarantees of transactional integrity) are not possible if you are running on compromised clients. There is a more fundamental reason for this weakness in remote authentication: So long as the user is approving transactions via a compromisable platform, transactions cannot be guaranteed secured. This is almost tautological. Man-in-the-middle attacks and Trojan attacks are just two classes of possible attacks. An authentication token that can be reliably used across the Internet has to be able to secure transactions in context of both compromised networks and compromised client platforms.

Assuming the server is a secured platform, there are two ways I can think of for securing transactions (1) secure the client platform, or, (2) off-load the security assurance to a Secure Transaction Token (STT).

In five to ten years, we might finally get a generic secured client platform(Windows 2010, anyone?) ... maybe. The problem is that the more a system can do, the less likely one is able to secure it.

My bias is to solving the problem with a Secure Transaction Token -- the minimal token system that's required to work across the Internet.

What does an STT need to do? I believe there are at least three requirements:

(a) Physicalize secrets. The purpose of a physical second factor authentication token is to make identity theft harder; to require the theft of a "what you have". A strongly physicalized token is a prerequisite to making cyber-attacks-only identity theft impossible.

(b) Know-your-server. Man-in-the-middle attacks are possible because the regular token will talk with any server that the client or network tells it to. An STT will only talk to trusted servers that it has been told about.

(c) Ask-the-user. If both the network and the client machine are compromisable, we cannot depend on the client to mediate conversations between the server and the user. Therefore, the STT must be able to act like a "terminal" for the server to securely communicate with the user. A compromised agent (Trojan) cannot tell the STT to do something bad without the user being aware because the server will always check with the user via the STT.

When we have such deployed such devices, we can support secured transactions across the Internet. The principle here is to build a minimal security component (the STT) to support transactions that cannot be compromised by technical attacks in the client or in the network.

Note that there are no systems that I know of that implement STTs ... but then again, I don't work for the government.

Friday, March 11, 2005, 6:26 PM

Strong Identities Can Be Anonymous

Just because a digital identity is strong, does not mean it cannot be anonymous.

An is a digital identity that is not linked (or bound) to a known legal entity (person or otherwise).

A , which represents an entity, is a digital identity which, when participating in multiple transactions, results in high confidence that it is the same entity involved in all the transactions. The "stronger" the digital identity, the "higher" confidence.

Thus, you can have (1) an anonymous identity that is not strong (e.g. for posting stuff low importance stuff on the web), (2) a strong identity that is not anonymous (e.g. for signing legal documents online), (3) an identity that is not strong or anonymous (e.g. email provided by your ISP), or, (4) an anonymous, strong digital identity (... I can't think of an example, but I'm sure someone can).

Why am I blogging this? Well, Stefan Brands just wrote Identity Bloggers: meet the Privacy Bloggers, recommending that digital identiy bloggers be familiar with privacy issues (which I agree with). However, Stefan goes further than I would by suggesting that
... whenever we talk about digital identity management, we are literally talking about moving around personal information, which is subject to privacy regulations and societal anxiety.
This is only the case when the digital identity in question is not anonymous. (Which, admittedly and unfortunately, is the norm today due to the ad hoc evolution of our "identity systems".)

Conversations about identities can be fairly independent of privacy if we decouple the discussion from the issue of whether there should be bindings between identities and legal entities. The privacy debate starts once bindings have been established ... and is centered around who gets to do what (read/store/distribute) with which bits of information in transactions... and it will be, in part, a "religious" debate, depending on your information dogma.

Perhaps the point at which the privacy debate starts to impinge on the digital identity discussion is around the question of should digital identity systems be required to implement support for anonymity. Once the ability to be anonymous is forfeit, the holder of an identity can only achieve a guarantee of privacy legislatively, and not technically.

Resources:
o Stefan Brands, Identity Bloggers: meet the Privacy Bloggers (http://www.idcorner.org/index.php?p=65).
o Alex Cameron, Beyond the Panopticon: Architectures of Power in DRM (http://www.anonequity.org/weblog/archives/000101.php).
o P.T. Ong, Support for Anonimity (http://blog.onghome.com/2005/01/support-for-anonymity.htm).
o P.T. Ong, Information Dogma (http://blog.onghome.com/2005/02/information-dogma.htm).

Updated (March 18):
o Stefan Brands responds in Identification and anonymity are not opposites (http://www.idcorner.org/index.php?p=68).
o Johannes Ernst points this way in Anonymous Digital Identities (http://netmesh.info/jernst/2005/03/17#ong-anonymous-identities).

Saturday, March 05, 2005, 12:12 AM

Entity Identity

When we talk about digital identities, the conversation is typically around identities of people. We do not necessarily include identities of all entities that can potentially interact on the net -- computers, services, gadgets, phones, appliances, ovens, trucks, even cans of sodas. Why don't we?

Why shouldn't we include all digital entities in any conversation on digital identities. In many cases, we might not even know if one of the participants in a transaction is human or a server. A participating entity might not even be representing a human -- it could be just an agent of a legal identity (like a company). "Human" versus "not human" is probably not the most useful discriminant when thinking about digital identities.

Put differently, we would probably never have secure, reliable networks unless all networked entities have strong digital identities, not just people.

Resources:
Here are a few articles discussing entity identities:
Robin Bloor, The Identity Crisis in IT (http://www.it-analysis.com/article.php?articleid=12172)
John Fontana, Extending identity management's realm (http://www.nwfusion.com/news/2005/021405specialfocus.html)
Dave Kearns, The identity of things (http://www.nwfusion.com/newsletters/dir/005/0221id2.html)
Mark Wahl, Identity Management for devices, (http://www.ldap.com/1/commentary/wahl/20041209_02.shtml)