4

Log encryption

I am building an Android app which stores log lines in a rotating log file. When a user faces a problem, he or she can send us a support request with the log files attached.

For obvious reasons, I would like to encrypt these log lines.

Wish list

  • Asymmetric encryption: the app should be able to encrypt, but not decrypt, the data
  • Line-by-line encryption, so that each line could be decrypted. This is required because log rotation might cut parts of the file.
  • Fast enough algorithm that would not slow older devices (at peak, there might be ~10 log lines/second)
  • Ability to encrypt very long (up to 4k chars) log lines. This excludes, for example, RSA, which is limited to 117 bytes of encrypted data for a 1024 bit key.
  • Decryptable using ordinary Linux command line tools like OpenSSL or gpg.

What's the best way to asymmetrically encrypt Android logs line by line?

Community
  • 1
  • 1
Adam Matan
  • 128,757
  • 147
  • 397
  • 562

2 Answers2

4

you've placed several constraints:

To be effective and secure, I'd suggest:

  • create a random key and IV (initialization vector - effectively the 'salt')
  • encrypt the key with the recipient's public key (see https://www.devco.net/archives/2006/02/13/public_-_private_key_encryption_using_openssl.php).
  • encrypt the log lines one by one (with increasing IV as counter or you can create one IV for each line) using any of feasible symmetric encryption. AES-CBC should be effective enough even on slow HW with precomputed S-boxes.
  • send over the encypted key, IV, log lines and authentication (authenticated signature of the content and IV, e.g. HMAC-SHA1)

Note: - if you want to stay really secure, do not implement security primitives (en/decryption, secure randomness, signing) by yourself, always use libraries which are reviewed and tested - asymmetric encryption must be always salted

Still - answer yourself - how secure you want to keep the communication. In many cases sending the logs through TLS (HTTPS) to achieve security of data on the move is enough. With encryption there are a lot of ways how to make system look safe and actually having weakness you may not realize.

Have fun

g.

gusto2
  • 11,210
  • 2
  • 17
  • 36
0

While not an "app" but a bash script instead, scenario one of a recently pushed project maybe still of interest. However, do be warned that it is still under heavy development and while it works on my Android devices it has not been tested in a production environment yet.

Features requested & their status

  • Not an app. You're welcome to translate it or use it as part of an app; just read up on the licensing used.

  • asymmetric encryption via GnuPG public keys is supported.

  • line by line encryption supported as well as per write encryption.

  • maybe slow. No stress tests have been performed yet, but seems snappy enough on my old phones.

  • large log lines supported via mapfile which can usually handle a few thousand lines per parsing operation.

  • decryption of logs is supported but requires a bit of help via another helper bash script found in the above linked document.

  • files written by encryption script copies cannot be decrypted on the same device so long as that device does not also have the related private keys.

System requirements for encryption

  • Version of bash equal or greater than 4, look up busy box for how to get bash'n'friends installed on Android.

  • Either gpg or gpg2 installed.

  • GnuPG public keys (up to two) for encryption

  • Custom script copy written by above project's main script (that's one of its features) to use above public keys.

  • logging process modified to use script copy's named pipe for writing actions.

System requirements for decryption

  • Same requirements as encryption, however, you'll need the private keys that correspond to the public keys used to encrypt files.

  • You'll need the helper script from above linked document to feed your decryption named pipe.

  • And instead of an encryption script copy you'll want to modify as instructed a script copy for decryption.

The main script it's under two-thousand lines and the copies it writes are substantially shorter. This is because the main script has to handle user input to figure out what your intent is where as the script copies just handles input read from it's named pipe and writing out encrypted data where it was told. Full documentation of all command-line options is also available if the provided linked scenario didn't quite hit the mark.

S0AndS0
  • 860
  • 1
  • 7
  • 20