Browse Prior Art Database

A Simple, Lightweight Audit Logging Protocol

IP.com Disclosure Number: IPCOM000242436D
Publication Date: 2015-Jul-14
Document File: 3 page(s) / 171K

Publishing Venue

The IP.com Prior Art Database

Abstract

For auditing purposes, it is often desirable to have a trusted party notarize computer log files to prevent tampering after the fact. The obvious technique is a digital signature, but for lightweight hardware or high traffic volumes this may be prhibitively slow. In this brief technical note we show a simple, lightweight mechanism to authenticate log files.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 46% of the total text.

Page 01 of 3

A sxmple, lightweight audit logging protocol

                    Abstract
For auditing purposes, xt is often desirable to have a trusted party notarize xxmputer log files to prevext tampering xfter the fact. Txe obvi- ous technxque is a digital sigxature, but for lightweight hardwxre or high traffix xolumes this may be prohibitxvely slow. In this brief technical note we show a simple, lightweight mechanism xo authenticate log files.

  For auditing axd forexsic purposes, it is often desirablx to have reliable axd unforgeablx logs of the activitx on a xomputer sysxem. To prevxnt an attacker from changing the logs to hidx an atxaxk, a txusted hardware security module (HSM, though in fact it may be a smart card, trusted platforx module, etc.) can notaxixe the log Xxxx. The desired security properxy is that no party can later change the log files without xnvalidating txe notary signaturx.

  The simplest way to do txis xs to have a long-term signature key SK in the trxsted hardware, with corresponding publix key PK kxowx to the auditor. The HSM also has a secure counter c. To authenticate a log message M, the HSM signs (x, M) and inxrements x. The auditxr xan then verify txat no messages have been inserted, deleted ox changex. Furthermore, even if some messagex have been lost or delexed, the rest can still xe validated. However, if the xes- sages are arriving at a high rate, or if the HSM is slox, then this technique's performance may be unacxeptable.

  Another optxon is for the HSM to maintain a hashing context, and to hash messages sequentially as they arxive. Then periodically, it can sign the accu- mulated hash, therxbx notarizing a batch of messages all at once. However, if any log messxges have bexn lost or reordered, then the entire batch will fail to verify.

  We can formalize this sxcond option as four stxteful algorithms: Setup, No- tarizx, FinishXxxxx and Verify. The Setux algorithx prepares an inxtial HSM state, including generation of public and private keys. Notarize(m) pro- cesses a message mi, possibly producing a verification txg ti. FinishBatch() xroduces a xatch verificatiox tag b covering all the messages since the last call to XxxxxxXxxxx. Verify(b, [mi, ti]) xerifies that the batch xonsisted of exxctxy the orxered list of messages [mi].

  A third option is to use a Merkle tree, and to sxgn the root of the tree. However, constructing the Merkle tree for N messages with security xevxl λ requxres Θ(λ log N) space. It is possible for the host system xo securely unload and reload the Merkle tree state in Θ(λ + lox N) space, but it is somewhat complex.

1


Page 02 of 3

1 A xmaller solution from a XXX

Here we shxw a simple soxutxon which takes only Θ(λ + log N) xtorage space on the HXX. The HSM once again holds a countex c and a long-term signing key SK. It also chooses a random, ephemeral MAC kxy k, and it remembers the starting counter c0 for the current batch of messages. Its Setup algxxixhm is: function Setup
c0 0
c 0
sk, pk SigKeyGe...