When i make a contactless transaction, no fit is matched with the card BIN even if the fit is well configured. The ATM use the track2 to match the fit, but since the transaction is contactless, the track 2 is empty. Is there any way to use the track2 equivalent data instead of magnetic data?
FYI: i already specified in the AID configuration to use the track2 equivalent data instead of magnetic data, but still no fit is matched.
This sounds like an ATM software vendor issue. It happens.
ATM is supposed to substitute magnetic stripe track2 with track2 equivalent on EMV transactions.
Related
I see a lot of videos showing withdrawals from ATMs with cloned EMV cards like code 201 so
how can be possible when a card uses DDA (dynamic keys) another question is cloned card just for magstripe because it is unencrypted or even EMV chip
It is a question that does not really belong to SO and due to the nature of what you are asking about, you may not receive a detailed answer. I will still try.
First of all, ATMs are online-only devices that do not need any form of Offline Data Authentication so DDA has little to do with them normally (there are exceptions from this rule, as usual).
There are still dynamic keys that are meant to provide security, nevertheless. A standard symmetric-key algorithm is used to generate online cryptogram and it is validated by the issuer. Symmetric keys are individual to each specific card and are not easily extracted (of course, nothing can be ever treated as 100% secure, but it would require a complex hardware attack to extract keys from a single card).
I assume your question about Service code 2xx, 5xx or 6xx is mostly revolving around magstripe data with no chip data available. In some situations (i.e. when card is mute) a fallback to magstripe transaction may happen. Normally, unattended devices should have this option blocked and decline such attempts but I would not bet there are no such devices around the world. You also need to consider that there are still devices that are not EMV-capable.
When it comes to magstripe data, they can be easily modified (for instance changing the service code) although such modification should be detectable. Same goes for using EMV track equivalent data on magstripe. In both cases, issuer is capable of detecting modification of the data or using it on different interface through the use of CVC/CVV which is encoded on a track and is created to cryptographically protect integrity of the track data. However, this requires to have proper implementation on the issuer side to detect and decline such attempts where cryptographic data from CVV or cryptogram are incorrect.
First, I want to apologize. I am complete noob in this area and many of my thoughts are probably misleading.
I need to verify that a user of my app is on a specific place in order to be authirized to perform an action. I want to use NFC for this purpose. The user have to put his smartphone by a NFC tag in order to be authorized to perform the action. Easy but I need it to be reasonably hackerproof. It means that the NFC tag must be impossible to clone without physical damage to the plastics around the NFC chip. It also means that the NFC chip must not contain only static data. The NFC chip must contain an app, that can receive some data (cryptographic challenge) and signs them using secure built-in private key (which must be unreadable through NFC interface). When the user wants to perform the action, he will ask server for the challenge, then he lets the chip to sign it, and then he sends the signed challenge back to the server which will verify the signature using known public key. This should be achievable using NFC JavaCard. But do these NFC JavaCards actually exist? I wasn't able to find a company which would be able to produce such NFC tags for me. When I try to explain my requirements to a NFC tags producer he looks like he has never heard of NFC JavaCards. I have tried about 10 producers without luck.
Can a commonly available chip meet my requirements? I mean a chip from the Mifare familly. I suspect that Mifare DESfire might be able to meet my requirements, but I am not sure.
Feel free to respond with an advertisement, because relevant advertisement is exactly what I look for :)
I try to collect some useful facts:
NFC is a very broad term, just finding that on both sides does not ensure interoperability.
Any ISO 14443 (one of the NFC flavours) compliant smart card with crypto functionality should be usable. Note, that a card with native OS may be a viable alternative to a JavaCard, since the functionality to sign a random number is pretty standard.
Any smart phone sporting a NFC chip can address such a card in principle. Unfortunately this is strongly dependent on the OS of the smart phone, for Android the relevant class to use is IsoDep, which gives you the APDU interface. After triggering the "card enters field" event, then the app receives a handle, via which further communication can take place.
Real smart cards can't be cloned, since you are not able to dump them; especially keys can't be read.
Now some things to consider:
Your approach looks unusual, which might become a problem. (To have a portable card somehow fixed to a wall, just to get the location; so you know where somebody is, but not who? While I don't consider cloning to be an issue, you somehow must ensure destruction in case of a theft attempt, which may collide with the distance topic below.)
I don't see, where the server comes into play. If not involved in the authorized action, provision of a random number is not sufficient reason.
Asymmetric key operations have a comparatively high power consumption, and this power has to be supplied via the electric field. This severely limits the distance between card and phone and may even require direct touch. While a power supply of its own would solve the issue in principle, it is not what ISO-14443 was designed for.
Yes JavaCards do exist.
https://github.com/OpenJavaCard/openjavacard-ndef is a project makes these JavaCards to output standard NDEF messages (thought note issue 4 in that there example uses the wrong APDU but that is easily changed)
This project also give a number of cards it is fully working and tested for
ACS ACOSJ - fully working
NXP JCOP J3D040/J3D081/J2E145 etc - fully working
Both ACS and Cardlogic do cards (just google the model numbers)
e.g.
https://www.acs.com.hk/en/products/405/acosj-java-card-combi/
https://www.smartcardfocus.com/shop/ilp/id~707/j3a081-80k/p/index.shtml
The answer a was looking for is not a chip which runs a custom code. Although this might be possible it is definitely not the best way to achieve the target.
I was looking for a solution that enables strong authentication using NFC data. There might be multiple chips that offers this, but probably the most available chip is NTAG 424 DNA TT. It works like this:
The chip has a memory, which is not readable through NFC. Private key is stored there.
The chip has a read counter. It increments everytime the data are read through NFC.
The chip can generate an AES-128 signature of string UID (chip serial number) + counter using the private key in the inaccessible part of the memory.
The chip can dynamicaly inject the data above into a URL that is stored in the readable memory.
So the solution will be like (I am waiting for delivery of NFC tags right now, so I don't know for sure yet):
Read the tag UID (serial number) and the actual counter value (should be 0 on an unused tag)
Generate the key-pair
Load private key to the chip
Load some data (URL, eg: https://my.app/) to the chip
Store UID, public-key, last-counter on the server
Configure the chip to inject UID, counter, signature to the URL stored on the chip
When a client reads the data, they should contain required variables, eg: https://my.app/?counter=1&uid=ff:ff:ff:ff&signature=xyz. Then on the server:
Fetch stored info (public-key, last-counter) using uid as a primary key
verifies the signature
verifies the counter that must be > last-counter
stores counter as the last-counter
successfully authorized
Is anyone able to hack this without reading the hidden memory of the chip which would require physical tampering with the chip?
I bought a bunch of NTAG213 cards and have an ACR122U reader writer. I want to password protect each card with the same password, write a unique ID to each card, and use that ID to compare against a database in order to get an approval or declined response. I've studied the documentation and learned how the cards work via various tool, but my biggest question is, how do I actually send commands to the cards to read and write stuff in the system I'm thinking about creating? Is there a specific scripting tool or software I should be using to read and write or build upon?
Speaking about unique IDs, I've been told that each card has an ID, and that the pages that store the IDs can never be overwritten right? So is it safe to assume that if I bought one million NTAG213 cards, I'd never have to worry about a duplicate ID? If that is the case, is it possible for me to instead just write a program that reads the ID from each card and use that instead of writing an ID to each card? How can I get a program I'm writing to read that ID?
Sorry about bothering you guys with what may be a total beginner question, but I'm totally clueless and really want to learn. I'd really appreciate any help that I can get.
You should get in the habit of asking individual/specific questions on this site, it's not really a forum.
With that said...
How do I actually send commands to the cards to read and write stuff in the system I'm thinking about creating? Is there a specific scripting tool or software I should be using to read and write or build upon?
This is a "bad" question in that it's too broad for Stack Overflow. There are hundreds of tools available. Literally google "programming NFC" or something similar.
Speaking about unique IDs, I've been told that each card has an ID, and that the pages that store the IDs can never be overwritten right? So is it safe to assume that if I bought one million NTAG213 cards, I'd never have to worry about a duplicate ID?
This is a good question.
The ID can never be overwritten on most tags. Definitely not on the NTAG213.
Yes your reasoning is correct, but because the UIDs are not a standardised GUID/UID (e.g. Universally unique identifier - Wikipedia) and the IDs are set by manufacturers (and therefore are open to spoofing and perfectly legal situations where a manufacturer can produce 1 million tags with the same UID), there is no 100% guarantee, it is just statistically very unlikely and a practical assumption that you can make in most cases.
If that is the case, is it possible for me to instead just write a program that reads the ID from each card and use that instead of writing an ID to each card? How can I get a program I'm writing to read that ID?
Yes that approach is good, but I would consider adding another form of authentication too, because as discussed the tag IDs are not 100% unique. How to do it? It's a bit of a complex question, but if you're writing an Android app, you can simply use the getId() method with the nfc.Tag class Tag | Android Developers API.
I understand that the EM4100 cards contain only read-only data, and no new data can be written to it. So my question is: who writes the initial data? Is it like a cd (write once) or does it have some kind of id/code on it when you buy it?
Thanks!
Tekin.
EM4100 is normally read only chip (chip spec on http://www.mikroe.com/download/eng/documents/development-tools/components/em4100_datasheet.pdf).
You have to order the good programming from your manufacturer/reseller and it will be done on the factory.
Depending on your use case, you can also purchase EM4100-like chip which behave just like these (in read at least) but are R&W with appropriate hardware.
I am looking to implement a simple registration key system. There will be printed codes, and we'd like users to type their code into our system.
This code will be used around the world, and we want to avoid any problems with confusing codes.
We're already doing the following:
using numbers and upper case letters
leaving off 2 and Z, Q and 0 and O, 5 and S, B and 8, U and V, and 7 and 1 and I
breaking up the code into four-digit chunks, so it's easier to digest
Is there better guidance online about common printed registration code pitfalls? I know this can be an annoying process for users and I want to make it as easy as possible in my system.
Put it on a durable, movable medium
Things that annoy me are
weak paper stickers glued permanently to hardware
small labels you don't know where to put
There is no ideal format, really. I'd suggest something similar to a business card - durable paper, in a size for which "containers" (carry boxes, folders, laminating cards) are readily available.
Allow Copy & Paste
Make sure I can copy and paste the key as a whole.
Your input should of course indicate the groups of characters, but when "Paste" only transfers the first group, I am a very unhappy customer.
Barcode
If you stick to print mostly, consider adding a bar code. Depends on your customer base, but it's a worthwhile option if some of them are already expected to have a barcode scanner, and might be expected to enter such a number more than once.
Unfortunately, they are much longer than the numbers, so that might be a format issue. (If you make it to small, scanners won't recognize it, if you make it to big hand scanners can't read it).
For mobile apps e.g. on a phone with camera, you could use image recognition of one of those fancy "square barcodes". (I'd expect libraries for that to be readily available).
Do you insist on print?
Allow the keys to be stored in a (e.g. text) file, give them a specific file extension that is registered for your program.
This way, you can attach a licence to an e-mail, the user just double clicks the attachment, gets a message box
Do you want to install the following licence:
dnord's GreatApp Pro - Evaluation licence (30 days)
[yes] [no]
We use a modified system to (a) have additional data in a licence file, and (b) bundle multiple licences (for separate modules/apps) into one package that can be installed at once.
At least it's an alternate to entering a key for each purchase, welcomed especially by our larger customers.
We never had support calls because of problems receiving or installing the custom file type, though this might be different if you have a consumer product. At least, no support calls because of mistyped keys :-)
General
Have a plan how to deal with "lost licences".
There's no recipe here, I guess with pure software solution you might have to show some lenience to not alienate paying users.
(We usually bind to 19" rackmounted hardware that's hard to lose, so we happily create new licences for a customer as often as he likes).