Java Card 101 - Black Hat USA 2003 by jcc96858

VIEWS: 0 PAGES: 34

									Java Card 101 - Black Hat USA
                         2003
                            Bruce Potter
                    bpotter@cigital.com
              Senior Security Consultant
                             Cigital, Inc.
              Who Am I and Why Care About this Talk?
 3 years of Java Card security experience
 Other security foo
 Senior Security Consultant at Cigital
 Founder of The Shmoo Group


 Smart cards gaining traction… finally.
    Post 9/11 security concerns
    US Gov’t deploying 11k smart cards a day
    Java card puts smart card tech within reach
 Last talk before heavy drinking
    Hopefully a good segue
    Broad coverage of Smart Cards security and Java Card
      Technology



May 1, 2010                                                 2
                                            What is a Smart Card
      Originally, there were mag stripes cards
         Predefined card shape, strength, etc
         Information encoded on a magnetic stripe on card
             You’ve seen a credit card, right?
         Easily copied
         Data is static


      Physical and electronic characteristics defined by ISO7816
         Same form factor as mag stripe
         Now, “punch outs” for phone like applications
      Many other specifications.. EMV talks about financial trans
      Integrated Circuit Card (embedded microprocessor)
         Not a memory card!


May 1, 2010                                                          3
                                          What is a Smart Card
      Receives clock and power from external source
         Never trust your environment
      Contact and contact-less
      Three types of memory
         ROM (64KB-ish)
         EEPROM (32KB-ish)
         RAM (8KB-ish)
      Used to be much less memory
         But we’ll never need more than 640KB




May 1, 2010                                                  4
                             Talking to a Smart Card - Entities
      Terminal
         Contains off-card application
         Card is useless without something to interact with it
      Reader
         Physically interface with card
         “smart” and “dumb” readers
         Sometimes contained within the terminal
      Card
         Surprise!


      Application Creator
      Card Issuer


May 1, 2010                                                       5
                                             Uses of Smart Cards
      Stored Value
         It’s money in there, ma…
      Wallet Applet
         Cuz carrying your regular wallet is hard
      Loyalty Applications
         Keeping track of your airline miles
      Identity
      Access Control
      Secure storage

      All of the above?



May 1, 2010                                                    6
                 Talking to a Smart Card - Conversation
      Command - Response based
         I ask, you tell… no independent thought
      Application Protocol Data Unit (APDU)
         Basic building block of a conversation
         ISO 7816-4
         There’s lower level (encoding) specs too…
             T=0 - byte oriented (real simple)
             T=1 - block oriented (no so simple)
      Answer to Reset (ATR)
         On power-on, card tells about protocol and other low-level
          comms parameters



May 1, 2010                                                            7
                                                       Command APDU
      CLA - Class of the APDU
      INS - Particular instruction within the class
      P1, P2 - Parameters (case 1 ends here)

      Lc - # of bytes of data (case 3 and case 4)
      Data - as you would expect
      Le - # of byes expected (case 2 and 4)




May 1, 2010                                                       8
                                                  Response APDU
      Data - Sent if Le was set in command APDU
      SW - Status word. Like an exit code, but with more info (2
       bytes)




May 1, 2010                                                         9
                                Attacks Against Smart Cards
      First off… just because you use smart cards doesn’t make you
       secure
         Just like using SSL, etc…
      Glitching
         Pulling power at appropriate times
         Under/over clocking
         Under/over volting
      Differential power analysis
         Kocher et al - http://www.cryptography.com/
         Watching the power draw over repeated cryptographic
           operations
         Performing differential cryptanalysis



May 1, 2010                                                           10
                                 Attacks Against Smart Cards
      Ross Andersen’s work - http://www.cl.cam.ac.uk/users/rja14/
         Low budget but sophisticated attacks
         Inducing errors with a lightbulb!
         Using laser cutters and microprobes to change data within
          card
      Shaving the ICC
         Yes Virginia, there are physical changes to registers
         Able to see 1’s and 0’s in memory


      Vendor Response?
         Make ICC’s more complicated
         Multi-dimensional tangle of circuits
         Still, with time and tools, ICC can be mapped
         Difficult to interact with ICC

May 1, 2010                                                           11
                  Attacks Against Smart Cards Systems
      The card may not be the weak point

      Reverse-engineering *gasp* really lame protocols
         Watch yourself…. DMCA is being used as a hammer


      By-passing smart card system
         Some systems use mag-stripes as backups
         Much easier to dupilicate




