You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Many APIs use static fields to define predefined values. For example, the class Cipher has the fields ENCRYPT_MODE that allows to call the method init as c.init(Cipher.ENCRYPT_MODE, ...). In reality, this static field just holds the value 1 (here). However, currently CrySL and CryptoAnalysis cannot deal with static fields in general. If we use a call c.init(1, ...), CryptoAnalysis can extract the value 1 and evaluate corresponding constraints. However, it cannot match the field ENCRYPT_MODE to the value 1, resulting in an ImpreciseValueExtractionError because it cannot evaluate the constraints correctly.
Solution: Extend CrySL rules with the functionality to specify static fields. Possible solutions include:
One can define a variable in the OBJECTS section and use it like other variables:
Further issue: When implementing a static field strategy, also consider static fields that define method calls/events. For example, Tink uses static fields to initialize its objects extensively. An example includes the class MGF1ParameterSpec. Here, we can use a constructor with a parameter to initialize an object, but we can also use static fields to do the same:
// Here, we can extract the parameter 'SHA-256' and evaluate corresponding constraintsMGF1ParameterSpecspec1 = newMGF1ParameterSpec("SHA-256");
// Here, we cannot evaluate the constraints because we have no access to the static fieldMGF1ParameterSpecspec2 = MGF1ParameterSpec.SHA256; // MGF1ParameterSpec.SHA256 just resolves to 'new MGF1ParameterSpec("SHA-256")'
Solution: Extend the EVENTS with static field calls. For the example above, this may look like
Many APIs use static fields to define predefined values. For example, the class
Cipher
has the fieldsENCRYPT_MODE
that allows to call the methodinit
asc.init(Cipher.ENCRYPT_MODE, ...)
. In reality, this static field just holds the value1
(here). However, currently CrySL and CryptoAnalysis cannot deal with static fields in general. If we use a callc.init(1, ...)
, CryptoAnalysis can extract the value1
and evaluate corresponding constraints. However, it cannot match the fieldENCRYPT_MODE
to the value1
, resulting in anImpreciseValueExtractionError
because it cannot evaluate the constraints correctly.Solution: Extend CrySL rules with the functionality to specify static fields. Possible solutions include:
OBJECTS
section and use it like other variables:CONSTRAINTS
section, e.g.Further issue: When implementing a static field strategy, also consider static fields that define method calls/events. For example, Tink uses static fields to initialize its objects extensively. An example includes the class
MGF1ParameterSpec
. Here, we can use a constructor with a parameter to initialize an object, but we can also use static fields to do the same:Solution: Extend the
EVENTS
with static field calls. For the example above, this may look likeWhen extending CrySL with these functionalities, a corresponding functionality also has to be added to CryptoAnalysis to extract the static fields
The text was updated successfully, but these errors were encountered: