Selecting a field for storage in the secure coprocessor causes the translator to perform the following operations:

The transformations have two consequences on the application. On one hand, the application becomes potentially more difficult to crack. More information about its state and the operations it performs is hidden from a potential cracker. On the other hand, the application takes a performance hit. The coprocessor is slower than the main processor and the communication bus introduces latency when the main processor must retrieve a value from the coprocessor. A good selection must balance these two conflicting consequences. Below are some characteristics of fields that are good candidates for storage in the coprocessor.

A field that has a long lifetime relative to the runtime of the application and that is modified and used several times over this lifetime is a good candidate. The analysis of the values returned by the coprocessor is more difficult if set and get operations are dissociated and performed over a long period.

A field that contains a configuration value or a state variable of the application is a good candidate. Such a field is often assigned constant values that need not be transmitted at runtime. Instead the constants are encoded inside ciphered instructions at recompilation time and the instructions that set the value of the field are completely indistinguishable from other ciphered instructions. The change is not linked to the transmission of a given value to the coprocessor but to the execution of a given branch of the code. The value of such a field is also often used to drive the flow of control of the application. When a conditional branch uses the value of the field in a comparison, the translator relocates the comparison inside the coprocessor and its boolean result is the only information that is returned to the main processor.

A field that triggers the execution of heavy numerical operations in the coprocessor is likely to cause performance problems. However if a computation takes some parameters that can be precomputed from configuration values, these parameters and the code that precomputes them can be relocated in the coprocessor. The precomputed values are then retrieved and used in the heavy computation that is performed by the main processor.

There is no tool yet to evaluate automatically the quality of protection afforded by a given choice of secured fields. One key point must be kept in mind when trying to estimate this quality: The result of all the information hiding performed by the translator is embodied in the streams of values flowing from the coprocessor to the main processor as the application is executed. These streams are the values returned by the calls to the in method of the runtime. There is one stream for each thread of execution making such calls. A given selection of fields can provide a weak protection in two different cases:

In the evaluation version of the Validy SoftNaos translator and virtual coprocessor package, only scalar fields of type byte, short, or int and Java 5 enumerated types can be stored inside the coprocessor. We plan to add support for the following types in the next versions of the tool.

When a field of an enumerated type is stored inside the coprocessor, the value that is actually stored is the ordinal of the enum constant. The ordinal is the integer rank of the constant among all the constants defined for the enum type. If the field is null, a negative integer is stored in place of the ordinal. When an enum field is stored inside the coprocessor, the following operations are performed inside the token:

If the enum is used as the key in a switch statement, the ordinal is retrieved from the coprocessor and used in place of the constant. For operations that require access to the enum constant object itself, such as displaying the string representation of the constant, the ordinal is retrieved and the corresponding enum constant instance is used by the translator.

The current implementation of the translator does not automatically select methods for call protection. The developer must mark methods with the SecureMethod annotation or list them in a separate text file (see option markers).

Because methods are secured in groups (see Section 2.4, “Call protection”), the methods that can be selected must satisfy a few constraints.

A slightly different constraint addresses how (rather than which) method groups should be marked so that all members of the group are identified by the translator. A method should always be marked in the highest^[8] class or interfaces in which it is defined. Consider the following counterexample:

class A {

	public abstract void f();

}

class B extends A {

	@SecureMethod
	public void f() {
	}

}

class C extends A {

	public void f() {
	}

}

If C is processed before or independently from B, C.f will not be treated as secured and the application will fail if C.f is called through a reference to A. The same problem occurs if A is defined as an interface and the extends keywords are replaced by implements keywords.

interface I {

	@SecureMethod
	void f();

}


class A implements I {

	public void f() {
	}

}

class B {

	@SecureMethod
	public void f() {
	}

}

class C extends B implements I {

	public void f() {
	}

}

class D extends A {

	public void f() {
	}

}

Within the constraints exposed above, the only limit to the number of secured method calls is performance degradation. However, secured calls have less impact on performance than secured fields for the following reasons:

The selection of methods one at a time for call protection can be tedious. A call graph builder was developed to simplify the process. This tool computes call graphs starting from entry point methods, checks that the call graph will be linked to the original secured code, and provides the list of methods that have to be secured. This is a standalone tool but its output can be used directly as an input for the translator and the provided Ant tasks allow easy integration.

Using the secure call graph builder has the following advantages over manual selection of methods to secure:

The call graphs computed by the builder are geared to their use for call protection. Compared to complete Java call graphs, they have the following limitations:

The com.validy.technology.annotation package defines three annotation classes, SecureField, SecureMethod, and SecureCallGraph. To use these annotations, you must add the vldy-tech-annot.jar file to your class path. The last annotation is used only by the call graph builder, the translator simply ignores it and removes it from the bytecode it transforms.

The SecureField annotation takes one optional parameter called registerNumber. Instance fields have as many copies as there are objects of the class they belong to. They can only be allocated in the heap of the coprocessor and they are accessed using an offset from the k$this pointer. Static fields on the other hand are unique and can be allocated in one of two ways: in the heap or in a global register. The allocation of static fields in the heap is similar to that of an instance field. A chunk of coprocessor memory is allocated in the class constructor and stored in a static pointer called k$class. This is the default behavior. When a register number is specified, memory is not allocated and the value of the field is stored permanently in the given global register.

Storing a static field in a register has the following advantages:

The characteristics of the coprocessor limit the number of static fields that can be allocated in global registers. The virtual coprocessor has 16 global registers numbered from 32 to 47. With the annotation below, the counter field of class A is allocated to register 40.

class A {

@SecureField(registerNumber=40)
private static int counter = 0;

...

}

The SecureField, SecureMethod, and SecureCallGraph annotations accept an optional boolean parameter called enabled whose default value is true. When this parameter is set to false, it instructs the translator not to secure the given field or method, or to output a list of methods not to secure in the case of the call graph.

The need to annotate an object to avoid protection seems paradoxal since objects that are not annotated at all are not secured. However using markers (see Section 2.5, “Markers”), it is possible to use automated tools to produce lists of fields or methods selected for protection and thus the same object may have several annotations. Adding a disabled annotation is useful when an automatically selected object must not be changed by the translator for a reason not taken into account by the tool. If an object has at least one disabled annotation, the translator will not change it.

For example, if the method g from class A is selected by a tool that automates call protection but must remain unchanged because it is called through reflection in some part of the application, the following annotation makes sure the translator does not apply call protection to it:

class A {

@SecureMethod(enabled=false)
public int g() {
...
}

...

}

This is an alternative method to using annotations and the only possible method for Java 1.4. It can also be used to accept the output of a tool that selects fields or methods automatically for protection.

To mark a field or a method, its containing class or interface name, its name and its signature must be listed on one line separated by spaces. The class name and the signature must follow the form defined in the Java Virtual Machine specification. Lines starting with a + character correspond to enabled annotations while lines starting with a - character correspond to disabled ones. If the + or - character is omitted, + is assumed by default.

Lines starting with a # character are ignored and can be used to add comments.

For example, to produce the same result as the following annotations:

package com.validy.sample;

import com.validy.technology.annotation.*;

public class Test {


	@SecureField
	private int value;


	@SecureMethod
	public final void f(String name);

	@SecureMethod(enabled=false)
	public int g();

}

the following lines should be added to the markers file:

+ com/validy/sample/Test value I
+ com/validy/sample/Test f (Ljava/lang/String;)V
# g is called through reflection in ...
- com/validy/sample/Test g ()I