Javacard: error on static array initialization in package build with ant-javacard

Question

I have the following toy code for a library package with a static array:

package testapplets.library;
import javacard.security.RandomData;

public class SomeLibrary {
    public static final short TRUE = (short) 0x5AA5;
    public static final short FALSE = (short) 0xA55A;

    public static final byte[] test = { 'a', 'b', 'c'};

    public static short booleantest(boolean b) {
            return b ? TRUE : FALSE;
    }

    public static RandomData getRandom() {
        return RandomData.getInstance(RandomData.ALG_SECURE_RANDOM);
    }
}

and the following ant task to build the library package:

  <target name="libtest" depends="prepare">
    <javacard jckit="${converter.sdk}">
      <cap targetsdk="${target.sdk}" sources="src/library" package="testapplets.library" aid="11:22:33:44:55" export="lib" output="build/libtest.cap" version="1.0"/>
    </javacard>
  </target>

but I am getting the following error message:

  [convert] [ INFO: ] Converter [v3.1.0]
  [convert] [ INFO: ]     Copyright (c) 1998, 2019, Oracle and/or its affiliates. All rights reserved.
  [convert]     
  [convert]     
  [convert] [ INFO: ] conversion completed with 1 errors and 0 warnings.
  [convert] error:  Static array initialization in class testapplets/library/SomeLibrary in library package not allowed.

Why is static array in a library problematic? builds fine if I remove the static array

Answer 1

If I remember correctly using new in field initialization is forbidden in Java Card. You either have to perform the new from within the static install method (or a method called from install) or you can mark the field private, in which case the array is stored in the constant pool. I would strongly recommend the latter. Basically, no static code execution is allowed.

Using TRUE and FALSE as public static fields is not a good idea either, as they would be reference lookups, which is vulnerable to timing oracles. The whole idea of having TRUE and FALSE defined this way is to protect against such oracles as well as fault injection; I suggest to make them private.