I apologize for not responding sooner. This one somehow just slipped by. Please forgive me for not responding right now but I wanted to let you know that I am going to read the paper again, but more thoroughly, so that I'm sure I have a good idea of what you are looking to do.
Ralph On Oct 25, 2012, at 12:12 AM, Jan Alsenz wrote: > 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-unsubscr...@logging.apache.org > For additional commands, e-mail: log4j-dev-h...@logging.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
