Home / Blogs

Comments on the National Strategy for Trusted Identities in Cyberspace

The White House has recently released a draft of the National Strategy for Trusted Identities in Cyberspace. Some of its ideas are good and some are bad. However, I fear it will be a large effort that will do little, and will pose a threat to our privacy. As I’ve written elsewhere, I may be willing to sacrifice some privacy to help the government protect the nation; I’m not willing to do so to help private companies track me when it’s quite useless as a defense.

The fundamental premise of the proposed strategy is that our serious Internet security problems are due to lack of sufficient authentication. That is demonstrably false. The biggest problem was and is buggy code. All the authentication in the world won’t stop a bad guy who goes around the authentication system, either by finding bugs exploitable before authentication is performed, finding bugs in the authentication system itself, or by hijacking your system and abusing the authenticated connection set up by the legitimate user. All of these attacks have been known for years.

The stress on authentication as a major defensive component is not new. It was in the report “Securing Cyberspace for the 44th Presidency”; I commented on that when it was first released. My caveats about too much emphasis on authentication still stand.

What’s new here is some detailed design principles. Fundamentally, the current draft is proposing a federated authentication system, with many different identity providers. But that’s not new; it’s been tried a number of times in the past, by such groups as the Liberty Alliance. Such efforts have been notable for their lack of success in the market. If this system is to be truly voluntary, as the draft states, why should this effort succeed? (Of course, whether or not the scheme proposed will actually be voluntary is open to some debate. The draft says the government will not “require individuals to obtain high-assurance digital credentials if they do not want to engage in high-risk online transactions with the government or otherwise”. In other words, you don’t have to participate, as long as you’re willing to forgo things like online banking, electronic filing of tax returns, perhaps working in certain jobs, etc.)

One very good thing the draft suggests is the use of attribute credentials rather than identity credentials. If done properly, that can provide very good privacy protection. To be effective, though, the government needs mechanisms—yes, strong privacy laws and regulations—that encourage use of attributes without identity whenever possible. We need ways to discourage collection of identity information unless identity is actually needed to deliver the requested service.

There has been a lot of academic work on unlinkable credentials, such as Stefan Brands’ schemes and those by Jan Camenisch and Anna Lysyanskaya. It is disappointing that the White House draft did not allude to such schemes. In fact, I’m concerned that there is no desire for true technical privacy mechanisms; the mention of forensics as a major goal worries me.

If we’re going to have multiple credentials, as the draft envisions, a lot of attention needs to be paid to making these identities usable. The report notes the problem but suggests that identity providers should conduct studies on the subject, presumably to ensure that their offerings are usable. That’s wrong; users deal with their own authentication agent, which in turn talks to providers without the user knowing or caring very much about how that is done. But that means that the authentication agent, in the computer, phone, or what have you, needs to be designed for usability. Of course, by centralizing authentication you’ve created a new, critical resource: the authentication manager. What better target for a malicious hacker….

Given all this, should we be focusing on authentication? Apart from the forensics issue (and I think that that is a major goal, though it is hardly stressed), I fear that people are looking under the lamppost for their keys. While there are certainly some challenges to doing authentication at such scale, it is a much simpler problem than buggy code. I suspect that this is being proposed because it looks doable, even though it will do little to solve the real problems and will create other risks.

By Steven Bellovin, Professor of Computer Science at Columbia University

Bellovin is the co-author of Firewalls and Internet Security: Repelling the Wily Hacker, and holds several patents on cryptographic and network protocols. He has served on many National Research Council study committees, including those on information systems trustworthiness, the privacy implications of authentication technologies, and cybersecurity research needs.

Visit Page

Filed Under

Comments

Comment Title:

  Notify me of follow-up comments

We encourage you to post comments and engage in discussions that advance this post through relevant opinion, anecdotes, links and data. If you see a comment that you believe is irrelevant or inappropriate, you can report it using the link at the end of each comment. Views expressed in the comments do not represent those of CircleID. For more information on our comment policy, see Codes of Conduct.

CircleID Newsletter The Weekly Wrap

More and more professionals are choosing to publish critical posts on CircleID from all corners of the Internet industry. If you find it hard to keep up daily, consider subscribing to our weekly digest. We will provide you a convenient summary report once a week sent directly to your inbox. It's a quick and easy read.

I make a point of reading CircleID. There is no getting around the utility of knowing what thoughtful people are thinking and saying about our industry.

VINTON CERF
Co-designer of the TCP/IP Protocols & the Architecture of the Internet

Related

Topics

Threat Intelligence

Sponsored byWhoisXML API

Brand Protection

Sponsored byCSC

Domain Names

Sponsored byVerisign

New TLDs

Sponsored byRadix

DNS

Sponsored byDNIB.com

Cybersecurity

Sponsored byVerisign

IPv4 Markets

Sponsored byIPv4.Global