PGP-Firmenschlüssel

[coogor]

Moin Leute,

ich wollte mal eure Meinung abfragen:
Wir sind ein kleines Team und wollen PGP Verschlüsselung anbieten/einsetzen. Anbieten deshalb, weil ich noch nicht sagen kann wieviele Kunden das können oder wollen.

Um die Handhabung auch für die Kunden zu vereinfachen war meine Idee, einen einzigen Schlüssel zu generieren, der vom gesamten Team genutzt wird. Damit wird die Verschlüsselung nicht mehr von dem einzelnen Mitarbeiter abhängig (sonst müsste der Kunde im Zweifel 5 Keys importieren und signieren). Die Passphrase für den Schlüssel müsste dann auch unter den Mitarbeitern geteilt werden (was potentiell ein Risiko darstellt)

Ist der Ansatz praktikabel? Gibt es bessere Alternativen?

TIA/Axel

 

[P6CNAT]

Hallo,

Anbieten deshalb, weil ich noch nicht sagen kann wieviele Kunden das können oder wollen.

Ich habe mir in meinem Freundeskreis schon den Mund franselig gababbelt, aber bis auf einen ist denen das zu kompliziert. Sogar Leuten mit gutem Wissen über IT und PC's.

Um die Handhabung auch für die Kunden zu vereinfachen war meine Idee, einen einzigen Schlüssel zu generieren, der vom gesamten Team genutzt wird. Damit wird die Verschlüsselung nicht mehr von dem einzelnen Mitarbeiter abhängig (sonst müsste der Kunde im Zweifel 5 Keys importieren und signieren). Die Passphrase für den Schlüssel müsste dann auch unter den Mitarbeitern geteilt werden (was potentiell ein Risiko darstellt)

Ist immerhin ein Anfang, könntest ja einen Gruppen und für jeden zusätzlich einen individuellen Schlüssel generieren.

Freie Alternativen kenne ich sonst keine.

Grüße
Georg

 

[coogor]

Ist immerhin ein Anfang, könntest ja einen Gruppen und für jeden zusätzlich einen individuellen Schlüssel generieren.

Freie Alternativen kenne ich sonst keine.

Das ist der Plan. Ich habe alle meine Geschäftspartner - gerade auch Anwälte u Steuerberater - angemailt und ihnen die Wahl gelassen, alles was über ein 'Hallo wie gehts' hinausgehen entweder zu verschlüsseln oder per SMail zu senden.

Es ging auch nicht um freie Alternativen, sondern eher generell darum, ob ein Gruppenschlüssel sinnvoll ist oder nicht. Ich würde ungern auf S/MIME wechseln, weil es IMHO die schlechtere Variante ist. (Vorgetäuschte Sicherheit durch 'Trust Organisations')

 

[/dev/null]

Ich würde ungern auf S/MIME wechseln, weil es IMHO die schlechtere Variante ist. (Vorgetäuschte Sicherheit durch 'Trust Organisations')

so so ...
Du kennst dich also auf diesem Gebiet aus?

 

[coogor]

Ich würde ungern auf S/MIME wechseln, weil es IMHO die schlechtere Variante ist. (Vorgetäuschte Sicherheit durch 'Trust Organisations')

so so ...
Du kennst dich also auf diesem Gebiet aus?

Ich arbeite dran, und habe zugegebenermassen deutlich längere Erfahrung mit PGP als mit S/MIME. Organisationen, die dazwischen hängen, und die gegen Bezahlung Vertrauen aussprechen, sind m.E. ein Designfehler.
Wenn Du eine andere Meinung, oder relevante Informationen hast, sind wir wohl alle begierig zu lernen.....

 

[RME]

Hallo,

Ich würde ungern auf S/MIME wechseln, weil es IMHO die schlechtere Variante ist. (Vorgetäuschte Sicherheit durch 'Trust Organisations')

...ist sicher berechtigt. Zum Beispiel: die Vertragsbedingungen bei "COMODO" (ein "Trusted Host") sagen:

COMODO TF CERTIFICATE SUBSCRIBER AGREEMENT

2.2. Limitations. The TF Certificate is being only licensed to you, not sold. You acknowledge that Comodo retains all rights, title, and interest in the TF Certificate and any related services or products. All rights not granted herein are reserved to Comodo.

3.2.
Either party may disclose Confidential Information to the extent required by law or if disclosure is in response to a judicial or regulatory proceeding, even if the proceeding does not have the force of law. Disclosure under this section is limited to the amount of disclosure necessary to comply with a proceeding. Either party may disclose any Confidential Information if the information comes into the public domain through no fault of the party.

>>> http://www.google.ch/url?sa=t&rct=j...SA-oAg&usg=AFQjCNG-5snO5wNswDEyuLGQv5re4-Df1g

So "trusted" scheint dies nicht zu sein. Will etwa ein Nachrichtendienst beispielsweise "falsche" öffentliche Schlüssel zertifiziert haben, wird der "Trusted Host" dies auch tun (müssen).

----------

Siehe z.B. ein "Meinungs-Austausch" hier (z.Z. 25 Seiten; gutes und weniger gutes):

Schutz gegen Internet-Spione: So verschlüsseln Sie Ihre E-Mails >>> http://forum.spiegel.de/f22/schutz-...so-verschluesseln-sie-ihre-e-mails-94729.html

Gruss,
Roland

 

[/dev/null]

Ok, gern.
Ich schreibe aber nicht über die "Billigheimer", die für lau Demozertifikate verschenken. Ich schreibe über die in Deutschland akkredidierten Trustcenter. Wobei auch bei den "Billigheimern" der private Schlüssel nicht im TC, sondern in der Kryptoengine des Browsers des Antragstellers erzeugt wird, und an das TC lediglich ein "Request" (auch "Zertifikatsanforderung" genannt) verschickt wird. Aus dem Request wird dann durch Hinzufügen des Herausgeberschlüssels des TC, Gültigkeitszeitraum und weiteren Zertifikatsdaten das "Zertifikat" erzeugt, welches dann mit dem privaten Schlüssel des Herausgebers signiert wird.
Dieses Zertifikat wird an den Browser des Antragstellers zurückgeschickt, dort mit dem privaten Schlüssel verknüpft und als passwortgeschützte Schlüsseldatei p12 oder pfx für den Export bereitgestellt. Alles das kannst du unter "PKCS#10" nachgoogeln.

Was es hier nicht gibt, und das ist der große Unterschied, ist die sicherere Personenidentifizierung. Diese kann es nicht für lau geben! Sie ist es, was das Produkt (berechtigterweise) teuer macht.
BTW: Damit hat ein derartiges Zertifikat die gleiche Qualität wie dein GnuPG-Schlüssel. Auch hier bestätigt dir niemand (außer vlt. Heise usw.) die Identität des Schlüsselinhabers. Und komme mir bitte nicht mit "Web of Trust". Es kostet mich ein Lächeln und etwas Zeit, 100 funktionierende eigene Mailadressen zusammenzusammeln. Und es kostet mich auch nur etwas Zeit, diese alle mit einem GnuPG-Schlüssel auszustatten. Und dann könnte ich Kryptoparty spielen und alle kreuzweise signieren. Wenn ichs denn wollte ... .
Für die eigentliche Verschlüsselung betrachte ich beide (GnuPG und Kostnixzertifikat) als gleichwertig!

Zurück zum Thema.
Wenn du es dir antun willst, dann studiere das dt. Signaturgesetz und die Signaturverordnung. (Gerade ersteres ist ein Gesetz "von Juristen für Juristen" und wegen dessen fast nicht zu realisierenden Forderungen für mich die Ursache, warum in Deutschland die elektronische Signatur nicht in die Gänge kommt. Aber das ist ein anderes Thema.) Und zusätzlich studiere die öffentlich verfügbaren "Zertifizierungsrichtlinien" (auch "Policy" genannt) der dt. Trustcenter. Darin werden alle Arbeitsabläufe sowie die dafür geltenden und anzuwendenden Bestimmungen klar und sehr ausführlich beschrieben.
Du wirst erkennen, welche enorm hohen Sicherheits-, organisatorischen und personellen Anforderungen an den Betrieb eines TC gestellt werden. Anforderungen, deren Durchsetzung noch extremer sind, als bei der Produktion und Bereitstellung von Schlüsseln für sonstige Geheimhaltungstechnik. (Ich weiß, wovon ich schreibe - aber mehr dazu gibt es nicht.)
So ist es in einem akkreditierten TC Vorschrift, dass die relevanten Räume nur von mindestens zwei Personen betreten werden dürfen (abgesichert mit Zugangskarten). Jede relevante Arbeit an der Technik muss von zwei Personen ausgeführt werden, was natürlich auch immer mit den entsprechenden Signaturkarten abgesichert ist. Jeder Vorgang wird in signierten Logs festgehalten. Und auch jeder Arbeitsschritt in der Registrierung und Produktion wird von den Mitarbeitern bei jedem Vorgang (!) mit deren Signaturkarte bestätigt. Die baulichen Absicherungsmaßnahmen sind ebenfalls "extrem aufwändig".

Die privaten Schlüssel der Antragsteller werden durch den qualifizierten kryptologischen Zufallszahlengenerator, welcher sich auf der Chipkarte befindet, direkt auf der Karte produziert, durch den ebenfalls auf der Karte befindlichen kryptologischen Coprozessor wird daraus der öffentliche Schlüssel berechnet (RSA) und die Schlüsselpaare werden dann auf der Karte gespeichert. Die privaten Schlüssel werden so gespeichert (durch Entfernen der Lese- und Schreibfähigkeit), dass diese niemals die Karte verlassen können. Nochmal: die privaten Schlüssel haben auch bei deren Generierung niemals den Chip verlassen! Die Karten bekommen vom KGS (KeyGenerationSystem) die Befehle, und die Prozessoren auf der Karte führen diese aus. Jeder Schlüssel ist also ein Unikat.
Das bedeutet, dass der zu entschlüsselnde SessionKey bzw. der zu verschlüsselnde Hashwert (für die Signatur) über den Kartenleser direkt zur Karte zu führen sind, und der kryptologische Coprozessor dort seine Arbeit macht.
Die privaten Schlüssel sind durch eine in der Regel 8-stellige PIN mit max. drei Fehlversuchen gesichert. Danach erfolgt die Sperrung. Und die PIN darf nur mit einem Klasse 2 (und höher) Leser eingetippt werden, bei dem sicher ist, dass die PIN niemals vom Rechner "gesehen" und "weggefangen" werden kann.
Der PIN wird in einem automatischen Verfahren von der Karte generiert und (verschlüsselt) an einen speziellen PIN-Briefdrucker gesandt. Dort wird er ausgedruckt und innerhalb des gekapselten und gesicherten Druckers gefaltet und heiß verschweißt (oder auf eine andere sichere Art und Weise verschlossen, du kennst ja die PIN-Briefe für Bank- und SIM-Karten.) Danach wird die PIN, die niemals ein Mesch bis jetzt gesehen hat, sofort kryptologisch überschrieben.
Dass diese Karten durch das BSI intensiv vor ihrer Zulassung für diese Verwendung geprüft werden, erwähne ich nur am Rande. Gleiches trifft natürlich auch für sämtliche Arbeitsabläufe usw. im TC zu. Dort kommt allerdings auch noch die Bundesnetzagentur, die aus für mich nicht zu erschließenden Gründen die Aufsicht über die TC führt.

BTW: Ich habe nicht umsonst den Prozess des Generierens der Schlüssel so umfassend beschrieben. Der "Beste Freund" eines Kryptologen sind Pseudozufallszahlen, welche auf einem PC erzeugt werden ... . Vergleiche selbst.

