Confide: A Quick Look

My inbox has been lighting up with questions about Confide, after it was allegedly found to have been used by staffers at the White House. I wish I had all of the free time that reporters think I have (I’d be so happy, living life as a broke beach bum). I did spend a little bit of time, however reverse engineering the binary and doing a simple forensic examination of it. Here’s my “literature in a rush” version.

Note: When I first wrote this blog post, I apparently had run into some corruption or some other strangeness going on with the framework; I suspect one of the tools I normally use might have decrypted it for me, and done a shoddy job without even telling me, so I have decrypted it by hand dumping memory from a debugger, and have updated my findings accordingly.

  1. A forensic analysis didn’t yield any messages in the application’s backup files. This is the same information that comes off with a forensic imaging from a vast majority of forensics tools. I did get basic configuration information, such as the number of times the app had been launched, last use, some unique identifiers, and so on. If someone were to get a hold of the device, using normal forensic acquisition techniques, messages don’t appear to be stored anywhere they would normally come off the phone.
  2. What does get stored, and this is obvious through the application’s GUI, are undelivered messages you sent to any of your contacts. This is part of Confide’s retraction feature, and if anyone gets UI access to your device (e.g. compels you for a passcode, or looks over your shoulder), they can read any undelivered messages, the content, who they were sent to, and the time they were sent. Even if you don’t pay for the retraction feature, Confide conveniently leaves the messages there so that you can see their advertising, in hopes that you will one day pay for this feature. Note: These messages are not forensically recoverable, but if you have UI access (e.g. a passcode) you can view them in the app.
  3. The encryption itself appears to be a fusion of PKI (public key cryptography) with symmetric EVP encryption components; it resembles EVP asymmetric envelope encryption, where the messages themselves are encrypted with a symmetric session key. Confide claims to use the OpenPGP standard (RFC 4880), which uses this paradigm, but it’s unclear how close to the RFC they stayed (a full review would be needed). It’s easy to read the overview of the RFC and develop something that smells like OpenPGP, or if they read the entire spec to implement the full standard. Some of the handling of this encryption appears to be home brew, however the encryption and decryption routines and random number/key generation is all tied to a “parts build” of OpenSSL, pieces of which have been statically compiled into the framework. The version I examined uses OpenSSL 1.0.2j from Sep 26, 2016, and so any vulnerabilities in the code patched after that are likely not in the product. It’s also important to note that OpenSSL is not FIPS 140-2 validated.
  4. While OpenSSL is used, and perhaps loose (?) compliance with either an EVP or OpenPGP standard, the implementation that pieces the final encryption product together does some interesting things with key management and public key regeneration, and has other code that looks home brew; it’s possible they come from a standard I am not intimate with, but they look more to be home grown ideas baked into the app to wrap the more standard components. Home grown encryption is nearly, but not quite, almost entirely nothing like tea. They might be fine, they might not – a much more in-depth review would be required. It is incredibly difficult to code the OpenPGP standard (or any other encryption standard) correctly, without having some weaknesses in your implementation. In this case, it’s glaringly obvious that there’s no fingerprint verification or other protections against server MiTM, and that the entire implementation appears to have been written by a guy named Jeff. This, combined with red flags like “battle tested, military grade encryption”, lead me more to the feeling that this wasn’t built by a team of expert cryptographers, but a couple of in-house devs, all named Jeff.
  5. The encryption appears to operate like most other e2e apps, where public and private keys are generated. In the case of Confide, an ephemeral key seems to be in play to encrypt messages themselves (with a symmetric cipher). What seems different about this encryption is that it appears to regenerate the public key under certain circumstances. It’s unclear why, but unlike Signal and WhatsApp, which consider it something to alert you about if your public key changes, Confide appears to consider this part of its function. Key exchange is always the most difficult part of good encryption routines. Depending on whether or not Confide is able to detect this and warn the user, it’s possible (although not confirmed) that the application could be susceptible to the same types of man-in-the-middle attacks that we’ve seen theorized in WhatsApp (if you leave the alerts off) and iMessage. This can easily be tested by setting up two devices to converse, and then replacing one device and re-provisioning it. I did not find time to do this, and lets be honest, you could do this yourself – you don’t need to pull me off the beach to do it.
  6. Because it has some proprietary encryption on the outer layer, and because I am not an encryption expert, I cannot vouch for the sanity of the entire encryption product, especially when talking about a closed source application that isn’t subject to peer review by outside cryptographers. I would be glad to provide any respectable cryptographer (such as Matt Green) any information needed in order to evaluate the sanity of the encryption.

This one’s a tough call. The application doesn’t smell fully kosher, but at least it uses some standard encryption routines, which many other applications fail to do. I did not see any obvious red flags in terms of forensics artifacts or other overtly nefarious behavior, but this, as I said, was a quick once-over. I spent more time on Meitu (it was awful).

Ultimately, the application warrants a cryptographic review before I could endorse its use in the White House. If I were the White House’s CIO, I would – other than hate my life – not endorse any third party mobile application that didn’t rely on FIPS 140-2 accepted cryptographic routines, such as Apple’s common crypto. OpenSSL is very clear about not being FIPS validated, and ultimately it would be up to the manufacturers of Confide to have each individual version of their software validated under FIPS. Nonetheless, as difficult as the FIPS validation process is, should the application not have been validated, it has no place in government in my opinion.

The app at least attempts to do what it says it does, and I don’t see any obviously gaping holes. That doesn’t mean its perfect, and obviously has at least a few disagreeable functions (such as retaining undelivered messages). On the whole, it may be fine for personal conversation, but I would recommend a more proven technology, such as Signal, if I were to have my pick of the litter.