Links

Kim wants to save the world from itself. In short, he is talking about yet another incident where some service asks for username and password to some other service, in order to glean information from your account to do something cool. Usually this turns out to be “harvest my contacts so I don’t have to find all my friends yet again on the social network of the month”, but in this case it was to calculate your “Twitterank”. Whatever that is. Kim tells us

The only safe solution for the broad spectrum of computer users is one in which they cannot give away their secrets. In other words: Information Cards (the advantage being they don’t necessarily require hardware) or Smart Cards. Can there be a better teacher than reality?

Well, no. There’s a safer way that’s just as useful: turn off your computer. Since what Kim proposes means that I simply can’t get my Twitterank at all (oh, the humanity!), why even bother with Infocards or any other kind of authentication I can’t give away? I may as well just watch TV instead.

Now, the emerging answer to this problem is OAuth, which protects your passwords, if you authenticate that way. Of course, OAuth is perfectly compatible with the notion of signing in at your service provider with an Infocard, just as it is with signing in with a password. But where is the advantage of Infocards? Once you have deployed OAuth, you have removed the need for users to reveal their passwords, so now the value add for Infocards seems quite small.

But if Infocards (or any other kind of signature-based credential) supported delegation, this would be much cooler. Then the user could sign a statement saying, in effect, “give the holder of key X access to my contacts” (or whatever it is they want to give access to) using the private key of the credential they use for logging in. Then they give Twitterank a copy of their certificate and a copy of the new signed delegation certificate. Twitterank presents the chained certificates and proves they have private key X. Twitter checks the signature on the chained delegation certificate and that the user certificate is the one corresponding to the account Twitterank wants access to, and then gives access to just the data specified in the delegation certificate.

The beauty of this is it can be sub-delegated, a facility that is entirely missing from OAuth, and one that I confidently expect to be the next problem in this space (but apparently predicting such things is of little value - no-one listens until they hit the brick wall lack of the facility puts in their way).

Share This

Kim writes about minimal disclosure. Funnily enough my wife, Camilla, spontaneously explained minimal disclosure to me a couple of nights ago. She was incensed that she ended up having to “prove” who she was in order to pay a bill over the phone.

First of all, they asked her for her password. Of course, she has no idea what her password might be with this particular company, so their suggestion was she guess. Camilla surprised me by telling me that she had, of course, declined to guess, because by guessing she would be revealing all her passwords that she might use elsewhere. So, they then resorted to the usual stupidity: mother’s maiden name, postcode, phone number and so forth. Camilla said she was happy to provide that information because she didn’t feel it was in any way secret - which, of course, means it doesn’t really authenticate her, either.

Anyway, her point was that in order to pay a bill she really shouldn’t have to authenticate to the payee - what do they care who pays the money, so long as it gets paid? In fact, really, we want the authentication to be the other way round - the payee should prove to her that they are really the payee. It would also be nice if they provided some level of assurance that she is paying the right bill. But they really don’t need to have any clue who she is, so long as she can hand over money somehow (which might, of course, including authenticating somehow to some money-handling middleman).

But what seems to be happening now is that everyone is using identity as a proxy for security. If we know who you are, then everything else springs from that.

Now, if what you want to do is to determine whether someone is authorised to do something, then certainly this is an approach that works. I find out who you are, then I look you up in my Big Table of Everything Everyone Is Allowed To Do, and I’m done. However, and now I finally circle back to Kim’s post, for many, if not most, purposes, identification is far more than is really needed. For example, Equifax just launched the Over 18 I-Card. I hope Equifax got this right and issued a card that doesn’t reveal anything else about you - but even if they didn’t, clearly it could be done - and clearly there’s value in proving you’re over 18, and therefore authorised to do some things you might not otherwise be able to do. Though I’d note that I am not over 18 in Equifax’ view because I do not have an SSN!

Anyway, current deficiencies aside, this is a great example of where minimal disclosure works better than identification - rather than everyone having a lookup table containing everyone in the world and whether they are over 18, someone who has the information anyway does the lookup once and then signs the statement “yep, the bearer is over 18″.

But in many other cases identification doesn’t work at all - after all, the premise of the ID card is that it is supposed to improve our security against terrorists. But its pretty obvious that identifying people really isn’t going to help - you can work that out just by thinking about it, but even more importantly, in several recent terrorist attacks everyone has been very thoroughly identified but it hasn’t helped one bit.

