[
https://issues.apache.org/jira/browse/LOG4J2-2930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17200318#comment-17200318
]
Matt Sicker commented on LOG4J2-2930:
-------------------------------------
More on the crypto design sample plugin idea so far:
* Using a known public key corresponding to the destination where data is being
encrypted to, we can generate a corresponding keypair every so often (every
2^31 log events if we match how SSH handles this as a secure maximum). Using
this keypair, we can include the public key which is used to create a shared
secret using a key exchange (DH, ECDH, XDH, etc.). This shared secret is then
used as the basis for a secret key used for encrypting the log event itself.
* Each batch of log events can potentially be encrypted using the same IV as
one large message.
* The IV should be included in messages as AAD plaintext.
* The public key should be included as well, but it doesn't need to be in every
message potentially (perhaps a digest of the key for large keys like
traditional DiffieHellman keys; small keys like in X25519 can probably be
included with little overhead)
Some of the design problems to figure out, though, are the granularity of
crypto here. The easiest but least performant implementation would be to
generate a new KeyPair and thus session key for every log event, but that seems
like a lot of overhead considering the typical size of log messages. The next
best ideal could be via the batching mechanism, but that would only make sense
for appenders that concatenate batched events together (i.e., it wouldn't work
with, say, any of the database appenders). As this is more of a sample than it
is a generic thing usable everywhere in Log4j, that shouldn't be too big a deal
since more advanced use cases can integrate with other systems' crypto, too.
Ideally, a nice feature to come from this could be some more generic layout
decorator plugins to allow for refactoring of various special case features
like compression, encryption, signing, integrity checks, generating metadata to
include in the output, etc.
> 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)
