[
https://issues.apache.org/jira/browse/LOG4J2-2930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17202883#comment-17202883
]
Matt Sicker commented on LOG4J2-2930:
-------------------------------------
Without a proper unit of work API, it seems like encrypting individual log
events is the best way to go. Regarding speed, there are a few alternatives:
# The simplest route to go is to continue having the configuration specify a
public key which we can then use to encrypt generated session keys used for
symmetric encryption. This secret key should be regenerated every 2^31
encryption operations (each message using a unique randomly generated IV; this
is simpler than trying to maintain a monotonic counter without an underlying
protocol support). This method works well for AES/GCM and ChaCha20-Poly1305.
The choice of asymmetric cipher will determine exactly how _big_ the encrypted
session key will end up being.
# A more complex implementation could use the {{KeyAgreement}} API to calculate
a shared secret between two asymmetric keys. Suppose we have a statically
defined public key as in the previous implementation. Then we can generate a
key pair on the logging side. This was an approach I was considering last week,
though this design now seems overkill as the log destination isn't
communicating back to us. This approach could also generate new keypairs for
every log event when using a fast asymmetric algorithm like X25519, but that's
still limited in security to compromise of the destination private key.
# If an API is created for plugins to implement that provide the public key to
use for encrypting the session key used in the log encryption, then that public
key can potentially be rotated. The exact details are fuzzy as there are
numerous ways to manage encryption keys in an application or system, so I'm not
sure what it'd look like yet.
> Add plugin for encrypting/decrypting log events
> -----------------------------------------------
>
> Key: LOG4J2-2930
> URL: https://issues.apache.org/jira/browse/LOG4J2-2930
> Project: Log4j 2
> Issue Type: New Feature
> Components: Appenders, Core, Receivers
> Affects Versions: 2.13.3
> Reporter: Matt Sicker
> Priority: Major
>
> Some of the existing appenders write log events to sophisticated systems
> which support encrypting said data at rest and in transit (e.g., storing
> events in an encrypted SQL database using a TLS connection, writing data to
> an encrypted filesystem or disk, etc.) However, not every system supported in
> Log4j provides a feature or ability to encrypt and decrypt data natively.
> There are a small collection of ad hoc cryptographic operations in Log4j
> (e.g., {{SslConfiguration}}, {{KeyStoreConfiguration}},
> {{SecretKeyProvider}}, etc.) which should be refactored and extended to allow
> for more flexibility in key management and message encryption/decryption.
> This will allow appenders and receivers that wish to support encryption to do
> so much more easily. This should also allow for more sophisticated use of
> cryptography such as adding message digests or authentication tags to log
> messages to help prevent tampering and add authenticity.
> Related resources:
> *
> https://cheatsheetseries.owasp.org/cheatsheets/Cryptographic_Storage_Cheat_Sheet.html
> *
> https://cheatsheetseries.owasp.org/cheatsheets/Transport_Layer_Protection_Cheat_Sheet.html
> *
> https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html#protection
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