And in the case of my wife trying to pay a bill, identification was completely without purpose. Yet everyone wants to do it. As Kim says, we really need to rethink the world in terms of minimal disclosure - and as I show above, sometimes this is actually the easiest way to think about it - my one area of disagreement is that we should not call this “identity” or even “contextual identity”. We need a term that makes it clear it has nothing to do with identification. I prefer to think in terms of “proof of entitlement” or “proof of authority” - but those don’t exactly roll off the tongue … ideas?

Share This

Way back when I wrote about The Neb. The basic idea here was that you can’t trust your PC, so you should have a separate trusted device (The Neb) which is used only for final authorisation of transactions - all the work of getting the transaction set up is done on the untrusted PC. The core point being that The Neb has to include UI, because the user cannot trust what their PC tells them the trusted device is going to do (this is why the often-touted smartcard is a crap answer to the problem).

Seems IBM agree - they’ve released a simple version of The Neb, called the ZTIC (Zone Trusted Information Channel). Also, you can watch a video.

IBM’s version isn’t quite the same as my vision of The Neb, though - in their case, all data is routed through the ZTIC, which tries to guess when you’re about to send something you might wish you hadn’t. In The Neb’s case, only the data relating to the final transaction is sent to The Neb, explicitly, by the server, which then displays it and, if the user agrees, signs it. Their version has the advantage of requiring the server only to start supporting client certificates (and refusing connections without them, I guess) but the disadvantage that what they intercept and display is bound to be somewhat ad hoc. The Neb requires more support from the server, but can’t get confused about what is going on.

Share This

Don’t worry, if we put all our data into central government databases, it’ll all be fine. Except when it isn’t. Our esteemed Prime Minister says

“It is important to recognise we cannot promise that every single item of information will always be safe because mistakes are made by human beings. Mistakes are made in the transportation, if you like in the communication, of information.”

in the aftermath of yet another ridiculous data breach: this time, people’s passwords to the Government Gateway on a memory stick dropped in the road.

Perhaps it is uncouth to point this out, but … if the system had been designed by people with any security clue whatsoever there would have been no passwords to put on a memory stick in the first place.

I notice that Gordon thinks the contractors in this case (Atos Origin) are responsible and action should be taken against them (though how he squares this with his statement that such events are inevitable only a politician can tell you). Well, sure. But why is he not taking action against the morons that designed and approved a system that made it possible for Atos Origin to have the passwords in the first place?

My theory? Policy makers think that it is beneath them to actually understand the technologies they make policy about, or to consult anyone who does. So, it has not occurred to Brown or any of his advisers that this is actually an avoidable error.

Share This

I’m very excited that Yahoo! have launched their gadget platforms, including an OpenSocial platform. Why am I excited? Because Yahoo! require all gadgets to use Caja so that they can be sure the gadgets behave themselves without review. Caja allows the container (i.e. Yahoo!’s platform, in this case) to completely confine the untrusted Javascript (i.e. the gadget, in this case), only allowing it to perform “safe” operations. All other platforms either have to manually review gadgets or take the risk that the gadgets will do something evil to their users.

Share This

When I wrote last week that I had implemented a J-PAKE demo someone rather churlishly commented, “not a demo till it runs on two machines, with a toy browser and toy server”.

So, this weekend I implemented J-PAKE as a proper OpenSSL module. Plus support in s_server and s_client. You can test it like this:

openssl s_server -jpake secret
openssl s_client -jpake secret

If you want to use two different machines, as required by Mr. Churlish, then you’ll need to use the -connect option to s_client.

If you want to use it yourself, you can find example code in apps/apps.c. Look for the functions jpake_client_auth() and jpake_server_auth().

Share This

Unless you are Red Hat, the answer is: about as much as eating lunch has to do with business models.

Whatever business you are in, you need your lunch, or you’re going to die. Likewise, but perhaps not quite so urgently, you need software. Open source is about getting the software you want for the minimum investment. It is cheaper and more efficient for those who need particular functionality to group together and provide it for themselves than it is to pay five different companies to not quite provide it in five different ways.

That’s all there is. End of.

So, when you read something like this: “Report: Pure Open Source No Longer a Viable Business Model”, what you are supposed to do is hit the keyboard violently and scream, “It never was, you morons! Get with the program!”

Selling support for software is a business model. Whether it is open source or not. That’s the business Red Hat is in. Not the “open source business”. There isn’t one.

Share This

Just for fun, I wrote a demo implementation of J-PAKE in C, using OpenSSL for the crypto, of course. I’ve pushed it into the OpenSSL CVS tree; you can find it in demos/jpake. For your convenience, there’s also a copy here.

