Unsere Sicherheit

 

Als Kunde von PrivaSphere vertrauen Sie uns Ihre sensitiven Daten an. PrivaSphere legt grossen Wert auf eine professionelle Dienstleistung und Sicherheit in der Abwicklung.

Applikation

  • Datenübermittlung immer mit mindestens 128bit Verbindungsverschlüsselung.
  • Einfache Benutzerauthentisierung mit dynamischem persönlichem "Web of Trust".
  • Auslieferung der Inhalte nur bei Gewährleistung der Vertraulichkeit.
  • Verschlüsselung mittels 'State-of-the-Art' Komponenten:
    - OpenSSL
    - GNUPG
    - Bouncy Castle
    - Java JCE/JSSE
  • Schutz vor Offline Passwortattacken
  • Für mehr Sicherheit ist auch End-zu-End Verschlüsselung möglich.
  • Eigenentwicklung der PrivaSphere AG. Das System ist patentiert unter "System and Method for Secure Communication"
    PCT/CH2004000329, US 8,539,603 B2

Infrastruktur

Die PrivaSphere Server sind wie folgt ausgestattet:

  • Redundante Datenspeicherung verteilt auf mehrere Server in verschiedenen Rechenzentren
  • Tägliches Backup.
  • Die Nutzdaten werden AES verschlüsselt. Der Schlüssel dazu liegt nicht auf dem Server.
  • Class 3 und EV SSL/SMIME Zertifikate von QuoVadis Trustlink Schweiz AG.
  • Virenscanner.
  • Zeitstempel Infrastruktur
  • Kein Speichern von Mail-Inhalten in Klartext auf der Hard Disk.

Die Rechenzentren verfügen über:

  • Elektronische Zutrittskontrolle
  • Biometrisches Zugangssystem
  • Personenvereinzelungsanlagen
  • Einbruchmeldeanlagen
  • Kameraüberwachung
  • Redundante Stromversorgung mit
    - doppelter Stromführung
    - Unterbrechungsfreier Stromversorgung mittels USV Batterien
    - redundanten Diesel Notstrom-Aggregaten
  • Automatische Feuerlöschanlage mit einem für Menschen unschädlichem Brandlöschsystem
  • Brandschutzwände
  • 5 x redundante Anschlüsse am Internet-Backbone
  • Die Rechner befinden sich alle hinter dedizierten Fortigate Firewalls.
  • Automatische Überwachung während 24/7 der laufenden Dienste mit Alarmierung
  • Redundantes Kühlungssystem

Betrieb

  • Strategische Partnerschaft für das Hosting der PrivaSphere Hardware mit iWay AG  (www.iway.ch). Das Rechenzentrum ist für optimalen Internet Access in die Infrastruktur von Interxion eingebettet und ist konform mit der FINMA Richtlinie 99/2 sowie ISO 27‘001 zertifiziert.
  • Redundantes örtlich getrenntes zweites Rechenzentrum.
  • Persönliche Identifizierung und Eignungsabklärung von Personal mit Root-Zugriff.
  • Trennung von Root-Zugriff und Zugriff auf Nutzdaten.
  • Servicequalität geregelt mit Service Level Agreement (SLA).
  • Prozesse ISO 27‘001 zertifiziert.

Kryptografischen Verfahren

PrivaSphere Secure Messaging verwendet zur Verschlüsselung die folgenden Verfahren:

  • SSL
  • TLS
  • SMIME
  • PGP
  • AES

Im Rahmen verschiedener Gesetzgebungsprojekte des Bundes zu Gerichtsorganisation und Verfahren wird den Parteien neu die Möglichkeit eingeräumt, Eingaben bei Gerichten oder Behörden auch in elektronischer Form einzureichen (so insbesondere Art. 130 der Zivilprozessordnung vom 19. Dezember 2008 [ZPO], Art. 33a des Bundesgesetzes vom 11. April 1889 über Schuldbetreibung und Konkurs [SchKG] und Art. 110 der Strafprozessordnung vom 5. Oktober 2007 [StPO]).

Mit der Verordnung vom 18. Juni 2010 über die elektronische Übermittlung im Rahmen von Zivil- und Strafprozessen sowie von Schuldbetreibungs- und Konkursverfahren (SR 272.1; AS 2010 3105; abgekürzt: VeÜ-ZSSchK) hat der Bundesrat geregelt, wie die Parteieingaben sowie der Versand der Urteile resp. Verfügungen in den verschiedenen Verfahren nach Massgabe ihrer Gleichheit auch technisch gleich abgewickelt werden können.

Für diesen Verkehr mit Behörden und Gerichten:

Hinweis

Eine unverschlüsselte Nachricht kann auf der Zustellplattform unverschlüsselt vorliegen und damit von der Dienstanbieterin oder von durch sie beauftragten Dritten eingesehen werden, selbst wenn dies untersagt ist. Benutzerinnen und Benutzer, die das Risiko einer Einsichtnahme nicht in Kauf nehmen können, müssen auf die Benutzung der Zustellplattform verzichten oder die Nachricht zusätzlich verschlüsseln (z.B. mit dem öffentlichen Signaturschlüssel der Empfängerin oder des Empfängers).

aus: Kriterienkatalog V2, Ziff 6.5. Absatz 2

 

siehe auch:

Der zweite wichtige Sicherheitsfaktor nebst Inhaltsvertraulichkeit ist die Empfängeridentität und dessen Beziehung zum Absender. Angefangen vom Vertrauensaufbau über einfache Nutzung während Vertrauen vorhanden ist, bis Entzug und Reinitialisierung, PrivaSphere verwaltet Ihre Onlinevertrauensbeziehungen.

Vertrauensstatus:

Vertraut

Identifizierter Empfänger; Vertrauensbeziehung ist intakt. 

Unbestimmt

Wird eine Meldung über "secure contact me" oder "vorfrankierte Rückantwort" versandt, wird keine Identitätsbestätigung vorgenommen.

Gesperrt

Der Benutzer kann auf seine Meldungen nicht mehr zugreifen. Das Konto ist temporär gesperrt oder wurde geschlossen; zum Beispiel arbeitet der Benutzer für einen anderen Arbeitgeber oder hat seine eMail Adresse gewechselt.

MUC unterdrücken
Ist der Empfänger Systemteilnehmer und sind Sie sicher, dass Sie sich nicht in der Mailadresse getäuscht haben, so können Sie das Systemverhalten übersteuern, den MUC Versand unterdrücken und den Empfänger per Mausklick zu Ihren vertrauten Kommunikationspartner hinzufügen. Der Fehlleitungsschutz wird dadurch aufgehoben.

 

Hinweis: Ermuntern Sie Nichtteilnehmer sich zu registrieren. Wenn der Empfänger bei Meldungsempfang die ‚Schnellanmeldung’ Funktion wählt, kann er ein Passwort wählen und Sie müssen keinen MUC mehr austauschen. Das Empfangen von Meldungen und die Registrierung sind kostenlos.

 

siehe auch:

Vermeiden Sie, dass eine unberechtigte Person Zugriff auf Ihre vertrauliche Informationen bekommt. Wenn Sie zum ersten Mal mit einem neuen Empfänger kommunizieren, senden Sie das Mitteilungspasswort (MUC) nicht per eMail. Sonst können Lauscher einfach Zugriff auf die Benachrichtigung und den MUC erhalten und damit Zugriff auf den Meldungsinhalt erhalten.

 

Siehe auch:

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:

Die Information, wer mit wem in Kontakt steht und wie oft, ist ein wichtiges Suchkriterium und liefert Beweisargumente. Normalerweise ist bei eMail die Beziehung zwischen Sender und Empfänger offengelegt.

Wenn Sie eine vertrauliche Meldung senden, können Sie mit PrivaSphere Ihre Kommunikations-Beziehung schützen (Default). Der Empfänger erhält dann eine Benachrichtigung vom Sender SecureMessaging@privasphere.com”.

Sie können diese Option in Ihren Einstellungen oder im Web Interface auf Meldungsbasis ändern:

1. Neue Mail öffnen

2. Hinzufügen von Empfänger(n), Betreff und Text

3. Klick auf “Versand vorbereiten”

4. Wählen Sie “Beziehungsvertraulichkeit unterdrücken"

5. Nachricht senden

 

Ihr Empfänger sieht nun als Absender Ihre eMail-Adresse.

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:


Versender von ungewollten Meldungen, auch SPAM genannt, verwenden vielfach automatisierte Mechanismen zum versenden von unerwünschten Meldungen über einen gratis eMail Service oder zum Sammeln von Zieladressen. "Human In the Loop Test" ist dafür eine effektive Schutzmassnahme, denn für einen Automaten ist es schwierig, einen aus einzelnen Punkten generierten Text zu kopieren. Geben Sie einfach die angezeigte Zeichenfolge in das nebenstehende Feld ein. Sie leisten damit einen Beitrag zum Erhalt einer SPAM freien Umgebung

Falls Sie mehr Information benötigen, kontaktieren Sie einen PrivaSphere Repräsentanten.

 

siehe auch:

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 ist am einfachsten mit XCA zu machen (Download Tool)

 

Anleitung:

 

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

2. Choose cert

3. Click on “Details”

 

Siehe auch: https://ssmtc.ch