Improving Crypto API Misuse Detection: Insights from Previous Static Analysis Approaches

Table of Links

Abstract and 1 Introduction

2 Background

3 Design and Implementation of Licma and 3.1 Design

3.2 Implementation

4 Methodology and 4.1 Searching and Downloading Python Apps

4.2 Comparison with Previous Studies

5 Evaluation and 5.1 GitHub Python Projects

5.2 MicroPython

6 Comparison with previous studies

7 Threats to Validity

8 Related Work

9 Conclusion, Acknowledgments, and References

8 RELATED WORK

Several, previous studies show that crypto misuses occur frequently in different languages and platforms. Egele et al. [4], Krüger et al. [8], Rahaman et al. [12], and Hazhirpasand et al. [6] analyzed Java and Android applications. They reported that 84.78 % up to 99.59 % of the applications using crypto have at least one misuse. Zhang et al. [13] analyzed Internet of Things (IoT) device firmwares written in C/C++, from which 24.2 % contain at least one misuse.

Previous work introducing new crypto misuse analyses either improve static analysis approaches for crypto misuse detection or introduce these to new languages imposing new challenges. CryptoLint [4] is the first (closed-source) static analysis for crypto misuses for Android applications introducing the six rules for crypto misuses, c.f. Table 1. While this analysis is built upon a deny-listing approach, CogniCryptSAST [8] introduces an allow-listing approach covering the standard Java library, BouncyCastle and Tink to analyze Java and Android applications for misuses. The focus of the analysis Cryptoguard [12] is a scalable deny-listing Java analysis for crypto misuses extending the rules implemented in CryptoLint [4]. CryptoREX is a framework for firmware written in C/C++ which covers the rules introduces by CryptoLint [4].

Acar et al. [1] conducted a user study with 5 different Python crypto APIs to analyze how developers perform on 5 crypto tasks with a pre-selected API. Their study reveals that APIs with a usability focus for security result in significant more secure code. In a similar study, Acar et al. [2] analyzed the security of 3 different crypto tasks and identified that more usable libraries resulted only in insecure solutions for encryption in 12.7 % of the cases.