This post is part of the Infineon Blockchain Starter Kit road test.

Blockchain - outside of the bitcoin context - is new to me.

Follow along with me on this path to learn the technology....

The Security 2Go Starter Kit User Manual describes the specifics for the cards of the Road Test.

And it comes with an example communication. I'll review part of that example here.

The commands that are supported by the Infineon cards and documented in the user guide are these:

image source: User Manual Blockchain Security 2Go Starter Kit + the envelope that my reader came in

What you need to test APDU (and the example from the user guide) is an NFC reader/writer that supports ISO/IEC 14443, and software that allows you to send and receive data via that reader.

I'm using Digital Logic's µFR Nano as reader, and their µFR APDU Send/Receive test application.

The app is easy to use. It's a minimal wrapper, accepting APDU commands, returning reply and status code.

Ideal for testing scenarios as the one in the user guide.

If you happen to have a PC/SC compatible reader, there are device independent test programs for this on various operating systems.

APDU Example: Open an Application Session with the Card

Send the SELECT APP command

This is the first command you have to send to the card before it can be used in a scenario.

The APDU command will be: 00A404000DD276000004150200010000000100.

It looks magical now, but it's explained below.

image source: User Manual Blockchain Security 2Go Starter Kit

APDU Send / Receive Communication Script

• 00 this is the instruction's class
• A4 this is instruction A4: SELECT APP (open application session)
• 0400 parameters 1 and 2 (both a byte). 04 indicates that the app is determined by the DF name. Second parameter is not used in this function.
• 0D the AID data field hereafter has a length of 13, (0x0D)
• D2760000041502000100000001 the AID of the Infineon cards.

• 00 length of the reply. The value Infineon's guide suggests here surprises me. The instruction doc says it expects 18 (0x12). The test app says we got 15 bytes back...

Analyse the Reply

This is what what the card sends back: 0002090C2900020040001576312E309000.

• 00 the pin isn't active - pin not set (by me)

• 02 09 0C 29 00 02 00 40 00 15  the ID of this particular card - If I tap another card this is different

• 76 31 2E 30 the ascii version string. Strange enough different than what's documented and what the card returns in the user guide's example. v1.0. That's 2 bytes shorter.

• 90 00 the return code. Success

So I get a successful reply but the version part of the reply puzzles me.

In particular because the definition with length 7 and then the example returning 6 bytes are in the same document, a few pages appart.

Now my own test: Get a public Key

The command should be, for the key with index 1: 0016010000.

Here's the test:

The answer is 9000, so that's a success. Let's look at the rest of the reply: 000F42360001869604D82CCB636938D3B7C721796BDB005C06D267881EF45C7989E43E96DF321CDAB14E69385C2D20BEC02C401274EA1C3EC77BFF090CD02E6D29AA160782CD73580D.

• 000F4236 how many signatures left for this card: 999990
• 00018696 how many for key #1: 99990
• 04D82CCB636938D3B7C721796BDB005C06D267881EF45C7989E43E96DF321CDAB14E69385C2D20BEC02C401274EA1C3EC77BFF090CD02E6D29AA160782CD73580D 65 bytes
  • 04: fixed value
  • D82CCB636938D3B7C721796BDB005C06D267881EF45C7989E43E96DF321CDAB1: 32 bit x-coordinate
  • 4E69385C2D20BEC02C401274EA1C3EC77BFF090CD02E6D29AA160782CD73580D: 32 bit y-coordinate

That's it. Talk to the card's on-board microcontroller via the APDU protocol. Initialise a session, then ask some data (one of the public keys).

That's the basis for all applications dealing with the card. You'll find exactly the same commands back in the Android app discussed before.

How does this link to blockchain?

Several of the functions in the card can play a role (and do play a role in the coinfinity app).

In blockchain, you work with smart contracts (it's actually executable code that's accepted by parties to perform a certain transaction in the ledger).

When submitting such a transaction, using such an agreed smart contract, you use the keys and API.

The public key (retrieved via the API) is used to determine your blockchain address.

The private key (not available via the API) is used internally in the card to sign the (hash representation of) the data inside the smart contract (calculated via the API).

Your blockchain application will talk to the chain to get info and submit transactions. And talk to the RFC reader to get addresses, keys, and signed hashes.

Your application will orchestrate the services of both the blockchain and the RFC-reader+card to or complete a full blockchain transaction.

Thanks for following along. This is the end of the story.

For the Digital Logic µFR Reader: