Bei der Entwicklung von webSignatureOffice (kurz webSO) wurde von Anfang an großer Wert auf Sicherheit gelegt. Als Frameworks wurden Spark und Spring gewählt, da diese von Haus aus viele Hilfsmittel besitzen um Webapplikationen sicher zu gestalten, z.B. SafeHtml zur Vermeidung von XSS Schwachstellen.

Zudem wurde eine zusätzliche Sicherheitsschicht bei der Kommunikation zwischen den einzelnen Komponenten eingebaut, welche in den nachfolgenden Kapiteln näher erklärt wird.

Komponenten Überblick

• Browser Mindestanforderungen: Edge 40, Chrome 49, Firefox 50, Safari 10
  Die Webapplikation ist ein Rich Client (Javascript) der mittels REST mit dem Server kommuniziert.
• Server: Java Servlets, die beliebig horizontal skalierbar sind. Unter allen Servern werden Datenbank und Filestorage geteilt. Durch die Aufteilung von Frontend und Signing Server ist es möglich den Signing Server in einem besonders gesicherten Netz aufzustellen.
• Mindestanforderungen Mobile Endgeräte: iOS App 12, Android App 7.

Datenaustausch bei der Erstellung von Signaturanforderungen

Server <-> Server

Die Kommunikation zwischen zwei Servern geschieht über die gleiche Schnittstelle (Tyr Service), die auch von den iSignatureOffice/aSignatureOffice Apps genutzt wird (XML-RPC). Der Schlüssel zum Signieren der Requests liegt geschützt auf den beiden Servern. Beim Tyr Service wird ein zusätzlicher mitgelieferter Application Key genutzt, um bestimmte Funktionen zu aktivieren oder zu deaktivieren.

Browser <-> Server

Der Datenaustausch zwischen Browser und webSO geschieht per REST API (Spark Framework). Alle Anfragen werden mit einem Key (Hashwert) signiert, um Request Forging zu erschweren. Dazu wird aus dem Request XML + Key ein SHA1 Hash gebildet und serverseitig überprüft. Der Key ist beim Viewer (Komponente zur Integration von webSO im eigenen Webauftritt) im Javascript verschleiert gespeichert. Bei der webSO Applikation wird er bei jeder Anmeldung des Benutzers (Login) neu gesetzt. Die Session wird per Cookie verwaltet.

Jeder Request besitzt zusätzlich einen Nonce (eine Zahl, die nur einmal benutzt werden kann), um Angriffe durch „Request Replays“ zu verhindern. Zudem wird ein Zeitstempel mit jedem Request mitgeschickt, um eventuell abgefangene Requests nach einem definierten Zeitfenster ungültig zu machen.

Datenaustausch beim Signieren von Dokumenten

Mit dem Signaturpad

Pad Connector <-> Browser

Die Kommunikation zwischen Browser und Pad Connector geschieht durch Secure Web Sockets (wss). Das SSL Zertifikat und der Keystore befinden sich im Installationsverzeichnis und werden verwendet, um die Mixed Content Barriere zu überwinden. Das Zertifikat hat keine Sicherheitsrelevanz, da der Datenverkehr den lokalen Rechner nicht verlässt. Das Zertifikat wird auf einen Host ausgestellt mit einem localhost DNS Eintrag (signsocket.stepover.com). Der Pad Connector lässt nur Verbindungen vom Localhost zu.