I’ve tried to write the code so the data structures reflect the way a real implementation would work, so there’s a structure representing what each end of the connection knows (JPakeUser), one for the zero-knowledge proofs (JPakeZKP) and one for each step of the protocol (JPakeStep1 and JPakeStep2). Normally there should be a third step, where each end proves knowledge of the shared key (for example, by Alice sending Bob H(H(K)) and Bob sending Alice H(K)), since differing secrets do not break any of the earlier steps, but because both ends are in the same code I just compare the resulting keys.

The code also implements the protocol steps in a modular way, except that communications happen by magic. This will get cleaned up when I implement J-PAKE as a proper OpenSSL library component.

The cryptographic implementation differs from the Java demo (which I used for inspiration) in a few ways. I think only one of them really matters: the calculation of the hash for the Schnorr signature used in the zero-knowledge proofs - the Java implementation simply concatenates a byte representation of the various parameters. This is a security flaw, as it can be subjected to a “moving goalposts” attack. That is, the attacker could use parameters that gave the same byte representation, but with different boundaries between the parameters. I avoid this attack by including a length before each parameter. Note that I do not claim this attack is feasible, but why gamble? It worked on PGP, after all.

The code and data structures are completely different, though. Also, because of the cryptographic difference, the two implementations would not interoperate.

Share This

Over the last few weeks, both Google and Yahoo! have released federated login usability studies.

Google’s proposes a flow very similar to login on Amazon, only changing “I’m a new customer” to “Help me log in” and “Do you have a foo.com account?” to “Do you have a foo.com password?”. Amazingly, this is enough for users to get themselves logged in without any training.

An interesting data point, though: users found their second login more confusing than the first. This is because they are used to having a password after the first login, whereas with a federated login, the experience is the same every time. Fortunately, although they’re not quite sure what’s going on, what they do ends up with them logged in anyway. My feeling is that if we start doing federated login widely this confusion will soon evaporate.

Yahoo!, on the other hand, focused on OpenID. This seems to have been a much less happy experience for users, which certainly comes as no surprise to me - it’s always been clear that the average user is not going to understand the idea of logging in with a URL. Plus, they’re damned unwieldy (i.e. big and hard to remember). So, their conclusion was one that doesn’t scale well: use per-IdP buttons.

This backs up my view that OpenID will never really work until it uses email addresses as user IDs.

Share This

I don’t normally post about my circumstances, but since I’ve been pretty silent for quite a while now, I’ll make an exception. I broke my wrist 5 weeks ago, which has significantly constrained my computer use. Things should gradually return to normal…

Share This

In their latest attempt to answer the question “how can we get everyone with a domain name to pay for it again?” ICANN are apparently enthused about this stupid idea.

But wait … I have it … why don’t we create a TLD for every service? We obviously need .www, .smtp, .dhcp and so forth, or how will people know what service you are offering?

Share This

Recent events, and a post to the OpenID list got me thinking.

Apparently rfc2817 allows an http url tp be used for https security.

Given that Apache seems to have that implemented [1] and that the
openid url is mostly used for server to server communication, would
this be a way out of the http/https problem?

I know that none of the browsers support it, but I suppose that if the
client does not support this protocol, the server can redirect to the
https url? This seems like it could be easier to implement that XRI .

Disclaimer: I don’t know much about rfc2817

Henry

[1] http://www.mail-archive.com/dev-tech-crypto@lists.mozilla.org/msg00251.html

The core issue is that HTTPS is used to establish end-to-end security, meaning, in particular, authentication and secrecy. If the MitM can disable the upgrade to HTTPS then he defeats this aim. The fact that the server declines to serve an HTTP page is irrelevant: it is the phisher that will be serving the HTTP page, and he will have no such compunction.

The traditional fix is to have the client require HTTPS, which the MitM is powerless to interfere with. Upgrades would work fine if the HTTPS protocol said “connect on port 80, ask for an upgrade, and if you don’t get it, fail”, however as it is upgrades work at the behest of the server. And therefore don’t work.

Of course, the client “requires” HTTPS because there was a link that had a scheme of “https”. But why did was that link followed? Because there was an earlier page with a trusted link (we hope) that was followed. (Note that this argument applies to both users clicking links and OpenID servers following metadata).

If that page was served over HTTP, then we are screwed, obviously (bearing in mind DNS cache attacks and weak PRNGs).