May 1, 2010                                                 12
                                                         Java Card
    So, you still want to deploy them?

    Back in the day, cards were made from a mask that contained
     the program
       Cards were single vendor and fixed applications
       Application mistake in the mask meant reissuance
    More advanced operating systems now allow for applications
     to be added post-fabrication
       Lots can be done with multi-application, dynamic cards
    Sounds like a good place for Java, eh?

    A really, really, really stripped down version of Java
       Applets need to be compiled to a few KB of bytecode
       Smaller than J2ME

May 1, 2010                                                        13
               New uses for Smart Cards Thanks to JC
      Smaller, custom deployments for Access Control and
       Identification
      Cheaper, large scale deployments
         Buy a vendors Java Card implementation
         All you need to do is write some card code, terminal code,
          and backend code

      Spoofing for other Smart Card systems
         If you know the APDU’s and transaction structure for
          another system (say stored value), write an applet to
          subvert terminal
         Nice hacking too, eh?




May 1, 2010                                                            14
                                                       Java Card API
      Java.lang - a subset of the java language
         Objects
             No double, long, chars
         Exceptions
      Javacard.framework - classes for the core functionality of an
       applet
         APDU
         PIN
         JCSystem
      Javacard.security - Security Classes
         Keys
         Random Data
      Javacardx.crypto - mad crypto foo


May 1, 2010                                                            15
                                   Java Card Virtual Machine
      Actually split into two parts
         Off card Converter (yes.. Part of the VM is off card)
            Performs security checks
            Creates optimized bytecode
            Initializes static variables
            Creates class datastructures
            Final Result: CAP file… like a shrunken JAR file
         On card installer
         On card interpreter
            For execution, bytecode is interpreted by on-card VM
            Handles memory allocation and very limited garbage
              collection


May 1, 2010                                                         16
              Java Card Virtual Machine




May 1, 2010                           17
                           Java Card Runtime Environment
      Think of it as “the OS”
      Lifetime of JCRE is lifetime of card
         A bit non-intuitive… unlike Java on a PC
         Instantiation of an applet usually only happens once
         Applet and Runtime remain between card resets
      Subset of the JRE
         Focused on things that matter to card in hostile
           environment
         Protects applets from each other and the world




May 1, 2010                                                      18
                            Java Card Runtime Environment
      Command Processing
         APDU dispatch to the applet’s process() method
      Handling of Transient objects
         Allows objects to be created and used in RAM for security
          and performance
      Transactions and atomicity
         Any single field write is made atomic by JCRE
         Futher, JCRE provides for safety within transactions
          boundaries
         Interrupting a transaction can be profitable if not properly
          handled




May 1, 2010                                                              19
                            Java Card Runtime Environment
      Applet isolation via applet firewall
         Unlike standard java, applets cannot invoke other applet’s
          methods
         Each applet in a package (basically a CAP file in JC case)
          runs in its own context
         Applet firewall forces applets to explicitly share interfaces to
          allow external access
      Exception Handling
         Key for a safe and secure application, card, and system




May 1, 2010                                                                  20
                            Java Card Security Architecture
      Type-safety
      Most important verification done off-card
         Byte code verified during compile
         Checks for language violation
             No bad datatypes, no threatds
      Once code on the card, most of the checks are runtime issues
         During the interim period, code (and ergo the cards,
          ultimately) are vulnerable
      Malicious bytecode a real problem
         Needs extra juice


      Applet firewall prevents silliness
         If properly implemented, remarkably effective



May 1, 2010                                                           21
                                                    Controlling Code
      So… it’s good that anyone can load an applet, right?
         Situation: Credit Card Vendor gives you a smart card which
          allows post-issuance applet loading
             Wallet applet
             Loyalty program
         Attack: Malicious applet loaded on card to attack other
          applets
         Attack: Malicious terminal terminates wallet applet
         Attack: Legit terminal tries to load code on card… code
          changed in transit
      Need a higher level controls to limit post-issuance code loading
      Also, due to off card validation, need some code signing
       mechanism to verify that code can be trusted

May 1, 2010                                                               22
                                                    Controlling Code
      Enter Global Platform (from Visa originally)
         APDU MAC’ing
         Cryptographically signed CAP file
         Authentication process for loading and installing code
         If multi-application, multi-vendor smart cards ever take off
          in the consumer financial industry.. They’ll use GP