Der Pad Connector ist eine Java-Anwendung, der mit den Signatur Pads über USB HID Bibliotheken per JNA kommuniziert.
Alle biometrische Daten werden verschlüsselt über einen Jetty-Server übertragen. Die Verschlüsselung geschieht bereits im StepOver Signatur Pad (hybride AES256Bit/RSA4096Bit Verschlüsselung / http://de.wikipedia.org/wiki/Hybride_Verschlüsselung)

Im Browser auf dem (mobilen) Endgerät (HTML5-Signer):

Browser <-> Server

Der Datenaustausch beim Signaturprozess zwischen Browser und webSO geschieht per REST API (Spark Framework) in SSL-verschlüsselter Form.

Zum Signieren mit biometrischen Daten sind zwei aufeinander aufbauende Requests nötig (Signature Request + Encode Request). Der Javascript Code ist auch hier verschleiert.

Die Verschlüsselung der Signaturdaten findet während des Unterschriftsprozesses vom RSA Verschlüsselungsserver (RSAEncryptor) statt:

Browser <-> RSA Verschlüsselungsserver

Nach dem Unterschreiben eines Signaturfeldes mittels HTML5-Signer, müssen die Signaturdaten durch das RSA Kryptosystem verschlüsselt werden. Daher sendet der Browser Daten an den RSA Verschlüsselungsserver (Teil der Server Backend Infrastruktur) mittels HTTPS.
Ein serverseitiges Java-Servlet verschlüsselt die Daten bevor sie an den Browser zurückgesendet werden.

In der iSignatureOffice / aSignatureOffice App:

App <-> Server

Die Kommunikation zwischen der iSignatureOffice / aSignatureOffice App und dem Server geschieht per SSL verschlüsselter Verbindung. Bei dem verwendeten Protokoll handelt es sich um den Standard XML RPC (http://de.wikipedia.org/wiki/XML-RPC). Die Sicherheitsmechanismen sind mit der Kommunikation zwischen Browser und Server vergleichbar. Jeder Request wird mit einem Schlüssel (Key) signiert (als Key wird ein SHA1 Hash eines Zufallswertes verwendet). Der Request beinhaltet einen Nonce, Timestamp und eine Session ID. Der Key ist in der App verschleiert (obfuscated) hinterlegt.

Der für die Verschlüsselung der biometrischen Daten benötigte Zufallswert (Random Key) wird bei den iOS Geräten in der Keychain (sicherer Speicherbereich für Daten, die nur von der speichernden App gelesen werden sollen) gespeichert. Bei Android Geräten wird dieser AES verschlüsselt in einem Bereich abgelegt, der nur von der App gelesen werden kann. Alle biometrischen Daten werden verschlüsselt übertragen. Die Verschlüsselung geschieht im mobilen Gerät (Tablet oder Phone, hybride AES256Bit/RSA4096Bit Verschlüsselung / http://de.wikipedia.org/wiki/Hybride_Verschlüsselung).

Beide Apps werden digital signiert, um eine nachträgliche Manipulation auszuschließen.

Allgemeines

Passwörter

Passwörter werden generell nicht gespeichert. Stattdessen wird ein Passwort-Hash erstellt (mit Salt) und abgespeichert. Somit kann ausgeschlossen werden, dass Passwörter durch einen Angriff auf den Server ausgespäht werden können.

Authorizer

Alle Serviceaufrufe durchlaufen einen Authorizer, der prüft, ob die entsprechende Aktion für diesen Benutzer zulässig ist. Dabei werden nicht nur Rollen untersucht, sondern auch die gelieferten Daten.

Aufbringen der Signatur

Die Signatur wird serverseitig aufgebracht. Alle biometrischen Daten werden schon verschlüsselt an den Server geschickt.

Die Zertifikate für die digitale Signatur werden serverseitig in verschlüsselten PKCS12 Containern verwaltet. Da der Server selbst die Benutzerpasswörter nicht speichert, ist sichergestellt, dass die Zertifikate nur durch erneute Eingabe des Benutzerpassworts zur Signatur verwendet werden können.

Verschlüsselung, Übertragung und Einbetten der biometrischen Daten

Im Signaturpad bzw. in der iOS/Android App befinden sich die biometrischen Daten der Unterschrift. Diese werden final verschlüsselt (d.h. verschlüsselt und mit einer Verknüpfung zum Dokument ausgestattet) an den Signaturserver übertragen. Als Schlüssel dazu dient ein für die jeweilige Signatur einzigartiger – per Zufallsgenerator im Signaturpad/App erzeugter Wert, der sog. „Random Key“. Mit diesem „Random Key“ als Passwort werden die biometrischen Daten verschlüsselt (AES256Bit) und an den Signaturserver übertragen. Die verschlüsselten biometrischen Daten werden in das Dokument (unsichtbar) eingebettet.

Zu diesem Zeitpunkt haben die verschlüsselten biometrischen Daten noch keinen Bezug zum Dokument. Ohne den für die Verschlüsselung verwendeten „Random Key“ sind sie allerdings nicht zugänglich (= geschützt). Dieser existiert zu diesem Zeitpunkt nur im Prozessor des Signaturpads bzw. im geschützten Speicher der App.

Herstellung des Bezugs zum Dokument und RSA – Verschlüsselung

Das zu unterzeichnende Dokument enthält nun das Schriftbild und die (AES 256Bit) verschlüsselten biometrischen Daten der Unterschrift. Zu diesem Zeitpunkt erstellt der Signaturserver die Prüfsumme (SHA-256) über Dokument inkl. Schriftbild und den verschlüsselten biometrischen Daten, den sog. „Preliminary Hash“ und sendet diesen zum Signaturpad bzw. zur App.

Der im Pad bzw. der App befindliche „Random Key“ wird nun im Pad bzw. in der APP zuerst mit diesem Preliminary Hash verschlüsselt (unter Zuhilfenahme der AES 256Bit Verschlüsselung). Dadurch entsteht unwiederbringlich der Bezug der biometrischen Daten zum Dokument.

Im Anschluss wird dieser bereits einfach verschlüsselte „Random Key“ ein zweites Mal unter Nutzung des „Notary Public Key“ final mit RSA4096 verschlüsselt. Beim „Notary Public Key“ handelt es sich um einen 4096Bit RSA-Public-Key, welcher von einer vertrauenswürdigen Instanz, wie z.B. einem Notar erstellt wurde. Der zugehörige „Private-Key“, welcher zu Entschlüsselung benötigt wird, befindet sich im ausschließlichen Zugriff dieser vertrauenswürdigen Partei.

Der auf diese Weise gesicherte „Random Key“ wird nun vom Pad bzw. von der APP an den Signaturserver übertragen und in das PDF-Dokument eingebettet. Die erste „biometrische Signatur“ ist damit abgeschlossen.

Anschließend wird noch eine digitale Signatur in das Dokument eingefügt (unter Zuhilfenahme eines 2ten Schlüsselpaares namens „Digital Signature Key Pair“). Diese zweite Signatur dient u.a. der Möglichkeit zur „Inhouseprüfung“ der Dokumentenintegrität.

Schlussfolgerungen aus diesen Abläufen und Vorteile des Verfahrens:

• Unverschlüsselte biometrische Daten werden weder übertragen, noch befinden sie sich zu irgendeinem Zeitpunkt im Arbeitsspeicher des Computers oder Servers des Betreibers (auf welchem im Zweifel evtl. Hacker oder spezielle Mitarbeiter des Betreibers Zugriff haben können).
• Zudem befinden sich zu keinem Zeitpunkt verschlüsselte biometrische Daten auf dem Server, welche erst serverseitig mit einem Dokument verknüpft werden können. Das heißt Daten, welche als „Blankounterschrift“ missbraucht werden könnten.
• Eine Entschlüsselung der biometrischen Daten ist nur mit Hilfe des „Notary Private Keys“ möglich. Da dieser von einer vertrauenswürdigen dritten Instanz (z.B. einem Notar) gehalten wird, kann der Betreiber nachweislich behaupten, selbst nicht die Möglichkeit zu haben, an diese Daten zu gelangen.
• Wurde das Dokument verändert, so sind die biometrischen Daten verloren. Die Bildung des für die Entschlüsselung erforderlichen Wertes ist mangels ursprünglicher Prüfsumme (Preliminary Hash) nicht mehr möglich (die Entschlüsselung des „Random Keys“ ohne Preliminary Hash ist nicht möglich). Somit kann die Zuordnung der Unterschrift zu einem Dokument nachgewiesen werden.
• Für die Beweisführung ist AUSSCHLIESSLICH das notariell erzeugte Schlüsselpaar verantwortlich. Ein Notar ist eine für die Gerichte vertrauenswürdige Institution.
• Die Beweisfähigkeit ist vollständig unabhängig vom 2ten Schlüsselpaar („Digital Signature Key Pair“). Dies bedeutet, dass die Beweisfähigkeit / Sicherheit somit auch in entscheidendem Maße unabhängig von der Sorgfalt des Anbieters/Serverbetreibers (und der Redlichkeit all seiner Mitarbeiter mit entsprechendem IT-Know-How und Zugang) und der nachträglichen Nachweisbarkeit dieser ist. Zudem ist auch ein direkter Zugriff des Signaturlösungsbetreibers auf die Server (z.B. im Falle des eignen Hostings) darstellbar.