JavaCard's algorithms support test

1. Provides list of supported algorithms from JavaCard API including supported lengths of keys
2. Provides information about available RAM and EEPROM memory and garbage collection capabilities
3. Provides basic speed tests for selected operations
4. Test possibility for using raw RSA for fast modular multiplication (usable to implement Diffie-Hellman for example)

    try {
      m_cipher = Cipher.getInstance(ALG_DES_CBC_NOPAD, false);
      // If this line is reached, than DES in CBC mode with no padding (ALG_DES_CBC_NOPAD) is supported.
      supported = true;
    }
    catch (CryptoException e) {
      if (e.getReason() == CryptoException.NO_SUCH_ALGORITHM)) {
        // algorithm is not supported
        supported = false;
      }
      else {
        // other error occured
      }
    }

1. Download prepared version or compile your own modification of AlgTest applet - Download and try compiled and converted applet *.cap from prepared AlgTest suite. If you are unable to upload the package to card or install it, then see Caveats, comment out unsupported classes and compile your own limited version of AlgTest applet (see for step-by-step JavaCard compile & convert instructions).
2. Upload AlgTest package to your smart card and install it - Use uploader supplied by your card vendor (e.g., GPShell, Martin Paljak's GlobalPlatform tool, Gemplus RADIII, IBM JCOP or Cyberflex Access Toolkit). Package AID: 6D 79 70 61 63 6B 61 67 31, Applet AID: 6D 79 70 61 63 30 30 30 31. No special installation parameters are given/required.
3. Run application AlgTestJClient.jar - Choose the target reader for card with uploaded AlgTest applet and let it run. CSV file with values separated by the semicolon is created (AlgTest_ATR.csv).

• javacard.security.Signature - all types
• javacard.security.KeyBuilder - all key types and key lengths
• javacard.security.KeyPair - on-card generation test for all key types and key lengths. Note, that generation of key pair may is time expensive operation (up to minute or more), so be patient. A time necessary for generation is measured, but this may differe significantly between repeated runs, so do your own multiple tests, if you are interested in average time (we are generating only ones).
• javacard.security.MessageDigest - all types
• javacard.security.RandomData - all types
• javacard.security.KeyAgreement - all types
• javacard.security.Checksum - all types
• javacard.framework.JCSystem - selected methods
• javacardx.apdu.ExtendedLength - manual compilation of source codes required at the moment

• Missing support for the whole class (e.g., javacard.security.KeyAgreement) - The test is examining all defined constants of algorithm type and possible key length for given class and return wheter is given algorithm or key length supported or not. Your card must be able to create instance of particular class for this to work. If your card do not support particular JavaCard class as a whole, you will probably not be able to upload and install pre-prepared converted packages as the on-card verifier will detects wrong reference. Then comment out test code in TestSupportedModes() for particular class and then compile and convert new version of AlgTest applet (converter should warn you about all unsupported classes you are linking from code). Commonly, following classes may not be supported: javacard.security.KeyAgreement, javacard.security.Checksum
• Limited memory/garbage collection of particular smart card - An allocation of objects during the test may lead to memory exhaustion, if the smart card do not support automatic garbage collection (often). Further allocation then fail even when the particular algorithm is supported. Try to re-install AlgTest applet if the test execution fail, allocated objects are often freed when applet is removed and installed again.
• Smart card must support exception handling - Not an issue on newer cards, but may be missing on older ones (e.g., Gemplus GXP211_PK). The exception handling (try/catch construct) is necessary to correctly process allocation of instance of unsupported algorithms. If you have card without exception handling, you must try to create instance inside your code one by one and check whether it is possible.
• Smart card should have reasonable memory size or garbage collector - We are allocating several instances of algorithm one by one and memory can be exhausted before the last object is allocated. Typical behaviour resulting from missing garbage collection is failed allocation of supported algorithms in second run of AlgTestClient.exe application, even when previous run successfully allocated algorithm object. Gemalto (Gemplus) cards work usually without any problem, but separate compilation of selected parts of AlgTest applet are necessary for cards like NXP JCOP4.1 or Cyberflex Palmera V5 (typically in KeyBuilder part - card is not able to support 20+ key objects without memory deallocation). If you encounter this issue, comment out most of the testing code, run only for small uncommented part, then comment it again and uncomment other part - inconvenient, but working.