5 ms·

An Empirical Study of Cryptographic Misuse in Android Applications [pdf]

74 points by nmc 13y ago

nmc 13y ago
OK, sorry about the custom title, I got it from there: https://twitter.com/csoghoian/status/398336912181579776 https://twitter.com/csoghoian/status/398336912181579776
deleted 13y ago
[deleted]
tptacek 13y ago
This is great: interesting systems research (reconstructing CFGs from bytecode, converting to SSA, discovering type constraints for registers, and slicing to find which code influences which registers) and a good starting point for crypto security. I'm particularly happy to see them pointing out how easy it is to end up with ECB mode, which allows attackers who can merely influence plaintext to decrypt messages a byte-at-a-time, "Hollywood-style". ECB is for Java the de facto default, the one you get when you ask the JCE for "AES" without specifying a block mode. This is no surprise: the other modes all need IVs and nonces, and so libraries give you the one that doesn't need more options when you don't tell it to. It's for this reason that we call ECB "the default mode"; it's a quirk of ours, but a useful one. Don't use the default mode. Here's the list of things they looked for: 1. Don't use ECB 2. Use random IVs for CBC mode (if you don't, you end up with ECB-like properties for the first blocks of messages). 3. Avoid constant encryption keys (if they're constant, they're trivially discoverable by attackers, and encryption is cosmetic). 4. Avoid constant salts for password-based key generation (so that attackers can't precompute tables). 5. Use at least 10,000 iterations for your KDF to slow down brute force attackers. 6. Don't pass static seeds to SecureRandom, which can have the side effect of turning off cryptographic randomness, destroying the security of your system. The one thing I'd caution readers about is to understand the limitations of this analysis. The authors are demonstrating the power of a particular static analysis technique, and also providing a useful survey of just how bad app crypto is (over 80% of the thousands of apps they tested flunked these basic tests!). But that list above isn't "The Six Commandments" of good crypto; it's missing extremely basic stuff, like never encrypting without authenticating, never repeating a nonce or counter, &c. We set out to build challenges to capture things we'd seen going wrong in real cryptosystems we'd tested, and we have more than 64 of them now.
- nmc 13y ago
  An example of "extremely basic stuff" is checking the domain entry in the SSL certificate, as bank ABN-Amro failed to realize [pdf] https://www.os3.nl/_media/2012-2013/courses/ssn/security_in_mobile_banking_ssn.pdf https://www.os3.nl/_media/2012-2013/courses/ssn/security_in_...
- hershel 13y ago
  Since there are so many types of errors,the usual recommendation is to use a higher level library, like NaCl. I wonder if using similar approach shown in this research ,one could determine if apps are using NaCl(say, for all outgoing communications). Such knowledge would be pretty useful to end users.
  - tptacek 13y ago
    Ensuring that programs use NaCl should be much, much easier than verifying that they use the JCE properly, especially if you adopt the constraint that you only need to analyze JCE crypto.
- spikels 13y ago
  One of the many mistakes by Adobe revealed in the recent hack was their use of ECB to encrypt passwords. The basic problem with ECB is the same input always results in the same output. And this applies not only to the entire input but specific subsections of the input, known as blocks. This leaks substantial information. In the Adobe leak accounts with identical passwords were easily identified as they had the same encrypted password. Frequency analysis can then be applied to find common passwords ("123456" is often the most common...). Even worse Adoble also leaked the password hints so you often had thousands of different hints to help you guess a single password. Of course you should not even be encrypting password in the first place (use a cryptographic hash with an individual cryptographically random salt for each password NO! SCRATCH THAT. JUST USE BCRYPT!) but that's another issue... http://nakedsecurity.sophos.com/2013/11/04/anatomy-of-a-password-disaster-adobes-giant-sized-cryptographic-blunder/ http://nakedsecurity.sophos.com/2013/11/04/anatomy-of-a-pass... http://en.wikipedia.org/wiki/Block_cipher_mode_of_operation#Electronic_codebook_.28ECB.29 http://en.wikipedia.org/wiki/Block_cipher_mode_of_operation#... Edit: Corrected based on tptacek's comment below.
adestefan 13y ago
Their list of Rules is out of order and that may affect Table 3. Mainly I'm wondering it there really are that many programs that use constant keys (e.g. is Rule 3 in the table really Rule 3 from the text since that's called out as rule 3 below.) Of course it wouldn't suprise me one bit of there really are that number of applications that use constant keys.
archivator 13y ago
Excellent study! I know it's not exactly easy to do with their analysis framework but I'd be interested to know how many apps just ignore certificate errors. It's a depressingly common "solution" on Stack Overflow..

74 points by nmc 13y ago

nmc 13y ago

OK, sorry about the custom title, I got it from there: https://twitter.com/csoghoian/status/398336912181579776 https://twitter.com/csoghoian/status/398336912181579776

deleted 13y ago

[deleted]

tptacek 13y ago

This is great: interesting systems research (reconstructing CFGs from bytecode, converting to SSA, discovering type constraints for registers, and slicing to find which code influences which registers) and a good starting point for crypto security. I'm particularly happy to see them pointing out how easy it is to end up with ECB mode, which allows attackers who can merely influence plaintext to decrypt messages a byte-at-a-time, "Hollywood-style". ECB is for Java the de facto default, the one you get when you ask the JCE for "AES" without specifying a block mode. This is no surprise: the other modes all need IVs and nonces, and so libraries give you the one that doesn't need more options when you don't tell it to. It's for this reason that we call ECB "the default mode"; it's a quirk of ours, but a useful one. Don't use the default mode. Here's the list of things they looked for: 1. Don't use ECB 2. Use random IVs for CBC mode (if you don't, you end up with ECB-like properties for the first blocks of messages). 3. Avoid constant encryption keys (if they're constant, they're trivially discoverable by attackers, and encryption is cosmetic). 4. Avoid constant salts for password-based key generation (so that attackers can't precompute tables). 5. Use at least 10,000 iterations for your KDF to slow down brute force attackers. 6. Don't pass static seeds to SecureRandom, which can have the side effect of turning off cryptographic randomness, destroying the security of your system. The one thing I'd caution readers about is to understand the limitations of this analysis. The authors are demonstrating the power of a particular static analysis technique, and also providing a useful survey of just how bad app crypto is (over 80% of the thousands of apps they tested flunked these basic tests!). But that list above isn't "The Six Commandments" of good crypto; it's missing extremely basic stuff, like never encrypting without authenticating, never repeating a nonce or counter, &c. We set out to build challenges to capture things we'd seen going wrong in real cryptosystems we'd tested, and we have more than 64 of them now.

nmc 13y ago
An example of "extremely basic stuff" is checking the domain entry in the SSL certificate, as bank ABN-Amro failed to realize [pdf] https://www.os3.nl/_media/2012-2013/courses/ssn/security_in_mobile_banking_ssn.pdf https://www.os3.nl/_media/2012-2013/courses/ssn/security_in_...
hershel 13y ago
Since there are so many types of errors,the usual recommendation is to use a higher level library, like NaCl. I wonder if using similar approach shown in this research ,one could determine if apps are using NaCl(say, for all outgoing communications). Such knowledge would be pretty useful to end users.
- tptacek 13y ago
  Ensuring that programs use NaCl should be much, much easier than verifying that they use the JCE properly, especially if you adopt the constraint that you only need to analyze JCE crypto.
spikels 13y ago
One of the many mistakes by Adobe revealed in the recent hack was their use of ECB to encrypt passwords. The basic problem with ECB is the same input always results in the same output. And this applies not only to the entire input but specific subsections of the input, known as blocks. This leaks substantial information. In the Adobe leak accounts with identical passwords were easily identified as they had the same encrypted password. Frequency analysis can then be applied to find common passwords ("123456" is often the most common...). Even worse Adoble also leaked the password hints so you often had thousands of different hints to help you guess a single password. Of course you should not even be encrypting password in the first place (use a cryptographic hash with an individual cryptographically random salt for each password NO! SCRATCH THAT. JUST USE BCRYPT!) but that's another issue... http://nakedsecurity.sophos.com/2013/11/04/anatomy-of-a-password-disaster-adobes-giant-sized-cryptographic-blunder/ http://nakedsecurity.sophos.com/2013/11/04/anatomy-of-a-pass... http://en.wikipedia.org/wiki/Block_cipher_mode_of_operation#Electronic_codebook_.28ECB.29 http://en.wikipedia.org/wiki/Block_cipher_mode_of_operation#... Edit: Corrected based on tptacek's comment below.

adestefan 13y ago

Their list of Rules is out of order and that may affect Table 3. Mainly I'm wondering it there really are that many programs that use constant keys (e.g. is Rule 3 in the table really Rule 3 from the text since that's called out as rule 3 below.) Of course it wouldn't suprise me one bit of there really are that number of applications that use constant keys.

archivator 13y ago

Excellent study! I know it's not exactly easy to do with their analysis framework but I'd be interested to know how many apps just ignore certificate errors. It's a depressingly common "solution" on Stack Overflow..