May 1, 2010                                                              23
                                             Issuing Smart Cards
      Pre-issuance - card assumed physically secure
      Post-issuance - Wild Wild West
         Card needs to protect itself
         No native methods may be declared
             Direct interaction with ICC would compromise all Java
              card security - no verification mechanism




May 1, 2010                                                           24
                                                    Important Methods
      Skipping a complete sample applet…
      install()
         Called when card installer wants to install a new Applet
         Instantiates applet (basically like regular Java)
        public static void install ( byte[] bArray, short bOffset, byte
           bLength) {
             new myApplet(null);
         }

         Note: myApplet must call register() so the JCRE knows the
           new applet has been instantiated



May 1, 2010                                                               25
                                                Important Methods
      select()
         When an off card entity wants to use an applet, it must be
           selected first
         Upon reception of SELECT APDU, JCRE calls applets
           select() method
         Applet verifies it is selectable and gets ready to receive
           more commands
      deselect()
         When another applet is selected, previous JCRE calls
           deselect() on previous applet first
         JCRE will not allow previous applet to block and stop
           deselection
             No DoS for you!


May 1, 2010                                                            26
                                              Important Methods
      process()
         The real meat of the thing
         When an APDU is received and the applet is selected, its
          process method is called by the JCRE and the passes it an
          APDU object.
         Now you can parse the APDU, do what you need to do with
          it and then respond.




May 1, 2010                                                           27
                                         Example Execution
# power on card and select AID 1 2 3 4 5 6 7 8
poweron: card turned on; connection establish
sendraw: transmitting (raw) (13): 0x80 0x50 0x00 0x00 0x08 0x01
 0x02 0x03 0x04 0x05 0x06 0x07 0x08
sendraw: receiving: (2): 0x61 0x1c
# there are 27 bytes of data to get. Get them.
sendraw: transmitting (raw) (5): 0x00 0xc0 0x00 0x00 0x1c
sendraw: receiving: (30): 0x00 0x00 0x02 0x80 0x00 0x00 0x29
   0x31 0x00 0xa7 0x0d 0x01 0x59 0x11 0xfe 0x51 0x49 0x45
   0x4e 0x09 0x19 0x35 0xec 0x2c 0x5a 0x8e 0xe0 0xb4 0x90
   0x00




May 1, 2010                                                       28
                                    Secure Coding Guidelines
      A bad applet can destroy the system
      Use some manner of code signing… home brewed or
       otherwise
         Barring that, verify chain of custody of code before
          installing
      Velocity Checking
         Note: Not like typical Velocity checking
             On a smart card, time has no meaning
         Any sensitive activity should only be allowed a reasonable
          number of times… then lock/terminate
             Don’t forget harvesting “random” data
      Only share what you need to
         Watch out for transitivity issues with Shared Interface
          Objects
May 1, 2010                                                            29
                                    Secure Coding Guidelines
      Proper exception handling
         Hacking a smart card may rely on making bad things
          happen
         Detect, throw, protect
      Use transient data where needed. Use transactions where
       needed
         When updating sensitive information, wrap in a transaction
          boundary
         Check commit capacity first
         JCSystem.beginTransaction();
         JCSystem.endTransaction();
         Don’t forget to abortTransaction() if things go wrong




May 1, 2010                                                            30
                                     Secure Coding Guidelines
      Remember things are smaller on smart cards
         Int may not be supported
         Keep your code tight
      When designing your protocol… think like an attacker
         Both terminal and card can be forged
             How does a fake terminal effect the card
             Vice-versa
         A simple Command-ACK protocol will likely be subverted
         Cryptographically sign sensitive operations
         Lots of prior art here
             See resent Blackboard ID hack
             http://features.slashdot.org/article.pl?sid=03/04/14/1846
              250
May 1, 2010                                                               31
                                                          Extra bits
      MUSCLE Project
         Movement for Use of Smart Cards in Linux Environments
         www.linuxnet.com
         PC/SC Daemon
         Lots of reader drivers
      Sun’s stuff
         http://java.sun.com/products/javacard/
         “Java Card Technology for Smart Cards” - Zhiqun Chen




May 1, 2010                                                        32
                                                     Card Vendors
      Oberthur - http://www.oberthurcs.com/
      Gemplus - http://www.gemplus.com/
         Low priced development kits with reader/cards
      Schlumberger - http://www.smartcards.net
         $50 readers / $12 a card
         Cards with USB logic imbedded in card




May 1, 2010                                                     33
                         Questions?
      Buy some books!




May 1, 2010                       34

								
To top