This leads to the inescapable conclusion that we should serve everything over HTTPS (or other secure channels).

Why don’t we? Cost. It takes far more tin to serve HTTPS than HTTP. Even really serious modern processors can only handle a few thousand new SSL sessions per second. New plaintext sessions can be dealt with in their tens of thousands.

Perhaps we should focus on this problem: we need cheap end-to-end encryption. HTTPS solves this problem partially through session caching, but it can’t easily be shared across protocols, and sessions typically last on the order of five minutes, an insanely conservative figure.

What we need is something like HTTPS, shareable across protocols, with caches that last at least hours, maybe days. And, for sites we have a particular affinity with, an SSH-like pairing protocol (with less public key crypto - i.e. more session sharing).

Having rehearsed this discussion many times, I know the next objection will be DoS on the servers: a bad guy can require the server to spend its life doing PK operations by pretending he has never connected before. Fine, relegate PK operations to the slow queue. Regular users will not be inconvenienced: they already have a session key. Legitimate new users will have to wait a little longer for initial load. Oh well.

Share This

When I joined Google over two years ago I was asked to find a small project to get used to the way development is done there. The project I chose was one that some colleagues had been thinking about, a key management library. I soon realised that unless the library also handled the crypto it was punting on the hard problem, so I extended it to do crypto and to handle key rotation and algorithm changes transparently to the user of the library.

About nine months later I handed over my “starter project” to Steve Weis, who has worked on it ever since. For a long time we’ve talked about releasing an open source version, and I’m pleased to say that Steve and intern Arkajit Dey did just that, earlier this week: Keyczar.

Keyczar is an open source cryptographic toolkit designed to make it easier and safer for developers to use cryptography in their applications. Keyczar supports authentication and encryption with both symmetric and asymmetric keys. Some features of Keyczar include:

• A simple API
• Key rotation and versioning
• Safe default algorithms, modes, and key lengths
• Automated generation of initialization vectors and ciphertext signatures

When we say simple, by the way, the code for loading a keyset and encrypting some plaintext is just two lines. Likewise for decryption. And the user doesn’t need to know anything about algorithms or modes.

Great work, guys! I look forward to the “real” version (C++, of course!).

Share This

Looking for links for the previous article on OpenID, I came across this post, from May 2007.

Sun’s House of Cards?

Sun have a plan. In short, they’re going to have an OpenID provider which authenticates Sun employees only.

That is, so long as you trust your DNS. Or, in other words, if you aren’t using any untrusted networks. How often does that happen?

And in the comments we find

Well, obviously it all has to run over TLS to be useful. Which should address those issues, right?

Comment by Tim Bray — 8 May 2007 @ 22:43 |Edit This

“Obviously”. Yes, that’s obvious to you and me, but really you need to write down the rules.

Plus, of course, X.509 certs haven’t proved to be the most invulnerable things in the world.

Comment by Ben — 10 May 2007 @ 8:10 |Edit This

Now, if that isn’t prophetic, I don’t know what is.

Share This

The New York Times’ Randy Stross has a piece about passwords and what a bad idea they are (sorry, behind a loginwall). So far, so good (and I’ll admit to bias here: I was interviewed for this piece, and whilst there’s no attribution, what I was saying is clearly reflected in the article), but Stross weirdly focuses on OpenID as the continuing cause of our password woes, because, he says, it is blocking the deployment of information cards, which will save us all.

Now, I am no fan of OpenID, but Stross is dead wrong here. OpenID says nothing about how you log in. It is not OpenID’s fault that the login is generally done with a password - that blame we must all accept collectively.

And whilst I firmly believe that the only way out of this mess is strong authentication, information cards are hardly the be-all and end-all of that game. They certainly have a way to go in usability before they’re going to be taking the world by storm. Don’t blame OpenID for that.

In the meantime, Scott Kveton, chair of the OpenID Foundation board, reacts:

The OpenID community has identified two key issues it needs to address in 2008 that Randy mentioned in his column; security and usability.

I just have to giggle. I mean, apart from those two minor issues, OpenID is pretty good, right? He forgot to mention privacy, though.

Share This

Where “P” stands for “Predictable”.

Richard Clayton and I today released a security advisory showing how three independent vulnerabilities combine to make a rather scary mess, mitigated only by the fact that no-one protects anything very valuable with OpenID anyway. But just think how much worse it could have been (on which I shall write more soon)!

Share This

Ever since the recent DNS alert people have been testing their DNS servers with various cute things that measure how many source ports you use, and how “random” they are. Not forgetting the command line versions, of course

