This is technical background information for compliance experts. You can skip this section if you are a 'normal' user.  


Espresso ELN implements digital signatures as follows: First, the current UTC time, as obtained from an NTP internet time server, is placed into the experiment dataset, along with the unique network machine name of your PC. Then all records defining the content of the experiment, including embedded documents and images, are merged into a single piece of information, to which a SHA-1 hash algorithm is applied. The resulting secure hash code (i.e. the fingerprint) is subsequently encrypted using an application built-in 1024 bit private RSA key, according to the RSA PKCS #1 standard for digital signatures.

The validity of the signature is verified each time a signed experiment is opened, using the public RSA key. If unauthorized changes to the signed content should have occurred, a well-visible red warning stamp across the header area appears.

Database, Password and Code Protection
The local experiment database is encrypted using a Microsoft proprietary encryption algorithm. Also, the private user password is neither stored in plain text nor in encrypted form – instead, only its encrypted fingerprint is persisted, from which it cannot restored in any way. Finally, the application code itself is protected from reverse-engineering by a code obfuscation tool sequentially applying string encryption, code obfuscation, code encryption and conversion of the .NET code into native Windows code.

Digital Certificates
The current Espresso ELN implementation of digital signatures establishes the identity of you and your organization to the maximum extent possible without the use of a digital certificate. Although digital certificates provide enhanced proof of identity, they require a substantial administrative overhead for maintaining a public key infrastructure (PKI) for their management (replacement after expiry, issuing of new ones, invalidation, etc) and cause recurring fees by the certification authority. Therefore digital certificates sometimes might be out of scope for smaller organizations.

Built-In Private Key
Even more importantly though, in digital certificate settings, typically the private key used for creating the digital signature is in the hands of the organization which is signing its own content with it – an often overlooked IP-protection loophole, since the possibility of unauthorized in house re-signing of modified content cannot be categorically ruled out. From this perspective, digital certificates might be regarded as enhancing authenticity at the cost of reduced proof of integrity. In Espresso ELN however, the private key is built into the well-protected application code, inaccessible to the customer, and therefore precluding any argument of unauthorized re-signing from the root.