Practical Java Card bytecode compression 1

Size: px

Start display at page:

Download "Practical Java Card bytecode compression 1"

Beryl Patterson
5 years ago
Views:

1 RENPAR 14 / ASF / SYMPA Practical Java Card bytecode compression 1 Gabriel Bizzotto Gilles Grimaud LIFL, Universite de Lille 1 Gemplus Research Lab bizzotto@dea.lifl.fr grimaud@lifl.fr Abstract Our work concerns bytecode compression on an embedded, tiny and safe environment, and more specifically JAVA CARDS. [2] and [4] propose a way to compress java card bytecode into a format executable in an ultra light embedded system, using macro-packing. Our implementation, improved with new specifical algorithms, allows a better compress rate (up to 32%). In a smart card having 32kB EEPROM, up to 10kB can be freed, it is enough to store some applets. The execution of macro-packed programs is very simple and the code overhead in the operating system and in the virtual machine is very small. Unfortunately, the compression process is not feasible in a tiny embedded system. We propose a distribution of the compression process called Compression-Carrying Code or simply CCC. This distribution maintains the Java Card 2.11 compatibility [11], and allows a trusted, just-in-time compression by the embedded bytecode loader. Keywords Smartcard, Java Card, CCC, macro-packing, bytecode compression. 1. JAVA CARD Bytecode compression : state of the art 1.1. Why compressing JAVA CARD bytecode using macro-packing? In a smart card, all kinds of memory (RAM, EEPROM 2 and ROM 3 ) can be directly addressed by the CPU. This hardware property allows the operating system to run bytecoded programs in place, in storage, persistent memory, without any loading step. Programs compressed using Lempel-Ziv [12], Huffman [6] or JAVA dedicated algorithm [8, 1] have to be decompressed to be understandable by the JAVA CARD virtual machine. This unpacking step is not feasible in a smart card, due to the amount of RAM needed for unpacking (at least one basic bloc for stream-based decompression) and the time spent to store the uncompressed program (writing one 64 bytes page from RAM to EEPROM hangs the system for cycles) That s why we focus on bytecode macro-packing [2, 4] which is able to produce executable code without preliminary unpacking Macro-packing general working ABCABCDEFDEFABCABC XXYYXX X :ABCY:DEF Compressed bytecode Macroblob Figure 1: Example of macro-packing on an arbitrary instruction set. Compiled programs often contain series of instructions that appear several times. Some compilers are able to detect and to factorize these patterns into a single subroutine. Every occurrence of these patterns This work was supported by a grant from Gemplus Research Labs, and was performed within the Gemplus Research Labs. Non volatile memory. Read Only Memory.

2 is replaced by a call to the pattern and therefore the program is smaller. In the case of JAVA, patterns are not replaced by JUMPs or JSRs or calls but by a new proprietary instruction of the virtual machine. The JAVA CARD 2.11 specification [11] lets holes in the instruction set. Indeed one instruction is coded on 1 byte but not all of the 256 possible instructions are used. Instructions 185 to 253 (included) are neither specified nor reserved. These free instructions can be transformed into macro-instructions Limitations of the macro-packing The macro-packing of JAVA binaries described in [2] is constrained. The parameters to take in account for implementing macro-packing in JAVA CARD are not the same as for standard compression. Instructions forbidden in a macro A label must not be part of a macro, TRY/CATCH zones edges, which are considered as labelled, must not either. Control flow breaking instructions (JUMP, INVOKE, SWITCH, JSR,... ) are forbidden in macros, some constant pool references too. A macro can not contain a macro-instruction. Nevertheless some of these instructions can be used in a macro according to a specific JCVM 4 implementation. System code overhead The main loop of the JAVA CARD virtual machine has to be modified to perform the execution of a macro when it reads a non-standard unknown instruction. The code overhead is less than 2kB. The onboard applet loader/compressor/verifier described in section 3.1 (page 4) will take 7kB of native code. All this system code overhead concerns the ROM, it is the less critical memory of the smart card, however it must be taken in account to evaluate the benefit of implementing the compression in a smart card. Execution slow down The execution of macro-packed JAVA CARD bytecode will be slower than standard programs because of the JAVA CARD virtual machine main loop modification. The slow down measured by the IRISA in [2] is between 2% and 30%, however the 15% compress rate announced in that article could be profitable although. The next section presents different ways to use macro-packing in the real world, and for each the advantages and disadvantages. 2. Practical impact of the JCVM architecture on bytecode compression The figure 2 shows the actual building line of JAVA CARD programs. Compiling Converting [Proof] Sending Off-card - Cap file Loading [Proof check] Linking Virtual machine On-card Figure 2: Building line of JAVA CARD programs as it is used today The standard JCVM architecture After being compiled by a JAVA compiler, programs have to be converted from the JAVA Class file format to the JAVA CARD Cap file format. A safety proof can be added to the Cap file format [7]. The Cap file is sent to the card and written in EEPROM. Before performing the link step, the card may check the proof to ensure that the program is safe. The linker transforms the Cap file before storing it in EEPROM. The bytecode compression is an additional step. Where and when could it be done? JAVA CARD Virtual Machine.

