What would be the best way to determine the issuer of a contactless EMV card. I am trying to determine if a card was issued by Amex, Visa or Mastercard. Is that information available via a USB EMV reader? I don't need to pull any other information from the card..
I'm assuming that it could be done by some python, or C++ code interacting with the card. I'm looking for a good jumping off point.
You should be able to get this info from the successful response of SELECT. Store the list of RIDs ( AID = RID + PIX ), and do SELECT one by one. On success, it will return status bytes 90 00, otherwise 6A 82( file not found ).
The easiest option would be through SELECT command as mentioned
before. The list of AID:
https://www.eftlab.com/knowledge-base/211-emv-aid-rid-pix/
The other option would be getting it from the PAN. You can define issuer
based on first 6 digits or 8 digits of the PAN, which represents Issuer
Identification Number (IIN)/Bank Identification Number(BIN).
34, 37 - American Express
4 - Visa
51-55, 2221-2720 - MasterCard
https://en.wikipedia.org/wiki/Payment_card_number#Issuer_identification_number_(IIN)
You would have to send commands:
SELECT
GET PROCESSING OPTIONS
READ RECORD
You would look for 5A - PAN and extract first digits.
Good tool that you can just use to read data from contactless EMV card is:
https://www.javacardos.com/tools/pyresman
You can create your own scripts or just proceed with some basic commands like a SELECT command.
Related
I've recently completed Chapter 3 of the associated textbook for this course: The Elements of Computing, Second Edition.
While I was able to implement all of the chips described in this chapter, I am still trying to wrap my head around how exactly the RAM chips work. I think I understand them in theory (e.g. a Ram4K chip stores a set of 8 RAM512 chips, which itself is a set of 8 RAM64 chips).
What I am unsure about is actually using the chips. For example, suppose I try to output a single register from RAM16K using this code, given an address:
CHIP RAM16K {
IN in[16], load, address[14];
OUT out[16];
PARTS:
Mux4Way16(a=firstRam, b=secondRam, c=thirdRam, d=fourthRam, sel=address[12..13], out=out);
And(a=load, b=load, out=shouldLoad);
DMux4Way(in=shouldLoad, sel=address[12..13], a=setRamOne, b=setRamTwo, c=setRamThree, d=setRamFour);
RAM4K(in=in, load=setRamOne, address=address[0..11], out=firstRam);
RAM4K(in=in, load=setRamTwo, address=address[0..11], out=secondRam);
RAM4K(in=in, load=setRamThree, address=address[0..11], out=thirdRam);
RAM4K(in=in, load=setRamFour, address=address[0..11], out=fourthRam);
}
How does the above code get the underlying register? If I understand the description of the chip correctly, it is supposed to return a single register. I can see that it outputs a RAM4K based on a series of address bits -- does it also get the base register itself recursively through the chips at the bottom? Why doesn't this code have an error if it's outputting a RAM4K when we expect a register?
It's been a while since I did the course so please excuse any minor errors below.
Each RAM chip (whatever the size) consists of an array of smaller chips. If you are implementing a 16K chip with 4K subchips, then there will be 4 of them.
So you would use 2 bits of the incoming address to select what sub-chip you need to work with, and the remaining 12 bits are sent on to all the sub-chip. It doesn't matter how you divide up the bits, as long as you have a set of 2 and a set of 12.
Specifically, the 2 select bits are used to route the load signal to just one sub-chip (ie: using a DMux4Way), so loads only affect that one sub-chip, and they are also used to pick which of the sub-chips outputs are used (ie: a Mux4Way16).
When I was doing it, I found that the simplest way to do things was always use the least-significant bits as the select bits. So for example, my RAM64 chip used address[0..2] as the select bits, and passed address[3..5] to the RAM8 sub-chips.
The thing that may be confusing you is that in these kinds of circuits, all of the sub-chips are activated. It's just that you use the select bits to decide which sub-chip's output to pass on to the outputs, and also as a filter to decide which sub-chip might perform a load.
As the saying goes, "It's turtles (or ram chips) all the way down."
I'm working on a profile for MasterCard EMV cards on M/Chip Select 4 version 1.1b and I need some help understanding the data elements for the 9F7E (Application Life Cycle Data) tag value and D5 (Application Control) tag value. Unfortunately, the MasterCard SSF form doesn't explain information. From our card vendor we found a document in which we found application Id number is it similar to ALCD(9F7E)? And how could could I found D5 value
9F7E is a 48 bytes long field organized into two 4 parts.
2 bytes - version number - for your case 03
7 bytes - type approval id - which is provided by MasterCard while
certifying applet.
20 bytes - Contents are issuer specific denoting application identification.
20 bytes application code identification
For options available on D5, download MChip 4 Version 1.1 Issuer Guide to Debit and Credit Parameter Management.pdf from MasterCard Connect. It has bit by bit information.
You can find this informations in:
M/Chip 4 Version 1.1 Issuer Guide to Debit and Credit Parameter Management
There, you will see next (tag D5 value related):
The Application Control activates or de-activates functions in the application.
The coding of the Application Control data element varies depending on the
version of M/Chip 4, and on whether the Lite or Select application is being
used.
You are using M/Chip Select 4 version 1.1b, so, there it is:
And, if you have M/Chip Lite 4 version 1.1b, first byte will be like:
Second byte value is same for both:
Hope this can help you.
Is there any way to understand if the card(emv or magnetic) is used first time at ATM or POS?
For EMV card ATC is reliable?
The "first time" could be different.
You can ask for ATC after selection ( command 80CA9F5200 ) and if it equals 0000, Get Processing Options wasn't performed, what means there wasn't any transaction.
Bit if if > 0000, it does not mean what "full" transaction was on card. ATC shows number of launch command Get Processing Options.
For Visa card you can find specific bit in CVR ( CVR3, BIT5 ) "New card". He shows if successful online transaction was performed with card.
You can trust ATC for EMV transaction but there is no counter for magnetic transaction.
There is one bit( new card bit) that was set in first EMV transaction. If the Last Online ATC Register is 0 then “New card” bit in the TVR will be set to 1. You could check that bit to see if this transaction is first for this card.
I found ATC is incremented just after GPO is performed. It is possible that transaction falied just after GPO,
Next time when we fire GPO, we get the value > 0 ( ATC already incremented) here we can't say that card is not new because yet to processed first transaction successfully.
so I think ATC value is not a parameter to find out whether card is new or already used. [Sometime as per setting we need to check the card is new or not to perform certain activity]
There are two ATC-related values could be read using GET_DATA: the current ATC and Last Online ATC. For a new card that never went online the Last Online ATC would be zero. This should be true for a 'classical' scheme of the EMV technology employment by a traditional payment system.
Hope this helps
In the user manual they only specify address's of "Analog Output Holding Registers", which allows you to implement function codes 3, 6 and 16.
PS. I want to change a single coil (bit) in Eprflag-register (bit 12), but the user manual dose'nt specify the data address of that coil. For exemple: bit 12 has coil-number 00002, that gives us 2-1=1 as the data address.
If the "write coils" function is not available, you may still have the possibility to read the entire register, change the desired bit, and write back the entire register.
I'm using http://maps.google.com/maps/geo? web service to geocode some addresses.
The problem I have is that a fuller address doesn't necessarily give a more accurate geocode.
e.g passing in Llantysilio, Denbighshire, UK is far more accurate than Llantysilio, Llangollen, Denbighshire, UK
The Accuracy attribute in the XML doesn't seem very helpful in deciding which address to pick.
How have other people dealt with this issue? Is there a good way to pick the best geocode that works most/all of the time?
*edit
A bit of extra info - when I put in the fuller address the first line of the address is ignored and the geocoder jumps to a different, but exact, address which is a central street located in the extra line added to the address. In this example, it picks Castle Street in the middle llangollen, seemingly disregarding Llantysilio.
Edit by kdgregory: here are the two API requests that I used (missing API key doesn't seem to be an issue):
http://maps.google.com/maps/geo?q=Llantysilio,+Denbighshire,+UK&sensor=false&output=xml
http://maps.google.com/maps/geo?q=Llantysilio,Llangollen,++Denbighshire,+UK&sensor=false&output=xml
You have to interpret the accuracy my friend. There are usually 2 parts to an accuracy, first the address macthing. The second part is the important part. You can geocode something to a accuracy level of the United States, or a city level, zipcode centroid, street interpolated level or an actual parcel precision level. The first example has a 4 and the second is 9. For this service higher is better.
Accuracy Value Description
0 Unknown accuracy.
1 Country level accuracy.
2 Region (state, province, prefecture, etc.) level accuracy.
3 Sub-region (county, municipality, etc.) level accuracy.
4 Town (city, village) level accuracy.
5 Post code (zip code) level accuracy.
6 Street level accuracy.
7 Intersection level accuracy.
8 Address level accuracy.
9 Premise (building name, property name, shopping center, etc.) level accuracy.
It's probably good to note that Google does not follow the XAL specs, but rather implements them in a subset.
So, this means that you won't necessarily be able to do:
place.AddressDetails.Country.AdministrativeArea.Locality.LocalityName
place.AddressDetails.Country.AdministrativeArea.AdministrativeAreaName
place.AddressDetails.Country.CountryName
Because a country and sub-locality may be provided while a administrative area is not.
The data that is returned is identified with an accuracy gauge that gives you a relative idea of what you can expect for data. So, you can store objects and chop off parts of the full address using this variable and try to geocode in such a fashion - It's not recommended though.
Typically, a full address is (without the thoroughfare) is a good way of finding the general location. You can use some of the weighted-preferential logic Google provides to refine the address.
E.g. Use the setViewPort or setCountryCode to give your searches a bit more accuracy.
Remember, Geocoding is not a science. You can't expect consistent results.
A geocode response.Placemark[0] via gmap you can check what you got, and take the level or try again. I chose default in the order
place.AddressDetails.Country.AdministrativeArea.Locality.LocalityName
place.AddressDetails.Country.AdministrativeArea.AdministrativeAreaName
place.AddressDetails.Country.CountryName
It could be more logically named as seen above. gmaps 3 works somewhat incompatible with v2.
You can try a very ugly hack which consists in geocoding your full adresse and all subsets of the words your adress contains, you get a lot of geocodes that you use to get the adresses related to them with reverse geocoding tool.
Once you have plenty of adresses you compare them with the one you first gave, then you take the most accurate geocode...
Many requests, lot of iteration growing with each word you add to your adress, well an ugly work but can be fun to make some statistics ^^
In the end I concluded that there are far too many weird blips in address consistency with google's geocoding webservice in the UK, but eventually managed to figure out a way of using postcodes instead, which is far more accurate: how it's done