apdu

I am working on JavaCard and I developed an applet with JCDE on Eclipse: import javacard.framework.APDU; import javacard.framework.Applet; import javacard.framework.ISO7816; import javacard.framework.ISOException; import javacard.framework.Util; import javacardx.framework.math.BigNumber; import javacard.security.CryptoException; import javacard.security.MessageDigest; public class SignatureGPS extends Applet { public static final byte CLA = (byte) 0xB0; public static final byte INS = (byte) 0x00; private BigNumber s; private BigNumber x; private MessageDigest h; private SignatureGPS() { s =

I've tested my Android Java application with Nexus 4, Nexus 5 and Samsung Galaxy S4 phones. In the test, the reader sends APDUs changing in length up to 252 bytes. Nexus phones receive APDUs successfully. On the other hand the Galaxy S4 phone can't receive APDUs which contain more than 128 bytes. It receives only the first 128 bytes of the sender's 252 bytes. How can I determine a device's maximum receivable APDU size? Currently there is no method to find the maximum receivable APDU length (except for trial and error). Regarding maximum receivable APDU length there is an open AOSP bug report (

What is the recommended data field size in a Java Card APDU ? From Zhiqun Chen's Java Card Technology for Smart Cards: Architecture and Programmer's Guide book, it mentions that Le field allows a max of 255. Are we to interpret it as follow for the APDU Command: |<----------------------- 255 Bytes total ------------------------>| |<- CLA -><- INS -><- P1 -><- P2 -><- Lc -><---- DATA ----><- Le ->| Thus, if CLA, INS, P1, P2, Lc, Le are all 1 bytes each, we should assume that the we can safely only set 249 bytes into the DATA region ? For the APDU Response are we to interpret: |<----------------

I have succesfully retrieved the CVM List from EMV card. 0000 0000 0000 0000 4103 4203 1E03 1F02 From the EMV specification book 3, the first 4 bytes and second 4 bytes are amount and rest is CV rules. Making these the CV Rule 4103 4203 1E03 1F02 The book also shows how to parse the CV rules, as shown below: I am assuming that I need to convert the first two bytes in a CV rule to binary and match with the table above? But why does the table above have empty cells? Also can someone explain in a simple pseudo code algorithm to parse this? Have you referred section 10.5.5 CVM Processing Logic in

I sent 80 50 00 00 08 00 00 00 00 00 00 00 00 [ INITILIZE UPDATE Command] via opensc-tool to my java card and received 00 00 11 60 01 00 8A 79 0A F9 FF 02 00 11 79 11 36 5D 71 00 A5 A5 EC 63 BB DC 05 CC [ Init Response ] as its response from the card. As you see: In the command,I send 00 00 00 00 00 00 00 00 as Host Challenge , And in the response : 00 00 11 60 01 00 8A 79 0A F9 = Key diversification data FF 02 = Key information 00 11 79 11 36 5D 71 00 = Card challenge A5 A5 EC 63 BB DC 05 CC = Card cryptogram Now I want to check myself,if the card cryptogram is OK or not. How I can do it? for

I am trying to generate AC manually, I have a tool to generate AC but I want to generate it by my own to understand the algorithm for the same. My calculation is fine for Discover card but it is failing for MasterCard. As per my understanding, data used to generate AC is depend on Tag 8C - CDOL1 which we provide to card with Gen AC command + AIP + ATC. AIP and ATC - accessed internally by ICC. Data used to generate AC is:- data part of Gen AC command + value of tag 82 + value of tag 9f36 + 80 + optional 00 to make it multiple of 8. this is my logic ,it might be I am using wrong data to

I am developing an Android app which has function to read data from a smart card. By default, NFC Controllers support APDU command with maximum transceive length is 261 bytes in single command. Because of large data need to be read on the card, the speed of reading is very slow. Are there any Android phones which support extended APDUs allow to send more than 261 bytes in single APDU ? Or are there any ways to modify the maximum transceive length by calling Android API to allow to do that? I have found some topic: link In which they increased the hard-coded value in the NativeNfcManager.java

What I am trying to achieve is to send APDU command to MIFARE Classic 1K card to change its A and B keys. I was able to establish a connection with the card and use a default key ( FFFFFFFFFFFF ) to read block 0 and block 1. I used HID MifareSamples application for it. Now, I would like to change A key from default to something else. I found a solution here, at stackoverflow ( Mifare Change KEY A and B ) which suggests that I have to send this APDU: New key A = 00 11 22 33 44 55 Access bits not overwritten Key B not used (so FF FF FF FF FF FF) => Write to Sector Trailer 00 11 22 33 44 55 FF 0F