

How can PrivateSky not see your data? - andyshora
http://security.stackexchange.com/questions/13226/how-can-privatesky-not-see-your-data

======
mckoss
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.

 _And, seriously, a Michael Scott protocol?_

~~~
pbsd
> And, seriously, a Michael Scott protocol?

Can you elaborate?

~~~
myersgp
[http://scholar.google.com/citations?user=GsM-
aeEAAAAJ&hl...](http://scholar.google.com/citations?user=GsM-aeEAAAAJ&hl=en)

Seriously

------
rdl
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.

~~~
bribriinlondon
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.

~~~
rdl
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)

------
emily37
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.

~~~
bribriinlondon
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....

~~~
emily37
_You obviously haven't worked in a real business._

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.

