Hallo,
so auf der Suche nach diesem und jenem (signierte Timestamps) stolpere ich auch über folgende URL und schaue die mir mal spaßeshalber an. Es wird IMHO eine Software beschrieben, die einen externen Chipkartenleser nutzend, Dokumente signiert und anzeigt.
https://www.bsi.bund.de/cae/servlet/contentblob/480564/publicationFile/29495...
GRUSEL!
Seite 41 ff . empfehle ich dem geneigten Leser besonders.
Kostproben:
"In a terminal server environment the communication between server and client/s is conducted via an encrypted channel and is therefore to be considered trustworthy."
ssh -X -c none?, ROT13?, HDMI+HDCP? Warum auf Details eingehen: "is" langt doch!
"The user must ensure that all components of the operating system are correct. The user must ensure that no harmful or malicious software is installed on the system."
Und das nach ausdrücklichem Hinweis, daß IE > 5.01 zum Betrieb der Software nötig ist und Internetverbindung nicht ausgeschlossen wird. Kein Wort, wie das passieren soll. Debsums für Windows? Wohin mit Updates? (Immerhin wird später erwähnt, daß die eigene Software wohl ihre Checksumme prüft.)
Mag sein, daß ich nach den letzten 40 Seiten an Abkürzungswerferei den Sinn nicht mehr verstehe, aber irgendwie klingt es danach, daß li_sha1 la_sha1 bestätigt, weil lo_sha1 sichert, daß lu_sha1 zuverlässig ist und sha5 nicht zutrifft. Kein Wort über konkrete Test, immer nur wird versichert. Findet ihr vielleicht einen Hinweis auf wenigstens einen statischen Code-Check a la lint?
Ich wüßte nach der Lektüre nicht viel mehr zum Thema Sicherheit der ganzen Sache zu sagen, als daß Papier wohl sehr geduldig ist. Wieviel Arbeit wohl in so einer Zertifizierung steckt? Ob das überhaupt jemand ernst nimmt (nehmen kann)?
Disclaimer: Nicht das ihr denkt, ich wollte jetzt einen Hersteller oder ein Produkt schlechtmachen, das hier ist mir zufällig untergekommen.
Bernhard
On Wednesday 17 March 2010, Bernhard Schiffner wrote:
"In a terminal server environment the communication between server and client/s is conducted via an encrypted channel and is therefore to be considered trustworthy."
ssh -X -c none?, ROT13?, HDMI+HDCP? Warum auf Details eingehen: "is" langt doch!
Das Wort "is" impliziert eine Menge. In diesem Fall fällt ROT13 nicht darunter.
"The user must ensure that all components of the operating system are correct. The user must ensure that no harmful or malicious software is installed on the system."
Hätte ich auch so geschrieben. Selbstschutz des Herstellers.
Und das nach ausdrücklichem Hinweis, daß IE > 5.01 zum Betrieb der Software nötig ist und Internetverbindung nicht ausgeschlossen wird. Kein Wort, wie das passieren soll. Debsums für Windows? Wohin mit Updates? (Immerhin wird später erwähnt, daß die eigene Software wohl ihre Checksumme prüft.)
Also Standard-Windoof-Software mit HTML Komponente. Warum wundert Dich das?
Mag sein, daß ich nach den letzten 40 Seiten an Abkürzungswerferei den Sinn nicht mehr verstehe, aber irgendwie klingt es danach, daß li_sha1 la_sha1 bestätigt, weil lo_sha1 sichert, daß lu_sha1 zuverlässig ist und sha5 nicht zutrifft.
SHA5 gibt es (noch) nicht. Meintest Du SHA-512? (Das wird zumindest erwähnt und ist eine Variante von SHA2.)
Kein Wort über konkrete Test, immer nur wird versichert. Findet ihr vielleicht einen Hinweis auf wenigstens einen statischen Code-Check a la lint?
Ich wüßte nach der Lektüre nicht viel mehr zum Thema Sicherheit der ganzen Sache zu sagen, als daß Papier wohl sehr geduldig ist. Wieviel Arbeit wohl in so einer Zertifizierung steckt? Ob das überhaupt jemand ernst nimmt (nehmen kann)?
Nach sehr kurzem draufschauen: das ist ein Überblick. Im Allgemeinen sieht eine komplette Spec oder ein Testbericht anders aus.
Zitat: "1 Introduction The following sections contain general information about the TOE 1 and other general information."
Mit dem Ding kann man lediglich entscheiden ob es sich lohnt weiteres Material anzufordern.
Wenn ich ein solches System für Windoofs-Umgebungen bräuchte würde ich jetzt Kontakt aufnehmen und nach den echten Infos fragen.
Konrad
On Wednesday, 17. March 2010 09:32:03 Konrad Rosenbaum wrote:
On Wednesday 17 March 2010, Bernhard Schiffner wrote:
"In a terminal server environment the communication between server and client/s is conducted via an encrypted channel and is therefore to be considered trustworthy."
ssh -X -c none?, ROT13?, HDMI+HDCP? Warum auf Details eingehen: "is" langt doch!
Das Wort "is" impliziert eine Menge. In diesem Fall fällt ROT13 nicht darunter.
is conducted using (strong) encryption ... vs. is conducted via an encrypted channel (claimed to be able to do so _and_ using it)
"The user must ensure that all components of the operating system are correct. The user must ensure that no harmful or malicious software is installed on the system."
Hätte ich auch so geschrieben. Selbstschutz des Herstellers.
Klar. NB: Ist das bei "effektiver" Verschlüsselung auch so. Langt da eine Herstellerbehauptung?
Und das nach ausdrücklichem Hinweis, daß IE > 5.01 zum Betrieb der Software nötig ist und Internetverbindung nicht ausgeschlossen wird. Kein Wort, wie das passieren soll. Debsums für Windows? Wohin mit Updates? (Immerhin wird später erwähnt, daß die eigene Software wohl ihre Checksumme prüft.)
Also Standard-Windoof-Software mit HTML Komponente. Warum wundert Dich das?
Als Umgebung: gar nicht. Als stand-alone-Variante (zumindest bei erstmaliger Nutzung) halte ich das sogar für relativ sicher. Im längeren, vernetzten Gebrauch: Tod im Topf.
Mag sein, daß ich nach den letzten 40 Seiten an Abkürzungswerferei den Sinn nicht mehr verstehe, aber irgendwie klingt es danach, daß li_sha1 la_sha1 bestätigt, weil lo_sha1 sichert, daß lu_sha1 zuverlässig ist und sha5 nicht zutrifft.
SHA5 gibt es (noch) nicht. Meintest Du SHA-512? (Das wird zumindest erwähnt und ist eine Variante von SHA2.)
Nicht ganz ernst gemeint hier. Mir ist bloß wichtig, den andauernden Selbstbezug der Aussagen anzuzeigen. Klar, daß sich das aus irgendwelchen (logischen oder auch gesetzlichen) Formalien herleitet. Die Matrizen sind dort das Problem: welche Methode schützt an welcher Stelle welchen Sachverhalt. Dazu braucht es halt viele ähnliche Namen.
Da die Matrizen per Behautpung etwas "sparse" sind, kommen mir einige Zweifel. Ich hatte bei Medizintechnik (interner Gebrauch) auch Matrizen. Die waren grün (getestete Funktionalität), rot (getestete Fehlerfälle), grau ("Beifang", also Test die sonst so durchgeführt wurden) und leer (erwägbare, aber ungetestete Zustände und Transitionen.) Bei großen Projekten mit unterschiedlichen Konfigurationen war das meiste leer. Es war eine große Diskussion, ob "leer" überhaupt zulässig ist: theoretisch nein, praktisch ja.
Kein Wort über konkrete Test, immer nur wird versichert. Findet ihr vielleicht einen Hinweis auf wenigstens einen statischen Code-Check a la lint?
Ich wüßte nach der Lektüre nicht viel mehr zum Thema Sicherheit der ganzen Sache zu sagen, als daß Papier wohl sehr geduldig ist. Wieviel Arbeit wohl in so einer Zertifizierung steckt? Ob das überhaupt jemand ernst nimmt (nehmen kann)?
Nach sehr kurzem draufschauen: das ist ein Überblick. Im Allgemeinen sieht eine komplette Spec oder ein Testbericht anders aus.
Hofftenlich. (Ich habe mir das BSI-Zertifikat dazu nicht angeschaut.)
Zitat: "1 Introduction The following sections contain general information about the TOE 1 and other general information."
Mit dem Ding kann man lediglich entscheiden ob es sich lohnt weiteres Material anzufordern.
Wenn ich ein solches System für Windoofs-Umgebungen bräuchte würde ich jetzt Kontakt aufnehmen und nach den echten Infos fragen.
+=1 Aber viel Glück! Nach meiner Erfahrung ist die aktuelle Version vermutlich gerade im Ausdruck. 400 Seiten, großzügiger Druck, eine Menge Unterabschnitte mit Verweisen und extrem wenig an "Substanz" drin, wenn sie dann vorliegt.
Konrad
:-) Bernhard
On Wednesday 17 March 2010, Bernhard Schiffner wrote:
On Wednesday, 17. March 2010 09:32:03 Konrad Rosenbaum wrote:
Das Wort "is" impliziert eine Menge. In diesem Fall fällt ROT13 nicht darunter.
is conducted using (strong) encryption ... vs. is conducted via an encrypted channel (claimed to be able to do so _and_ using it)
Da liegt der Unterschied zwischen "Management-Überblick" und "wissenschaftlich abgesichert". Ein Manager versteht z.B. den Unterschied zwischen "eins" und "eins und nur eins" nicht. Also wozu Worte verschwenden?
Klar. NB: Ist das bei "effektiver" Verschlüsselung auch so. Langt da eine Herstellerbehauptung?
Worauf beziehst Du Dich? Falls Kopierschutz und Urheberrecht: die legal akzeptierte Version von "effektiv" ist "Otto Normalbürger kann es nicht knacken". Die Behauptungen vom Hersteller sind da egal. Die von Kryptoexperten auch.
[Disclaimer: ich nix Anwalt]
Da die Matrizen per Behautpung etwas "sparse" sind, kommen mir einige Zweifel. Ich hatte bei Medizintechnik (interner Gebrauch) auch Matrizen. Die waren grün (getestete Funktionalität), rot (getestete Fehlerfälle), grau ("Beifang", also Test die sonst so durchgeführt wurden) und leer (erwägbare, aber ungetestete Zustände und Transitionen.) Bei großen Projekten mit unterschiedlichen Konfigurationen war das meiste leer. Es war eine große Diskussion, ob "leer" überhaupt zulässig ist: theoretisch nein, praktisch ja.
In der Kryptographie sind es üblicherweise nicht Matrizen, sondern Ketten:
Algorithmus A schützt B verwendet C basiert auf D. Dann machst Du einfache Beweise der Kettenglieder: fällt B aus, reicht der Schutz von A, fällt C oder D aus sind A/B wirkungslos.
Nach sehr kurzem draufschauen: das ist ein Überblick. Im Allgemeinen sieht eine komplette Spec oder ein Testbericht anders aus.
Hofftenlich. (Ich habe mir das BSI-Zertifikat dazu nicht angeschaut.)
Das Zertifikat wird auch recht einfach aussehen. Interessant ist sicherlich der Testbericht (falls man da so ohne weiteres rankommt).
Zitat: "1 Introduction The following sections contain general information about the TOE 1 and other general information."
Mit dem Ding kann man lediglich entscheiden ob es sich lohnt weiteres Material anzufordern.
Wenn ich ein solches System für Windoofs-Umgebungen bräuchte würde ich jetzt Kontakt aufnehmen und nach den echten Infos fragen.
+=1 Aber viel Glück! Nach meiner Erfahrung ist die aktuelle Version vermutlich gerade im Ausdruck. 400 Seiten, großzügiger Druck, eine Menge Unterabschnitte mit Verweisen und extrem wenig an "Substanz" drin, wenn sie dann vorliegt.
In den 400 Seiten wird so 2-10 Seiten geben die interessante Tabellen enthalten, die für den Experten alles Wichtige sagen.
Vorgehensweise aus der Praxis: man nimmt den Hersteller dem man am wenigsten mistraut. ;-)
Konrad
Mal eine praktische Frage: Real kann man z.B. bei der deutschen Post ein Krypto-Karte kaufen, die einen kleinen Prozessor enthält. Dieser kryptet dann mit dem darauf ebenfalls enthaltenen Signaturen usw. Ziel ist die Signaturen niemals irgendwo außerhalb der Karte zu haben. Was mache ich aber, wenn die Karte unbrauchbar wird? Ich kann dann zwar eine neue (mit neuer Signatur) beantragen, aber z.B. alte verschlüsselte Mails nicht mehr lesen...
Gruß Jörg
On Wednesday, 17. March 2010 14:46:23 Joerg Bergmann wrote:
Mal eine praktische Frage: Real kann man z.B. bei der deutschen Post ein Krypto-Karte kaufen, die einen kleinen Prozessor enthält.
Hast Du dazu eine Link?
Dieser kryptet dann mit dem darauf ebenfalls enthaltenen Signaturen usw. Ziel ist die Signaturen niemals irgendwo außerhalb der Karte zu haben. Was mache ich aber, wenn die Karte unbrauchbar wird? Ich kann dann zwar eine neue (mit neuer Signatur) beantragen, aber z.B. alte verschlüsselte Mails nicht mehr lesen...
Gruß Jörg
Exakt. Weg ist weg. Du kannst damit nicht mal einen Ausdruck der Schlüssel in ASCII machen.
Habe ich erzählt, daß ich meine "sämtlichen " .gnupg-Verzeichnisse im Rahmen einer Neuinstallation vernichtet habe? Auf der Rettungs- _diskette_ (2001) war der seckey nicht mehr lesbar ("verrostet" / bitrot im wahrsten Sinne), zum Glück war wenigstens noch der Revokation-key zugreifbar :-( )
Das ist mir eine Lehre über solche Dinge. Zugegeben, ich habe sie nicht viel genutzt.
800 Jahre Herrschererfahrung der Wettiner in Sachsen kulminierten 1918 in dem Satz "Nu macht doch euern Dreck alleene!".
Solange Du nicht drauf angewiesen bist: Mach's also selbst.
Außer Spesen nichts gewesen gilt für die Sachen mit der (qualifizierten) digitalen Signatur. Du kriegst Da Deine privaten (selbsterzeugten) Schlüssel nicht drauf. Im Ernstfall haftet die austellende Behörde für nichts. Zertifikate dazu sind wohl 5 Jahre gültig und 30 zu speichern. Die ersten Firmen haben schon dicht gemacht und bei der Übertragung scheint es alles andere als glatt gegangen zu sein. Passphrasen aus 16-stelligen Nummern (weil nur die sich auf den kleinen Tastaturen eingeben lassen) die sich natürlich jeder von uns ganz leicht für 30 Jahre merken kann. etc. etc.
Wichtiger ist aber die Bandbreite des "Gadget": Jedes zu hashende oder zu verschlüsselnde Byte muß über die (USB?) Leitung hin und her. Denk dann mal an X oder verschlüsselte Festplatte. Nix für mich. GAR NICHTS!
Bernhard
Am Mittwoch, den 17.03.2010, 15:35 +0100 schrieb Bernhard Schiffner:
On Wednesday, 17. March 2010 14:46:23 Joerg Bergmann wrote:
Mal eine praktische Frage: Real kann man z.B. bei der deutschen Post ein Krypto-Karte kaufen, die einen kleinen Prozessor enthält.
Hast Du dazu eine Link?
www.post.de ->Geschäftspost ->links: Dienstleistungen ->links: Elektronische Signatur
Dieser kryptet dann mit dem darauf ebenfalls enthaltenen Signaturen usw. Ziel ist die Signaturen niemals irgendwo außerhalb der Karte zu haben. Was mache ich aber, wenn die Karte unbrauchbar wird? Ich kann dann zwar eine neue (mit neuer Signatur) beantragen, aber z.B. alte verschlüsselte Mails nicht mehr lesen...
Gruß Jörg
Exakt. Weg ist weg. Du kannst damit nicht mal einen Ausdruck der Schlüssel in ASCII machen.
Habe ich erzählt, daß ich meine "sämtlichen " .gnupg-Verzeichnisse im Rahmen einer Neuinstallation vernichtet habe? Auf der Rettungs- _diskette_ (2001) war der seckey nicht mehr lesbar ("verrostet" / bitrot im wahrsten Sinne), zum Glück war wenigstens noch der Revokation-key zugreifbar :-( )
Das ist mir eine Lehre über solche Dinge. Zugegeben, ich habe sie nicht viel genutzt.
800 Jahre Herrschererfahrung der Wettiner in Sachsen kulminierten 1918 in dem Satz "Nu macht doch euern Dreck alleene!".
Solange Du nicht drauf angewiesen bist: Mach's also selbst.
Außer Spesen nichts gewesen gilt für die Sachen mit der (qualifizierten) digitalen Signatur. Du kriegst Da Deine privaten (selbsterzeugten) Schlüssel nicht drauf. Im Ernstfall haftet die austellende Behörde für nichts. Zertifikate dazu sind wohl 5 Jahre gültig und 30 zu speichern. Die ersten Firmen haben schon dicht gemacht und bei der Übertragung scheint es alles andere als glatt gegangen zu sein. Passphrasen aus 16-stelligen Nummern (weil nur die sich auf den kleinen Tastaturen eingeben lassen) die sich natürlich jeder von uns ganz leicht für 30 Jahre merken kann. etc. etc.
Wichtiger ist aber die Bandbreite des "Gadget": Jedes zu hashende oder zu verschlüsselnde Byte muß über die (USB?) Leitung hin und her. Denk dann mal an X oder verschlüsselte Festplatte. Nix für mich. GAR NICHTS!
Bernhard
Lug-dd maillist - Lug-dd@mailman.schlittermann.de https://ssl.schlittermann.de/mailman/listinfo/lug-dd
On Wednesday, 17. March 2010 15:49:21 Joerg Bergmann wrote:
Am Mittwoch, den 17.03.2010, 15:35 +0100 schrieb Bernhard Schiffner:
On Wednesday, 17. March 2010 14:46:23 Joerg Bergmann wrote:
Mal eine praktische Frage: Real kann man z.B. bei der deutschen Post ein Krypto-Karte kaufen, die einen kleinen Prozessor enthält.
Hast Du dazu eine Link?
www.post.de ->Geschäftspost ->links: Dienstleistungen ->links: Elektronische Signatur
Jetzt bekommt das ganze mal Gesicht.
Auch sonst so scheinen die Ahnung zu haben. Die Preise: na ja. Eben teuer bei Verlust. Ich möchte von so was nicht alle Nasen lang genervt werden, xxx Vorgänge ohne Pin sollten konfigurierbar sein und nichts zusätzlich kosten. Vermutlich kostet der zusätzliche Counter in der Karte soviel :-) Interessant auch die Aussage, daß vorfabrizierte Karten (vermutlich mit "fertigen" Schlüsseln) personalisiert werden. Ob's dazu auch was unter Linux lauffähiges gibt? Schließlich sind das alles ja Standardkomonenten und -verfahren.
Schön ist die Zertifikatsabfrage, die keine Liste mit Auswahl anbietet sondern nur einen Eintrag exakt getroffen haben will (Test mit "Deutsche Post" als Nachname.)
Bernhard
Am 17.03.2010 18:29, schrieb Bernhard Schiffner:
On Wednesday, 17. March 2010 15:49:21 Joerg Bergmann wrote:
Am Mittwoch, den 17.03.2010, 15:35 +0100 schrieb Bernhard Schiffner:
On Wednesday, 17. March 2010 14:46:23 Joerg Bergmann wrote:
Mal eine praktische Frage: Real kann man z.B. bei der deutschen Post ein Krypto-Karte kaufen, die einen kleinen Prozessor enthält.
Hast Du dazu eine Link?
www.post.de ->Geschäftspost ->links: Dienstleistungen ->links: Elektronische Signatur
Jetzt bekommt das ganze mal Gesicht.
Auch sonst so scheinen die Ahnung zu haben. Die Preise: na ja. Eben teuer bei Verlust. Ich möchte von so was nicht alle Nasen lang genervt werden, xxx Vorgänge ohne Pin sollten konfigurierbar sein und nichts zusätzlich kosten. Vermutlich kostet der zusätzliche Counter in der Karte soviel :-) Interessant auch die Aussage, daß vorfabrizierte Karten (vermutlich mit "fertigen" Schlüsseln) personalisiert werden. Ob's dazu auch was unter Linux lauffähiges gibt? Schließlich sind das alles ja Standardkomonenten und -verfahren.
Soweit ich weiß ist die Mac-Anwendung eine Java-Anwendung, sollte also mit Sun-Java unter Linux eventuell zum Laufen zu kriegen sein
Jörg
Schön ist die Zertifikatsabfrage, die keine Liste mit Auswahl anbietet sondern nur einen Eintrag exakt getroffen haben will (Test mit "Deutsche Post" als Nachname.)
Bernhard
Lug-dd maillist - Lug-dd@mailman.schlittermann.de https://ssl.schlittermann.de/mailman/listinfo/lug-dd
Hi,
Bernhard Schiffner schrieb:
Exakt. Weg ist weg.
das ließe sich umgehen, wenn man sich mehrere völlig identische Karten ausstellen lassen könnte. Technisch machbar, aber ich habe keine Ahnung, ob es angeboten wird.
Wichtiger ist aber die Bandbreite des "Gadget": Jedes zu hashende oder zu verschlüsselnde Byte muß über die (USB?)
Hier arbeitet man mit symmetrischen Session-Schlüssel und nur diese müssen über die Smartcard, nicht das gesamte Filesystem.
Viele Grüße, Torsten
On Wednesday, 17. March 2010 16:08:55 Torsten Werner wrote:
Wichtiger ist aber die Bandbreite des "Gadget": Jedes zu hashende oder zu verschlüsselnde Byte muß über die (USB?)
Hier arbeitet man mit symmetrischen Session-Schlüssel und nur diese müssen über die Smartcard, nicht das gesamte Filesystem.
Riesen Denkfehler meinerseits. Die Karte dient ja _nur_ zum Signieren! Verschlüsselung ist wahrscheinlich nur ungewollter Nebeneffekt. Und ich Trottel habe die Signierung und Verschlüsselung als selbstverständlich und gleichberechtigt angenommen! Bin halt von gpg-verwöhnt.
Meinst Du das etwa so: Ich erzeuge Schutztext/Passphrase/Kodewort, schicke das an die Karte zum Verschlüsseln und erhalte einen Geheimtext zurück, den ich als symmetrischen Schlüssel für Dinge außerhalb der Karte mit Bandbreitenbedarf verwende. (indirekte Verschlüsselung mit der Karte, Entschlüsselung nur über den ensprechenden Key der Karte wäre so nicht möglich.)
Wo / wie bekommt man für eine qualifizierte Signatur (zwecks Prüfung) eigentlich den pubkey eines Partners?
Viele Grüße, Torsten
Danke! Bernhard
Am 17.03.2010 17:53, schrieb Bernhard Schiffner:
On Wednesday, 17. March 2010 16:08:55 Torsten Werner wrote:
Wichtiger ist aber die Bandbreite des "Gadget": Jedes zu hashende oder zu verschlüsselnde Byte muß über die (USB?)
Hier arbeitet man mit symmetrischen Session-Schlüssel und nur diese müssen über die Smartcard, nicht das gesamte Filesystem.
Riesen Denkfehler meinerseits. Die Karte dient ja _nur_ zum Signieren! Verschlüsselung ist wahrscheinlich nur ungewollter Nebeneffekt. Und ich Trottel habe die Signierung und Verschlüsselung als selbstverständlich und gleichberechtigt angenommen! Bin halt von gpg-verwöhnt.
Meinst Du das etwa so: Ich erzeuge Schutztext/Passphrase/Kodewort, schicke das an die Karte zum Verschlüsseln und erhalte einen Geheimtext zurück, den ich als symmetrischen Schlüssel für Dinge außerhalb der Karte mit Bandbreitenbedarf verwende. (indirekte Verschlüsselung mit der Karte, Entschlüsselung nur über den ensprechenden Key der Karte wäre so nicht möglich.)
Wo / wie bekommt man für eine qualifizierte Signatur (zwecks Prüfung) eigentlich den pubkey eines Partners?
Soweit ich dass verstanden habe, wurde da kürzlich eine Hierarchie der Bestätigung aufgebaut: Es gibt auf der Welt eine Hand voll Root-Zertifikat-Aussteller, der zertifiziert die nächste Ebene (dort ist eventuell die Post vorhanden), die zertifiziert die Administratoren und die zertifizieren die normalen User. Zumindest bei https soll das seit kurzem so laufen. Zu jedem Zertifikat gehört also ein (zertfizierter) Link zur ausgebenden Stelle, und man muß die ganze Zertifikatkette prüfen.
Entschuldigung, aber ich bin auf dem Gebiet Laie und versuche das wesentliche zu verstehen...
Gruß Jörg
On Wednesday 17 March 2010, Joerg Bergmann wrote:
Mal eine praktische Frage: Real kann man z.B. bei der deutschen Post ein Krypto-Karte kaufen, die einen kleinen Prozessor enthält. Dieser kryptet dann mit dem darauf ebenfalls enthaltenen Signaturen usw.
Erstmal: der Chip enthält keine Signaturen, sondern Schlüssel, die zum signieren benutzt werden.
Ziel ist die Signaturen niemals irgendwo außerhalb der Karte zu haben.
Falsch. Richtig wäre: die Signaturschlüssel niemals außerhalb der Karte zu haben, um es unmöglich (oder zumindest schwer) zu machen sie zu "stehlen".
Wenn es konsequent umgesetzt ist wird die Karte auch nicht mit einem Schlüssel programmiert, sondern erzeugt ihn selbst wenn sie initialisiert wird.
Was mache ich aber, wenn die Karte unbrauchbar wird? Ich kann dann zwar eine neue (mit neuer Signatur) beantragen, aber z.B. alte verschlüsselte Mails nicht mehr lesen...
Das kommt darauf an, wie das System umgesetzt wird. Üblicherweise werden heutzutage für Signatur und für Verschlüsselung unterschiedliche Keys benutzt.
Ich bin mir nicht sicher, wie das Post-System exakt funktioniert, aber ich würde auf der Karte nur den Signaturteil einsperren und vom Verschlüsselungskey Backups erlauben. Ich bin mir auch nicht ganz sicher, ob das bei S/MIME im Allgemeinen so umgesetzt ist...
Konrad
lug-dd@mailman.schlittermann.de