How To Win Friends and Influence People Through The Magic of Java SmartCard Programming

1
How To Win Friends and Influence People Through
The Magic of Java SmartCard Programming

• Michael Brubaker
• Orlando Java Users Group
• July 31, 2003

2
Hardware

• Smart Card
• Smart Card Reader
• Follows ISO 7816 standards

3
Anatomy of a SmartCard
4
MicroAnatomy of a SmartCard
5
Smart Card Pieces and Parts

• Processor
• Math Co-processor (optional)
• No power
• Memory
• ROM
• EEPROM
• RAM

6
Memory

• ROM Read only from the birth of the card,
  JCRE, applications, native code
• EEPROM Persistent memory, 10 years
• RAM Transient Memory, very expensive, very fast

7
Smart Card Acceptance Devices

• ISO 7816-4
• Terminals
• Have memory, logic, power
• ATMS, gas pumps
• Readers
• Connect to a computer
• USB, serial, parallel port
• Pipeline for data

8
Smart Card Reader

• Brands
• Schlumberger
• Gem Plus
• 2 dozen others
• USB or Serial port
• In Windows, installed via Add/Remove Hardware
• Shows up in Device Manager

9
Software

• JCRE
• JCVM
• SmartCard Applet
• Client Application
• Development Environment

10
JCVM

• Subset of J2SE
• Allows multiple applets, enforces sandbox,
  manages memory
• Loads, initializes and selects applets.
• Typically uses bytes, shorts, objects
• No Strings, ints, floats,
• Optional Garbage Collection
• Applets can be loaded during life of card

11
JCVM File System 4 types

• Transparent
• Linear Fixed
• Linear Variable
• Cyclic 1 through 8

12
Files 3 levels

• MF Master file, similar to root.
• DF Dedicated File,similar to a directory
• EF Element File, actual file which holds data.
• Files referred to with a 8 byte identifier.

13
Smart Card Applet Lifecycle

• Life Cycle
• prepersonalization,
• init,
• select,
• deselect
• Answer to Reset (ATR)
• Message Passing

14
Relationship between Client/Host

• Half duplex communication
• Master-Slave
• Whos who?

• Host master
• Applet slave

15
Client Application

• Most of the heavy lifting and carrying
• Any language
• Uses Application Protocol Data Units (APDUs) to
  interface between client and applet
• Abstracted protocol for passing info to/from card
• Independent of the underlying T1 or T0 protocol

16
APDUs

• Direction - 2 flavors
• Request
• Response
• Extra Data 2 flavors
• Some APDUs have only a command
• Some APDUs have command a data buffer

17
4 permutations of APDUs

• Request
• Without data buffer
• select
• With data buffer
• writeBinary

• Response
• Without data buffer
• verifyPin
• With data buffer
• getChallenge

18
Anatomy of an Command APDU

• CLA INS P1 P2 Lc L Le
• 00 60 0B 0C 00 ((v)) FF
• Minimum of 6 bytes, maximum of ???

19
Anatomy of an Command APDU

• CLA INS P1 P2 Lc L Le
• 00 60 0B 0C 00 ((v)) FF
• CLA determines which applet is being given this
  command.

20
Anatomy of an Command APDU

• CLA INS P1 P2 Lc L Le
• 00 60 0B 0C 00 ((v)) FF
• INS is the Instruction code being applied to the
  applet. Examples
• 60 Select File
• 20 Pin Verify
• 84 Get Challenge

21
Anatomy of an Command APDU

• CLA INS P1 P2 Lc L Le
• 00 60 0B 0C 00 ((v)) FF
• P1 and P2 are parameters sent to the card.
• Can be used as two 1 byte params or one 2 byte
  params.
• Not used with all commands simply 00 00
• Example shows which file to chose, in this case
  0B0C

22
Anatomy of an Command APDU

• CLA INS P1 P2 Lc L Le
• 00 60 0B 0C 00 ((v)) FF
• Lc is the optional data buffer length if
  additional info is needed to be sent with this
  command.

23
Anatomy of an Command APDU

• CLA INS P1 P2 Lc L Le
• 00 60 0B 0C 00 ((v)) FF
• L is the optional data buffer if additional info
  is needed to be sent with this command.