dig +short porttest.dns-oarc.net TXT
dig +short txidtest.dns-oarc.net TXT

which yield output along the lines of

"aaa.bbb.ccc.ddd is GREAT: 27 queries in 12.7 seconds from 27 ports with std dev 15253"

But just how GREAT is that, really? Well, we don’t know. Why? Because there isn’t actually a way to test for randomness. Your DNS resolver could be using some easily predicted random number generator like, say, a linear congruential one, as is common in the rand() library function, but DNS-OARC would still say it was GREAT. Believe them when they say it isn’t GREAT, though! Non-randomness we can test for.

So, how do you tell? The only way to know for sure is to review the code (or the silicon, see below). If someone tells you “don’t worry, we did statistical checks and it’s random” then make sure you’re holding on to your wallet - he’ll be selling you a bridge next.

But, you may say, we already know all the major caching resolvers have been patched and use decent randomness, so why is this an issue?

It is an issue because of NAT. If your resolver lives behind NAT (which is probably way more common since this alert, as many people’s reactions [mine included] was to stop using their ISP’s nameservers and stand up their own to resolve directly for them) and the NAT is doing source port translation (quite likely), then you are relying on the NAT gateway to provide your randomness. But random ports are not the best strategy for NAT. They want to avoid re-using ports too soon, so they tend to use an LRU queue instead. Pretty clearly an LRU queue can be probed and manipulated into predictability.

So, if your NAT vendor is telling you not to worry, because the statistics say they are “random”, then I would start worrying a lot: your NAT vendor doesn’t understand the problem. It’s also pretty unhelpful for the various testers out there not to mention this issue, I must say.

Incidentally, I’m curious how much this has impacted the DNS infrastructure in terms of traffic - anyone out there got some statistics?

Oh, and I should say that number of ports and standard deviation are not a GREAT way to test for “randomness”. For example, the sequence 1000, 2000, …, 27000 has 27 ports and a standard deviation of over 7500, which looks pretty GREAT to me. But not very “random”.

Share This

Ralf Bendrath asks what’s wrong with the W3C and the IETF that the OWF is trying to solve? So, to be very brief…

The W3C is a pay-to-play cartel that increasingly gets nothing done. Open source developers can’t even participate, as a rule. It also has an IPR policy that’s just as crap as everything else we’re trying not to emulate. So, not a realistic alternative.

The IETF is much better, but its main problem is that it has no IPR policy at all, other than “tell us what you know”. In practice this often works out OK, but there have been some notable instances where the outcome was pretty amazingly ungood, such as RSA’s stranglehold over SSL and TLS for years - a position Certicom are now trying to emulate with ECC, also via the IETF.

A more minor objection to the IETF that I hope the OWF will solve similarly to the ASF is that it is actually too inclusive. Anyone is allowed to join a working group and have as much say as anyone else. This means that any fool with time on their hands can completely derail the process for as long as they feel like. In my view, a functional specification working group should give more weight to those that are actually going to implement the specification and those who have a track record of actually being useful, much as the ASF pays more attention to contributors, committers and members, in that order.

Share This

I’m very pleased that we’ve launched the Open Web Foundation today. As Scott Kveton says

The OWF is an organization modeled after the Apache Software Foundation; we wanted to use a model that has been working and has stood the test of time.

When we started the ASF, we wanted to create the best possible place for open source developers to come and share their work. As time went by, it became apparent that the code wasn’t the only problem - standards were, too. The ASF board (and members, I’m sure) debated the subject several times whilst I was serving on it, and no doubt still does, but we always decided that we should focus on a problem we knew we could solve.

So, I’m extra-happy that finally a group of community-minded volunteers have come together to try to do the same thing for standards.

Share This

The government has quietly launched two quite fascinating initiatives. I have no idea why there wasn’t more fanfare. I was even at OpenTech, where one was announced, and I didn’t know!

Firstly, Show Us A Better Way

Ever been frustrated that you can’t find out something that ought to be easy to find? Ever been baffled by league tables or ‘performance indicators’? Do you think that better use of public information could improve health, education, justice or society at large?

The UK Government wants to hear your ideas for new products that could improve the way public information is communicated.

And 20 grand for the best ideas, too.

Secondly, The Public Sector Unlocking Service (Beta). I love that they put “Beta” in there. Tell them about crown copyright data some bureaucrat is hoarding, and they’ll read them the riot act. Awesome.

Share This