3 2.2. On-card : embedded analyzer/compressor The macro-packer would be too big, complex and slow to work on a smart card : is the number of instructions in the applet to com- the pattern detection complexity is, press (up to 18500) ; the memory amount needed to compress with an acceptable speed and efficiency is unacceptable in a smart card ; the bytecode analyzer/compressor itself is too big to be stored on a smart card ; the compressor would often write in EEPROM, used as extra RAM, slowing down the process and stressing the EEPROM; after the bytecode analysis and the construction of the set of patterns, the selection of the best subset of patterns has a exponential complexity, simpler algorithms exist but are less efficient. RAM needs and complexity forbid an embedded execution of the analyzer/compressor on a smart card, and even if a practicable implementation is written, its size in ROM would not be recovered by the space saved by the compression External Macro-Packing usage If the bytecode analyzer/compressor is placed... Before the converter, the compressor would compress the Class file. This is not possible because of the converter. We do not write it and it checks the validity of the class file. If we modify the class file, the converter will refuse to work. Before the proof generator, the compressor would compress the Cap file. The proof generator would have to create a proof for a non-standard bytecode. After the proof generator, the embedded proof verifier will not be able to make the link between the proof (giving information on non-compressed bytecode) and the compressed bytecode. Compressing JAVA CARD bytecode off-card involves manifestly some problems. More, compressing an applet off-card breaks the JAVA CARD 2.11 compatibility due to the non standard macro-instructions added inside the bytecode. J. Ernst proposes in [3] a way to produce compact code on a native (non-java) executable file format. It could be a valid way to compress, indeed no macro-instruction is added in the bytecode, instead, subroutines are used. This way, the JAVA CARD 2.11 compatibility is not broken, the verifier can process the proof, and the virtual machine does not have to be modified. But it can not be used on Cap files, because : we do not produce the JAVA compiler. In the case studied by J. Ernst in [3], the compiler produces a highly compressible binary ; usage of JSR and GOTO (JAVA CARD instructions) for the macro-packing is too limited because of the verifier rules (jumps over a method area are forbidden) [10]; 3. Our solution We propose a solution feasible in a tiny embedded system and compliant with the JAVA CARD 2.11 specification. The process is split into 2 steps. The figure 3 shows the building line improved with the compression steps. First, the bytecode analysis is done off-card and information about how to compress is added to the Cap file. So all the complexity, RAM need and slow process are carried out by an off-card powerful device. This analyzer provides binaries in a special form called Compression-Carrying Code, or simply CCC. Second, the compression, the transformation of the bytecode, is done on-card thanks to code annotations received with the Cap file. This way, the Cap file respects the JAVA CARD 2.11 specification. This 2-steps compression process does not modify any other step of the building line.

