Worst-case resource-usage analysis of java card classic editions application bytecode
Java Card is the dominant smartcard technology in use today, with over 12 billion Java Card smartcards having shipped globally in the last 15 years. Almost exclusively, the deployed Java Card smartcards are instances of a Classic edition for which garbage collection is an optional component in even the most recent Classic edition. Poorly written or malicious Java Card applications may drain the available memory of a Java Card Virtual Machine to the point the card becomes unusable, and
... ned use of the transaction mechanism may exhaust the available transaction buffers, resulting in programmatic abort by the Java Card Runtime Environment and so limit the range of services a Java Card application may successfully be able to offer. Given the size and global nature of the user base, and the commercial importance of Java Card, there is a stunning lack of tools supporting analysis or certification of the memory, transactional or CPU usage of Java Card applications. In this thesis we present a worst-case resource-usage analysis tool for Java Card which is capable of producing worst-case memory usage and worst-case execution-time estimates for Java Card applications (also known as applets). Our main theoretical contribution is a static analysis for Java Card applets at the bytecode level which conservatively approximates properties of interest affecting memory usage, input-output/APDU usage and transaction usage. Our static analysis provides the high-level information for subsequent worst-case resource-usage analysis in our tool which exploits well-known results and techniques from hard real-time systems. We generate a resource usage graph per registered applet lifecycle method entry point as the start node and the control-flow returning to the Java Card Runtime Environment as the final node. We use the Implicit Path Enumeration Technique to generate and solve Integer Linear Programming problems representing the worst-case memory-usage and worst-case execution-time.