qes qualifizierte elektronische Signatur beA

Es ist aber auch nicht fair, immer gleich abschätzig über “proprietäre” Software zu urteilen, und gleichzeitig selbst nur halbgare Lösungen anzubieten, die nur gegen kostenpflichtigen (oder zeitaufwendigen eigenen) Support zum Laufen zu bekommen sind.

Das ist schön für euch und eure Kunden, aber als Privatmensch, der funktionierend qualifiziert signieren will, ist der Secsigner dann bestimmt die preiswertere Lösung, selbst wenn ich dort eine Lizenz kaufe. Oder was kostet dieser “Support”, wenn es eine lauffähige Installation sein soll?

Da bin ich offen: Noch ist die Kombination Okular/GnuPG für qualifizierte Signaturen nicht leicht einsetzbar. Aber sie existiert und wird einsetzbarer. Für manche Nutzenden geht das leichter, für andere schwerer.

Die allgemeinen Nachteile von proprietärer Software bleiben jedoch - davon unberührt - bestehen. Deshalb arbeiten wir ja daran (mit den uns verfügbaren Mitteln) die Freie Software-Lösungen zu verbesseren, was allen zu Gute kommt.

Ja komm dann lass uns doch mal herausfinden warum das bei dir nicht geht.
Also support in der Hoffnung das wir unsere defaults so ändern können das das in Zukunft nicht notwendig ist.

Also als erstes mal unter %APPDATA%\gnupg\scdaemon.conf
pcsc-shared
eintragen.

Dann bitte auf die Kommandzeile und einmal:

gpgconf --kill all
Und dann
gpgsm --learn-card

Und da dann bitte die Ausgabe hier posten.

Antwort:

C:\Users\user>gpgconf --kill all

C:\Users\user>gpgsm --learn-card
gpgsm: error learning card: No such device

C:\Users\user>gpgsm --learn-card

C:\Users\user>gpgconf --kill all

C:\Users\user>gpgsm --learn-card

C:\Users\user>

Da fehlt wohl noch irgendwas. Ab dem zweiten “learn-card” war der Kartenleser angeschlossen, Karte steckte. Eine Ausgabe erfolgt nicht.

Oh ok. Da hatte ich dann mit einer Fehlermeldung gerechnet. Weil Kleopatra ja nichts anzeigt. Das scheint dann schonmal funktioniert zu haben.

Mit “gpgsm --list-secret-keys” werden aber nicht die Zertifikate von deiner Karte gelistet und Sie sind auch nicht in Kleopatra vorhanden?

Dann wäre

Dann wäre ich als nächstes mal auf die ausgabe von
“gpg-card” gespannt (so zusammengeschrieben das ist ein eigenes programm)

Da kannst du auch mit “help” dir alle befehle anzeigen lassen und mit “quit” kommst du wieder raus. Mich intressiert die Ausgabe von “list” aber die wird direkt beim start angegeben.

Richtig. Nur zwei in Kleopatra installierte Softzertifikate werden aufgeführt.

C:\Users\user>gpg-card
Reader ...........: REINER SCT cyberJack RFID standard USB 1
Serial number ....: (20stellige Seriennummer)
Application type .: DINSIG

gpg/card>

Nur zur Klarstellung: es steckt während dieser Befehle eine qualifizierte DGN-Signaturkarte. Die hat gegenüber anderen Karten unter Windows die Besonderheit, daß sie keine Middleware braucht. (Aber mit einer DATEV-Karte, die eine Middleware hat, klappt es auch nicht.)

Ah, wir kommen vorran. Die DINSIG app hatten wir (also zumindest ich) so gar nicht mehr auf dem Schirm, wir haben uns auf generelle PKCS#15 Karten konzentriert, ich hätte jetzt auch ganz naiv angenommen das diese Karten wenigstens noch eine andere app mit drauf haben und nicht nur die eine. :roll_eyes: Habe ⚓ T6740 scd: Add / improve support for DINSIG cards mal aufgemacht. Also ja funktioniert aktuell nicht, und da hilft auch kein Support aber das wird bestimmt keine 10 Jahre dauern :wink:

Kannst du gpg-card nochmal mit der DATEV Karte aufrufen? Nur damit wir schauen können ob es das gleiche problem ist, sonst ist die vielleicht auch noch einen anderen issue wert.

1 Like

Da sieht es noch düsterer aus:

C:\Users\user>gpgconf --kill all

C:\Users\user>gpgsm --learn-card
gpgsm: error learning card: No such device

C:\Users\user>gpg-card
Error reading card: Card not present
gpg/card> gpg-card

Die DATEV-Middleware (“Sicherheitspaket compact”) läuft, die Karte steckt und wurde gerade zum E-Mails signieren verwendet. In Kleopatra wird sie auch nicht angezeigt.

Dann bin ich ja mal gespannt!

Da hab ich übrigens noch eine, eine sog. EPO-Karte vom Europäischen Patentamt. Diese Karte hält sich wohl ganz sauber an den Standard, hat eine Middleware von Cryptovision und stellt sich genauso tot wie die DATEV-Karte.

Jo, das wird wohl so schnell eher nichts.

Mh, die klingt auch intressant. Du bist ein guter Tester :smiley:

Ok. PKCS#15 da sagen mir die Smartcard leute ist auch kein wirklicher Standard sondern man muss immer noch was anpassen.

Ist das zufällig die:
Hersteller ID: A.E.T. Europe B.V.
Profiltyp: PKCS#15
Unterstützte Algorithmen: DES, RSA
Kartenbetriebssystem: G&D STARCOS 3.2

Da sind gerade testkarten zu uns unterwegs und könnten es ins nächste release noch schaffen.

