Data Authentication

FAQ

Home → Keyless Signatures → FAQ

Frequently Asked Questions

We’ve compiled a list of common questions regarding the Keyless Signature service and technology. To get started, click one of the links below to jump straight to that section.

General Questions on Keyless Signatures

Why the name Keyless Signature?

The most accurate technical summary of what we do is “a combination of hash-based server-side digital signatures and hash-linking based timestamping delivered using a scalable distributed infrastructure”. We chose the word “keyless” to emphasize that the verification does not rely on the security of cryptographic keys. Public key cryptography is an extremely successful technology for authenticating data in motion  however the complexity and cost of key management make it very challenging to use for authenticating data at rest, especially for long term, large scale storage.

What new cryptography is involved ?

There is no new cryptography. The only cryptographic necessary is the hash-function and the proofs can be derived using formal methods without the need for trusted third parties. There has been much academic research published on KSI with a the focus on proving what properties of hash functions are necessary to ensure provable security in the adversarial model.

How do keyless signatures compare with hash values?

Hash values alone don’t prove anything, at least not to anyone but the creator of the hash value. Consider some simple use-cases.

  • A bank needs to present digital evidence and wants to prove to the court it has not been modified. Presenting a hash value along with the evidence is meaningless as employees in the bank could simply modify the evidence and generate a new hash value prior to presenting it. In other words as it requires trust in the party presenting the evidence presenting a hash-value along with the evidence is meaningless
  • Party A wishes to send an email to Party B and wishes to ensure party B is alerted to modification. Hashing the email and including the hash value will alert party B against corruption of the email but an attacker could intercept the email, modify it, generate a new hash value and forward it on.
  • A forensics examiner conducting an investigation and writes down a hash value of some data (typically a hard drive) in his notebook (the status quo). Later this may prove to the examiner that the data has not changed but to no one else. He is in fact acting as a trusted third party “hosting” the hash value.
How do Keyless Signatures compare with PKI based digital signatures/timestamps?

PKI has many different use cases but the complexities and cost of key management make it very challenging to scale as a signature/timestamping scheme for electronic data at rest (there is a reason the NIST handbook on key management is over 500 pages). The two technologies are however entirely complementary. Estonia is the birthplace of KSI and also the only country that has achieved widespread adoption of PKI based legally binding digital signatures. (One of us, Buldas, helped architect it and write the legal framework). In Estonia PKI is used for electronic (legally binding) signatures and KSI is used for signing of machine-generated data such as system logs and banking transactions.

Guardtime Keyless Signature Service

What is the capacity of the Guardtime system in terms of volume of signature requests that can be supported?

The theoretical capacity of the Guardtime system is determined only by the strength of the hash function; thus the system can theoretically support over 2^100 signatures per second. However, due to clustering at each node in order to provide higher redundancy, the system can be safely said to be able to support over 4 billion signatures per second assuming full roll-out of the aggregation grid and Gateway nodes. The capacity of the Guardtime global service at any given moment is determined by the number of Gateway nodes and the supporting aggregation grid.

Hash Functions and Cryptographic Basics

Why does Guardtime not use a more secure hash algorithm than SHA2-256?

There are two main reasons for this:

  1. There is no need to use more secure hash functions. No attacks that would affect the security of the Guardtime system – specifically pre-image resistance of the cryptographic hash function (collision resistance is a different property of a hash function and attacks against it are not relevant in Guardtime’s context) – are known to exist against SHA2-256.
  2. More secure hash functions are harder to compute and have larger outputs which would make the Guardtime system more resource-consuming. For example, changing to SHA2-512 would almost double the size of the signature in the Guardtime system.
If a hash algorithm is known to be compromised, can the Guardtime system switch to a stronger hash algorithm, and if so, how specifically does Guardtime do this?

Guardtime can quickly switch from one hash function to another. The internal hash function is specified in configuration files that can be changed without recompiling or reinstalling any system software.

How are older signatures protected in the event that the Guardtime hash algorithms are compromised?

