I am using JC30M48CR Type B Javacard and JCIDE for compiling.
I searched for the whole forum to find out if it is possible to change ATQB response for JAVACARD. However, all topics are about change ATR as given in setATRHistBytes() method always returns false.
May I know whether it is possible to customise ATQB? For example, the request code for ISO14443B is 05 00 00, then the ATQB response is 50 00 00 00 00 D1 03 86 0C 00 80 80.
Thanks
No, because Java Card does not control the lower level protocols at that level. And actually, the historical bytes are not applicable to Type B cards; you'd need to have an ATR specific file in the root folder to be able to communicate the historical bytes, because they are simply not present in the ISO/IEC 14443 type B protocol.
If the communication parameters can be set then that specific functionality is OS specific. So in general - if you're big enough - then you can have chips delivered with special settings. You may also be able to set the parameters yourself through another OS provided initialization application on chip. Those are all vendor specific.
Of course the vendors do not want to let any applet change the communication parameters. For the historical bytes the Java Card Forum compromised on only allow the default selected applet change the historical bytes (instead of using a specific INSTALL for INSTALL flag or other authentication measures).
In short: contact your supplier and ask for the user manual.
Related
I´m trying to access the Information on a Mifare Smartcard(iso14443A) over a Omnikey 5321 CL reader.
I tried to use the smartcard lib, but it uses an other iso standard.
For accessing the Card I have to set a Application ID ( 3x hex), a key (32 int), keyid (hex).
You can still use smartcard lib, but you have to configure the reader to use the MIFARE mode instead of the T-CL variant of 14443 protocol.
If I remember corectly, the Omnikey workbench provides a graphical configuration tool for that purpose.
I strongly recommend to study Omnikey contactless smart card readers developer guide, especially the section MIFARE emulation mode, for serious work.
(I have no idea, what a one byte Application ID means in Mifare context, and what value 3x is supposed to represent.)
I am busy with similar process, however after searching I found this example:
https://github.com/santigimeno/node-pcsclite
EDIT
In fact I actually got this one working
https://github.com/pokusew/nfc-pcsc
It returns the following:
ACS ACR122 0 card detected {
atr: <Buffer 3b 8f 80 01 80 4f 0c a0 00 00 03 06 03 00 01 00 00 00 00 6a>,
standard: 'TAG_ISO_14443_3',
type: 'TAG_ISO_14443_3',
uid: '767aec7e'
}
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 calculate A.C that's why getting different result from my test tool.
Terminal Supplied Data
Amount, Authorised - 000000000201
Amount, Other - 000000000000
Terminal Country Code - 0826 - United Kingdom
Terminal Verification Results - 00 00 00 00 00
Transaction Currency Code - 0826 - Pound Sterling
Transaction Date - 15 04 28
Transaction Type - 00 - Goods and Services
Unpredictable Number - 30 90 1B 6A
Terminal Type - 23 - Attended, offline only. Operated by Merchant
Data Authentication Code - 00 00
ICC Dynamic Number - 1E AB C1 26 F8 54 99 76
CVM Results - 00 00 00
Gen AC Using CDOL1
80 AE 40 00 2B 0000000002010000000000000826000000000008261504280030901B6A2300001EABC126F8549976000000
this command is returning 9F26.
data i used for calcatation is:-
0000000002010000000000000826000000000008261504280030901B6A2300001EABC126F85499760000003800000180 [ data is multiple of 8]
Where 3800 is AIP 0001 is ATC and 80 for Padding [ Padding method 2 EMV] This is my logic, Is any body tell me where I should focus more to generate same AC as my tool generated.
MasterCard Application Cryptogram (AC) generation is more complicated than other card schemes.
Card can use different ICC Session Key Derivation (SKD) methods:
MasterCard Proprietary SKD, where involved Application Transaction Counter (ATC) and Unpredictable Number (UN);
EMV2000 Method, where involved only ATC - see EMV 4.0, Book 2;
EMV Common Session Key (CSK) Method, where involved only ATC - see EMV 4.2, Book 2;
Data Objects (DO) can be with different sets of additional or modified values:
Card Verification Results (CVR) can be 6 or 4 bytes.
The offline counters from Issuer Application Data (IAD) can be included.
Last online ATC value can be included.
The used method and data variant can be detected by Cryptogram Version Number (CVN) and Application Control bits. CVN is sub-field of IAD tag 0x9F10 .
The detailed information are proprietary and available for the MasterCard members.
For deep learning about it take a look into "M/Chip Card Application Cryptographic Algorithms" and M/Chip Card Application references.
I'm creating a Lua library to help process sending and receiving DNS requests and am currently reading this (DNS protocol RFC), but I'm unaware of how to properly format the request. For instance, do I have to specify how long the message? How do I do this?
I understand, from my Wireshark inspection, that I'm supposed to also include options afterwards. I also see a 0x00 in the response; does this mean that I just simply have to zero-terminate the request name before adding in values?
The section I'm specifically talking about is 4.1.3 of the RFC.
Some notes: I tested this with a personal server and got these values in the query section: 06 61 6c 69 73 73 61 04 69 6e 66 6f 00. The 00 in particular is what interests me, it's highlighted in WireShark, which means it's significant. I assume it means that the values are null-terminated? Then the options about the type and class follow?
When section 4.1.3 refers to a "NAME", it's referring back to the definition in section 3.1, which specifies that a domain name consists of a sequence of labels, each of which consist of a length specification octet and a number of octets. The final label is always the root zone, which has a zero-length name and thus consists only of a length octet with a zero in it. So, yes, the whole name is terminated with a zero octet, but it's not "zero-terminated" in the usual C string sense.
Note also that only the lower six bits in the length octets are the length data, the uppermost two bits are flags.
I have two different smartcard chips with Visa Paywave inside (one is native, and other is Java Card).
I am trying to run select PPSE or select Application command, one card is giving the expected result while another card is giving status word 6700.
Command ---->CMD 00A404000E325041592E5359532E4444463031
Sw1-sw2 <----67 00
Command ---->CMD 00A4040007A0000000031010
Sw1-sw2 <----67 00
We have some other proprietary test tool that is receiving a good result for both cards. That means that both cards have a PPSE and application in it. I wonder why my tool is sending the same command but getting a different result.
Any advice would be helpful here.
As we know that there are 4 cases defined in ISO7816-4 like,
As per my experience maximum card does not worry about Le field in apdu command, card O.S just process the command and return data if require.
Here i am getting error -6700 because here my card is expecting Le byte too.( card expecting case 4 instead of case 3)
Send command like below solve my problem,
00 A4 04 00 0E 325041592E5359532E4444463031 00 ( adding Le = 0x00 at last)
I understand that each packet has some header that seems like a random mix of chars. On the other hand, the content itself can be in pure ascii and therefore it might be human friendly. Some of the packets I sniffed were readable (raw html headers for sure). But some packets looked like this:
0000 00 15 af 51 68 b2 00 e0 98 be cf d6 08 00 45 00 ...Qh... ......E.
0010 05 dc 90 39 40 00 2e 06 99 72 08 13 f0 49 c0 a8 ...9#... .r...I..
0020 64 6b 00 50 c1 32 02 7a 60 4f 4c b6 45 62 50 10 dk.P.2.z `OL.EbP.
That was just a part, these packets were usually longer. My question is, how can I decode the packet content/data? Do I need the whole stream? Is the decoding simple, or every application can encode it slightly else, to ensure these packets are secured?
Edit:
I don't care about the header, Wireshark shows that. However, that's totally worthless info. I want to decode the data/content.
The content of a packet is defined by the process sending it. Think of it like a telephone call. What's said is dependent on who is calling and who they are talking to. You have to study the programs that construct it to determine how to "decode" it. There are some sniffers that will parse some commonly used methods of encoding and try to do this already.
Why not just use something like wireshark?
Packet headers will depend on the application sending the packet in question, as mentioned in an earlier post. You can also use Wiresharks protocol reference for understanding some of the common protocols.
What you have listed here is the Packet Byte, what you need to see is the Packet Detail view to understand what does the seemingly random data correspond to. In Packet Detail view, when you select various parts of the packet, it will highlight corresponding byte in the Packet Byte view.
If you're using C#, grab SharpPcap and look at the examples in code to get a feel for how it works.
Set the filter to only capture UDP, capture a packet, parse it to udp, and extract the payload. The payload's format is based on the application sending it.
There's a lot of extra gibberish because every udp packet contains a stack of:
Ethernet header
IP header
UDP header
of information before your data and all incoming data is in binary format until you parse it to something meaningful.