Der größte Unterschied zwischen der "Kryptografie für die Massen" und Zertifikaten eines TrustCenters ist aber die Identitätsprüfung der Antragsteller. Gemäß §5 SigG ist jeder Antragsteller sicher zu identifizieren. Und diese Identifizierung hat gem SigVO durch Vorweisen eines amtlichen Lichtbildausweises und und einer Unterschriftsleistung nach dem 4-Augenprinzip zu erfolgen. Und genau diese Identität des Antragstellers ist es, welche das TC durch die Signatur des gesamten Zertifikates, natürlich incl. des öffentlichen Schlüssels, mit seinem privaten Schlüssel bestätigt.
Oder anders gesagt, neben der hochsicheren Erzeugung des einmaligen privaten Schlüssels des Antragstellers muss das TC garantieren, dass "in einer Karte mit dem Namen <user> auch 100% <user> steckt"!

Das ist das, was du so geringschätzend "vorgetäuschte Sicherheit" nennst.

Bevor du mir damit kommst:
Ich weiß selbstverständlich, dass es in der Vergangenheit zu Vorkommnissen gekommen ist, wo (beschreibendes Wort bewusst nicht hingeschrieben!) Organisationen es geschafft haben, Trustcenter zu kompromittieren und gefälschte (nein, es waren trotzdem "echte"!) Schlüssel zu produzieren. Aber in keinem der Fälle haben sie es geschafft, ein TC direkt anzugreifen! Es wurden immer Schlampereien ausgenutzt, und dezentrale Registrare "gehackt" oder auch Fehler bei der Administration ausgenutzt. All das ist mir bekannt. Auch, dass der betreffende Staat dieses TC mit den großen Mängeln sofort aufgelöst hat.
Solche Fehler passieren, wenn das Management einzig und allein auf die Kosten schaut und dabei die notwendige und geforderte (!) Sicherheit bewusst missachtet.


MfG Peter

 

[RME]

Hallo Peter,

Danke für den interessanten Artikel.

Egal wie aufwendig die Massnahmen, es sind immer irgendwo noch Menschen involviert.

Und die Sicherheits-Hardware (z.B. Chiffrier-HW) ist nicht verifizierbar (ich weiss dies aus eigener Erfahrung).

Und die Computer können gehackt werden (SW sowie HW), oder bereits so installiert sein.

Die NSA/CIA (nur als Beispiel) sehen nicht einfach zu wie ihre Daten-Quellen versiegen.

Gruss,
Roland

 

[/dev/null]

Und was wolltest du mir damit sagen?
Trifft das nicht auch alles für unsere Krypto-Laien zu?

 

[RME]

Encryption works. Properly implemented strong crypto systems are one of the few things that you can rely on. Unfortunately, endpoint security is so terrifically weak that NSA can frequently find ways around it.
— Edward Snowden, answering questions live on the Guardian's website

"Properly implemented strong crypto systems" ... wenn es denn so ist.

"endpoint security" ... verschlüsselte Daten sind an sich sicher; die Risiken sind alles rund-herum.

Und was ist mit Microsoft?

Microsoft Corp. (MSFT), the world's largest software company, provides intelligence agencies with information about bugs in its popular software before it publicly releases a fix, according to two people familiar with the process. That information can be used to protect government computers and to access the computers of terrorists or military foes.

>>> http://www.bloomberg.com/news/2013-06-14/u-s-agencies-said-to-swap-data-with-thousands-of-firms.html

Ich würde keine sensiblen Daten über MS Software (z.B. Office, Skype) verarbeiten.

Trifft das nicht auch alles für unsere Krypto-Laien zu?

...da hast Du wohl recht; leider.

-/-

 

[coogor]

Hallo Peter,

vielen Dank für die Aufklärung, sehr interessant!
So lange Menschen im Prozess involviert sind wird es Schwachstellen geben, wie RME schon richtig bemerkte.
Und ja, auch das Web of Trust hat seine Schwächen, die c't Krypto-Kampagne (Heise...) ist nur ein Tropfen auf den heissen Stein.

