LC Networks Communication


Security Testing Tool
  • JCworkBench

Product details

Unique in testing Java Card security
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.

Key features
  • Extensive test suites
More than 200 tests are provided covering the JCRE, JCVM, GlobalPlatform, SIM/OTA, implicit and explicit security requirements. 
  • Extensive test flow control
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. 
  • Basic Applet Verification
Automatically verify compatibility of packages against Global Platform mandated guidelines to ensure incompatibilities between packages using by the basic applet does not impact security. 
  • Intelligent on-card testing
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.
  • Extensible and smart
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. 
  • CAP2JCA Reversing
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
Test suites cover Java Card Runtime Environment, Java Card Virtual Machine, Global Platform, OTA and GSM
  • JCRE persistent/temporary entry point objects
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. 
  • Context switches
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. 
  • Atomic updates
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. 
  • GlobalPlatform
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. 
  • Transient memory allocation
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. 
  • Transactions
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. 
  • Remote method invocation
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.