This is an example where a short answer is better than a long answer. There is so much detail provided by the CEO in his explanation, that it is very difficult to understand the outline of the protocol and structure of the system. Security does not derive from complexity, but rather a careful analysis of the potential attacks and their difficulty.
So, rather than allay fears about his service, I'm left feeling more skeptical about their claims.
I would love hear from people more versed in cryptographic key exchange protocols as to the basis for their claims.
The short answer was supplied at the end of his response. He gives a step by step run down of how the encryption and decryption works. The only thing most people not familiar with crypto would probably have an issue with is understanding D-PKG(Distributed-Public Key Generators) and ECCSI(Elliptic Curve-based Certificate-less Signatures for Identifier Based Encryption).
I personally wasn't familiar with D-PKGs but his response allowed me to understand what they were pretty easily.
The real short answer seems to be: encryption is done client-side by Javascript.
I'd worry about the extra attack vectors because of that - man in the middle, snooping browser extensions, etc (or even just strong-arming them into silently changing their javascript do no encryption)
To his credit, he writes about this as well:
> 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 [...] a system such as PGP is better [...]
> 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. [...]
> 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. [...]
I use enigmail + thunderbird, and it's pretty simple to use. It's only difficult because the tools are immature. Sending a mail and seeing a "verified from foo@bar.com", or "can only be viewed by foo@bar.com" isn't difficult to understand.
The smartphone vendors are in a unique position where they could make this happen.
The thing is, doing it correctly still actually requires quite a bit of understanding.
The hard part has always been key management. If a user doesn't have a properly managed web of trust, they have no real assurance of privacy or authenticity.
I think the people who are actually in a position to fix this problem are the social networks. Imagine if the act of joining Facebook caused a keypair to be generated by you, and friending someone brought their key into your web of trust with some sensible defaults.
Unfortunately Facebook has no incentive to build such a thing. But maybe something third party can leverage all those social connections to help users manage keys in a more natural way.
All these acronyms for a browser-based service? Even if you trust this company to have good intentions, it seems that the weakest link by far is the possibility of an XSS, a malicious extension, or a CA compromise. And of course the whole thing depends in multiple ways (verifying your identity, logging in if you clear localStorage, etc.) on the security of your inbox. Their crypto and protocol might be fine, but they should be more forthcoming about the many pieces of software that you are trusting when you use their service. I skimmed their whitepaper but didn't see any mention of the ways that they or someone else could in fact see your data.
You obviously haven't worked in a real business. You would NEVER disclose your internal processes or architecture, that's nuts, it's like drawing out your whole attack surface for your adversary.
Nevertheless, someone asked a follow on question with these exact same points back on the thread; we have posted answers.
It also seems you are being a bit disingenuous. You've studied under Dan Boneh, the founder of our competitor. You know very well what these acronyms mean.
Also, who said this is only going to be "browser based"? Browser's are a good start though....
You would NEVER disclose your internal processes or architecture, that's nuts, it's like drawing out your whole attack surface for your adversary.
Though it might not be a bad idea, I wasn't actually intentionally suggesting that you open-source all your code and make your internal processes completely transparent. I was suggesting that you maybe add a section in your whitepaper detailing the possible attacks, and that you reconsider phrases in your marketing copy like: "Who can see your data with PrivateSky™? No one, not even us." I find it misleading.
Nevertheless, someone asked a follow on question with these exact same points back on the thread; we have posted answers.
In the stack exchange thread, you talk about what would be needed to compromise the SkyPin authentication process. But I don't see how this is sufficient. Suppose there is an XSS vulnerability on the browser-based inbox on your site. What stops an attacker from inserting a single line of Javascript that opens up a message of his choice in my inbox, decrypts the contents, and sends the contents to the attacker? Suppose that your SSL private key is compromised. What stops the attacker from eavesdropping on my connection to PrivateSky, stealing my session cookie, and using that session cookie to open up my inbox in his browser? Maybe you have some defenses against these attacks, but you don't seem to address them anywhere (at least that I can find).
It also seems you are being a bit disingenuous. You've studied under Dan Boneh, the founder of our competitor. You know very well what these acronyms mean.
The point was that there is a lot of heavy-handed crypto thrown around and not enough discussion of the actual weakest links in your system.
Also, who said this is only going to be "browser based"?
Definitely not me. The current offering is browser-based, and the currently advertised guarantee is that no one can read your data, not even your company.
I think the crypto behind this is valid; weaknesses would be in implementation or in bypassing it.
There isn't anything inherently browser based about this.
I'm not a huge fan of browser based security (I know just enough appsec to be terrified).
If they had an API, it would be fun to do a secure mobile client for it (I trust iOS security way more than PC browsers..). There is less point when you have a client (just as easy to build some kind of key server with locally stored keys), but being able to send messages to future users is a nice trick.)
It looks like an interesting use of HSMs. I'm curious if they do real crypto in the HSM or just use it to protect a bootable VM. If it is just a VM, there are a lot more attacks possible.
I can confirm we use the secure execution environment of the HSM, we say VMs in a general sense because of the limited knowledge of HSMs, makes it easier for people to understand. But it is actually compiled C code running in the tamper proof / tamper resistant part of the module doing the share issuance and the multiparty computation protocols.
Awesome. Thales/nCipher or SafeNet or something else? I'll assume that since you're in the UK and doing HSM stuff it's ex-nCipher people from Cambridge...
Overall this is quite an impressive application, especially on the backend/server side. I wish more people used HSMs in a productive way (I've done some stuff with them in the past, and am working on related things now)
15 comments
[ 5.4 ms ] story [ 51.3 ms ] threadSo, rather than allay fears about his service, I'm left feeling more skeptical about their claims.
I would love hear from people more versed in cryptographic key exchange protocols as to the basis for their claims.
And, seriously, a Michael Scott protocol?
I personally wasn't familiar with D-PKGs but his response allowed me to understand what they were pretty easily.
Can you elaborate?
Seriously
I'd worry about the extra attack vectors because of that - man in the middle, snooping browser extensions, etc (or even just strong-arming them into silently changing their javascript do no encryption)
To his credit, he writes about this as well:
> 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 [...] a system such as PGP is better [...]
> 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. [...]
I use enigmail + thunderbird, and it's pretty simple to use. It's only difficult because the tools are immature. Sending a mail and seeing a "verified from foo@bar.com", or "can only be viewed by foo@bar.com" isn't difficult to understand.
The smartphone vendors are in a unique position where they could make this happen.
The hard part has always been key management. If a user doesn't have a properly managed web of trust, they have no real assurance of privacy or authenticity.
I think the people who are actually in a position to fix this problem are the social networks. Imagine if the act of joining Facebook caused a keypair to be generated by you, and friending someone brought their key into your web of trust with some sensible defaults.
Unfortunately Facebook has no incentive to build such a thing. But maybe something third party can leverage all those social connections to help users manage keys in a more natural way.
Nevertheless, someone asked a follow on question with these exact same points back on the thread; we have posted answers.
It also seems you are being a bit disingenuous. You've studied under Dan Boneh, the founder of our competitor. You know very well what these acronyms mean.
Also, who said this is only going to be "browser based"? Browser's are a good start though....
Yes, I have.
You would NEVER disclose your internal processes or architecture, that's nuts, it's like drawing out your whole attack surface for your adversary.
Though it might not be a bad idea, I wasn't actually intentionally suggesting that you open-source all your code and make your internal processes completely transparent. I was suggesting that you maybe add a section in your whitepaper detailing the possible attacks, and that you reconsider phrases in your marketing copy like: "Who can see your data with PrivateSky™? No one, not even us." I find it misleading.
Nevertheless, someone asked a follow on question with these exact same points back on the thread; we have posted answers.
In the stack exchange thread, you talk about what would be needed to compromise the SkyPin authentication process. But I don't see how this is sufficient. Suppose there is an XSS vulnerability on the browser-based inbox on your site. What stops an attacker from inserting a single line of Javascript that opens up a message of his choice in my inbox, decrypts the contents, and sends the contents to the attacker? Suppose that your SSL private key is compromised. What stops the attacker from eavesdropping on my connection to PrivateSky, stealing my session cookie, and using that session cookie to open up my inbox in his browser? Maybe you have some defenses against these attacks, but you don't seem to address them anywhere (at least that I can find).
It also seems you are being a bit disingenuous. You've studied under Dan Boneh, the founder of our competitor. You know very well what these acronyms mean.
The point was that there is a lot of heavy-handed crypto thrown around and not enough discussion of the actual weakest links in your system.
Also, who said this is only going to be "browser based"?
Definitely not me. The current offering is browser-based, and the currently advertised guarantee is that no one can read your data, not even your company.
There isn't anything inherently browser based about this.
I'm not a huge fan of browser based security (I know just enough appsec to be terrified).
If they had an API, it would be fun to do a secure mobile client for it (I trust iOS security way more than PC browsers..). There is less point when you have a client (just as easy to build some kind of key server with locally stored keys), but being able to send messages to future users is a nice trick.)
It looks like an interesting use of HSMs. I'm curious if they do real crypto in the HSM or just use it to protect a bootable VM. If it is just a VM, there are a lot more attacks possible.
Overall this is quite an impressive application, especially on the backend/server side. I wish more people used HSMs in a productive way (I've done some stuff with them in the past, and am working on related things now)