Problem: The authors suspect that there is rampant misuse of cryptographic APIs across Android applications, and they'd like to measure and categorize this misuse, to inform how best to improve the ecosystem.
Approach: They develop a lightweight static analysis tool called CryptoLint that can identify common crypto API misuse patterns given a raw Android binary. Then they run this tool across a large sample of Android applications in the Google Play store.
Conclusions: The conclusions are objectively bad, but perhaps not surprising: a whopping 88% used cryptography incorrectly (note that this proportion is out of the applications that actually use the crypto APIs in question). More specifically, the authors define six distinct, basic rules that must be followed when using cryptography to achieve IND-CPA security. The most common rule broken is using ECB mode for encryption. As the authors previously indicated, this isn't a surprising result, because ECB mode is the default mode in the crypto API! The authors also conclude the paper with three proposals for improving the status quo: (1) warn about semantic contracts in APIs (e.g. use CryptoLint prior to publishing an app), (2) improve defaults in crypto APIs (either change the current defaults or force them to be explicit), and (3) improve API docs (the docs don't even specify that ECB will be used by default!). Honestly, it sounds like the Java API and docs are almost as much to blame as the app developers.
New ideas: According to the authors, prior to this paper, the tools available for checking cryptographic implementations are all "heavy weight". They provide strong guarantees, but require expertise and manual effort to use. The new idea behind CryptoLint is to be "light weight": the scope of what CryptoLint checks for is smaller, so that it can run quickly, and it operates directly on the Android binary, so a wide variety of developers and app store operators can use it efficiently. And, such a tool is much better suited to a large scale analysis, such as the one performed in this paper. The authors also claim that this large scale analysis is the first of its kind.
Improvements: One improvement would be to operate on more than just Dalvik bytecode. This paper was published in 2013, and it looks like Dalvik was completely replaced by Android Runtime shortly afterwards, in 2014 (in Android Lollipop OS). I tried to search for CryptoLint but nothing came up, so I wonder if the project has since died. That prompts another improvement: include source code in the Appendix or at least host it somewhere for the public.
New directions: An obvious new direction for future work would be to expand on the ruleset to catch more misuse patterns. Furthermore, one could also implement heuristics for common cryptographic patterns to detect hand-rolled crypto implementations, rather than just restricting the analysis to usage of the defined crypto APIs. Lastly, another direction would be to analyze iOS apps. It's possible that this is infeasible if Apple's compiled apps are opaque given its proprietary nature; I'm not a mobile developer, so I'm not sure. However, given Apple's outward marketing focus on privacy, having a tool detect such cryptographic misuses prior to being published on the App Store seems quite valuable.