JCworkBench 3.0 incorporates new test scenarios marked relevant by payment schemes and it implements tests to verify compliance with the Basic Applet Security Guidelines from Global Platform. Discover the new features:
1. Global Platform Basic Applet verification
Java Cards are designed to host multiple applications which are provided in binary CAP files, containing library code or applets. The owner of a sensitive application (e.g. payment application) requires assurance that other applications on the card, referred to as basic applets by Global Platform, are not harmful. This can be achieved by verifying that basic applications behave well, but also that platforms are robust against undesired behavior of applets.
The Global Platform organisation has defined a set Security Guidelines for Basic Applications. JCworkBench 3.0 implements these guidelines in an automatic manner. A user receives a quick and clear report on the compliance of a CAP file with these rules. This way card issuers, test labs and application providers can verify that a binary CAP file does not exhibit harmful behavior and complies with the GP Security Guidelines.
2. Applet reverse engineering
When JCworkBench detects suspicious code inside an applet CAP file, it now offers the possibility to disassemble the binary code into human readable code by using the standard JCA format. The user can review the disassembled code to verify if weaknesses are exploitable. JCworkBench is unique in this powerful feature. For a detailed description refer to our white paper: Basic Applet Verification White Paper
3. Compatibility test suite
An additional risk arises when incompatible applets interact on a Java Card. JCworkBench 3.0 includes a new Compatibility test suite that challenges platform resistance against these potentially harmful interactions. This test suite includes 23 test scenarios looking at version conflicts, signature conflicts between applets and libraries as well as inter-applet, and cross-applet reference management in case of applet deletion. Issues arising from these test scenarios are a risk for sensitive applets. Platform vendors and test labs use this test suite during product development and certification.
JCworkBench includes a flexible architecture and intuitive IDE to develop applets and run them on the Java Card under test. The strength of this tool resides in the extensive suite of detailed security test applets supplied in the package. The test applets can directly be run on and against a Java Card to identify security vulnerabilities. Running this security test suite may reveal security problems on a Java Card which has not been tested before with these security tests. The security test suites are also used by Riscure to certify the security of the operating systems of EMV cards and 3G Java SIM cards for large international mobile operators.
JCworkBench comes with software, test suites and hardware to support power down and card tearing operations. The software is familiar to Java software developers and extendible, our test suites are extensive and easy to perform on the device under test With our service contract we provide updates and support from our experienced security testing team. User training to get you and your colleagues started with the tool is optional. We are able to provide consultancy service in case you would like assistance with developing test for your card or develop new attack scenarios, for example, based on proprietary requirements.
JCworkBench helps you find critical security bugs.
JCworkBench helps you find critical security bugs.
More than 200 tests are provided covering the JCRE, JCVM, GlobalPlatform, SIM/OTA, implicit and explicit security requirements.
Tests control their own test flow and report back to the test engine. The test engine itself is then able to control the test or perform actions off-card. This way we can perform operations such as power down or card tearing.
Automatically verify compatibility of packages against Global Platform mandated guidelines to ensure incompatibilities between packages using by the basic applet does not impact security.
Applets that define a test are automatically loaded and executed onto the Java Card to test the operating systems’ interfaces and this way to expose a vulnerability or risk.
JCworkBench integrates all tools necessary for a test or applet developer. Automatically, the security tester or developer is provided with an extensible, pluggable platform to make things even easier.
Convert a binary CAP file into human readable assembly code. On top of the Global Platform guidelines, some schemes require manual inspection of the code by reverse engineering steps.
Test suites cover Java Card Runtime Environment, Java Card Virtual Machine, Global Platform, OTA and GSM
Entry point (EP) objects allows an applet to perform privileged operations by performing a context switch. Persistent EP objects such as AID instances may be stored permanently, but temporary EP objects such as the APDU buffer may not be stored locally.
Applets might switch execution context when calling methods of JCRE objects, static methods in the JC API or methods through the shareable interface. It is necessary for the JCRE to properly restore contexts when the call returns.
The power cycles of JCVMs are short and may be interrupted at any time. To prevent memory corruption all persistent assignments, regardless of the transaction mechanism, are atomic. When atomic updating is not implemented properly, the memory content of the card can be corrupted.
The Global Platform test suite contains about 40 tests that verify the security of the Global Platform mechanism of a Java Card. The suites covers SecureChannel protocols, card/ application life cycle changes and PIN mechanism.
This type of memory is allocated in RAM and must be nullified on reset or deselect of the applet. Transient memory is typically used to store session data and is much faster than persistent memory due to the physical characteristics. Operations on transient memory need not be captured by the transaction mechanism, but special care must be taken to avoid dangling references.
Applets in the same package run in the same context and cannot access applet objects outside their own package unless the object is acquired through the Shareable interface mechanism offered by the JCRE. Accessing the objects must be checked by the firewall rules.
To abstract from the APDU layer, a remote method invocation mechanism is offered by the JCRE. Methods are identified only by the first 2 bytes of the SHA1 hash of its method descriptor, leaving room for collisions.
Please call +31 (0) 15251 4090 or send us an email
When purchasing JCworkBench, customers receive a permanent license to use the tool. Under the service contract, the software of the tool is maintained, and users can use our online helpdesk for support questions.