Digital signing

Basic principles

A common complaint about paper is that it is easy to forge documents. Digital files are by default much easier to forge – it is impossible to check them for DNA or age. However, with the advent of e-commerce and trade, techniques for secure transfer and protection against forgery have been developed. Digital signatures are used to protect digital documents from forgery and, if correctly used, provides much higher security than any paper signatures can provide.

A signature relies on having two cryptographic keys: one which is private (and is never given out), and one that is public. Anyone with the public key can verify that the signature was made by a person using the private key. The signature could be done as this:

  1. Alice with the private key generates a text such as “...this is my document...and this is the date of the signature”
  2. Alice encrypts the text with her private key
  3. Bob receives the text and decrypts it using the public key
  4. Because only Alice could encrypt it, Bob knows the document was signed by Alice
This software uses a variant that in addition relies on using a hash function (call it H). The hash function generates a fingerprint H(document) which is much smaller than the original document. The point here is that if someone else signs the document, the entire encrypted document need not be sent back but only a smaller version, speeding up transfer and reducing disk usage. The only caveat is that the function H must be a “secure hash function”, that is, it must be difficult to find a forged copy such that H(document)=H(forged document). Luckily, good such functions exist.

Counter signing

A problem occurs when you cannot trust the one signing the document – Alice can at any time generate a document, with any creation date of her choice. This is a big problem if you wish to apply for a patent, and claim that she did it before her competition. The solution to this problem is counter-signing: Bob can sign not only her document, but also her signature. If Bobs signature can be trusted, then it proves that Alice signature is authentic and was not produced at a date later than that of Bobs signature (assuming Bob did his homework checking this, which the software does automatically). So, Bob can now join Alice to the patent court and witness in her favor. The more people counter-sign the document, the more people can help her witness.

What if Alice and Bob work at the same company. Are they not biased, having similar interests? This software helps you let other trusted people outside your organization counter-sign your documents.

TODO

Implemented signing methods

Several hash functions are supported and new methods can be used as they become available. The default hash function is currently SHA-512.

By default the software supports the use of PGP cryptographic keys (IETF RFC 4880). As such, these can be shared by other software, in particular for signing and/or encrypting email. Options for exporting/importing these keys can be found in the User profile menu.

The software is prepared to support the X.509 cryptographic standard. This is the standard used by authorities issuing for example bank cards, and would allow signing using personal smart cards. Other signing methods can also be used in tandem. Contact us for further details.

Storing the private keys on a server

This software provides the option of storing private keys on a central server. This is a handy feature because some users just can't seem to keep track of their files... However, it comes with security considerations. What could the server do with the keys in worst case?

It is a hard requirement that a server administrator can not use the keys stored on the server. Imagine if the administrator could sign document with one user, and counter-sign with all other users of the system – the administrator might be biased toward helping the own institute or a particular user. This would mean that all users of this server have to be treated as one in court, and only external users could be trusted for counter-signing! In addition, the keys could be leaked to the outside (central key deposits are prime targets for hackers) and be used for ID-theft. Thus this software is designed to make it impossible for the administrator to use the keys. All keys are password protected, and the password is never sent to the server. Rather, the keys are downloaded to the client on demand. That said, with enough computational recourses, a given key can be unlocked, so it is still an utmost responsibility for the server administrator to not let the keys end up in the wrong hands.

The issue of storing keys on the server should be considered when comparing to other competing ELN systems. A system without personal cryptographic keys is equivalent to a system where the administrator has full access to all the keys. Thus these systems have serious concerns about the credibility of signatures. Even if they do have personal cryptographic keys, it is important to check that the password is not transmitted to the server.

Cryptography and transfer security

If nothing is done, a program sends the content of a data transfer as raw data. This is for example the case of HTTP. Unfortunately, this data can be read by other users having access to the network, allowing them to catch passwords and read the contents of the documents. In fact, it is even possible to hijack a connection. This software uses state of the art encryption standards to ensure that nothing of the transfer is leaked to third parties nor that they can hijack the connection. This is done by encapsulating the transfer using the SSL protocol (IETF RFC 5246). Thus no extra measures need to be taken by the user or administrator to secure the traffic.