[prev in list] [next in list] [prev in thread] [next in thread] 

List:       log4j-dev
Subject:    Secure Audit Logging
From:       Jan Alsenz <Jan.Alsenz () oneconsult ! com>
Date:       2012-10-25 7:12:37
Message-ID: EA4A35F5FF57994ABAEF2EA10C53F3CE0C6833CB () SROCTH022 ! office ! oneconsult ! com
[Download RAW message or body]

Hello everyone!

I originally joined the discussion at \
https://issues.apache.org/jira/browse/LOG4J2-100 , but this seems to be the better \
place for the current state of the idea.

What I am looking for is a secure audit logging solution which employs cryptography \
to protect the audit log. One paper I found which describes what I am looking for can \
be found at http://www.schneier.com/paper-secure-logs.html . Unfortunately I didn't \
find any implementation of such a mechanism (neither in Java nor any other language). \
So I came looking for logging frameworks where it could be implemented as an add-on.

For those too lazy or time constraint to read the paper a quick overview of what the \
idea is (the description is in chapter 3 with a nice picture on page 5): We have some \
log messages D_j we want to protect from tampering (and maybe also read access). To \
do that we generate an initial secret A_0, which is stored in volatile memory on the \
system and communicated to a secure system. A_0 is then used to calculate a MAC of \
D_0 (and can be used to derive an encryption key to encrypt D_0). Then A_1 is \
calculated with a one-way hash function (A_j+1=H(A_j)), overwrites A_0 and continues \
with the next message.

What I want to build is a Log4J2 Plugin consisting of a RewritePolicy to add the \
checksum, MAC and encrypted message to the LogEvent and some converters to output the \
Audit entries. (In my setup I want to have encrypted/protected and unprotected \
logging in parallel, so simply replacing the message is not an option)

Currently there are two main challenges for the implementation:
- The previous A_j values must not be recoverable from the current system state, \
which is something very difficult to do with the Java GC. But this has nothing to do \
                with Log4J and I'm pretty sure I already have a solution.
- What is the best way to communicate the audit-information from the RewritePolicy to \
the converters?  Solutions, that came up in the discussion were: subclassing \
Log4jLogEvent, adding a (serializable) attachment to LogEvent or subclassing various \
Message types.

So my main question is what would be the best way for the internal communication?

Subclassing Log4jLogEvent in currently not compatible with the AsynchAppender and the \
existing RewritePolicies and would require code changes to the core (a possible path \
was proposed in the mentioned issue). Additionally there may be problems if the \
LogEvents are communicated outside of the current JVM (Java serialization). Adding an \
attachment to the LogEvent would also require code changes, but could be made \
compatible with outside JVM communication relatively easy and would be unobtrusive \
for any other component. Subclassing Messages I am still investigating, but it is \
possible that similar issues as with subclassing Log4JLogEvent show up.

To my current knowledge LogEvent attachments seem to be a nice option, as I said my \
analysis is not finished yet and any additional ideas are very welcome!

Best Regards,

Jan
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org


[prev in list] [next in list] [prev in thread] [next in thread]