Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Атаки на платформу Java Card с использованием вредоносных апплетов

369 views

Published on

Докладчик расскажет об атаках на защищенные контейнеры смарт-карт на базе Java, позволяющих злоумышленнику украсть криптографические ключи и PIN-коды других установленных на карте апплетов.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Атаки на платформу Java Card с использованием вредоносных апплетов

  1. 1. 0/30 Java Card platform attacks based on malicious applets Sergei Volokitin
  2. 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. 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. 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. 5. 4/30 Java Card firewall
  6. 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. 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. 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. 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. 10. 9/30 Recovering the key of the other applet Figure: Retrieving the key without any knowledge about internal representation
  11. 11. 10/30 Script files Figure: Script files of benevolent and malicious applets
  12. 12. 11/30 Card memory dump (1/3) Figure: Found DES key of the benevolent applet
  13. 13. 12/30 Card memory dump(2/3) Figure: DES key and byte array
  14. 14. 13/30 Card memory dump(3/3) Figure: DES key and byte array metadata
  15. 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. 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. 17. 16/30 OwnerPIN try counter reset (2/2) Figure: Brute force attack on OwnerPIN implementation
  18. 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. 19. 18/30 DESKey retrieval (2/2) Figure: DESKey decryption attack
  20. 20. 19/30 OwnerPIN retrieval OwnerPIN has no getPIN() method Figure: OwnerPIN decryption attack
  21. 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. 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. 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. 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. 25. 24/30 Conclusions (2/2) Figure: Killed cards
  26. 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. 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. 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. 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. 30. 29/30 Bonus #3 – Cloning applets Figure: Full memory dump attack
  31. 31. 30/30 Bonus #4 – Memory dump Figure: Full memory dump attack

×