How can an app prove that it is, in fact, encrypting data?

Question

Created Nov ’21

Replies 2

Boosts 0

Views 1.1k

Participants 3

Apps like Password Managers and such claim to encrypt your sensitive data, and only transmit and store your data on their servers in encrypted form, never in plain text. But how are we supposed to believe that? Just take their word for it? Who's to say that their developers won't accidentally (or intentionally!) make a mistake in their code at some point and get to see your sensitive data?

I am asking because I am currently writing an app using the Swift-Crypto package to do AES encryption. I save the user's data in encrypted form in Core Data on the device as well as mirror it on their iCloud account using CloudKit. When I submit the app to Apple for review, without looking at the source code, will they be able to verify 100% that my app actually and correctly encrypts all the data so that users can confidently trust that their data will be safe? How can we be sure?

Boost

Answer 1

DTS Engineer OP

Apple

Nov ’21

How can an app prove that it is, in fact, encrypting data?

It can’t. Even if the developer could mathematically prove that their code encrypts correctly, such a proof would depend on the underlying platform being proved secure and Apple offers no such proofs for our platforms.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

0

Answer 2

Hoffman OP

Nov ’21

Proving a negative is... difficult.

There are myriad ways to go wrong with data encryption.

One common mistake is using encryption for certain data, where a cryptographic hash would be more appropriate.

Claiming data security can involve open-sourcing at least some of the storage-related details if not the related code (and also allowing reverse-engineering for the related area), or can involve the performance of an outside audit. Even then, it's still exceedingly difficult to prove that no backdoors exist, and that critical members of technical staff are not themselves compromised.

It's also seldom a vulnerability in the encryption itself that's targeted—AES and TLS and Argon2 are decently secure—it's usually something around the encryption or key management that's targeted. Or the people.

Upgrading to newer encryption or newer hashes tends to be an interesting discussion for developers too, and one that some apps are ill-prepared for.

With third-party password managers, arguably the biggest problems folks have had have involved apps that vaporized.

1