search by google languageEN +41 43 500 62 45

Webmail

×
  1. Support
  2. Knowledgebase
  3. Security
  4. Our Security

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.

Applications

  • Communications protected by at least 128bit secure socket layer (SSL) encryption.
  • Simple user authentication with dynamic personal web of trust.
  • Delivery of contents only if confidentiality is assured.
  • Encryption with 'State-of-the-art' components:
    - OpenSSL
    - GNUPG
    - Bouncy Castle
    - JAVA JCE/JSSE
  • Protection from Offline Password attacks.
  • For Additional security, end-2-end encryption is encouraged through our service.
  • Developed by PrivaSphere AG. The System is protected by the patent "System and Method for Secure Communication"
    PCT/CH2004000329, US 8,539,603 B2.

Infrastructure

The PrivaSphere Servers are equipped as follows:

  • Redundant data storage distributed on different se
  • vers in different data centers.
  • Daily backup.
  • Backup is encrypted  (GNUPG). The decryption key is not stored on the server.
  • Class 3 SSL/SMIME certificates of the Swiss qualified (ZertES) Certificate Service Provider QuoVadis Trustlink Schweiz AG.
  • Virus scan
  • Mail contents are not stored in plain text on the hard discs.

The data centers possess:

  • Electronic access control
  • Biometric access control system
  • Person gate
  • Intrusion detection system
  • Camera surveillance
  • Redundant power supply with
    - Redundant electricity supply
    - Uninterruptible power supply UPS batteries
    - redundant gasoil emergency power aggregate
  • Automatic fire extinguishing system which is harmless for the human being
  • Fire barriers
  • 5 x redundantly connected to the internet backbones with up to 1 GBit/s
  • The server equipment is behind dedicated redundant firewalls.
  • 24/7 operations monitoring with alarming in case of failure.
  • redundant climate control system.

Operations

  • Strategic Partnership with iWay Communication GmbH (www.iway.ch) for hosting the PrivaSphere infrastructure.
  • The datacenter is for optimum internet access integrated into the infrastructure of Interxion and is conform to Finma guideline 99/2 .
  • Redundant second data center at a second site which has been certificated by SunTone as a highly reliable data center.
  • Personal identification and assessment of staff with root access.
  • Separation of root access and access to mail content.
  • Service quality according to service level agreement.
  • Processes are documented in an operations manual.
  • ISO 27’001 certified processes

 

see also:

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.

Trust status:

Trusted

Validated recipient - no change of the trust relation has occurred. 

Trust level not determined

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 MUC
The 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.

 

see also:

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.

 

see also:

WHY to communicate out-of-band

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.

 

see also:

If you send a secure message, we recommend hiding your email-address to keep your relationship private (Default). The recipient will receive an email from the sender “SecureMessaging@privasphere.com”. 

You may change this setting before sending an eMail:

1. Open new email

2. Add recipient, subject and text

3. Click on “prepare to send”

4. Choose “No Relationship Privacy: Sender "yourname@privasphere.com"

5. Send message

 

Your eMail-address will now be shown to the recipient.

see also:

Um erhöhten Sicherheitsbedürfnissen von Kundendaten Rechnung zu tragen, hat die PrivaSphere AG eine zusätzliche Verschlüsselung der Kundendaten im PrivaSphere Secure Messaging Service entwickelt, die ohne asymmetrischen Endbenutzerschlüssel auskommt. Diese kann durch den Sender optional zugeschaltet werden - zurzeit im Beta-Test.
Dabei werden die Nutzdaten mit einem vom System generierten symmetrischen Schlüssel auf dem System zusätzlich verschlüsselt. Dieser Schlüssel wird dem Empfänger mit der Abholeinladung im Link versandt. Zusätzlich werden sie auch noch mit einem auf dem Server liegenden und automatisch generiertem Schlüsselmaterial verschlüsselt.

 

siehe auch:


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.

 

see also:

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.

Furthermore, there is a function that does not store your contents on PrivaSphere's Servers or alternatively, it is not accessible by simple login, but only message-based invitation.

 

see also:

PrivaSphere Secure Messaging uses for

  • PrivaSphere Registered Secure eMail™
  • PrivaSphere™ eGov Secure eMail

the following official time sources:

  • SwissSign

 
These ZertES mandated time sources are used to determine eGov Sending Time and eGov Receipt Time as per the "Kriterienkatalog v2"

 

see also:

Zu der ganzen Diskussion um Sicherheit, Verschlüsselung und Überwachung ein Kommentar:

PrivaSphere Secure Messaging ist eine Schweizer Firma - und alle Dienste werden aus der Schweiz erbracht. PrivaSphere wurde noch nie (Stand 6.9.2013) von der Strafverfolgung angefragt und untersteht dem aktuellen BÜPF nicht.

Ferner legt  PrivaSphere Secure Messaging grossen Wert auf Sicherheit - ist ISO 27'001:2005 zertifiziert (Security) und setzt neue Technologien ein (v.a. OpenSource Programme wie OpenSSL, etc.).

Zum Thema „knacken“ von Verschlüsselung gibt es aktuell den vertiefenden Bericht von heise.de zu:
http://www.heise.de/security/meldung/NSA-und-GCHQ-Grossangriff-auf-Verschluesselung-im-Internet-1950935.html

Da steht unter anderem ganz am Schluss:
"Verschlüsselung funktioniert. Sauber implementierte, starke Verschlüsselung ist eines der wenigen Dinge, auf die man sich noch verlassen kann."

PrivaSphere Secure Messaging favorisiert deshalb starke Verschlüsselung (<=256bit (in Ausnahmefällen 128bit))!

Wichtig ist auch, dass durch den Benutzer/die Benutzerin eine aktuelle Browser-Version eingesetzt wird, am besten noch optimal  konfiguriert:
Die Auswahl der Server-seitigen Verschlüsselungs-Ciphers ist immer ein Kompromiss, da z.B. in der Verwaltung zum Teil etwas bejahrte Browser eingesetzt werden und Upgrades manchmal  auf längere Sicht nicht möglich sind. Nicht-ganz-state-of-the-art-Verschlüsselung ist immer noch besser als keine Verschlüsselung. Daher werden nicht alle von PrivaSphere angebotenen Ciphers als „grün“ bezeichnet: https://www.ssllabs.com/ssltest/analyze.html?d=www.privasphere.com

Wenn Sie neue Clients einsetzen – richtig konfiguriert – so können Sie gut sicherstellen, dass für Ihre Übertragungen aber nur „Grünes“ verwendet wird.
PrivaSphere behält sich vor, schwächere Ciphers jederzeit „ausser Betrieb“ zu nehmen. Die Nutzung der schwächsten Ciphers wird so gelogged, dass PrivaSphere im Stande ist, ausgewählte Nutzer auf das diesbezügliche Optimierungspotential aufmerksam zu machen.

 

siehe auch:

SHA256 it's easy to proof with XCA (download tool)

Manual:

 

1. Drag cert file out of File-Explorer into XCA

2. Choose cert

3. Click on “Details”

 

see also: https://ssmtc.ch