jay-to-the-dee / javaemvreader Goto Github PK

What steps will reproduce the problem?
1. Access a card with PDOL
2. EMVTerminalProfile does not contains the expected settings
3. GET PROCESSING OPTIONS command fails

What is the expected output? What do you see instead?
It would be great to set the terminal profile using ressource files (as AID or 
ATR). 
Would need to change the static declarations of EMVTerminalProfile. 


What version of the product are you using? On what operating system?
Last one

Please provide any additional information below.

The app processing loop in start() currently terminates if one of the apps 
throws an exception, and thus the rest are not processed. It should skip the 
failed app and continue. See attached patch. 

javaemvreader 0.5.2

(see patch file attached)

I use this library with oracle java-7, and always get response hex "67 00".

The problem seems to be the missing Le-Field in the APDU, so for example 
instead of

[Step 3] SELECT FILE Master File by identifier (if available)
---------------------------------------------------------------------
00 A4 00 00 02 3F 00

it should be sent

[Step 3] SELECT FILE Master File by identifier (if available)
---------------------------------------------------------------------
00 A4 00 00 02 3F 00 00

which results in correct "90 00" response

Descriptions for "Signature (paper)" and "No CVM required" are incorrect.

See attached patch.

There is a typo in parseFCIDD() that causes an exception while walking the TLV. 
Additionally, even when parsing is successful, the application is not added to 
the card. See attached patch for details. 

For some cards (for example, Maestro issued in the Netherlands), the INTERNAL 
AUTHENTICATE command fails (with code "69 85 - Command not allowed; conditions 
of use not satisfied") if not issued immediatly after READ RECORD(s).

To solve the problem, the Offline Data Authentication step must be executed 
immediatly after Read Application Data and before any other methods such as GET 
DATA.

I have attached a patch that reverses the order of INTERNAL AUTHENTICATE and 
GET DATA in the Explorer class.

When I send first generate command to ICC using CDOL1
I get status word 6985. has anyone get same problem?
------------------------------------------------------
 Card Risk Management Data Object List 1
    Amount, Authorised (Numeric) (6 bytes)
    Amount, Other (Numeric) (6 bytes)
    Terminal Country Code (2 bytes)
    Terminal Verification Results (TVR) (5 bytes)
    Transaction Currency Code (2 bytes)
    Transaction Date (3 bytes)
    Transaction Type (1 byte)
    Unpredictable Number (4 bytes)
    Terminal Type (1 byte)
    Data Authentication Code (2 bytes)
    ICC Dynamic Number (8 bytes)
    Cardholder Verification (CVM) Results (3 bytes)

Add public getters so info can be used in GUI, etc. See patch. 

need to perform ICC publickey validation

What steps will reproduce the problem?
1. Use a dual interface(contact + contactless) smart card reader
2. Insert smart card (contact)

What is the expected output? What do you see instead?
I expect javaemvreader to read from the chip instead of RFID. However, it will 
always choose RFID if available.

What version of the product are you using? On what operating system?
Tested on Windows and Linux using an Omnikey 5321 v2 dual interface

Perhaps sleeping will solve the issue? RFID initializes faster than chip most 
of the time. Or if(chip && rfid) readfrom(chip)?

javaemvreader 0.5.2

(see patch file attached)

Index: emv/IBAN.java
===================================================================
--- emv/IBAN.java       (Arbeitskopie)
+++ emv/IBAN.java       (Arbeitskopie)
@@ -15,26 +15,53 @@
  */
 package sasc.emv;

+import java.io.PrintWriter;
+import java.io.StringWriter;
+
+import sasc.util.Util;
+
 /**
- * International Bank Account Number (IBAN)
- * Uniquely identifies the account of a customer at a financial institution as 
defined in ISO 13616
- *
+ * International Bank Account Number (IBAN) Uniquely identifies the account of 
a
+ * customer at a financial institution as defined in ISO 13616
+ * 
  * Length 0-34 bytes
- *
+ * 
  * TODO
- *
+ * 
  * @author sasc
  */
 public class IBAN {
-//IBAN - International Bank Account Number. Often (incorrectly) referred to as 
IBAN Number. 
-//An unique account identifier for every bank account in Europe, supervised by 
SWIFT. 
-//The IBAN system was originally intended for use within Europe, and its use 
is 
-//largely confined thereto: most notably, the USA does not participate. 
-//Among British dependencies, only Gibraltar assigns IBANs. 
-//All of Europe does however participate with the exception of the CIS 
countries: 
-//urkey uses IBANS and so do some African countries. The number consists first 
of a 
-//two-digit country identifier, followed by two check digits, then up to 30 
characters representing the local account. 
-//The number of characters varies from country to country, but is fixed for 
each country. 
-//When used electronically there are no spaces in IBANs, but the convention on 
paper 
-//is to separate into groups of four with any odd digits in the last group.
+       public String iban;
+
+       public String accountNumber;
+
+       public String bankNumber;
+
+       public String countryCode;
+
+       public IBAN(byte[] iban) {
+               this.iban = new String(iban);
+               countryCode = this.iban.substring(0, 2);
+               if (countryCode.equalsIgnoreCase("de")) {
+                       bankNumber = this.iban.substring(2, 10);
+                       accountNumber = this.iban.substring(10);
+               }
+       }
+
+       @Override
+       public String toString() {
+               StringWriter sw = new StringWriter();
+               dump(new PrintWriter(sw), 0);
+               return sw.toString();
+       }
+
+       public void dump(PrintWriter pw, int indent) {
+               pw.println(Util.getSpaces(indent) + "International Bank Account 
Number (IBAN) - " + iban);
+               pw.println(Util.getSpaces(indent + 3) + "Country - " + 
countryCode);
+               if (bankNumber != null) {
+                       pw.println(Util.getSpaces(indent + 3) + "Bank - " + 
bankNumber);
+                       pw.println(Util.getSpaces(indent + 3) + "Account - " + 
accountNumber);
+               }
+       }
+
 }


Index: emv/EMVUtil.java
===================================================================
--- emv/EMVUtil.java    (Revision 15)
+++ emv/EMVUtil.java    (Arbeitskopie)
@@ -523,6 +523,10 @@
             } else if (tlv.getTag().equals(EMVTags.DDOL)) {
                 DOL ddol = new DOL(DOL.Type.DDOL, tlv.getValueBytes());
                 app.setDDOL(ddol);
+                       } else if (tlv.getTag().equals(EMVTags.IBAN)) {
+                               app.setIBAN(new IBAN(tlv.getValueBytes()));
+                       } else if 
(tlv.getTag().equals(EMVTags.BANK_IDENTIFIER_CODE)) {
+                               app.setBIC(new String(tlv.getValueBytes()));
             } else {
                 app.addUnhandledRecord(tlv);
             }


Index: emv/EMVTerminalProfile.java
===================================================================
--- emv/EMVTerminalProfile.java (Revision 15)
+++ emv/EMVTerminalProfile.java (Arbeitskopie)
@@ -84,6 +84,12 @@
             //TODO not supported at the moment
             //http://www.codeproject.com/Articles/100084/Introduction-to-ISO-8583
             return new byte[tal.getLength()];
+               } else if (tal.getTag().equals(EMVTags.TERMINAL_TYPE) && 
tal.getLength() == 1) {
+                       return Util.fromHexString("14");
+               } else if (tal.getTag().equals(EMVTags.TERMINAL_CAPABILITIES) 
&& tal.getLength() == 2) {
+                       return Util.fromHexString("60 c0");
+               } else if 
(tal.getTag().equals(EMVTags.ADDITIONAL_TERMINAL_CAPABILITIES) && 
tal.getLength() == 1) {
+                       return Util.fromHexString("00");
         } else {
             Log.debug("Terminal Resident Data not found for " + tal);
         }


