1

The Android Bluetooth Low Energy documentation recommends adding application layer encryption on-top of the BLE connection if the exchanged data is sensitive:

Caution: When a user pairs their device with another device using BLE, the data that's communicated between the two devices is accessible to all apps on the user's device.

For this reason, if your app captures sensitive data, you should implement app-layer security to protect the privacy of that data.

As I would like to avoid "rolling my own encryption", I am looking for a production-ready way to encrypt packets.

I have an out-of-band channel to exchange one message (e.g key) from one participant to the other (QR code). Both participants are Android devices, one operating in server mode (peripheral), and one as a client (central).

I looked at the Noise Protocol Framework as a more lightweight alternative to TLS, but that feels like it is still to much manual work(?).

Is there an easy solution? It seems like this has to be a solved problem.

Improve this question

1 Answer 1

Reset to default
1

First, a word of advice: StackExchange is not for recommending specific products, so I'm going to be relatively general here. Whoever reads this in the future may be in a world where there are new and much better alternatives, or even where the old guard has been found to be broken.

There are several high-level crypto libraries that - given a pre-shared key - will handle message or possibly stream encryption (and related security requirements such as data integrity) with a minimum of effort. Simply searching for "easy crypto library" will find you some candidates. Note that lots of people ignore the advice against rolling your own crypto, and some of them publish it, so you do want to make sure the library you pick is well-reviewed by experts, ideally unrelated to its development.

You'll also want to consider what exactly you want (and need) from your library. Does it need to support arbitrary-length encrypted streams (or very large messages that don't easily fit in memory), or will a simple message-based protocol work? Must the library be very small, in install footprint or RAM usage? Very fast, on a particular CPU? Compatible with any particular other library? Use specific ciphers or other primitives for compliance reasons (I hope not)? Available in a particular language?

For a few well-regarded examples as of mid-2020, consider LibSodium or Monocypher. Both are well-regarded, reviewed, and focused on ease of use. Other alternatives are NaCl, LibHydrogen, and so on. Note that not all of these focus equally on security, speed, or convenience; for example, TweetNaCl emphasizes minimal code size, sacrificing a lot of speed and potentially some security in the process, compared to the original NaCl.

Improve this answer
4
  • "TweetNaCl ... sacrificing ... potentially some security ... compared to the original NaCl." Erm, what do you mean by this?
    – domen
    Aug 18, 2020 at 7:06
  • @domen TweetNaCl skips some potentially-security-relevant operations, like securely wiping memory, and also may be more susceptible to timing attacks (it's certainly not specifically optimized against them, and also it's much slower, which means any timing side channels are more likely to be detectable and also slightly increases risk of DoS if running near the system's limit).
    – CBHacking
    Aug 18, 2020 at 9:10
  • Source? tweetnacl.cr.yp.to/tweetnacl-20140917.pdf says "TweetNaCl is secure and reliable. TweetNaCl is a C library containing the same protections as NaCl against simple timing attacks, cache-timing attacks, etc. It has no branches depending on secret data, and it has no array indices depending on secret data. We do not want developers to be faced with a choice between TweetNaCl’s conciseness and NaCl’s security." Though, obviously these are claims from authors, who are likely to be biased.
    – domen
    Aug 18, 2020 at 9:23
  • 1
    Fair enough, perhaps it is fully secure against timing attacks after all (I'm not sure what distinguishes a "simple" timing attack from other ones, but it does contain the protections I know of). There are (as mentioned in the "Why Monocypher?" link above) two undefined operations in TweetNaCl, but for any real-world compiler they would not be dangerous. Not wiping internal buffers is still a slight risk, but it doesn't use dynamic allocation so there wouldn't be a lot of data left in memory, probably at most the last operation's secrets might be recoverable.
    – CBHacking
    Aug 18, 2020 at 10:14

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .