HammerServer - The Tamper-Resistant Audit Log


HammerServer is an implementation of a networked process where arbitrary data are securely stored and can be retrieved. The server makes sure that data tampering (e.g., by a malevolent database administrator) is detected. Hence, the HammerServer provides ``tamper-resistance''.

The next step in security would be probably a tamper-free log - which is very hard to achieve and involves specialized hardware. HammerServer provides some means to accomplish this: one of the storage back ends is a flat file, which can be mapped onto a read-only medium (CD/R, DVD/R).


The basic concept of the HammerServer is the following:

Data entry:

An application needs to create a copy data that may not be tampered. An example is a payment which is about to be processed. In order to avoid data tampering by internal staff, a copy of the relevant data is sent to the HammerServer. The HammerServer sends back a key that uniquely identifies the data.

Data retrieval:

At a certain time, the application will want to re-verify that its payment data are still valid, e.g., right before sending the payment request to the financial clearinghouse. The application uses the key that it obtained from the HammerServer during insertion, and retrieves the copy. If the copy is the same as the app's own data, then there was no tampering.

Otherwise, something's afoot - the data was maybe tampered with in the application's database, or data corruption occurred. In any case, the application can be sure that the HammerServer's data is the correct version (see Security Measures below). And incase the HammmerServer's own database is compromised, then the HammerServer will warn about this.

A simplified concept is the following:

Data entry:

An application generates/modifies data or makes decisions. These actions must be retained, incase a review is necessary (i.e., ``who's done what''). Such data is offloaded to a remote (secure) HammerServer.

Data retrieval and verification:

If a review of actions is necessary, the previously stored data are queried. Given the fact that the data on the HammerServer are uniquely identified by a timestamp, an ``audit trail'' can be reviewed.

To facilitate management of the remote storage, the following actions are also possible:

Bulk upload:

In one go, many records can be sent to the HammerServer for storage. The server then of course returns many keys - each of which can be used to retrieve a record.


Incase of the loss of a key (which was generated during insertion and returned to the calling application), the datastore can be searched.

Data verificaton:

HammerServer's internal data set can be periodically checked for tampering. A call exists to (re)verify all entries that were inserted between two dates.

Data offloading:

In order to prevent unchecked database growth (and hence, performance loss), data can be offloaded from the HammerServer's database onto a flat file. Depending on the purpose of the server, the resulting flat file can be backed up or removed. This is of course up to the application owner.


The HammerServer provides a set of networked interfaces, which can be turned on or off on the server. In the documentation these are referred to as:

Basic interfaces:

These allow insertion of data (which returns a key), and retrieval by key (which validates and returns the data). This is the basic purpose: an interface for applications to provide a tamper-resistant log.

Extended interfaces:

These allow bulk upload and searching. These interfaces are aimed at specialized applications.

Management interfaces:

These allow verification of the datastore and offloading onto a flat file, and are also application-to-application interfaces.

Browser interface:

The HammerServer can also expose its functions through the browser. This is useful for e.g. monitoring or verifications by hand. The browser interface can be customized using an XML transformation sheet.

Every function (or group) can be turned on or off on the server. Also, more than 1 server can be started to use the same datastore. It is therefore possible to e.g. start one server with the basic interfaces, for general usage by all applications. Another server can be started and be ``protected'' from the network to provide only the management interface. This granular approach provides flexibility.


The tamper-resistance of the HammerServer's datastore is based on strong cryptography. The used algorithms are freely available - as with all good crypto, the strengh lies in the keys that are used to encrypt and decrypt, not the algorithm. Technically, the following measures are in place:

Data Signing

Each record that is sent to the HammerServer for insertion is signed. The data are stored together with their signature, which ensures that the integrity of the data can be verified. This prevents data tampering by malevolent DBA's with access to the HammerServer's database. It is also a protection against data corruption from technical faults.

Protection against Insertion and Deletion

Deletion of records, or insertion of fakes, is also detected. Data signatures are based on the hash of the data, and on the hash of the previous entry. The signatures therefore form a ``chain'' of evidence: tampering of separate links (entries) is detected, but also tampering of the entire chain.

Protecting data from Different Sources

When a record is inserted, the caller obtains a key for later retrieval. The keys are unique, but seemingly random, so that it's not feasible to query to HammerServer and to try to obtain data using random ID's.

Cryptographic Functions

The HammerServer uses AES for encryption and decryption. SHA512 is used for hashing. Signing is implemented using an encrypted hash. Human-readable versions of binary data are achieved using Base64-encoding.

When deploying the HammerServer in an environment where tamper-resistant storage is a must, additional security measures should be enforced. E.g., four-eyes-principles and segregation of duties between app administrators and HammerServer administrators are a must.


For further information please read the Installation Guide and the Client API Guides.


The tamper-resistant server, all tooling, and the documentation were written by Karel Kubat / Copyright (c) 2009 ff. Distributed under GPLV3.