I can encoded an NFC Sticker with a website that will open when I tap it with a mobile phone. For the application I want to use it for I need to be able to expire that link so the user can't just save the URL and use it again. Basically I need to be able to put a random string in the URL that changes each time it gets scanned, such as www.mywebsite.com/TCHQ23, www.mywebsite.com/LQ8FT, ect.
Is this possible with a regular NFC sticker? If not, what kind of device would I use to make this happen? I know there are Arduino modules that can do this, but is there a simpler method or a ready made product that can act as an NFC but have the URL changed by a computer via a USB cable?
Thanks
NFC tags (some) have a feature called "Mirroring". You can mirror the read counter value to the URL, which gets incremented every time you tap it to reader i.e. Every time read command is called, the counter increases by 1. Tags like NTAG 213, NTAG 215 etc have that feature.
Update:
If your requirement is to get a portion of URL to to return random data and on a cheaper tag or sticker then I would suggest considering NTAG 213 tag, which is cost friendly and also have Mirroring feature supported.
If your URL data is http://www.abc#xyz.com then once the counter Mirroring is enabled (read counter must be enabled first) it will look something like
http://www.abc#xyz.com?000001
The last 6 digit value gets increased by value 1,every time a read command is invoked. (000002, 000003, 000004 and so on)
you can refer this link for more info
So your card/device has to present when read a NDEF record with a link in it (A "Well Known Type 1 with a record type definition of type U, etc), this will cause most phones to open a browser automatically
Some details on the Record type needed at https://www.oreilly.com/library/view/beginning-nfc/9781449324094/ch04.html
Most cards have the ability to store some static data, some have as #Adarsh Rotte says have counters, random number generators, crypto, password protection, mirroring (backup) of data, other functions but non of these will help as these custom functions and are card specific and don't / cannot present the data to match the NFC NDEF specification.
There is one type of card that can do this called JavaCard as these can run fully programmable Java Apps. These can be programmed to respond to NFC read request with the right NDEF measure where the URL can be generated on the fly.
There is a github repo with an example Java App to run on these cards that shows how to respond with and NDEF message at https://github.com/OpenJavaCard/openjavacard-ndef.
Watch out for https://github.com/OpenJavaCard/openjavacard-ndef/issues/10 if trying to use this, the default magic AID number is not the right one for NDEF and should be configured at the time you install the App on the Card.
This app emulates the behaviour of an NFC Type 4 spec card.
You would also need to customise it to have the right NDEF payload data with the right generated URL ending.
There are examples of the Card make/model supported by this App listed on the the github pages some are dual interface cards but there are some without the chip contacts and only NFC interface.
Generating the URL ending could be challenging or easy depending on level of security/validation you need.
Starting from a Random String which would be easy to fake because it has no level of validation, to a obfuscated counter, to a public key type encrypted counter.
There are also other solutions to generating the NDEF data with the right URL that don't use a Card and usually require there own power to run.
Some options:-
An Android phone can do what is call Host Card Emulation (HCE) which is very like what the JavaCard is doing, it is pretending to be a NFC Type 4 Card and the response it sends if fully programmable and could be the right type of NDEF message as per the JavaCard.
There are some "Card Reader" Devices that can be attach to a PC/Raspberry Pie via USB can also do HCE like the Android phone. e.g. https://www.acs.com.hk/en/products/342/acr1252u-usb-nfc-reader-iii-nfc-forum-certified-reader/ - this is well documented in the datasheets on how to do.
There are some other "Card Reader" modules that can connect via I2C to Arduino that can do HCE as well. (Technically most Arduino PN532 Chip's which are used in a lot of USB readers as well can do HCE but it is a bit undocumented on how to do it - see section 4 of https://www.nxp.com/docs/en/user-guide/141520.pdf)
There are some other chips that can act as static data NFC devices the also have an I2C interface to write the static data but allow a "pass through" mode to the I2C interface, again these tend to be NFC Type 4 but do some of the HCE type work for you.
e.g. the M24SR04-Y https://www.st.com/resource/en/datasheet/m24sr04-g.pdf can do it
So technically possible with a variety of methods but all not that simple to implement BUT not "Sticker" type format of NFC devices tend to be very simple NFC device as the format restricts the complexity of the hardware contained in them.
Related
How does an OS maps USB device with its device driver? I understand that in the interface descriptor of client USB firmware if no class type has been selected for the device then developer has to provide its own device driver.
I am keen to know how OS maps the pluggged USB device with its device driver? Does descriptors in the USB client firmware contains the file name of the custom device driver? Please let me know.
As a hobby, I have done quite a bit of work with the USB hardware, and had these same questions when I first started.
An OS can map a USB device any way it wants. However, to be more precise toward your question, a USB device will, and must return a class and interface code. Granted, that class code can be 0xFF for user-defined, where the device now must require a unique driver.
In my opinion, this is where the USB shines. All USB devices that return a valid class code specified within the USB specification, will and must follow a specific sequence of events and will "work right out of the box" as indicated. However, this doesn't mean that it cannot have extra capabilities.
For example. A pointing device, such as a mouse, will probably always follow the boot protocol when first plugged in. This is the protocol used and specified in the USB specification so that any OS that follows this protocol can use this pointing device. This protocol specifies a simple three (or more) byte packet for pointer input.
Byte Description
0 Button(s)
1 X Displacement
2 Y Displacement
3 (Device Specific) (optional)
Any pointing device that follows the USB specification most likely has this protocol and will use this protocol until told otherwise. This is so any USB capable OS can use the pointing device.
Every USB device also has a vendor, device, and protocol definition. Once the OS has found this device, it can search through its drivers for a driver that can support this device. That driver, once loaded, can then tell the device to now use a different protocol. i.e.: Return a different Input Report.
Here is an example. Let's say that you have a fancy gaming mouse with three directions of displacement (X, Y and Z), and six buttons. As the OS is booting, it probably has no idea how to use that mouse. Therefore, the manufacturer creates the mouse to use the boot protocol shown above until the driver can be loaded. Once the driver is loaded, which knows how to use the three direction displacements and all six buttons, it can tell the mouse, through a Control packet, maybe the SET INTERFACE command as well, to now start sending a different report, now using the full capabilities of the mouse.
So, as along as the device is USB specification accurate, and has a class code not of user defined (0xFF), the device will be recognized, even if it is a minimal use and/or is to show a statement that a driver is needed.
As for giving a file name of a custom device driver, this is all up to the device manufacturer. However, usually this is not that case. Usually, the OS will retrieve the DEVICE DESCRIPTOR which contains the manufacturer, device, protocol, and other fields. It will then match any driver to those fields. If it does not find a compatible driver, it will ask for one.
For example, one of the pointing devices I used with my research has the following few bytes of the 18-byte Device Descriptor:
Offset Field Value
0 Length 0x12
1 Type 0x01
2 Release Num 0x0110
4 Device Class 0x00
5 Sub Class 0x00
6 Protocol 0x00
7 MaxPacketSz 0x08
8 VendorID 0x04FC
10 Product ID 0x0003
...
Notice that it specifies the Vendor and the Product. Using these two values, a compatible driver can be found.
Now, notice that the class code is zero. This is not an error and is a perfectly valid class code, and simply means that the interface descriptor is to be used instead.
So, hopefully with this information, and specifically, the Manufacturer and Product codes within the DEVICE DESCRIPTOR, you can now see how an OS can find the correct driver for any device.
I am using winscard.dll within my Dotnet smart card application. My reader, an Omnikey 5321 has both a contact and a contactless interface, which are detected as two different readers. The contactless has the letters "CL" within it's name. I have no problems manually selecting the readers and doing everything I need to with them.
Is there a reliable way however, using SCardGetAttrib or another call, to determine which of these readers supports ISO14443 - i.e. EMV contactless? I would ultimately like a quick "Select Contactless settings" button, which would be generic enough to work with all PC/SC readers, and therefore also allow me to disable contactless options if such an interface is not present.
No, there is no such method simply for the reason, that PCSC is older than contactless technology (ancient contactless chips were older but required special readers and drivers, so there was no overlap). Therefore only the naming convention for the reader name provides this information ina manufacturer dependent way. In practice, this does not matter. You don't label your readers, so that the user is able to select the correct one but typically simply demand, that the user plugs in/lays on the card to the reader. PCSC will then allow to detect, which reader is loaded, as long as it is only one.
You can use Advanced Query Syntax to search for devices exposing smartcard interface class and having NFC enabled.
string query = "System.Devices.InterfaceClassGuid:=\"{DEEBE6AD-9E01-47E2-A3B2-A66AA2C036C9}\"";
if (readerKind != SmartCardReaderKind.Any)
{
query += " AND System.Devices.SmartCards.ReaderKind:=" + (int)readerKind;
}
DeviceInformationCollection devices = await DeviceInformation.FindAllAsync(query);
where readerKind is of Windows Runtime type Windows.Devices.SmartCards.SmartCardReaderKind. Code snippet comes from official Microsoft NFC UWP example (PscsUtils.cs).
How does DirectInput generate the GUID for the guidProduct field in DIDEVICEINSTANCE? The documentation reads:
guidProduct
Unique identifier for the product. This identifier is established by the manufacturer of the device.
I am searching for a way to retrieve or synthesize the product GUID for a joystick without using DirectInput. I have successfully used RawInput to retrieve the device path and class GUID, but I have not yet found a way to retrieve the product GUID using RawInput and/or SetupDi* functions.
While searching, I noticed that MAKELONG(VID, PID) == guidProduct.Data1, which makes me hopeful that there is way to do what I want (DirectInput somehow does it, after all.)
Questions:
Is there an API to retrieve the product GUID for an HID (esp. joystick) device?
If not, does anyone know how DirectInput synthesizes this field? (The first fields combines VID and PID. What about the rest?)
Edit:
By hacking around the guidProduct field, I came across an interesting discovery. The product GUID for the P880 USB gamepad has the following format:
010906a3-0000-0000-0000-504944564944
The first 4 bytes are quite evidently the PID and VID for the controller. The last part of the GUID is common for all HID controllers in my possession. After a while it dawned on me - they are ASCII characters! The translation is:
010906a3-0000-0000-0000-504944564944
010906a3-0000-0000-0000- P I D V I D
PID_VID_-0000-0000-0000-'P I D"V I D'
I have verified this using the SDL2 game controller database, and it appears to hold! Of course, this does not cover bluetooth devices (such as the OUYA controller), which is only a minor issue for now.
Does anyone know how guidProduct is composed for bluetooth devices?
I can't find information about if it's possible change AFI number in RFID chip with NFC. I'm sure it's possible read AFI number with NFC. AFI number has some special block on RFID chip thats reason why I'm not sure if it's possible change it. Thank you
For a ISO 15693 tag you can use the NfcV command transceive(byte[] data) to send a "write AFI" command to the tag, followed by a "Lock AFI" command to lock the AFI value.
Write AFI has the command code 0x27. Lock AFI has the command code 0x28.
This should work as long as the RFID chip supports AFI (AFI is optional) and the AFI of that tag has not been programmed beforehand.
You can find more details about AFI in the ISO 15693-3.
See: See Android reference for transceive()
Have you seen this post about the application family identifier : google
In ISO 15693, the AFI describes the type of application targeted by the reader. This identifier is used to extract all transponders in the reader field that meet the required application criteria. After the reader sends out the AFI, only the AFI-compliant transponders of the appropriate family will respond. Programmed by the transponder issuer, the AFI is read-only and its value cannot be modified.
However I see some systems seem to allow you to write the AFI code, and sa well as lock it. I guess it may be up the individual the chip manufacturer. So while its not locked, I guess you could change it. Who makes your the card you are trying to write to?
I'm attempting to start coding for the new NTAG21X due to be released by the end of the year. There is very limited information available regarding the new tags. Only released to partners :-(
I'm trying to figure out how to use:
password protection on the tag. Will this be a key stored in one of the sectors and how will you go about reading NDEF? Do you pass the password to read?
originality signature. Will it be a sector as on Mifare where you write key and lock the page(s) to protect.
NTAG21x is (will be) a NFC Forum Type 2 Tag (T2T) device, like NTAG203 (hence the "2" in the names). You can expect accessing functionality will be similar to standard T2T (and MIFARE Ultralight) read/write commands (so no MIFARE Classic sectors). Reading of NDEF shall be according to the T2T spec, so no password required. Write protect could be possible (similar to MIFARE Ultralight C).