Index: emv/EMVApplication.java
===================================================================
--- emv/EMVApplication.java     (Revision 15)
+++ emv/EMVApplication.java     (Arbeitskopie)
@@ -89,7 +89,9 @@
     //Transaction related data elements
     private TransactionStatusInformation transactionStatusInformation = new TransactionStatusInformation();
     private List<BERTLV> unhandledRecords = new ArrayList<BERTLV>();
-
+    private IBAN iban;
+    private String bic;
+    
     public EMVApplication() {
     }

@@ -262,6 +264,14 @@
         this.ddol = ddol;
     }

+       public IBAN getIBAN() {
+               return iban;
+       }
+
+       public void setIBAN(IBAN iban) {
+               this.iban = iban;
+       }
+    
     public void setCardholderName(String name) {
         this.cardholderName = name;
     }
@@ -324,6 +334,8 @@
     }

     public Date getExpirationDate() {
+       if (applicationExpirationDate==null)
+               return null;
         return (Date) applicationExpirationDate.clone();
     }

@@ -715,4 +727,12 @@
         }
         pw.println("");
     }
+
+       public String getBIC() {
+               return bic;
+       }
+
+       public void setBIC(String bic) {
+               this.bic = bic;
+       }
 }

Even after executing the bogus command, selecting the PSE still fails sometimes 
for cards that do contain the PSE.

This happens rarely and especially when the card is "cold" (after reading the 
card for a few times this doesn't happen).

Maybe introducing a short delay after connect would solve the problem?

During the validation of the ICC Public Key Certificate, the reference to the 
Issuer Certifiate may be null. This happens when the ICCPublicKeyCertificate 
object was created before the IssuerCertificate object.

To reproduce the issue, read a card that contains the ICC Certificate in a 
record placed before the Issuer Certificate (this happened to my VISA Electron 
card that I tested the program with).

I have attached a patch for this issue.

During direct selection of applications, if a partial match is allowed, only 
the first occurrence is added to the candidate list. For the second and next 
selections, before the corresponding FCI is parsed, an application object is 
created with the AID used during the partial selection (only the beginning of 
the complete AID). When the FCI is parsed, the complete AID is set to the 
application. When setting the new (longer) AID an exception is thrown 
("Attempting to assign a different AID value").

The problem is reproducible only when the AID obtained by partial selection is 
not present in the known AID list. If the AID is known, it will be selected 
during the direct selection and the problem will be hidden.

I observed this bug while reading a VISA Electron card with 2 applications 
(VISA Electron and VISA Auth), not supporting PSE. VISA Auth (AID: A000000003 
8002) was not known and, while it was selected using partial selection for AID 
A000000003, it did not show up in the candidate list.

I attached a patch for this bug and also another patch for adding VISA Auth to 
the known AID list.

Also, I think that the hack from line 434 of file EMVSession.java isn't needed 
(or if you decide to keep the hack, also apply it for the first selection - 
line 412).