Frequently Asked Questions - Allgemeine Informationen

Aktuelle wichtige Informationen

Die Herstellererklärung und weitere interessante Dokumente finden Sie    hier.

Tutorials zu verschiedenen Themen finden Sie   hier.

Stand: Dezember 2016

 

Was bedeutet „Sign Live! CC implementiert den jeweils gültigen Algorithmenkatalog“?

Ein Algorithmenkatalog definiert, welche kryptografischen Algorithmen aktuell und für einen Zeitraum in der Zukunft als sicher betrachtet werden. Damit legt er maßgeblich das Sicherheitsniveau einer PKI fest.
SigG/SigV definieren für qualifizierte elektronische Signaturen eine PKI und fordern dazu einen Algorithmenkatalog, der ständig aktualisiert wird.

Die für das SigG zuständige Behörde, die Bundesnetzagentur, veröffentlicht den SigG-Algorithmenkatalog jedes Jahr über das Bundesamtsblatt bzw. auf der eigenen Homepage. Das BSI erstellt diesen Katalog und legt dabei jeweils eine Vorausschau von 7 Jahren zu Grunde. D. h. die betrachteten Algorithmen sind heute und mit aller Wahrscheinlichkeit mindestens die nächsten 7 Jahre noch als sicher zu betrachten. Sehr oft werden diese Zeiträume jahresweise verlängert. Wenn zu erwarten ist, dass ein Algorithmus unsicher wird, haben die Nutzer außer in Ausnahmefällen also eine Vorwarnzeit von 7 Jahren. Dass bekannt gewordene Angriffe das Sicherheitsniveau von Kryptoalgorithmen so plötzlich gefährden, dass ein Gültigkeitszeitraum verkürzt werden musste, ist seit der Existenz des SigG-Algorithmen-Katatalogs nicht vorgekommen.

Sign Live! CC implementiert die Vorgaben des jeweils zum Veröffentlichungszeitpunkt der Software gültigen SigG-Algorithmenkatalogs. Welcher dies ist, entnehmen Sie der zugehörigen Herstellererklärung. Z. B. wurden in SLCC 6.x RSA-Signaturen noch mit dem Padding-Algorithmus PKCS#1-v1.5 erstellt. Erst ab Version 7.x wird der sicherere PSS-Padding-Algorithmus verwendet. Diese Umstellung wurde so spät wie möglich durchgeführt, weil aktuelle Adobe Programme Signaturen mit PSS-Padding nicht prüfen können (s. auch FAQ „Adobe“).

Insbesondere bei der Validierung werden die Ablauffristen von Algorithmen berücksichtigt! Validierungen können zu einem falschen Ergebnis führen, wenn die eingesetzte Software nicht aktuell ist. Genau hier setzt die Verantwortung von Hersteller und Betreiber ein, stets aktuelle Software zur Verfügung zu stellen und einzusetzen.

Ausnahme in Sign Live! CC 7.0

Mit SLCC 7.0 weichen wir von der o.g. Regel leicht ab und erweitern in Vorausschau auf den noch nicht veröffentlichten, jedoch bereits abgestimmten  Algorithmenkatalog 2017 den Ablauftermin von PKCS#1-1.5 Padding auf den 31.12.2017 und die durch den Betrachtungszeitraum von 7 Jahren bedingten Ablauftermine auf den 31.12.2023 (s. auch BSI-Seite https://www.bsi.bund.de/DE/Themen/DigitaleGesellschaft/ElektronischeSignatur/TechnischeRealisierung/Kryptoalgorithmen/kryptoalgorithmen_node.html )

Was passiert mit dem Algorithmenkatalog, wenn die eIDAS-VO umgesetzt wird?

