Our Security

PrivaSphere is the first Swiss provider of a Secure Messaging Platform. The hosting location is Switzerland which is known for its sound data protection law. As a customer of PrivaSphere you entrust us your sensitive data. PrivaSphere endeavors to provide a professional service according to best practice security levels.

Besides content confidentiality, the management of the trust relationship between sender and recipient over its lifetime proves to be as important: starting from the trust bootstrapping process to ease of use when established, to revocation and recovery in case of trust changing events and usability once it is established. PrivaSphere manages trust in all exchanges conducted by email and over the web.

If a message is sent via the "secure contact me" or "prepaid return envelope" feature, trust level can not be determined.

Closed or deleted user

This user can no longer access the messages. The account has been closed - for example because this user works for a different employer and no longer is the owner of that e-mail address.

Suppress MUCThe system behavior can be modified and the MUC can be suppressed, if the recipient is a participant of the secure messaging system and you are sure not to be mistaken about the eMail address. By clicking on ‘trust’, a recipient can be added to the personal list of trusted users. The protection against misdirection of information is suspended.

Hint: Encourage your non-validated, non-participant recipients to become participants. If the recipient clicks on the quick register button, he can obtain a password, trust with the sender is established and a MUC is not any longer needed when communicating between these two parties. Registering only to receive does not have a cost impact for the user.

Avoid that a third party can gain access to your privileged information. When communicating for the first time with a new recipient, do not send the access code MUC over the same communication channel as the message (which is via internet). Otherwise an eavesdropper along the channel can easily get in possession of the notification message and the MUC and in this way gain access to your information.

You as the user can better assess the degree of privacy a message of yours requires and who potential adversaries are. When using Private Message, it is assumed that an adversary possibly or even likely eavesdrops on your Internet communications such as e-mail, www, chat, etc. But because Internet communication is still the most convenient medium to communicate, you elect to use it all the same and protect yourself with additional technology. Each such technology, however requires at least an initial establishment of mutual trust between you and your recipient counterparts. This time, you must take the extra effort to communicate with them in a way that you are not or at least to your least imaginable degree intercepted by the adversary.

How to communicate PUBLIC KEY FINGER-PRINTS out-of-band

If you use personal public keys of yourself and/or the recipients, you must ensure that you REALLY use theirs and not some public key of an adversary that got to you by a so-called "man-in-the-middle" attack where the adversary replaced your counter-parts' key in transit when your counter-part tried to send it to you. Or an adversary could spoof your counter-part during that key exchange altogether. Public key encryption systems provide a fingerprint function that makes it feasible to compare even long public keys efficiently for example over the phone. Pre-condition for this to succeed again is that your public key system on your own hard-disk is genuine and correct and no adversary has put a secret trap-door into it that will allow the attacker to (i) replace keys after their integrity has been verified with the out-of-band approach described here or to (ii) copy the private messages as they are exchanged in an unnoticed way. The good news in this type of systems is that you need not to worry if the adversary listens in on that conversation - public keys are public and they can learn that finger-print without being able to cause harm.See "Validating other keys on your public keyring" for further information on this!

HOW to communicate MESSAGE UNLOCK CODES out-of-band

In this case, you want all you want for finger-prints as just described, but on top of that it is important that the adversary not even learns what your Message Unlock Code is. The good news in this type of private message exchanges is that you need not worry about where to get a good encryption system and how to operate it. As long as your web browser and its root certificates are untampered, you ought to be fine.

Rules of thumb on choosing good out-of-band channels (for both)

do not use an Internet based-channel (e-mail, www, chat)

use a channel operated by a different provider: If your <acronym title="Internet Service Provider">ISP</acronym> is also your phone fixed net provider, perhaps your cell-phone is operated by someone else? If so, a call via cell phone or an <acronym title="Short Message Service">SMS</acronym> may be the channel of your choice.

use different terminals: If your fax line is not operated by your ISP, but your recipient uses a fax-to-email conversion service and faxes are received digitally on the very same computer again, the purpose of out-of-band is defeated again...

hand over in person: this approach is a lot better, but quite an effort and only makes sense for finger-prints. Because Message Unlock Codes are exchanged each time a message is exchanged, you preferably exchange the message itself (on a floppy disk/CD you burned/etc.) if it is feasible to meet in person or have a reliable and timely messenger.

Pigeons: In former times, pigeons were used for such purposes. Yes, most people will never in their life have any, but you get the point to choose a channel that is costly for an adversary to monitor and alter. Be creative in the way to get these short and easy messages securely to your counter-part.

use different message transportation infrastructure: one might think that cell phones go over the air while fixed net phones use wires. Right next to your phones this is obviously true, but most cell phone calls make the long distance over wire as well. Possibly not even wires owned and operated by themselves. But still, hopefully, your cell operator uses a virtual private networks at least until their gateways to the recipients provider. Even if they don't, by choosing a cell phone channel you have most likely added a degree of complexity in the attack that needs to be mounted against you. But sure, staying with the air versus wire example, using walkie-talkies or true long-distance radio is better than cell phones.

As long as there are no good revocation mechanisms, even if you successfully verified the integrity of your counterpart's public "out-of-band" as explained above, it makes sense to verify it again after some time because your counterpart in the mean-time have might have his or her key lost, stolen or otherwise compromised. <acronym title="Certificate Revocation Lists">CRLs</acronym> and OCSP are efforts to spare you this chore in the future, but for now, there isn't really a way around it.

The senders of unsollicited mail aka SPAM more and more use automated engines to collect e-mail addresses of future victims and to sign up with free e-mail services to send their unwanted messages. "Human In the Loop Tests" are a technique that makes it significantly harder for such engines to so by requiring to copy a text that is easily recognizable for the human eye, but hard to decypher for automated engines because this text is not constructed out of normal computer characters, but in fact, is an image in single dots. Just copy the displayed character sequence into the field next to it. Doing this will reduce the incidence of SPAM to an easily tolerable level for your PrivaSphere account.

If you need more information, then contact a PrivaSphere representative for additional assistance.

The risk of information disclosure is proportional to the time data is remaining on the system. Even though our architecture is meeting best practice standards, we recommend removing data from the system once it has been transmitted e.g. if you use secure pop3, for example set "delete on server after 2 days" instead of "leave on server". The system automatically deletes your contents after 30 days.