4 RENPAR 14 / ASF / SYMPA Compiling Converting [Proof] Analyzing Sending Off-card : Cap + compress component Loading [Proof check] Linking Compressing Virtual machine On-card Figure 3: Building line of JAVA CARD programs including the two steps of the compression process. If an applet containing code annotations produced at step 1 is sent to a smart card that does not support the CCC technology, the compress component will be simply ignored and the applet will be loaded as any other JCVM Architecture The analyzer Our analyze step consists in the detection of the repetitive bytecode portions (patterns) in the bytecode of the Cap file. Once all the patterns are found, the 69 most interesting are selected (the JAVA CARD instruction set lets 69 unused instructions [11]). When a good 5 set of patterns is selected, the analyzer creates code annotations : the compress component. These annotations are sent with the applet in a custom component (the Cap file format defines 11 standard components and lets users add 116 additional components, their format is not specified and the user can send anything to the card). The compress component format is designed to be compact to minimize the amount of information to send to the card (in the case of an applet sent to a mobile phone via the GSM 6 network, this custom component have to be little). The Loader/Compressor The compress component is structured to allow an embedded just in time compression : the compression can be done in one pass on the bytecode. Moreover, it is designed to be easily verifiable in order to make the embedded compressor able to ensure the safety of a compressed program. The on-card verifiability of the compress component is mandatory to be consistent with the security policy inherent in smart cards. The following section deals with security in the compression process. When the applet loader has verified the proof, performed the link step and verified the compress component, the embedded compressor can use it to perform the macro-packing. The compression process consists in replacing all the occurrences of every pattern by the corresponding macro-instruction, and in storing every macro in a macroblob, out of the methods body Verification and security Because the compress component is created out of the card by an unknown generator, it is not trusted. The embedded compressor modifies the bytecode in the way specified by the compress component. So it is necessary to ensure that the compressed program is safe. Before the compression, the applet is verified by the smart card, using any technique (for example a proof-check [9]). To ensure that the compressed applet is safe too, we just need to prove that the virtual machine executes exactly the same instructions by when interpreting the compressed applet or the original applet. The verification of the custom component can be performed separately for each pattern occurrence (that are going to be replaced by a macro-instruction). The information given by the compress component on every pattern occurence has to verify some constraints : it must start in the body of a method and end in the body of the same method ; only the first instruction (the first byte) of the bytecode zone can be a label (in this case, the macroinstruction replacing the pattern occurrence will be a label) ; The complexity of finding the optimal set of patterns is exponential, so we use heuristics to find just a good one. Global System for Mobile communications.

5 the pattern occurrence must not contain any control flow breaking instruction (GOTO, SWITCH, INVOKE, JSR... ) ; the pattern occurrence must contain exactly the same bytes as the code zone stored in the macroblob. These checks ensure that the compressed applet s bytecode has exactly the same semantics, which is trusted thanks to the verifier (the proof checker). The embedded compressor/verifier has the same behavior as the proof checker with hostile applets : they are rejected. The embedded compressor/verifier has to know the offset of every label before starting the compression process, in order to be able to verify that a pattern occurrences do not contain any label. More, it has to relocate the bytecode during the compression process. Bytecode portions are shifted whenever a macroinstruction replaces a pattern occurrence, so some branch instructions have to be updated. One pass on the bytecode is necessary to build the label table before starting the compression, unless it is provided by the proof checker, which has built it. That is a technical improvement of the JAVA CARD bytecode, the next section describes a strategy improvement Alternative strategy : global macros Our experiments show that some patterns have a general purpose. We consider them as global macros, because any applet or package can contain these patterns. These patterns contain only simple stack operations like PUSH, DUP, ADD... In these macros, instructions taking in parameter constant pool entries are forbidden because a constant pool entry is local to an applet, whereas global macros are not. Instead of being redefined in every applet sent to the card, these patterns could be hard-coded in the JAVA CARD virtual machine, in assembly language (instead of JAVA) and in ROM (instead of EEPROM). This would make the compressed programs faster than the others, because several iterations of the main loop of the virtual machine are suppressed when executing a macro-instruction. Moreover, the compression process could be fully embedded. Indeed, the repetitive patterns are already known and stored in ROM when an applet is sent to the smart card. This makes the complexity of the pattern detection become in instead of (with the size in bytes of the applet, up to 18500, and the count of macros stored in ROM, up to 69). The macroblob is stored in ROM instead of EEPROM. So we could expect a better compress rate by using global macros than by using standard macros. But the results shows that it is not true, because the patterns are more constrained. Our experiments show that each kind of applet uses a specifical set of macros. To improve the compress rate of this technique, we can benefit from the fact the macros are stored in ROM ( cheap memory). Multiple sets of macros could be stored in ROM, one by kind of applet the smart card may receive. For example, a set of macros could be defined for GSM applets, and another one for banking applets. In this case, the compress component just have to specify which set of patterns the compressor should use. We may mix the technique of global macros with the standard macros to profit by both techniques advantages. 4. Experiments We present here the estimated compress rates obtained with our solution on a benchmark set of applets. We have tested 37 applets, with : 50% of GSM applets, containing less than 1kB of bytecode ; 25% of banking applets, containing from 1kB to 5kB of bytecode ; 25% of applications, containing more than 5kB of bytecode Compress rate The compress rate obtained with standard macro-packing is up to 32%. The compress rate obtained using only the global macros for a faster execution of compressed programs is up to 18%. This rate is measured only on the bytecode, not on the entire Cap File, which contains metadata for describing the applet.

