Erzeugung von qualifizierten elektronischen Signaturen aus einer Webanwendung heraus mit dem SecSigner

Bei der Digitalisierung von Schriftgut im Rahmen des Posteingangscannens tritt häufig die Frage nach der Beweiswerterhaltung auf. Wie lässt sich sicherstellen, dass ein Siegel eines Notars oder eine Unterschrift auch in elektronischer Form erhalten bleibt? Die technische Lösung für diese Fragestellung ist die qualifizierte elektronische Signatur. Um eine lückenlose Nachvollziehbarkeit beim Posteingang scannen sicherzustellen, ist nach TR-RESISCAN auch ein ergänzender Transfervermerk notwendig.

Für die Erstellung von elektronischen Signaturen stehen mehrere Anwendungen zur Verfügung.
In diesem Artikel betrachten wir den SecSigner von SecCommerce mit der Besonderheit der Erstellung von Signaturen aus einer Webanwendung heraus.

Zur Abbildung einer Unterschrift in elektronischer Form kann eine qualifizierte elektronische Signatur mit einem persönlichen Schlüssel dienen.

Webtechnologie zur Signaturerstellung

Gerade in der elektronischen Vorgangsbearbeitung oder Aktenführung werden häufig Webanwendungen verwendet, die auch eine integrierte Signaturerstellung unterstützen sollten. Der SecSigner unterstützt den Einsatz im Webbrowser durch ein eigenes Java Applet, das über die Startparameter für einen beliebigen Signaturvorgang konfiguriert werden kann. Falls in der Anwendung unterschiedliche Signaturvorgänge vorgenommen werden sollen, ist es sinnvoll, das SecSigner Applet in einem eigenen iframe zu laden und den Inhalt des iframes durch die Serverkomponenten befüllen zu lassen oder clientseitig mit JavaScript zu erstellen. Dadurch, dass ein eingefügtes Applet-Element im HTML-DOM sofort vom Browser ausgeführt wird, muss der Inhalt bei der Generierung vollständig vorliegen.

Vorteile des Applets

Die Nutzung des bereitgestellten Java Applets bietet einige Vorteile:

• Java Applets sind eine bewährte Webtechnologie, um den Restriktionen der Browser-Sandbox zu entkommen.

• Es ist keine lokale SecSigner Installation notwendig.

• Die verwendete SecSigner-Version und -Konfiguration wird einheitlich und zentral auf dem Server verwaltet.

• Eine Massensignaturlizenz kann auf dem Server für alle Nutzer bereitgestellt werden.

Nachteile des Applets

Leider birgt der Einsatz des Applets auch einige Nachteile:

• Auch wenn Java im Unternehmensumfeld auf Clientsystemen typischerweise vorausgesetzt werden kann, ist es dennoch eine zusätzliche Abhängigkeit, die installiert werden muss.

• Aus einem 32-Bit Webbrowser wird eine 32-Bit Java Virtual Machine gestartet, wodurch nicht der gesamte Arbeitsspeicher von modernen PCs adressiert werden kann.
  Über den Applet-Parameter java_arguments können Startparameter an die JVM weitergebenen werden, wie -Xmx, um die maximale Größe des verwendbaren Arbeitsspeichers zu definieren.
  Leider ist durch die 32-Bit Einschränkung deutlich weniger Speicher nutzbar als verfügbar ist. In unseren Tests konnten je nach PC ca. 1000 bis 1600 MB allokiert werden.
  Da diese Grenze schwankend ist und bei einer Überschreitung auf einen geringen Standardwert reduziert wird, muss man bei der Konfiguration von dem niedrigen Wert ausgehen.
  Das Problem wird im Detail in diesem Stackoverflow-Forumseintrag erklärt: 32-bit JVM on 64-bit Windows crashes on launch with -Xmx1300m and plenty of free memory
  Die Anzeigekomponente des SecSigners muss eine Bildseite zur Anzeige unkomprimiert laden können. Bei großformatigen Dokumentseiten (Formate >= A3) können so schnell die Speichergrenzen erreicht werden. Dieses Problem kann nur gelöst werden, indem der SecSigner lokal installiert wird oder aus einer lokal ausgeführten 64-Bit JVM aufgerufen wird.

• Es treten lange Wartezeiten für den Nutzer beim Abruf von großen Dokumenten von einer Server-URL auf, wenn die Netzwerkbandbreite gering ist.
  Hierzu sind im nächsten Abschnitt Lösungsmöglichkeiten beschrieben.

Reduzierung von Wartezeiten bei der Übergabe großer Dokumente an das Applet

Ein zu signierendes Dokument, z.B. eine PDF-Datei, wird üblicherweise von einer angegebenen URL abgerufen. Auf Serverseite kann ein entsprechender Download-Service implementiert werden, der das benötigte Dokument bereitstellt. Bei größeren oder mehreren Dokumente wird also eine starke Netzwerkverbindung benötigt, um keine unnötigen Wartezeiten für den Nutzer zu generieren. Alternativ können die zu signierenden Dokumente lokal gespeichert und per File-URL übergeben werden. Dazu müssen die Dokumente entweder lokal erzeugt werden oder durch Download vor der Signierung vom Server abgerufen werden. Um diese lokalen Dokumente für die Signaturkomponenten bereitzustellen, gibt es verschiedene Möglichkeiten:

• Der Inhalt der Datei kann als Base64-codierte Zeichenkette als ein Applet-Attribut übergeben. Da dabei der gesamte Inhalt einer Datei in den HTML-DOM eingefügt wird, kommt diese Lösung bei großen und/oder vielen Dokumenten sehr schnell an Grenzen. Obwohl nach der HTML5-Spezifikation keine Größenbeschränkung bei HTML Attributen besteht, verursachen die Speicherbewegungen unnötig Aufwand und belasten den Browser.

• Im Zusammenhang mit den HTML5-Technologien gibt es die Möglichkeit Dateien als Blob abzubilden und über eine URL zu repräsentieren. Diese Blob-Daten müssen in JavaScript generiert und durch die empfangende Anwendung interpretiert werden, was bei großen Dateien einen hohen Speicherbedarf bedingt. Diese Möglichkeit ist bei großen Datenmengen nicht praktikabel und die Blob-Repräsentation wird durch den SecSigner nicht unterstützt.

• Dateien auf dem lokalen Dateisystem können über eine File-URL an den SecSigner übergeben werden. Um Dateien von einer Webanwendung auf das lokale Dateisystem zu speichern, wird eine Schnittstelle benötigt, die die Berechtigungen dazu hat. Die Unterstützung der File API, die diese Operationen ermöglicht, ist leider noch nicht für alle Browser gegeben - speziell der Internet Explorer unterstützt diese API nur partiell. Es muss also entweder ein weiteres Applet bereitgestellt oder eine Anwendung installiert werden, die eine JavaScript-Schnittstelle zur Speicherung bzw. zum Laden von Dateien unterstützt. Durch ein zusätzliches Applet lässt sich auch die 32-Bit Speicherbegrenzung des Applets umgehen, indem eine 64-Bit JVM für den SecSigner aus dem Applet heraus gestartet wird.

Testen der Signaturkomponente

Mit dem Parameter seccommerce.secsigner.allowsoftwarekey lässt sich eine Signatur im SecSigner mit einem Softwareschlüssel durchführen, der zwar keine qualifizierten Signaturen im
Sinne des deutschen Signaturgesetzes erstellt, aber für Entwicklungstests verwendet werden kann, falls keine Signaturkarte griffbereit ist. Ein Softwareschlüssel lässt sich mit openssl relativ einfach erzeugen.

Fazit: für übergroße Formate ist eine zusätzliche Clientanwendung notwendig

Ohne eine ergänzende installierte Anwendung oder ein weiteres Applet lässt sich, bei der aktuellen Unterstützung der File API durch die gängigen Browser, eine Signierung von größeren und mehreren Dokumenten alleine über das SecSigner Applet praktisch nicht umsetzen. Für den gelegentlichen Einsatz bei einzelnen Dokumenten aus einem webbasierten Dokumentenmanagementsystem heraus, ist das SecSigner Applet ohne Ergänzungen sehr gut geeignet.