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