6 4.2. The compress component The compress component, in the basic way we implemented it, represents on the average 30% of the size of the Cap file. It is a basic implementation because we do not use a feature of its structure. So 30% is a maximum and it can be reduced in future implementations. The size of the compress component has an impact on the cost of sending an applet (in the case of an applet sent via the GSM network), on the time necessary to send the applet, and on the time spent by the card to load the applet Impact of macro-packing on the JCVM speed According to the IRISA in [2], using standard macros (as described in section 1.2, page 1), slows down the execution of compressed programs from 2 to 30%. But our solution with the global macros improvement makes the execution of compressed programs faster than the execution of standard programs. In the case of global macros, we expect a speed up of the execution of a macro-instruction of at least 22% (depending on the virtual machine implementation), regarding the execution of a standard instruction. Because the main loop of the virtual machine does not have to be modified (instructions are just added to the interpreter), the speed up is real. Global macros Conclusion In this paper, we have shown a new compression approach to allow backward compatibility in macropacking. The compression process is split into 2 steps. The first one, off-card, analyzes the applet and creates code annotations. The second one, on-card, processes the code annotations and produces the compressed bytecode. Our technique can be integrated in a safe virtual machine. The onboard process checks key rules to ensure the consistency of the compressed bytecode. Finally bytecode compression is possible in tiny devices like smart cards thanks to a distribution of the analysis complexity on an untrusted powerful device. The virtual machine safety does not depend on the analysis process but on the embedded compressor. Bibliography 1. BRADLEY, Q., HORSPOOL, R. N., AND VITEK, J. JAZZ : An efficient compressed format for Java archive files. In IBM Centre for Advanced Studies Conference (CASCON 98) (november 1998), pp CLAUSEN, L. R., SCHULTZ, U. P., CONSEL, C., AND MULLER, G. Java Bytecode Compression Low-End for Embedded Systems. In ACM Transactions on Programming Languages and Systems (TOPLAS 00) Volume 22, No. 3 (may 2000). 3. ERNST, J., EVANS, W., FRASER, C. W., LUCCO, S., AND PROEBSTING, T. A. Code Compression. ACM SIGPLAN 97 Conference on Programming Language Design and Implementation (PLDI) 32, 5 (15-18 June 1997), EVAN, D. R. Compact Java Binaries for Embedded Systems. In Proceedings of the 9 th NRC/IBM Centre for Advanced Studies Conference (CASCON 99) (november 1999), S. A. MacKay and J. H. Johnson., Eds. 5. HORSPOOL, R. N., AND CORLESS, J. Tailored Compression of Java Class Files. Software Practice and Experience 28, 12 (1998), HUFFMAN, D. A. A method for the construction of minimum redundancy codes. Proceedings of the Institute of Electronics and Radio Engineers 40 (1952), NECULA, G. C., AND LEE, P. Safe Kernel Extensions Without Run-Time Checking. In the 2 nd USENIX of Symposium on Operating System Design and Implementation (OSDI 96) (Seattle, Washington, October 1996), USENIX Assoc., pp PUGH, W. Compressing Java Class Files. In ACM SIGPLAN Conference on Programming Language Design and Implementation (PLDI 99) (may ), pp ROSE, E., AND ROSE, K. H. Lightweight Bytecode Verification. In Formal Underpinnings of Java, OOPSLA 98 Workshop (Vancouver, Canada, october 1998). 10. STRK, R. F., AND SCHMID, J. Java bytecode verification is not possible. 11. SUN MICROSYSTEMS. Java Card 2.11 virtual machine specification, may ZIV, J., AND LEMPEL, A. A Universal Algorithm for Sequential Data Compression. IEEE Transactions on Information Theory IT 23, 3 (1977),

Compressing Java Class files

Compressing Java Class files 1999 ACM SIGPLAN Conference on Programming Language Design and Implementation William Pugh Dept. of Computer Science Univ. of Maryland Java Class files Compiled Java source