PCSC | pcsc-lite : PC/SC implementation | Telnet library

The option with System.setProperty works for me.

The only problem in my case was, that there was a typo in the property name. The correct property name is sun.security.smartcardio.library

Finally, I found the solution, I need to select AID before execute the GPO. (It's Mandatory, it doesn't work if you try to execute GPO directly)

1. Request AID --> 00 A4 04 00 A0000000031010 00
2. Request GPO --> 80 A8 00 00 8302 00

After that, I was able to get GPO response.

I hope it'll help

The Type 4 NDef Spec might help at https://web.archive.org/web/20190827131645/http://apps4android.org/nfc-specifications/NFCForum-TS-Type-4-Tag_2.0.pdf

I assume you have done all the file select stuff correctly

but the update procedure in the spec says

The NDEF update procedure is:

1. If the length of the NDEF message (to be written) is bigger than Maximum NDEF size-2 (see NFC File Control TLV in Section 5.1.2.1), the NDEF update procedure is aborted. Otherwise, go to item 2.
2. Write the value 0000h in the NLEN field (see Table 9) using the NDEF Update command.
3. Write the NDEF message in the NDEF message field (see Table 9) using one or more NDEF Update commands.
4. Write the length of the NDEF message in the NLEN field (see Table 9) using the NDEF Update command.

It seems as the NLEN field has a size then your offset should never be zero but 2h

I've not tried this with Type 4 Tags but thought the spec might help you.

The PCSC library does not appear to explicitly support Android. In my experience, nugets that work with Xamarin.Android have explicit dependencies set for the platform, but this one does not.

The library tries to use P/Invoke wrappers around native code. You can see that there are implementations for a number of operating systems here, but I don't see any references to Android. The stack trace shows that the code is deciding to use the Linux wrapper, which makes sense. It's looking for the libpcsclite.so.1 native "C/C++" library, but it's not finding it. That library has a home page that does not reference Android.

The PCSC nuget docs state:

pcsc-sharp does not contain any device drivers. A PC/SC compliant reader + driver is mandatory.

That's the libpcsclite.so.1 . Either your Android device doesn't provide it, or if it does, it's not in a location that your Android app can find it. My Android device (running Android 9) does not have that library in any of /system/*lib* directories, which means that at least for my device someone would need to compile that native library for the CPU (usually arm64) for the device. If you can either compile the native code yourself or find someone who has, AND the native code supports the reader on your Android device, then you could get the whole thing to work.

I don't have any experience with PCSC myself - just some experience with Xamarin and native libraries.

Finally I need to update from PHP 5 to PHP 7 (late enough). The REMI repo for CentOS unfortunately does not support PCSC for PHP7 anymore so I tried to install it manually by using the command:

If the extension was compatible, it would be in the repository, as all other extensions

So this looks as a dead project.

I had no detailed look into Tachograph specification for years, but this might help you to start:

• a challenge is just a random number, you have to encrypt it (symmetric algorithm) or sign it (asymmetric algorithm) by yourself. The appropriate algorithm has to be defined before, since the card has to follow the same rules for checking.
• external authenticate is far more likely using symmetric cryptography (nobody likes to sign something unknown, which could also be a hash code for a message)
• there are two standardized modes for retrieving the public key:
  • either as response to a special Generate Asymmetric Key Pair command (there is one, which just reads but does not generate a new key)
  • or in some file to be read using standard READ commands (e. g. a certificate which has the advantage, that you may check its signature). Which case applies has to be stated in the specification.
• Manage Security Environment just informs the card, which key to use for a subsequent operation like PSO, giving its Control Reference Template, id and usage qualifier

Henry, from your latest comment to @guidot it looks like you send the SELECT EF.COM twice? First without Secure Messaging which will destroy your trusted channel established with BAC, followed by the secured APDU, which then tries to use the session keys / trusted channel that no longer exists.

Your error says:

main.cpp:(.text+0x140): undefined reference to `logicalaccess::LibraryManager::getReaderProvider(std::__cxx11::basic_string, std::allocator > const&)'

It occurs because your CMake is using libstdc++11 to link, however, Conan is configured to use libstdc++ due backward compatibility. You need to update your default libcxx:

Some time ago I looked into this in detail and concluded that the PN532 NFC controller chip from NXP has an issue with its firmware that prevents it from successfully transceiving some commands with NFC Forum Type 1 tags (Topaz/Jewel brands). The ACR122U is based on this chip as noted.

When I tried to write 8 byte blocks at a time using the WRITE-E8 (0x54) command, the response received is 0x01, a timeout waiting for the tag to respond.

Things I tried that don't work:

Including the UID echo in the InDataExchange, I even played with the endianness of the UID echo and still the same result.

Using the inCommunicateThru command rather than InDataExchange and calculating the CRC1 and CRC2 values at the application level (same results)

The final conclusion I reached is:

The PN532 cannot write to pages 0x10 and greater on a Type 1 tag which makes it impossible to write to the full range of memory on popular models such as the Topaz 512.

Recommendation:

This issue was relevant in 2012 when the Topaz 512 was a great low cost yet high memory NFC tag. Now that there's the NAG215 and NTAG216 models, I recommend using those models that have high memory and universal compatibility with NFC readers.