The document discusses security attacks on Java Card platforms, particularly focusing on logical attacks facilitated by malicious applets and vulnerabilities in secured containers. It outlines various attack methods, such as illegal casting and metadata manipulation, alongside proposed countermeasures and their effectiveness. The conclusions highlight the insufficiency of current security measures against these logical attacks, emphasizing the need for improved defenses.

1. 0/30
Java Card platform attacks
based on malicious applets
Sergei Volokitin

2. 1/30
Outline
• Java Cards
• Java Card platform security
• Logical attacks
• Secured containers attack
– PIN try counters modification
– Retrieval of PINs
– Retrieval of keys
• Countermeasures
• Conclusions

3. 2/30
Java Card
• Java Card is a smart card running Java Card VM
• Very limited resources
– Small processor(often 8-bit)
– 4-8 KB of RAM
– ∼100 KB of flash memory
• Over 2 billion Java cards produced every year

4. 3/30
Java Card platform security
Java Card security mechanisms:
• Bytecode verifier
– Off-card
– On-card
• The Java Card firewall
• The Java Card transaction mechanism
• Secured key and PIN containers

5. 4/30
Java Card firewall

6. 5/30
Attack prerequisites
In this study it was assumed that an attacker can:
• Load applets on a Java Card
– Has the applet management keys
– Can make a third party to install an applet
– Modify behavior of the existing applets using FI
• Install malformed applets
– No on-card bytecode verifier
– Transform applet into a malicious one with a single fault

7. 6/30
Logical attacks
• Logical attacks are much cheaper than physical attacks
• Logical attacks do not require any specialized equipment
• Malformed applets contain code which cannot be legally generated
• Illegal cast byte[] reference to a short[] allows to read twice as
much memory bytes
s t a t i c byte [ ] ba = {0x01 , 0x02 , 0x03 };
s t a t i c short [ ] sa = ( short [ ] ) ptr ( addr ( ba ) ) ;
public s t a t i c short addr ( Object o ) {
return o ;
}
public s t a t i c Object ptr ( short addr ) {
return addr ;
}

8. 7/30
Type confusion
s t a t i c byte [ ] ba = {0x01 , 0x02 , 0x03 };
Figure: Memory representation of the array
• Successful type confusion allows to read n byte followed the
initialized n elements of the array.
• In most cases metadata and code is stored next to each other and
could be corrupted using the type confusion attack.

9. 8/30
State-of-the-art
There are a number of known logical attacks and techniques:
• Illegal casting
• Abuse of transaction mechanism
• Metadata manipulation
• Binary incompatibility
• Stack underflow attack
• AID modification

10. 9/30
Recovering the key of the other applet
Figure: Retrieving the key without any knowledge about internal representation

11. 10/30
Script files
Figure: Script files of benevolent and malicious applets

12. 11/30
Card memory dump (1/3)
Figure: Found DES key of the benevolent applet

13. 12/30
Card memory dump(2/3)
Figure: DES key and byte array

14. 13/30
Card memory dump(3/3)
Figure: DES key and byte array metadata

15. 14/30
Secured containers
Java Card specification defines secured containers:
• DESKey, AESKey, RSAKey, OwnerPIN, etc.
• Key interface methods: setKey(), getKey()
• OwnerPIN methods: update(), check(), getValidatedFlag()
• Internal design of a secured container is not defined in the specs
The only paper pointing out security weaknesses in the implementation
of the secured containers is Chronicle of Java Card death proposes
encryption of the content (published in May 2016).

16. 15/30
OwnerPIN try counter reset (1/2)
• OwnerPIN object is supposed to provide a safe implementation of a
PIN
• Specification does not contain requirements w.r.t. internal
representation of the data structure
Figure: OwnerPIN instance memory representation

17. 16/30
OwnerPIN try counter reset (2/2)
Figure: Brute force attack on OwnerPIN implementation

18. 17/30
DESKey retrieval (1/2)
DESKey class defines methods which allows to store a key in a DESKey
object and return the plain text of the key.
byte getKey ( byte [ ] keyData , short kOff )
Returns the Key data in p l a i n t e x t .
void setKey ( byte [ ] keyData , short kOff )
Sets the Key data .

19. 18/30
DESKey retrieval (2/2)
Figure: DESKey decryption attack

20. 19/30
OwnerPIN retrieval
OwnerPIN has no getPIN() method
Figure: OwnerPIN decryption attack

21. 20/30
Illegal opcodes (1/2)
• JCVMS only specifies opcodes: 0x00 – 0xB8, 0xFE, 0xFF
• An instruction can take zero or more bytecode parameters
• An instruction can take zero or more words from the operand stack
• An instruction can push a word on a stack
CAP file fragment containing the illegal opcode:
0xBF 0x03 0x03 0x03 0x03

22. 21/30
Illegal opcodes (2/2)
Illegal opcode Equivalent instruction
0xBD sload 4
0xBE sload 5
0xBF sload 6
0xC0 sload 7
Table: Corresponding legal instructions to illegal opcodes
One of the illegal bytecodes 0xC5 has almost entirely similar execution
trace as get_static_b apart from one call of a single subroutine.

23. 22/30
Countermeasures
• Indirect memory referencing
• Runtime type checks
• Additional runtime checks
• Shadow stack
• Unconditional jump offset check
• Instruction getstatic() index check
As a result 2 out of 5 cards were not vulnerable to most of the attacks.

24. 23/30
Conclusions (1/2)
• Logical attack scalability is not straightforward
• Implemented countermeasures are not sufficient and sometimes
inconsistent
• The secured containers are not secure against logical attacks
• Encryption of keys does not help against logical attacks
• Physical countermeasures slow down and annoy an attacker a lot
• Logical attacks do not require special equipment, but still could be
costly

25. 24/30
Conclusions (2/2)
Figure: Killed cards

26. Riscure North America
550 Kearny St.
Suite 330
San Francisco, CA 94108
+1 (650) 646 9979
inforequest@riscure.com
Riscure B.V.
Frontier Building, Delftechpark 49
2628 XJ Delft
The Netherlands
Phone: +31 15 251 40 90
www.riscure.com
Contact: Sergei Volokitin
Security Analyst
volokitin@riscure.com
Riscure is hiring!
HRM@riscure.com

27. 26/30
Bonus #0 – Sweep tool
The script iterates over all possible addresses and checks if the pointer is
a valid pointer of a given type.
for ( short i = 0; i < ( short )0 x 7 f f f ; i++) {
Object o b j e c t = ptr ( i ) ;
i f ( o b j e c t instanceof byte [ ] ) {
. . .
}
}

28. 27/30
Bonus #1 – Memory dump using get_static
get_static instruction allows to get static field from class.
private short getMem ()
{
short memVal ;
// JCA code
get_static 0x0000 ;
sstore_0 ;
// JCA code
return memVal ;
}

29. 28/30
Bonus #1 – APDU buffer reference
All global arrays are temporary global array objects. These objects are
owned by the JCRE context, but can be accessed from any context.
However, references to these objects cannot be stored in class
variables, instance variables or array components. The JCRE detects
and restricts attempts to store references to these objects as part of the
firewall functionality to prevent unauthorized re-use.
public static short addr( byte[] ptr ) {
return (short)ptr;
}
public static byte[] ptr( short addr ) {
return null;
}

30. 29/30
Bonus #3 – Cloning applets
Figure: Full memory dump attack

31. 30/30
Bonus #4 – Memory dump
Figure: Full memory dump attack