Um die eIDAS-Verordnung in Deutschland umzusetzen, werden SigG/SigV Ende 2017 durch das Vertrauensdienstegesetz und die zugehörige Verordnung abgelöst. Ein Algorithmenkatalog ist z. Zt. noch nicht in der eIDAS-VO verankert. Es ist noch offen, ob bis dahin die EU-Verwaltung die notwendigen Regeln auf EU-Ebene beschließen wird oder Deutschland weiterhin am deutschen Katalog festhält, solange kein EU-Katalog existiert. Wir werden Sie zu diesem Thema weiter informieren.

 

Stand: Dezember 2016

Auf Grund gesetzlicher Vorschriften müssen Dokumente unterschiedlich lang archiviert werden. Dies gilt auch für digitale Dokumente, einschließlich der sich auf dem Dokument befindlichen Signaturen.

Ob die Signatur valide, also gültig ist, sollte auch nach Jahren – vorzugsweise auch ohne Verbindung zum Internet – möglich sein.

Die Lösung ist, die Validierungsdaten direkt in das Dokument einzubetten. Somit gelingt der Nachweis, dass die Signatur zum Signaturzeitpunkt gültig war.

Die Voraussetzung für den Nachweis einer gültigen Validierung ist, dass bestimmte Normen eingehalten werden. Um diese Normierung kümmert sich ETSI1 ( European Telekommunications Standards Institute ). ETSI hat für die Signaturformate verschiedener Dokumentenarten die Standards PAdES2, CAdES3 und XAdES4 entwickelt. Diese Profile tragen dem Umstand Rechnung, dass digital signierte Dokumente oft viele Jahre archiviert werden und es zu jedem Zeitpunkt in der Zukunft möglich sein muss, die Signatur des Dokuments zu prüfen. Dieses Konzept nennt man Long-Term Validation (LTV).

  Tutorial


1 ETSI ist eine gemeinnützige Organisation und verfolgt das Ziel, weltweit anerkannte Standards für Informations- und Telekommunikationstechnologien zu schafften. ETSI ist von der Europäischen Union offiziell anerkannt.
2 PAdES (engl.: PDF Advanced Electronic Signatures ) für PDF-Dokumente
3 CAdES (engl.: CMS Advanced Electronic Signatures ) für CMS-Dokumente
4 XAdES (engl.: XML Advanced Electronic Signatures ) für XML-Dokumente

Stand: August 2016

Das von der Cloud Suite verwendete Java-Plugin beruht auf der NPAPI-Plugin-Architektur, die bis vor kurzem von allen gängigen Web-Browsern unterstützt wurde. Vor einigen Monaten wurde die NPAPI-Unterstützung für Chrome für Linux-Plattformen eingestellt. Für Chrome unter Windows wird die NPAPI-Plugin-Architektur voraussichtlich bis Ende 2015 unterstützt.

Stand: Februar 2015

nach unserer Erfahrung kann Adobe Reader nicht vollständig mit indirekten Sperrlisten (CRLs) umgehen. Dies führt dazu, dass die Überprüfung qualifizierter Zertifikate deutscher Trust Center nur eingeschränkt ermöglicht ist. 

Ein wenig zum Hintergrund:
CRLs lassen sich in direkte und indirekte CRLs unterscheiden. Charakteristisch für direkte CRLs ist, dass sowohl das zu prüfende Zertifikat als auch die Sperrliste vom selben Ausstellerzertifikat signiert wurden. Im Falle indirekter CRLs hingegen unterscheiden sich die Aussteller von Zertifikat und Sperrliste. Der Common PKI Standard sieht vor, dass in diesem Falle der CRL-Aussteller explizit im zu prüfenden Zertifikat benannt sein muss. Dies ist jedoch bei den Zertifikaten der Bundesnetzagentur und aller qualifizierten / akkreditierten Anbieter in Deutschland nicht gegeben, was – der Fehlermeldung „Aussteller der Zertifikatssperrliste weicht ab“ (in Adobe Acrobat / Reader einzusehen) zufolge – zu einem Prüffehler bei Adobe führt.

Das von deutschen Anbietern praktizierte Ausgabemuster für Zertifikate und Sperrlisten ist dennoch korrekt, da dieses durch eine Profilierung des Common PKI Standards (SigG Profile) gerechtfertigt wird. Dieses lässt den Wegfall des CRL-Ausstellernamens auch bei Nutzung indirekter CRLs zu, um mehr Flexibilität bei der Ausstellung von Dienstzertifikaten zu erreichen. Der Adobe Reader scheint diesen Sonderfall jedoch nicht zu berücksichtigen. Ähnliche Einschränkungen gelten für die Sperrprüfung mittels Online Certificate Status Protocol (OCSP). 

Zusammenfassend lässt sich sagen, dass die Sperrprüfung in Adobe unvollständig scheint und den deutschen Gegebenheiten nicht gerecht wird. Eine Einflussnahme auf das Signaturprüfverfahren beim Dokumentenempfänger ist unseres Wissens nicht möglich, so dass wir Ihnen leider keine Möglichkeit nennen können, um unter Garantie zu einem positiven Prüfergebnis für die bekanntlich gültige Signatur zu kommen.

Der Anwender könnte die Sperrprüfung in seinen Anwendungseinstellungen generell deaktivieren, beeinträchtigt damit aber die Sicherheit der Signaturprüfung in Adobe Reader generell. Die Deaktivierung erfolgt in Adobe Reader unter „Bearbeiten > Voreinstellungen > Sicherheit > Erweiterte Sicherheit“ durch Deaktivierung des Kontrollkästchens „Beim Prüfen von Unterschriften nach Möglichkeit immer feststellen, ob das zugehörige Zertifikat gesperrt wurde“.

Für weitere Informationen zum Adobe Reader wenden Sie sich bitte dirket an Adobe.

Für eine zuverlässige Prüfung qualifizierter Signaturen empfiehlt es sich, eine sichere Signaturanwendungskomponente (gem. SigG/SigV) wie z.B. Sign Live! CC einzusetzen.

Stand: Juli 2014

 

Eine Signatur, die mit Sign Live! CC und einer aktuellen, deutschen Signaturkarte erstellt wurde, wird bei der Signaturverifizierung mit Adobe Reader bzw. Adobe Acrobat offensichtlich nicht korrekt erkannt. Adobe meldet die Fehlerinformation „Interner kryptografischer Bibliotheksfehler“.

Konstellation Sign Live! CC ab Version 7.0 mit RSA-Karten

In dieser Konstellation verwendet Sign Live! CC zur Kodierung von Signaturen den sichereren PSS-Padding Algorithmus. Adobe Produkte lehnen damit erzeugte Signaturen ab, weil sie ihn nicht kennen.
Adobe hat zugesagt, diesen Algorithmus ab Q1.2017 in ihren Produkten zu unterstützen. Sofern Sie auf die Prüfbarkeit erstellter Signaturen in Adobe Reader angewiesen sind, ist daher unsere Empfehlung, übergangsweise weiterhin Sign Live! CC 6.x mit PKCS#1-v1.5 Padding einzusetzen bis Adobe das Problem gelöst hat. Nach SigG-Algorithmenkatalog 2017 ist dieser Padding-Algorithmus noch mindestens bis Ende 2017 für qualifizierte Signaturen zugelassen.

Konstellation Sign Live! CC mit speziellen ECDSA-Karten (Dt. Telekom, neuer Personalausweis)

In dieser Konstellation liegt das Problem darin begründet, dass Adobe den von den Signaturkarten verwendeten ECDSA-Algorithmus mit brainpool-Kurven nicht kennt.
intarsys-Produkte haben leider keinen Einfluss auf dieses Problem. Hier hilft nur die Auswahl einer Signaturkarte, die entweder auf RSA-Algorithmen basiert oder ECDSA-Algorithmen verwendet, die von Adobe akzeptiert werden.

