PrivaSphere è il primo fornitore svizzero di piattaforma di messaggistica sicura. L'hosting è tenuto in Svizzera che è conosciuta per il suo diritto sulla protezione dei dati. Come cliente di PrivaSphere ci affidi i tuoi dati sensibili. PrivaSphere tenta di fornire un servizio professionale in base ai livelli delle migliori pratiche di sicurezza.
I server PrivaSphere sono attrezzati come segue:
I centri dati sono caratterizzati da:
Oltre alla riservatezza dei contenuti, anche la gestione del rapporto di fiducia tra mittente e destinatario durante la sua vita dimostra di essere altrettanto importante: a partire dal processo di instaurazione della fiducia alla facilità d'uso una volta istituito, alla revoca e recupero in caso di eventi che modificano l'affidabilità e l'usabilità, una volta che è stata stabilita. PrivaSphere gestisce la fiducia in tutti gli scambi condotti tramite e-mail e attraverso il web.
Stati di affidabilità
Affidabile
destinatario validato - nessun cambiamento del rapporto di fiducia si è verificato.
Livello di attendibilità non determinato
Se un messaggio viene inviato tramite le funzioni "contatto sicuro" o "busta di ritorno prepagata", il livello di attendibilità non può essere determinato.
Utente chiuso o cancellato
Questo utente non può più accedere ai messaggi. L'account è stato chiuso - per esempio perché l'utente lavora per un diverso datore di lavoro e non è più il proprietario di tale indirizzo di posta elettronica.
Sopprimere il MUC
Il comportamento del sistema può essere modificato e il MUC può essere soppresso, se il destinatario è un utente del sistema di messaggistica protetta e si è sicuri di non sbagliarsi circa l'indirizzo di posta. Cliccando su 'fiducia', un destinatario può essere aggiunto alla propria lista di utenti affidabili. La protezione contro il depistaggio delle informazioni è sospeso.
Suggerimento: Incoraggia i tuoi destinatari non-validati, non-utenti a diventare utenti. Se il destinatario clicca sul pulsante di registrazione rapida, può ottenere una password, la fiducia con il mittente è stabilita e il MUC non è più necessario durante la comunicazione tra le due parti. La registrazione solo per ricevere non ha un impatto di costo per l'utente.
vedi anche:
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)
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.
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.
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
the following official time sources:
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