WebID security picture

Hello folks,

I've been thinking on the security aspects of WebID since some conversations with Henry last week, and I wanted to outline them here to get some sense of collective opinions (and share mine, naturally). My take is that there are some gaps in the picture, but that they're possibly resolvable in some fashion or another.

The default scenario — the one which most efforts to date have focussed on — is that the private key for a WebID certificate is managed by the individual, on their own client device, while the FOAF RDF is served by what amounts to an untrusted entity (even if it might well sign the RDF).

Further, the subject URI named in the certificate and the FOAF RDF *is* the identity of the certificate-holder.

Confirming that the agent on the end of an SSL connection is the one who holds a particular public key is easy.

Confirming that the agent on the end of an SSL connection is the same as the agent with the identity described by the FOAF RDF is less easy.

Consider an attacker who wishes to impersonate you, and has gained access to the [untrusted] server where your RDF is published. All they need to do is generate a certificate with a SAN matching yours, and modify the RDF to include their public key. As far as a relying party is concerned, they *are* you, because you verifiably have the same subject URI.

Worse, even if the RDF is signed in some way — be it via SSL (often inconvenient) or a detached signature (workable) — then this problem isn't mitigated, because they can just sign the RDF using their own key as though they were you.

The big question is whether this is a problem which actually needs to be solved, and if so, how?

In other words:

- Is it simply the case that if an attacker gains access to the server hosting your RDF, all bets are off? If so, this means that relying on a third party to serve that then becomes a matter of calculated risk and trust (and for large-scale adoption, does this then mean that you're trusting, e.g., Facebook not to hijack your identity)? This would seem to me to be less than ideal: if everybody has to have a web server that they can trust, the barrier to entry is significantly raised IMHO, even if it would be a good thing in general.

- Is the subject URI an adjunct, and relying parties should instead pay attention to the keys instead? Clearly, the way that WebID is structured suggests the answer is “no” — certificates [and so keys] are deemed to be essentially disposable, and you can by design have multiple certs+keys referring to the same subject — one per browser/device if you wish.

- Does there need to be a 'shared' key which is associated with both the certs and the RDF in some way, and only you hold? This solves the problem, but complicates the processes — you need to make sure that you don't lose that root key [naturally], and you need to have it to hand whenever you need to generate a new certificate; on the other hand, it does allow a cryptographically strong identity to be maintained for an agent independently of the certificate/browser/device being used (i.e., the public half of the shared key), which will be very useful for certain applications; of course, it doesn't preclude multiple 'shared' keys for different identities which you might want to maintain.

I'd appreciate the thoughts of others (I'm don't know if this might be old ground? apologies if so).

M.

-- 
Mo McRoberts - Data Analyst - Digital Public Space,
Zone 1.08, BBC Scotland, 40 Pacific Quay, Glasgow G51 1DA,
Room 7066, BBC Television Centre, London W12 7RJ,
0141 422 6036 (Internal: 01-26036) - PGP key 0x663E2B4A




http://www.bbc.co.uk/
This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in error, please delete it from your system.
Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately.
Please note that the BBC monitors e-mails sent or received.
Further communication will signify your consent to this.

Received on Friday, 8 April 2011 09:41:06 UTC