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.

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?

There are two main reasons for this:

There is no need to use more secure hash functions. No attacks that would affect the security of the GuardTime system are known to exist against SHA2-256 (or even against SHA-1, or MD5).
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 up to double the size of the signature in the GuardTime system.

Can I use other hash algorithms in my application?

Users of the GuardTime system are able to choose between several hash functions for creating a signature request for the document they want to sign. Currently available choices supported by the GuardTime APIs are SHA-1, SHA2-224, SHA2-256, SHA2-384, SHA2-512, RIPEMD-160.

The causal links between signature requests and the published hash codes are created internally in the GuardTime system, and therefore use hash functions selected by GuardTime. Users have no control over this choice.

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 doubled
The gateway server’s required memory size is doubled
The load on the Gateway servers and the GuardTime internal servers is somewhat higher

GuardTime Keyless Signatures

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 the Keyless Signature Working Group.

RFC 3161 : This is a 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.

How do I view the contents of my signature?

The signatures are encoded in ASN.1 and can be read by any ASN.1 viewer.

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 the Client is 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?

In case of data tampering (modifying the signature request or response) the signature system returns error and the signature will not be formed nor verified.

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

Signature requests and responses between the client application and the Gateway are protected by a GuardTime signature on the signature data; when a signature is received from the Gateway, it will be fully verified. In case of any problems an error is reported and the received invalid signature is thrown away.

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.

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