If developments in cryptanalysis of hash functions start putting existing signatures in danger, then it is possible to re-sign the original document and its old signature with a new hash function (e.g. SHA2-384) that still remains secure.

A new signature on the old document proves that the document existed before the old hash function was broken. A new signature on the old signature proves that the old signature (that represents a chain of hashing operations with the old hash function) existed before the old hash function was broken. As a result, there is still undeniable evidence that proves the existence of the document at the date given in the old signature.

What are the implications (i.e. signature size, communications overhead, etc.) of switching to a stronger hash algorithm such as SHA-512?
  • Communication volume inside the Guardtime network is doubled
  • The size of the signature is almost doubled
  • The Gateway server’s required memory size is doubled
  • The load on the Gateway servers and the Guardtime internal servers is somewhat higher

Standards

What standards does Guardtime comply with?

Guardtime complies with various standards related to digital signatures/timestamps. In general our design philosophy is to build a “universal gateway” allowing users to specify on request the format to be returned.

KSIX 1.0 : This is the optimized format for keyless signatures as defined by openksi.org

RFC 3161 : This is an Internet Engineering Task Force specified format for PKI based digital timestamps. The need to rely on the security of private or secret keys for the lifetime of the data has severely limited the adoption of PKI based digital timestamps, especially for long term proof of integrity when the lifetime of the data is much longer than the operational lifetime of the key used to sign the data. Guardtime supports this standard for legacy applications.

ISO/IEC 18014: This is the ISO standard for linking based digital timestamps. Guardtime supports this standard.

PAdES Standard (ETSI TS 102 778) : This is the European Telecommunications Standards Institute standard for PDF based digital signatures. Guardtime supports this standard.

What information does my signature contain?

Besides the date and time of signature generation, the signature contains other information about the issuer of the signature and a serial number assigned to the signature by issuer. Please refer to Guardtime for more detailed information about the signature format.

Privacy and Security

If I host my own Gateway, what security issues should I be concerned about?

Hosting a Guardtime Gateway is similar to hosting any Linux server. Usual systems management practices apply. The only necessary externally visible service is the lighttpd web server daemon. If you are providing a service over the Internet then it is recommended to host the Gateway in a DMZ environment. There is no confidential information stored in Gateways, except configuration files with access parameters.

Additionally, there are multiple ways to limit client access to the Guardtime Gateway. As the service is run over the HTTP protocol all web authentication methods can be used. The following are some examples:

  • Using an appropriate network topology, for example putting the Gateway into an internal network so that only LAN users can access it.
  • Using basic authentication. For setup it is recommended to refer to the lighttpd documentation. Also, in basic authentication cases passwords are sent over the network without encryption, thus SSL/TLS tunneling is recommended. In this case the Gateway address can be specified in the form of https://name:password@gwaddr/service in the Guardtime API.
  • Using authentication with an SSL/TLS client certificate.
  • Using client IP address limitation. This could be done through lighttpd web server configuration, Linux host firewall configuration or using some external means.
What if someone modifies the signature request/response?

The signature request and response data, when transferred within the Guardtime Grid, is protected by keyed HMAC codes; in case of tampering a redundant path is chosen transparently.

If a signature request from the client application to the Gateway is modified either the request becomes invalid and Gateway returns an error or the resulting signature will fail verification in the client application (depends on the nature of the change in the request).

Signature responses from the Gateway to client application are protected by Guardtime signatures; when a signature is received from the Gateway and fails verification, it can be just thrown away and a new one can be requested.

Signature Verification

How does Guardtime guarantee that the verification process or tool is correct?

The correctness of the verification process relies on a mathematical proof of individual steps required to reach the conclusion. After all efforts of finding the fault in the process have failed, it is reasonable to assume that the verification process is correct, until proven otherwise.

Source code for verification tools is provided to every interested party in order to make possible an independent quality audit of the code. Considerable effort is made to guarantee that the implementation, support libraries, and coding styles do not weaken the reliability of the results. Correctness of the tools is warranted by the inability to find a fault in them.

KSI Glossary

Please download the glossary document from the OpenKSI.org Reference section.

If you have any additional questions regarding our service, please let us know.