0

I am working on a Java Card application where our requirement is to keep some static data and balance in the card.

For security I was thinking to make 2 object of OwnerPIN. One object is for terminal authentication (i.e. the terminal needs to send 8 bytes of data to authenticate itself) and the other object is for user authentication (i.e. the user needs to enter a 4 digit PIN to authenticate theirself)

Only if both authentications are successful, we can read the data or update the balance.

Or is there any other advice on how to implement security on card to avoid theft?

Also is there any guideline for choosing proprietary class and instruction bytes during applet development?

Michael Roland
  • 39,663
  • 10
  • 99
  • 206
Arjun
  • 3,491
  • 4
  • 25
  • 47
  • Is there any guideline while choosing proprietary Class and Instruction byte during applet development - I do not understand... Could you explain it in other words? – vojta May 07 '15 at 17:30
  • I mean , can I choose any value for class/INS BYTE like 0xa0 or 0xc0 or 0x44 and so on....????? – Arjun May 07 '15 at 18:47
  • A PIN is intended for knowledge-based authentication. I would not recommend it for terminal authentication, since a simple line sniffer could pose severe problems. Instead use the challenge-response test designed for that purpose. – guidot May 08 '15 at 21:54

1 Answers1

3

For user authentication, the OwnerPIN is certainly one good way to go (there are alternatives ofcourse, but OwnerPIN provides security features (e.g. tearing protection) that you would otherwise have to implement manually).

For terminal authentication, nothing should prevent you from using an approach based on an instance of the OwnerPIN. However, depending on your security requirements, you might want to choose some form of mutual authentication instead of a simple PIN code. If the terminal simply sends a PIN code (especially if it does that in plain text), an attacker could simply intercept that PIN code (while sent to a card) and then use that discovered PIN code to create their own (malicious) terminal.

With regard to class and instruction byte (and especially with regard to standard operations like PIN code verification) I would suggest that you stick to standards. ISO/IEC 7816-4 defines many instructions for such standard operations.

Michael Roland
  • 39,663
  • 10
  • 99
  • 206
  • Actually I need to store data like PAN, NAME in separate command { one command to store PAN, another command for store NAME). Could I choose 0x12 , 0x14 or 0x16 as an INS here. Is there any problem to choose any INS byte for My purpose??? – Arjun May 08 '15 at 06:43
  • For INS you can choose pretty much any value you want. However, as I already wrote above, I would strongly recommend you to read ISO/IEC 7816-4 inorder to understand what standardized formats are already there. There's usually no need to reinvent the wheel. – Michael Roland May 08 '15 at 08:47
  • 4
    INS codes 6x and 9x are invalid due to specifications in ISO 7816-3; they *may* work, but are definitely not recommended for real deployment. – guidot May 08 '15 at 21:49