During the development of webSignatureOffice (short webSO) one of the focus points was security. The used Frameworks (Spark framework, Spring framework) have a lot of built in tools to create highly secure web applications-e.g. SafeHtml to sort out XSS weak points.
Also, an additional security layer was added, which will be explained in detail in the following chapters.
Every request also has a Nonce (a number which can be used only once) to prevent attacks via „Request Replays“. Additionally a timestamp is sent with every request to nullify requests, which maybe intercepted after a given amount of time.
The communication between Browser and Pad Connector is done by using secure web sockets (wss). The SSL certificate and the keystore are stored locally in the installation directory and are used to overcome the browsers mixed content barrier. It has no security relevance as the data does not leave the local realm of the users computer. The SSL certificate is issued for a host name that has a localhost DNS adress (signsocket.stepover.com). The Pad Connector web socket only excepts connections from localhost.
The Pad Connector is a Java applet, which communicates with the signature pads via USB HID Library per JNA.
All biometric data is transfered encrypted via a Jetty based server. The encryption is happening on the StepOver signature pad (hybride AES256Bit/RSA2048Bit / https://en.wikipedia.org/wiki/Hybrid_cryptosystem)
After signing a field with the HTML5-Signer, the signature data has to be encrypted by RSA cryptosystem. So the Browser sends data to the RSA Encryption Server (part of the backend system infrastructure) via HTTPS. A serverside Java-Servlet encrypts the given data before sending them back to the Browser.
The communication between the mobile devices and the server is SSL encrypted. The used protocol is standard XML RPC (http://en.wikipedia.org/wiki/XML-RPC). The security mechanisms are comparable to the ones between browser and server. Every request is signed with a key (the key is a SHA1 hash of a random value). The request includes a Nonce, timestamp and session ID. The key is saved obfuscated in the App.
The Random Key, which is needed for the encryption of the biometric data, is stored in the keychain for iOS devices (secure Memory, which can only be read by the App). Android devices encrypt it with AES and save it in a place, where only the App can read it. All biometric data is transferred encrypted and is done in the mobile device (Tablet or phone, hybrid AES256Bit/RSA2048Bit encryption / http://en.wikipedia.org/wiki/Hybrid_cryptosystem).
Both Apps are digitally signed to prevent later manipulation.
The communication between the servers is also done by the same Interface, which is used by the mobile devices (Tyr-Service). They key, which is used to sign the requests, is safely stored on each server. While using the Tyr-Service also an additional Application Key is used to activate or deactivate certain features.
Passwords are generally not saved, instead a password hash (salted) is saved. By using this method, no passwords can be found, if an attack should be successful.
All service calls traverse an Authorizer, which checks, if the given action is allowed for the user. Not only roles are checked with this method, but also the provided data.
The signature is applied to the document on the sign server. All biometric data is sent to the server encrypted.
The certificates for the digital signatures are managed in encrypted PKCS12 containers on the server. The server itself does not save any passwords, which means the use of the certificates is secured by a renewed input of the password.
The biometric data of the signature is stored in the Signature-Pad or iOS/Android App (only for the time of the signature). It is send finally encrypted (encrypted and linked to the document) to the signature server. As key for the encryption, a value is used, which is specifically generated for each signature. The so called “Random-Key”. This “Random-Key” is the password for the encryption of the biometric data (AES256), which then is send to the signature server. The encrypted biometric data is embedded (invisible) into the document.
At this point in time the encrypted biometric data has no link to the document. Without the “Random-Key”, which was used for the encryption, the biometric data is inaccessible. This key only exists during the encryption process in the processor of the signature pad or the secure memory of the App.
The document to be signed now stores the image of the signature and the (AES256) encrypted biometric data of the signature. At this point the signature server creates a checksum (SHA-256) of the document incl. image of the signature and encrypted biometric data, the so called “Preliminary Hash” and sends it to the Signature-Pad or the APP.
The “Random Key” will be encrypted with the “Preliminary Hash” inside the Signature-Pad or App (AES256). Doing this, an irrevocable connection between the document and the biometric data is created.
Afterwards the already encrypted “Random Key” is encrypted a second time with the “Notary Public Key” using RSA 2048. The Notary Public Key is a 2048 Bit RSA Public Key, which is created by an trusted authorization, e.g. a notary. The corresponding “Private Key”, which is needed for decryption, can only be accessed by the trusted authority).
The double encrypted “Random Key” is transferred from the Pad/App to the signature server, where it is embedded into the PDF. The biometric signature is finished now.
Additionally the whole document is digitally signed with a second key pair named “Digital Signature Key Pair“. The second signature can be used for in-house verification of the document integrity.