Stand Dezember 2016 wird diese besondere Art des ECDSA-Algorithmus basierend auf brainpool-Kurven n i c h t   e x p l i z i t Bestandteil von PDF 2.0, welches im Q1.2017 erwartet wird. Damit ist nicht absehbar, ob und wann Adobe diese Variante des Algorithmus in seinen Produkten berücksichtigen wird. Auf der anderen Seite widerspricht die Nutzung von brainpool-Kurven auch nicht den Vorgaben des PDF 2.0 Standards in der aktuellen noch nicht veröffentlichten Version.

Weitere Links:

https://forums.adobe.com/message/2635350#2635350
https://forums.adobe.com/message/3305286#3305286
https://forums.adobe.com/thread/2107060#2107060
https://forums.adobe.com/message/3040431#3040431

http://www.pdflib.com/en/knowledge-base/pdf-20/existing-acrobat-features/

 

Stand: Dezember 2016

Wie die Bundesrechtsanwaltkammer in ihrer Pressemitteilung vom 28. November 2016 mitteilte, wurde die Einführung des „besonderen elektronischen Anwaltspostfachs“ (beA) zum 28. November 2016 realisiert. Die gesamte Pressemitteilung können Sie auf der Seite der Bundesrechtsanwaltskammer nachlesen..

  Zur bea-Seite (Bundesrechtsanwaltskammer)

Stand: 29. Dezember 2016

 

Um mit dem EGVP arbeiten zu können, benötigen Sie eine Signaturkarte (für die Authentisierung bei EGVP) und ein Kartenlesegerät. Diese Komponenten haben Sie z. B. bei uns erworben.
Grundsätzlich können Sie mit Ihrer Signaturkarte auch Dokumente außerhalb des EGVP signieren. Dazu benötigen Sie eine Signaturanwendungskomponente (SAK), zum Beispiel Sign Live! CC.

Bitte beachten Sie, dass das EGVP durch das beA (besondere elektronische Anwaltspostfach) abgelöst wurde. Die für den 01.01.2016 geplante Einführung wurde am 28. November 2016 realisiert.
  Zur Seite der BRAK

  • Bei allgemeinen Fragen zu Sign Live! CC nutzen Sie bitte unser Kontaktformular.
  • Bis zum 31.12.2017 steht das EGVP noch zum Download bereit. Sicher haben Sie Verständnis dafür, dass wir keinen Support für das EGVP leisten können.
    Das EGVP selbst hat den Support zum 31.12.2016 eingestellt. Weitere Informationen erhalten Sie auf der Homepage des EGVP.   Zur Homepage EGVP

Letzte Änderung: 22. Februar 2017

Die T-Systems (Telesec) hat die Unterstützung von ELSTER eingestellt. Wir können leider keine Empfehlung von Karten für ELSTER abgeben. Ob die von Ihnen eingesetzte Signaturkarte von ELSTER unterstützt wird, können Sie auf der Internetseite von ELSTER prüfen. Dort finden Sie auch weitere Informationen.

  Zu ELSTER

Stand: Oktober 2014

Bitte beachten Sie:

Sollten Sie für die in Ihrem Haus eingesetzte Software einen Wartungsvertrag mit uns abgeschlossen haben, erhalten Sie als Wartungskunde exklusiv wichtige Informationen - zum Beispiel Informationen über die Ihnen zustehenden kostenlosen Updates und Bugfixes. Diese Informationen werden über Newsletter kommuniziert. In diesem Fall sollten Sie den Newsletter nicht abbestellen.

Wir haben Ihre E-Mail-Adresse durch einen geschäftlichen Kontakt mit Ihrem Unternehmen erhalten. Jeder intarsys Newsletter enthält am Ende den Abschnitt Newsletter abbestellen. Wenn Sie zukünftig keine Newsletter von intarsys mehr erhalten möchten, nutzen Sie bitte den Link im Newsletter und bestätigen Sie diesen. Sie erhalten dann ab sofort keine Newsletter von intarsys.

Stand: Juli 2015