• If Lc is zero, there is no data buffer.

24
Anatomy of an Command APDU

• CLA INS P1 P2 Lc L Le
• 00 60 0B 0C 00 ((v)) FF
• Le is the expected length of the return data
  buffer in the response APDU.
• Card may need to handle this (throw exception or
  otherwise) if not enough space is requested.

25
Anatomy of an Response APDU

• ((d)) SW1 SW2
• ((v)) 90 00
• The first field is the variable length data
  buffer being returned.
• How does the client know how long it is?

26
Anatomy of an Response APDU

• ((d)) SW1 SW2
• ((v)) 90 00
• The next two bytes indicate a status word
  indicating a success/error code.

27
Example Get ChallengeCommand

• CLA 80
• INS 84
• P1 00
• P2 00
• Lc 00
• Le 08
• 80 84 00 00 00 08

0x80 0x84 - getChallenge Not used Not used Not
used 0x08 8 bytes expected in return buffer
28
Examples Get ChallengeResponse

• Data 0011223344556677
• SW1 90
• SW2 00
• 0011223344556677 90 00

Hex data being returned Status Word1 90 Status
Word2 00 9000 success, normal completion
29
Examples PIN VerifyCommand

• CLA 80
• INS 20
• P1 00
• P2 00
• Lc 03
• L 010203
• Le 00
• 80 20 00 00 03 010203 00

30
Examples PIN VerifyResponse

• Data (nothing)
• SW1 90
• SW2 00
• Some possible Status Words
• 9000 normal termination, acceptance, success
• 67LL wrong length data buffer to return (Le)
• 6581 memory failure
• 6985 conditions not satisfied

31
All right! Finally some code!!

• import javacard.framework.
• import ISO7816.
• public class WalletApplet extends Applet
• final static byte WalletCLA (byte) 0xB0
• final static short SW_INVALID_TRANS_AMT
• 0x6A83
• OwnerPIN pin
• short balance

32
The constructor

• private WalletApp ( byte bArray, short
  bOffset, byte bLength)
• pin.update(bArray, bOffset, bLength)
• balance 0
• register()
• //register gets a unique number from the JCRE,
  similar to a filetable registry.

33
install

• public static void install(byte bArray, short
  bOffset, byte bLength)
• new WalletApp(bArray, bOffset, bLength)
• // install is only called once when the applet is
  initially loaded on the card
• // should claim all persistent memory it will
  need now

34
select

• public boolean select()
• if (pin.getTriesRemaining() 0)
• return false
• return true

35
deselect

• public void deselect()
• pin.reset()

36
process

• public void process(APDU apdu)
• byte buffer apdu.getBuffer()
• if (selectingApplet()) return
• if (bufferISO7816.OFFSET_CLA ! Wallet_CLA)
• ISOException.throwIt(
• ISO7816.SW_CLA_NOT_SUPPORTED)

37
process contd

• switch (bufferISO7816.OFFSET_INS)
• case GET_BALANCE getBalance(apdu)
• case DEBIT debit(apdu)
• case CREDIT credit(apdu)
• case VERIFY verify(apdu)
• default ISOException.throwIt(
• SW_INS_NOT_SUPPORTED)

38
getBalance

• public APDU getBalance(APDU apdu)
• // typically would re-use the same apdu to save
  memory
• // put balance into SW1, SW2
• return apdu

39
Now lets analyze Hello World!

• On the host side
• Select a file
• Convert a String to a byte array
• Build an APDU that uses INS writeBinary, with
  optional data of the new byte array.
• Send the APDU to the card.
• Wait for a response
• (contd)

40
Hello World! host - contd

• 6. Select the file (if not still selected.)
• 7. Construct another APDU with the INS for
  readBinary.
• Send the APDU
• Wait for the Response.
• Cull out the optional data.
• Decode and display to screen.

41
Bibliography

• http//java.sun.com/products/javacard/
• http//java.sun.com/products/javacard/documentatio
  n/
• Java Card Techniques for Smart Cards, Chen,
  Zhiqun, Addison Wesley, 2000
• (unwitting supplier of code)
• http//www.iis.ee.ic.ac.uk/
• (unwitting supplier of images)