Ich bin ein guter Pechvogel. Mir geht es mit Software wie anderen Leuten mit fremden Hunden (“Das hat er ja noch nie gemacht.”) :grimacing:

Keine Ahnung, wo sieht man das? In der Cryptovision-Software steht nur die Kartennummer. In Thunderbird steht als Hersteller “Gemalto S. A.”.

Die DGN-Karte ist übrigens nicht die neueste. Es gibt wohl seit 2023 neue Karten. Ob die gleich genug geblieben sind, weiß ich nicht.

Könnte man nicht die Kartenverwaltung einfach von Thunderbird oder Firefox übernehmen? Bei denen habe ich noch fast jede Karte zum Laufen bekommen. Dort kann man nämlich den Speicherort der Treiberdatei angeben und dann “kann” das Programm die Karte.

Thunderbird und Firefox sind doch auch Open Source und man darf den Quelltext verwenden?

Hallo? Ist noch jemand zuhause?

wir haben tickets dafür offen die neuen Karten hinzuzufügen. Vielen Dank auch auf deinen Hinweis bezüglich des DGNService. Aber wir werden die Karten nur nach und nach hinzufügen können, da der zuständige Entwickler aktuell sehr stark ausgelastet ist und ein neuer Kollege der ihn entlasten soll erst diesen Monat angefangen hat. So ist das leider manchmal. Ich denke für das nächste release schaffen wir maximal eine weitere Karte und das ist die genante Karte von A.E.T Europe, da die aber auch mit Cryptovision Software gemanaged wird könnte es sein das es deine Gemalto Karte mit supported. :slightly_smiling_face:

Sorry, aber hey, transparenz. Wir haben das schon auf dem Schirm das wir uns da etwas verschätzt haben wie verbreitet andere QES Karten sind und hatten hauptsächlich Telekom und Bundesdruckerei gedacht weil das bei unseren Kunden so ist.

1 Like

Jaja, DGN ist groß. Sie machen auch wohl nicht nur die eigenen Signaturkarten, sondern zusätzlich nochmal 200.000 Heilberufsausweise für eine Tochterfirma.

Von A.E.T. habe ich jetzt noch nie gehört.

Aber wäre das nicht eine Möglichkeit, die Entwicklung von Firefox oder Thunderbird zu übernehmen, wenn es dort schon funktioniert? Das könnte doch Zeit sparen, oder?

Aber wäre das nicht eine Möglichkeit, die Entwicklung von Firefox oder
Thunderbird zu übernehmen, wenn es dort schon funktioniert? Das könnte doch
Zeit sparen, oder?

Meiner Vermutung nach geht das nicht, weil die Technik unterschiedlich ist.

Genau, aktuell ist das für uns keine option. Mit scute bieten wir ein Modul mit dem wir unseren Kartensupport für Firefox und Thunderbird bereitstellen. Es war mal unsere bewusste Entscheidung das wir keine “Black Box” in form eines proprietären Treibermoduls zwischen uns und der Smartcard dulden wollten. Aber… wir sind ja doch ein bisschen pragmatisch :stuck_out_tongue: In: ⚓ T6234 Implement access to smartcards via a generic pkcs#11 interface sollte das eigentlich implementiert werden. Das Ticket ist aber glaube ich etwas in vergessenheit geraten, ich habe da gerade mal gepingt.

Da kann man nur auf eine ordentliche Portion Pragmatismus hoffen. Wenn man sich eh schon schwer tut, mit der technischen Entwicklung schrittzuhalten, dann auch noch auf 100% Eigenentwicklung zu setzen, finde ich gelinde gesagt: originell.

Wozu gibt es denn Middleware? Bis ihr eine Kartengeneration integriert habt, ist die Zulassung für ein Kartenbetriebssystem abgelaufen ( z. B. STARCOS 3.5) und das nächste ist auf dem Markt ( z. B. STARCOS 3.7). So hinkt ihr ewig hinterher.

Übrigens, was auch noch zu qualifizierter elektronischer Signatur gehören würde, habe ich gerade einmal anhand von GPG 4.3.0 ausprobiert. QES müssen nämlich mit anderer QES-Software prüfbar sein. Und umgekehrt sollte eine QES-Software fremde QES-Signaturen prüfen können. Die Ergebnisse stehen gleich darunter:

  • Prüfen einer GPG-Signatur in Secsigner:
    “Beim Einlesen der Daten ist ein Fehler aufgetreten: Die Daten entsprechen keinem gültigen Signaturformat. DER decoder found unknown tag: 13”

  • Prüfen einer echten QES-Signatur aus Secsigner mit GPG:
    “Gültigkeitsprüfung fehlgeschlagen: Nicht unterstützte CMS Version.”
    und
    “gpgsm: ksba_cms_parse failed: Nicht unterstützte CMS Version”

  • Zeitstempeleinholung? Nicht möglich.

  • Zeitstempelüberprüfung? Nicht möglich.

Und schon der Versuch, zu signieren mit Okular:
Ergebnis sind zwei 0-Byte-Dateien, okular_CCLiMM.png und okular_tibyrx.pdf

Frohes Schaffen! :sweat_smile:

Frohes Schaffen!

Danke für Deine Tests und Hinweise!

Es geht halt nur Schritt für Schritt, da GnuPG nicht über die Entwicklungsresourcen verfügt, wie manche Großanbieter.

Zwischenstücke sind durchaus möglich, denke ich, allerdings nur, wenn sie komplett überprüfbar sind (also Freie Software). Ich finde die Strategie schon in Ordnung, zu sagen wir möchten etwas machen, was langfristiger haltbar ist, offen und überprüfbar (also im Quelltext sichtbar). Wenn ich mich erinnere, wieviele proprietäre Krypto-Lösungen wieder verschwunden sind, dann halte ich langsamer für vielversprechender.

Gruß
Bernhard