This is Brian Spector; I'm the CEO of CertiVox.
Thanks for starting this discussion on PrivateSky, our secure information exchange service. I’ll do my best to answer the intelligent comments and criticisms on this thread.
Second, I’ll try my best to walk the reader through step by step on how our integrated key management and two factor authentication works.
I invite the folks on this thread who haven’t read the white paper to please do so. Everything I am writing has already been written in detail and is publicly available in that document on our website. But since no one reads white papers….
First, let’s refute the statement that we are "lying". We are not, and indeed, we are trying to be as transparent as possible about how we do what we do. It’s hard to argue with that kind of blanket statement, so rather than go there (“so Mr. Jones, when did you stop beating your wife?”), let’s just go through the intelligent points on this thread, as there are quite a few.
To that end, that’s also why we open source our MIRACL SDK, freely available off of our website. MIRACL powers PrivateSky, and the same cryptographic processes in use in PrivateSky are available as libraries in the MIRACL SDK, so you can review the code. MIRACL is in use by hundreds of companies around the globe, and has a fairly decent reputation as having very fast elliptic curve cryptography optimized for constrained environments. It is trusted by many organizations. We take that trust extremely seriously; it’s our bread and butter.
To correct Lucas’ statement here:
Probably the simple answer is: it's not.
If I read correctly they just seem to have used a form of symmetric encryption to authenticate yourself to the system after which you can access your private keys to encrypt data (the private keys are encrypted with your pin).
That’s not correct. Let’s clear up that one up first. The SkyPin you see that logs you into PrivateSky with your email address and 4 digit pin is an elliptic curve authenticated key agreement protocol that uses two factors of authentication, based upon an IEEE P1636.3 draft standard, Wang’s protocol, with the addition of our chief cryptographer, Dr. Michael Scott’s protocol for remote login with simple token and 4 digit pin using elliptic curve bilinear pairings.
Note that Mike’s protocol has been peer reviewed extensively since its first publication in 2002, has withstood over a decade of cryptanalysis, and we’ve published an updated version, this time adapted for use with Wang’s protocol.
Of the two factors, the first factor is a mathematical token stored in your browser, locked to the domain of our authentication service, the second factor being your pin. It work’s like this: The SkyPin Pad you use is actually performing a reconstitution of an identity based encryption key issued in the ID of your email address, we issue this to you when you register. During the registration process, the SkyPin Pad performs a equation on the IBE key you were issued using the 4 digits you select. This process is performed locally. We don’t know what those 4 digits are. At that point, it becomes what we call a “token”. The token is stored in your browser’s HTML5 local storage, not session storage (i.e., not a cookie). This is locked to our authentication service’s domain.
The next time you login, the SkyPin Pad is served from our web server (over TLS, domain secured by DNSSEC) and runs locally in your browser. The SkyPin Pad takes as input your 4 digits, reverses the equation, reconstituting the identity based encryption key you were issued when you registered, again, performed locally. This is Scott’s protocol. The next step is an authenticated key agreement protocol based upon Wang’s protocol, whereby encrypted nonces are exchanged with the IDs of the server and individual attempting to authenticate mutually. At then end of the protocol, both the server and individual have identified themselves to each other, and each side has at their disposal an AES 128-bit key, the session key. Hence the term; authenticated key agreement protocol.
Lucas is also incorrect with this statement (note Lucas that generally you don’t decrypt with public keys, you verify signatures with public keys, you encrypt with public keys):
It still might be decrypted with a the other persons public key browserside. But then again everyone has a public key available, they just need to fetch it from the server and apply it by the browser. – Lucas Kauffman5 hours ago
And by association Rasmus is correct with this statement (thank you for reading the white paper, btw):
According to the white-paper they use SK-KEM, which is an identity-based encryption scheme. This explains why you do not need the public key of B in order to send an encrypted message to him (the email-address is the public key).
In an exponent inversion system like the variant of SK-KEM that we are using, it’s actually a key encapsulation system, whereby the content encryption key is encapsulated (i.e., encrypted) using a protocol with inputs of the global public key of the system and the email address of the recipient. The message is signed using the ECCSI protocol with the user’s private key issued from our private key generator. The user employs a different private key issued from our private key generator to decrypt a message, using the SAKKE protocol (a variant of SK-KEM). The cool thing about SAKKE is that is also has the ability to federate private key generators. Assuming a user has access to the public parameters of another’s private key generator, user A who has a private key of a PKG A can communicate with user B who has their private key issued from PKG B.
Both ECCSI and SAKKE are part of an IETF informational draft called MIKEY-SAKKE, which is being standardized to provide voice data and encryption over 3G networks. MIKEY-SAKKE has strict guidelines on the operations of the PKG to cover such nuances as master key rotation (every 30 days) and packet assembly.
Up until recently, it was assumed that you could not distribute the private key generator in an exponent inversion system. Thankfully, Smart and others devised a multiparty computation protocol that enabled such a possibility.
Developing further on that work, Smart and Geisler published a paper called “Distributing the Key Distribution Centre in Sakai–Kasahara Based Systems.”
Effectively, you could split the PKG into distributed private key generators, or D-PKG’s. The nice thing about this is that after the initial setup, the master key doesn’t live anywhere in whole; it is split into thirds. Only two of the three nodes need to be available to server shares of the private key to the intended party. The master node is taken offline and discarded after setup. Assuming you have built processes by which to do this, shares of private keys in such a system can be created dynamically as they are requested.
Rasmus makes this statement:
Usually identity-based encryption relies on a trusted third party. So their claim that they cannot decrypt the messages themselves is based on their having placed the master private key and the associated private key generator inside what basically amounts to a hardware security module.
And Lucas makes this statement:
Yes, it seems they just put the trust somewhere else. They can't decrypt it their selves, but their claim that no-one else can seems to be false
Rasmus is partially correct, and Lucas is not correct. It’s actually several hardware security modules, none of them actually possessing the master key in whole. We take the additional steps: D-PKG nodes into HSMs that are tamper proof, tamper resistant, with integrity verification upon boot up of the VM, and carry no state (other than their share of the master key and the code to distribute shares upon authenticated request). We cannot access the shares of the D-PKGs without ruining some expensive kit. But let’s assume we could re-constitute the shares of the PKG.
Because we are following the MIKEY-SAKKE operational guidelines, these D-PKGs are only in operation for one month, meaning, the master key and subsequent private keys issued are only good for one month, and the entire population is rotated every month.
In PrivateSky, the user will be asked to create a unique passphrase. This is used to create a 32-byte long-lived ECDH private key (and subsequent public key), which can also be used in an ECIES setting. The ECDH public key of the user is stored in our directory. The D-PKGs have ECDH key pair that is not long-lived, only monthly. When new keys are issued, a DH secret key between the D-PKG month private key and the ECDH public key of the user is created to encrypt the newly issued ECCSI and SAKKE private keys for the user. This happens for every user. These are stored within our directory for the user so they can decrypt old messages outside of the 30-day master key rotation window.
The point being, after the 30-day window where the shares of the master key are in use, the VMs are destroyed, the key material inside the HSMs are wiped, and we start over again.
So let’s outline the general attack scenarios:
Inside the 30 day window, in order for us to decrypt the data (or turn over keys when we are served summons for requests for information):
- We need to carefully hack an HSM at FIPS 140-2 Level 3 so as not to destroy the units, twice. In two different data centers.
Outside of the 30 days window:
- We need to crack AES 256 in order to decrypt the archived private keys OR
- Someone has to crack AES 128 bit for every single message
You are probably wondering, why in the hell have these guys gone to such great lengths to construct such a system? Especially in light of this admission:
User 1202236 makes this statement:
Thanks for clarifying. So instead of trusting a software company, now you trust a hardware company and that the software company actually uses the provided hardware. It seems to me that you need to trust quite a few people when compared to PGP.
That’s correct. Let me ask this is a more direct way: On a trust scale, is it better to use PGP or PrivateSky if you want to be 100% sure that no one can see your data? Answer: There is no question that creating your own private key via a system such as PGP is better as a trust model. No question at all.
There is only one problem. PGP and the current state of the art are too damn hard for the general population at large to use. Not the people on this board mind you. But I mean my daughter, or her friends, or my parents.
In PrivateSky, using a PIN, a passphrase and your email address, we can get you close, with two-factor authentication as a bonus. And you don’t have to learn anything. You don’t have to do anything different to use PrivateSky than you would any other web property around. That’s why we built it.
The people at CertiVox sincerely believe that just because we want to communicate something through the Internet doesn’t give the government, the NSA, Dropbox, Google or any media companies the right to use my family’s information or mine in the largest data mining scam ever perpetrated on the human race.
From a business perspective, our architecture also accomplishes the following:
We will be served with requests for information from authorities. That’s a fact of life when you run a Saas business. Thankfully, in the UK and the EU, there is due process and law for this. How we comply, and our ability to prove the extent of our compliance, rests with the architecture we develop. If your data is accessible by us in the clear, then we have to turn it over. If it’s not, then we still have to turn it over. But if what we turn over is encrypted, and we don’t possess the keys, then what good is the data (it’s encrypted), and what good is serving a FISMA warrant or EU equivalent on us? Complying with requests for information is really, really expensive for a young company. Not being a target for such requests is a competitive edge.
Which leads me to my next point. The team at CertiVox has made a bet that there is a market for a secure information exchange service where our business model is dependent on NOT seeing your data. We believe (maybe naively) that there is enough people and organizations out there who are concerned about the erosion of privacy but don’t have the technical expertise to do anything about it. Dropbox needs to see your data to de-duplicate. Google needs to see your data to serve you ads. We don’t do either and never will.
To that end, we will soon introduce the capability for anyone to run your OWN distributed private key generators, and register these on our system (through the SAKKE federation capabilities), completely taking us out of the loop. You control your own population of users, can rotate master keys at will, revoke users, etc. That WILL give you the equivalent trust model of PGP.
Lastly, let’s go through the steps of how our integrated key management system works. We call this Incognito Keys. You can download an info graphic PDF that is a visual diagram of the following explanation:
To encrypt and sign a message:
- Alice logs into PrivateSky with her SkyPin and email address. The two-factor authenticated key agreement protocol produces an AES 128 bit key for use at the browser end and at the authentication server’s end.
- The authentication server passes the AES key to our “black boxes”, the D-PKG nodes.
- The D-PKG nodes assemble the shares of Alice’s ECCSI key and encrypt these with the AES key.
- Alice receives the encrypted ECCSI key (shares), decrypts the shares with her AES key, assembles the ECCSI key from the shares, and is ready to go.
- Alice writes a message to Bob and encrypts the message with an AES key, called the content encryption key.
- Alice encapsulates the content encryption key with inputs of the Global Public Key and Bob’s email address and appends the encrypted / encapsulated key to the message.
- Alice signs the message with her ECCSI key.
To decrypt and verify a message:
- Bob logs into PrivateSky with his SkyPin and email address. The two-factor authenticated key agreement protocol produces an AES 128 bit key for use at the browser end and at the authentication server’s end.
- The authentication server passes the AES key to our “black boxes”, the D-PKG nodes.
- The D-PKG nodes assemble the shares of Bob’s SAKKE private key and encrypt these with the AES key.
- Bob receives the encrypted SAKKE private key (shares), decrypts the shares with his AES session key, assembles the SAKKE private key, and is ready to go.
- Bob receives the message in his portal, which contains the encapsulated content encryption key.
- Bob verifies Alice’s signature, and de-encapsulates the content encryption key with his SAKKE private key.
- Bob uses the content encryption key to decrypt the message.
So there you have it. You can argue with the math, the implementation or our intentions, but hopefully we have made all three clear.
Thanks for reading all the way through, and please sign up for PrivateSky! You can see all of this working in action for yourself.