Bytecode verification on Java smart cards

Abstract

This article presents a novel approach to the problem of bytecode verification for Java Card applets. By relying on prior off-card bytecode transformations, we simplify the bytecode verifier and reduce its memory requirements to the point where it can be embedded on a smart card, thus increasing significantly the security of post-issuance downloading of applets on Java Cards. This article describes the on-card verification algorithm and the off-card code transformations, and evaluates experimentally their impact on applet code size.

User Centric Security Model for Tamper-Resistant Devices

“…However, in the UCOM environment, applications are not required to be evaluated by third parties, and so evaluations can be costly, and may discourage small and medium-scale organisations from opting for the UCTD-based architecture. To verify the security and reliability of an application, a smart card can employ on-card veri cation mechanisms like bytecode veri cation [128].…”

“…For this purpose an on-card byte code veri cation is performed [161], which is already mandated by the Java Card 3 [16]; this can be based on the well-de ned on-card byte code veri cation proposals [128,161] [163].…”

“…Therefore, security and reliability analysis (e.g. bytecode veri cation [128,161]) of the downloaded application and not of the SP which supplied it is adequate to protect the UCTD. Furthermore, an adequate protection mechanism implemented by the UCTD runtime environment avoids malicious runtime activities (discussed in chapter 8)…”

“…The assurance for the JCRE reliability against ill-formed applications was based on bytecode veri cation [128,161] [163], which became a compulsory part of the Java Card speci cation version 3 [16].…”

Trusted Computing, Trusted Third Parties, and Verified Communications

“…In a recent paper [18], Leroy discusses the cost of traditional bytecode verification on Java cards, and also discusses alternatives. Leroy writes:…”