The Persona identity system uses public key cryptography to ensure trust and security in authentication.
Why does the system described in the Persona IdP overview work?
Chain of Trust
The user's browser locally stores a few pieces of information for each of the user's identities: an email address, a keypair, and a certificate from the associated Identity Provider.
The user's keypair is a standard DSA or RSA cryptographic keypair, and it's generated and stored locally in the user's browser. The certificate is signed by the IdP associated with the user's chosen identity. These certificates are designed to last no more than 24 hours, and may be silently re-provisioned whenever they expire, so long as the user has an active session with the IdP. User keypairs are neither shared across computers nor across browsers.
As described in the Protocol Overview, the user's browser is able to generate and sign ephemeral site-specific identity assertions. When taken together with the information in a user certificate, a site is able to verify the identity of a user. The authenticity of certificates must be verified by retrieving the IdP's public key, which is published in a document available over SSL.
Thus, Persona's security relies on the user's private key remaining secret, the domain's private key remaining secret, and the SSL connection to the IdP being secure. A break at any one of these points could undermine the security of a user's identity.
Generating IdP Keypairs
For IdPs, the jwcrypto package provides a command line utility,
generate-keypair, which generates keys suitable for use with Persona. Because the generated keys are already JSON-serialized, the public key is suitable for direct inclusion into the public-key field of an IdP's /.well-known/browserid.
Certificate and Assertion Format
Please refer to the BrowserID spec for detailed information, but at a high level, both certificates and assertions are strings with three parts: a header, a body, and a cryptographic signature. Each part is separately base64url encoded and concatenated, with "
." characters delimiting each part. The body is not encrypted, so its plaintext is available if you base64url decode it.
Certificates and assertions are bundled together into a "backed assertion" when a user attempts to authenticate with a site. The bundle is created by concatenating a certificate and an assertion with a "
~" separating them.
Private Key Storage and Access in the intermediate implementation and the final implementation:
???? Are the certificate (public), and the private key (relied upon to be private) on the client side stored inside the browser's local storage (for the login.persona.org page)? To be more specific - what are the bits stored on the client side and where are they stored.
What are the implications for the intermediate implementation (JS) and the final one? What are the threats and specific attacks (from say injected JS or anything else)?
Does the final implementation of persona rely on the proposed crypto W3C standard?