How do you communicate with the chip ?
- Via a bi-directional serial interface
- Using T=0/T=1 (or T=CL) protocol
- Card contacts pinout:
- Only Vcc, I/O, RST, CLK & GND used
- Or just install the right packages & USB reader...
Basically, you send data to the card, it replies (or not).
Steps to communicate with the card.
- Establish protocol parameters, a.k.a obtain ATR (Answer To Reset), depends on tooling & reader.
- Send commands to the card, called APDU (Application Protocol Data Unit)
- Receive data & response code, called SW (Status Words)
APDU format (XX denotes 1 Byte in Hex)
- CLA: Class of the command "generally" '00' for industry-standard command and '80' for proprietary commands (could differ).
- INS: The instruction of the command : The actual instruction that the card will act upon (i.e. what to do).
- P1/P2: The First/Second Parameter : The parameters for the Instruction whenever it needs one (or '00' otherwise).
- Lc: The length of the Data that follows.
- Data: The Data to send to the card (also in hex), optional and not needed if Lc='00'.
Except for the Data, all those bytes are mandatory.
SW format (XX denotes 1 Byte in Hex)
- SUCCESS: 9000
- ERROR: 6XXX (Could be '6985', '6601', etc.) different code = different error.
- Special Case: 61XX, more bytes await in reply, send "GET RESPONSE" to card to have them.
Example using SELECT command.
One last advice... (a.k.a I was lazy)
You have to be very careful of the return of the SELECT command, some cards might return 9000 for any SELECT command even if the selected context does not exist.
You would only be able to know you've selected the right context by looking at the returned value from SELECT or by sending other commands to the application and see if they work.