Mir geht es an der Stelle auch mehr darum, Geschäftspartnern in aller Welt (die sich über deutsche Signaturgesetz und weitere Stilblüten eh kaputt lachen) eine sichere Kommunikation anzubieten, und da scheint mir der 'Firmenschlüssel' nicht der sicherste, aber ein gangbarer Mittelweg zwischen Sicherheit und Kundenkomfort zu sein. Ich denke langfristig werden wir auch beide Verfahren einsetzen (müssen).

 

[/dev/null]

Hi coogor,

im Grunde genommen ist es mir völlig Banane, welche Form der Mailverschlüsselung ihr nutzt. Allein, dass du dir darüber Gedanken machst, ehrt dich. Leider stoßen wir an dieser Stelle (und damit meine ich die GnuPG- genau so wie die S/MIME-Fraktion!) auf eine Wand aus Dummheit und Ignoranz. So viele Enthüllungen kann es gar nicht geben, dass der dt. Michel aufwacht.

Nur bei einem gerate ich in Action: Wenn jemand der, sorry, "nicht allzu viel Ahnung vom Sachverhalt " hat, etwas aufgeschnapptes wiedergibt.
Wenn du einmal die Möglichkeit hättest, ein funktionierendes TrustCenter zu besichtigen (und damit meine ich nicht das einer Uni usw.), wenn du einmal sehen könntest, mit welchem Aufwand selbst der "menschliche Faktor" der Unsicherheit zumindest reduziert wird (4- oder gar 6-Augenprinzip), dann würdest du mich verstehen.
In einem sind wir uns einig: der Mensch ist und bleibt die Schwachstelle Nr. 1 auf dem Gebiet der IT-Sicherheit. Und niemand ist in der Lage, zu sehen, was sich hinter der Stirn an Gedanken befindet. Da helfen auch keine Sicherheitsüberprüfungen und -Verpflichtungen. Siehe E. S. ...

So, für mich ist das Thema damit durch. Entschuldige, dass ich mich in deinen Thread eingeschlichen habe.

Doch noch ein Hinweis zu deinem eigentlichen Problem:
Selbstverständlich gibt es das auch bei S/MIME, dass mehrere Leute (Arbeitsgruppen) sich ein E-Mailpostfach teilen, welches verschlüsselt sendet und empfängt. In diesem Fall sind es selbstverständlich keine Chipkarten (du weißt ja, das sind immer auf eine Person bezogene Unikate), sondern so genannte Softtoken. Also PKCS#12-Dateien, die nach prinzipiell den gleichen Prinzipien produziert werden und in diesem Fall den Vorteil haben, dass sie beim Nutzer kopiert werden können. Nur so können sie auf mehreren Rechnern genutzt werden.
Deine Lösung (und hier wieder völlig egal, ob GnuPG oder S/MIME, ist also durchaus üblich!


MfG Peter

 

[RME]

Nur bei einem gerate ich in Action: Wenn jemand der, sorry, "nicht allzu viel Ahnung vom Sachverhalt " hat, etwas aufgeschnapptes wiedergibt.

Da bin wohl ich gemeint

Ich schicke Dir eine PN und dann ist die Sache auch für mich erledigt.

-/-

 

[spoensche]

@coogor:

Da es sich um geschäftliche e-Mails handelt, kannst du den Gruppenschlüssel schon mal definitiv vergessen.
Grund: Wie willst du gewährleisten, das ein entlassener Mitarbeiter mit dem Schlüssel keinen Unfug anstellt und die Vertrauenswürdigkeit sicher stellen? Gar nicht, weil nicht machbar.

Wie willst du Vertrauenswürdigkeit sicherstellen, wenn man mal eben einen neuen PGP Key erzeugen kann und per Social Engeneering diesen Schlüssel als "echten" an die Kunden verteilt und die Kunden darauf hin den "alten" Schlüssel als nicht vertrauenswürdig einstufen und dritte daraufhin vertrauliche Informationen erhalten, die du selbst nicht mehr "lesen" kannst?



Ich hoffe du hast bei der Verschlüsselung auch die gesetzl. vorgeschriebene revisionsischere e-Mail Archivierung mit eingeplant.

 

[coogor]

Da es sich um geschäftliche e-Mails handelt, kannst du den Gruppenschlüssel schon mal definitiv vergessen.
Grund: Wie willst du gewährleisten, das ein entlassener Mitarbeiter mit dem Schlüssel keinen Unfug anstellt und die Vertrauenswürdigkeit sicher stellen? Gar nicht, weil nicht machbar.

Womit wir wieder beim menschlichen Faktor wären.... Den Unfug kann er auch mit seinem eigenen Schlüssel anstellen, immer auch vorausgesetzt er kann den privaten Schlüssel exportieren und wo anders installieren. Ich hoffe dafür fehlen die Skills

Wie willst du Vertrauenswürdigkeit sicherstellen, wenn man mal eben einen neuen PGP Key erzeugen kann und per Social Engeneering diesen Schlüssel als "echten" an die Kunden verteilt und die Kunden darauf hin den "alten" Schlüssel als nicht vertrauenswürdig einstufen und dritte daraufhin vertrauliche Informationen erhalten, die du selbst nicht mehr "lesen" kannst?

Dies Problem ist wohl immanent - es reicht ja schon wenn er mit dem eigenen Schlüssel kommuniziert. Das kann nur über Information verhindert werden, was bei unserer kleinen Gruppe machbar sein sollte. Oder welche Lösung fiele dir ein?

Ich hoffe du hast bei der Verschlüsselung auch die gesetzl. vorgeschriebene revisionsischere e-Mail Archivierung mit eingeplant.

Yep, das haben wir zumindest auf der Agenda, wenn auch nicht im ersten Schritt. Im Moment werden die Mails einfach beim Dienstleister gehostet, ggf. werden wir später entweder eine Groupwarelösung (Zimbra o.ä.) mieten oder einen eigenen Mailserver aufsetzen. Da müßte man mal sehen was es da für Lösungen gibt. In der 'Outlook' Welt wurden uns ein paar angeboten...schon heftig, wie die Anbieter zulangen :schockiert:

 

[spoensche]

Wie willst du Vertrauenswürdigkeit sicherstellen, wenn man mal eben einen neuen PGP Key erzeugen kann und per Social Engeneering diesen Schlüssel als "echten" an die Kunden verteilt und die Kunden darauf hin den "alten" Schlüssel als nicht vertrauenswürdig einstufen und dritte daraufhin vertrauliche Informationen erhalten, die du selbst nicht mehr "lesen" kannst?

Dies Problem ist wohl immanent - es reicht ja schon wenn er mit dem eigenen Schlüssel kommuniziert. Das kann nur über Information verhindert werden, was bei unserer kleinen Gruppe machbar sein sollte. Oder welche Lösung fiele dir ein?

S/MIME, also Zertifikate die von einem offiziellen Trustcenter signiert sind. Damit wäre auch Punkt 1 mit eigenem Schlüssel erledigt.

Ich hoffe du hast bei der Verschlüsselung auch die gesetzl. vorgeschriebene revisionsischere e-Mail Archivierung mit eingeplant.

Yep, das haben wir zumindest auf der Agenda, wenn auch nicht im ersten Schritt. Im Moment werden die Mails einfach beim Dienstleister gehostet, ggf. werden wir später entweder eine Groupwarelösung (Zimbra o.ä.) mieten oder einen eigenen Mailserver aufsetzen. Da müßte man mal sehen was es da für Lösungen gibt. In der 'Outlook' Welt wurden uns ein paar angeboten...schon heftig, wie die Anbieter zulangen :schockiert:

Was willst du in der Outlook Welt? (ausser Viren etc. einfangen u. anderen leichte Angriffe ermöglichen?)

Beim mieten einer Groupwarelösung liegen die kritischen Daten allerdings bei einem Fremdanbieter. Du kannst Zimbra auch downloaden und installieren.
Statt Zimbra kannst du auch Open-Xchange verwenden.

Sieh dir mal das Mailarchiv von Heinlein Support an, http://www.heinlein-support.de/mail-archiv.