I want to create a NFC-enabled pass for ApplePay. My problem ist I dont know how I get the merchent the pass was used and how can I configure which mergents are allowed.
The idea is:
- User gets our loyality card
- User goes into the store and pays with ApplePay
- I get information were the user pays to manage loyality points
But I can' find a way in the documentation were I can define allowed stores, or how I get an feedback about buying something on a store.
I think this is the important part of the documentation:
The NFC-enabled pass will not function without a terminal compatible with the Apple value added services protocol. Each NFC-enabled pass contains a 64-byte data element which can identify a customer. This data element can represent a rewards card for a loyalty program, a stored value card, or a ticket. Apple Wallet only transmits this data element to an NFC-enabled terminal that is compatible with the Apple value added services protocol.
NFC-Enabled Pass Keys
NFC-enabled pass keys support sending reward card information as part of an Apple Pay transaction.
Important: NFC-enabled pass keys are only supported in passes that contain an Enhanced Passbook/NFC certificate. For more information, contact merchant support at https://developer.apple.com/contact/passkit/.
Passes can send reward card information to a terminal as part of an Apple Pay transaction. This feature requires a payment terminal that supports NFC-entitled passes. Specifically, the terminal must implement the Value Added Services Protocol.
Passes provide the required information using the nfc key. The value of this key is a dictionary containing the keys described in NFC Dictionary Keys. This functionality allows passes to act as the user’s credentials in the context of the NFC Value Added Service Protocol. It is available only for storeCard style passes.
Key name Type Description
nfc nfc dictionary Optional. Information used for Value Added
Service Protocol transactions. For
this dictionary’s keys, see
NFC Dictionary Keys.
Available in iOS 9.0.
NFC Dictionary Keys
Information about the NFC payload passed to an Apple Pay terminal.
Key name Type Description
message string Required. The payload to be transmitted to the Apple
Pay terminal. Must be 64 bytes or less. Messages
longer than 64 bytes are truncated by the system.
encryptionPublicKey string Optional. The public encryption key used by the
Value Added Services protocol. Use a Base64
encoded X.509 SubjectPublicKeyInfo structure
containing a ECDH public key for group P256.
But as I can see there is only a possibility to give a message, but not to define a merchant or to define a callback.
How will I know where the card is used? How can i define which merchants are allowed?
Thanks
It is not possible to determine when an ApplePay card is used other than from the terminal provider itself. You would need to have a NFC-enabled loyalty pass in the users wallet and use a VAS enabled NFC reader to read the relevant user data, then you would have application logic in your terminal to determine where the pass was used.
At PassNinja, we provide readers and an SDK that can read GPay and Apple Pay loyalty passes.
Related
I have a programmable device (Galaxy Watch) that can act as a ISO7816 smart card and I have another programmable device (Android Smartphone) that can act as a card terminal. Without needing any of the smart card functionality as it is supposed to be used all I need to do is send and receive a few bytes from the phone to the watch.
I have a working implementation that registers an AID on the watch. The phone is sending an A4 (SELECT FILE) instruction with command P1=04 and P2=00 and that registered AID in the data field. The watch does then get a callback and can respond to it with arbitrary data. This is working fine.
My question is this: how can I extend this so that I'm able to send a few arbitrary bytes of custom information to the watch? I have too many different information objects in order to register a separate AID for every one of those. Can I somehow add some arbitrary bytes to that A4 or probably any other command?
I am basing my answer on the host-based card emulation overview.
You seem to already have extended the HostApduService and implemented the processCommandApdu() function that receives all APDUs sent in the scope of your "application" (i.e. what you want to access through your AID).
Now you have to decide how to model and encapsulate the "few arbitrary bytes of custom information" in terms of ISO7816 (see here for a nice entry point for reading up on ISO 7816; here you have the options of
record oriented files that you'd access by READ / UPDATE / APPEND RECORD
transparent files that you'd access by READ / UPDATE BINARY
objects that you'd access by GET / PUT DATA
Once you have decided upon data organization, you'd have to enable the above mentioned processCommandApdu() to decode the respective APDUs and read / write the "few arbitrary bytes of custom information".
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 am trying to implement an authorization system based on general NFC tags. One of the concerns I want to address is tag cloning. I have read some literature ensuring tag authenticity by using a read-only tag ID written on the tags during manufacture. This ID is signed by the owner and written on the tag. This way, a cloned tag (which will have a different, tag-manufacturer assigned ID) can be detected by comparing tag IDs with the cloned signature.
My question is, is it safe to assume that all (or most) NFC tags will have such a coded-in, read-only ID which I may use for cloning detection?
Narrow your problem down first pick a tag type and manufacturer that is suitably secure for your needs.
A UID is a general property of most tags BUT different tags have different specifications. Some tags have a small UID size and thus UID re-use is likely. Different tags have different length UID's. Some are supposed to be set at the factory but clones allow them to be set later. Some specification state the tag UID is always writeable.
Also using Host Card Emulation, it possible to write program to brute force any security based on UID alone (time taken could vary depending on UID length used)
Various tags offer password protection and encryption of the data on the tag (older tag types can have weak encryption/password protection though).
Most of the of the password protection is done with a special area where a password can be written to by a Reader/Writer but can only be read by the tag itself.
If you do use the password protection features of some tags make sure you don't the same password for every instance of the system, make sure the Admin of the system is forced to set one for their systems.
Considering UID for authenticity check is not a good idea, because cloned cards can have the UID cloned exact same as that of original card.
I'm not sure about other manufacturers, but as I have worked a lot with NXP tags, I'm just gonna suggest a solution here, if that suits your requirements then you can go ahead. For working with NXP cards they have provided an open api called TapLinx, where you get an api for originality check. Using which you can get to know if the card is authentic or cloned. It will identify the cloned cards even if the UID is also cloned.
Do not rely on the UID as security mechanism. There are cloned chips on the market, as well as chips where you can program the UID yourself. On top we have seen mistakes from manufactureres, resulting in duplicate UIDs.
Better use your own numbering scheme. Ideally on a cryptographic basis.
I have one stupid question. I have mifare classic tags (1k). I want to hide content of this card (any data stored there). How to do it?
What about ndef records?
MFC (MiFare Classic) got reverse engineered completely, so storage should be considered read-write, and clear text, copiable/clonable, etc.
If you can afford encryption of the payload before putting it on the card, you may be able to make data confidential, but not "hide" it: third parties will be able to tell card is not blank, but will not be able to tell what is actually stored.
NDEF wont help you there.
MIFARE Classic allows to store data in sectors, which can be access protected. So authentication with the sector key needs to be done before any read operation (if configured that way).
"Generic" apps like NFC TagInfo usually try out "well-known" keys, before declaring a sector content "unknown". They don't try to hack the keys.
You can also use more advanced products, like MIFARE Plus or MIFARE DESFire, which both use AES cryptography for authentication and data encryption.
I'm creating a system that uses NTAG203 tags to identify accounts. The tags are formatted in the following way:
An Android app reads the tag's unique id.
The tag id is sent to a web server.
The web server creates a new account record, create a hash and salt from a combination of the new account id and the tag id and stores the hash and salt with the new account record.
The hash is returned to the Android app which then writes it on the tag.
When the tag is then scanned in future, the hash and tag id is sent to the web server for authentication.
My question is, how easy would it be to duplicate a tag like this? This would involve creating a tag with the same unique id, is this possible or can only NXP create the chips?
Creating or modifying a tag such that it is identical is probably rather hard. However, emulating such a tag is not so hard. Several hardware platforms or schematics for them that can do this can be found on the Internet.
In general, it is not a good idea to make your security depend on the uniqueness of the ID or address of a piece of hardware that was not designed for security.
You could use NDEF record type 'U' well known category type 1 (drop the http:\) or type 2 (drop the https:\) and write protect the tag after a successful write - remember that the OTP also should be set for the NDEF aspect to work else you will have either a TAG DISCOVERED or TECH DISCOVERED (which means either it has content but not NDEF else is an empty tag. Look up the NDEF standards for NFC, which are NOT part of the android framework, but is used by the framework.
Trap the tag ID (NDEF DISCOVERED or TECH DISCOVERED or TAG DISCOVERED) - if NDEF then do the server lookup, else treat as an empty tag - pass the Ident (remember its the 14A not 16A image value!) to the server for lookup, and on return perform a dead drop write (else display a button and let user press with tag present). The encoding and decoding action of the NDEF NFC will be then as per the user phone setting, and automatic by android.
The 'emulation' aspect of a ISO14443 (a,b,c) tag by a device is still in its infancy, but if an Ident is present, has got a lock field and user area that is consistent then it is fairly difficult to duplicate - but add in some obfuscation and it gets interesting. There is a requirement that certain areas cannot be written to, or the lock bits undone, will give you an idea if the tag is being emulated or not. The NTAG201/NTAG203/MIFARE tags are freely available, look on ebay.