RoadTest: Infineon Blockchain Starter Kit
Author: Jan Cumps
Creation date:
Evaluation Type: Development Boards & Tools
Did you receive all parts the manufacturer stated would be included in the package?: True
What other parts do you consider comparable to this product?: European eID
What were the biggest problems encountered?: find an NFC reader that's compatible with the Python software examples understanding how the card supports blockchain
Detailed Review:
|
The Infineon Security 2Go Smart Cards are NFC tags that have on-board logic to support blockchain processes. The Starter Kit is a set of 5 smart cards, an Android app and a set of examples that show how the cards can support safe blockchain operation.
|
The starter kit box contains 5 Infineon 2Go smart cards and a flyer. That's it. But it's enough.
You actually own 5 little computers. Each capable of holding secrets and performing security related actions.
A smart, by default, is a microcontroller + antenna hidden in a credit card sized plastic tag.
The controller has non-volatile memory to store public and private keys. It also has it's own fixed keypair.
It's pre-programmed to perform key-related activities.
Communication and supplying power are via the antenna.
Some highlights of the functionality:
There's a number of additional resources, documentation and software.
The wealth of supporting resources more than makes up for the sparse box content.
Documents:
image source: User Manual Blockchain Security 2Go Starter Kit
After reviewing all resources of the kit, I'd say that the easiest way to learn the value of the cards is to load the app source code in Android Studio.
Then connect your smartphone to your PC and use the Studio's debug functionality to load the app.
Set a breakpoint at some interesting points, use the app and inspect the code and variables. Then step through the code.
I found that the 3 most interesting points were when a card is detected, when a transaction is sent to a blockchain network and when a vote is sent.
All other documentation (and maybe my posts I'm linking in below) will then help you to understand what's happening.
If I have to describe blockchain as simple as I can, I'd say it's a linked list.
A list where you can only put transactions at the tail of the list. And only if you are an agreed participant.
You can only do that if that transaction is properly signed and verified.
A transaction can be a transfer of currency between two blockchain addresses. It can also be the execution of an approved contract.
There is a mechanism to detect that you are trying to meddle with existing transactions.
A participant in blockchain is represented by a blockchain address. The address is derived from your public key.
When you put a new transaction on the chain, you have provide a signature that represents that transaction's data. The signature is created using your private key.
The signature of the last transaction has to be included as a data member when calculating the new signature. That takes care that it's terribly difficult to meddle with data and sequence later.
Blockchains are expected to be distributed. Many players should run an instance of the chain. They have then the chance to validate and accept or reject any new transaction.
The validators use your public key to validate the signature you put in the transaction.
Smart Contracts are a specific kind of transaction. They are a block of executable logic that has been reviewed and approved by the players. When executed, it can transfer amounts of goods between accounts based on the algorithm.
The cards support these main functions:
image source: User Manual Blockchain Security 2Go Starter Kit
The first part you usually do once. You create the key and the card stores it.
Every time you need to make yourself known (e.g. to play sender or receiver in a transaction in the app), the public key can be retrieved.
There are then APIs (not on the card, public available code), to render that into the blockchain representation.
image source: User Manual Blockchain Security 2Go Starter Kit
This is the spectacular part. The private key that's stored on the card is used to sign the data that you want to push up the chain.
You use the APDU API to send a hashed representation to the card, and it replies with a signature. Made using the private key. Can be verified as valid by anyone that holds your public key.
One of the main dangers with electronic signing is that someone gets hold of your private key.
With these cards, there is no (known to man) way to retrieve the private keys. They are generated by the card, stored there but not accessible by anything but the signing algorythm.
The app uses a scenario where you want to exchange Ethereum crypto currency between parties.
When the app starts, it doesn't know any of the parties.
I as a sender make myself known by tapping my card on the phone.
The app uses my public key to find out my Ethereum address.
It then connects to the Ethereum network to retrieve my balance and shows it in the app.
image source: real test with my cards
I can then say I want to send some of that balance to a receiver, you.
I push the Send Currency button, and the app then expects a 2nd tap of a card. The card of the receiver.
So you take my phone and tap your card against the back.
I take the phone back and fill in the amount.
image source: real test with my cards
At this point, nothing secret has happened, but the card functionality has been used twice.
Once to determine who I am (sender). Once to determine who you are (receiver).
And the blockchain network is contacted 3 times:
2 times because the app uses it's API to retrieve addresses from the public keys, and 1 time to get the sender Ethereum balance.
Then the last point happens: confirming the transaction.
Because it's the sender that has to give away the balance, it's normal that it's expected from that person to confirm the transfer.
This is done by again holding the sender's (mine) card against the back of the phone.
The app will then use the APDU API to send a hashed version of the transaction data (in this case, all fields you see on the screen, and the hash of the previous block in the chain) to the card.
The card then sends that hash to the signing engine - that will use the private key to generate a signature that represents that hashed data.
That signed value becomes part of the transaction that's pushed up the chain.
At this point, because the transaction hasn't been validated by other members, both cards will show a theoretical amount, if you tap them to the app:
image source: real test with my cards
After some time, the transaction is verified by some partners and the balance is firm.
image source: real test with my cards
Check my post linked below for a very deep dive into the app and the code. There's an easter egg.
I've used the term APDU a few times above without explaining it. It's the way to communicate with these smart cards.
APDU is a low level protocol that only exists out of data blocks. Blocks you send and blocks that you receive.
The sending payload contains info about the functionality you want to invoke, its parameters and the dataset that the function has to work on.
The returning payload contains the exit status (sucess, error), and additional info such as a public key, PIN status, hash signature, ...
image source: real test with my cards
All programs I've seen have built a wrapper around these APDU calls. They are too abstract to be used in code and then to understand that code. It's arrays of bytes.
In the Android app, they have done this very beautiful. A class per APDU function:
image source: session in Android Studio
I've tested almost everything, except these:
PIN functionality: I haven't used PIN codes and the related APIs. Because I wanted to focus on the key generation and signing. PINs add an additional safety layer, but also the requirement of a human typing the PIN. And that interferes with the debug work I'm currently doing.
I want to step through code without having to switch to the GUI view to type the PIN.
The Python libraries: I don't have a matching NFC reader. There's a list with supported readers. I didn't find an easy-to-order one in the list, took a risk and bought a different one. That wasn't a success.
I've been playing with part of the lybraries though. My Belgium eID, and the reader that comes with it, is compatible with some pieces of the libraries. But I didn't test the Infinity 2Go cards. Maybe something for one of the fellow road testers.
Smart Contracts: The app has the functionality to test a smart contract: the Voting functionality. Although the app succeeds in building and signing the contract, then sending it to the BlockChain, it never appeared as a transaction.
Stepping through the code helped me to understand how to use a contract in practice. Seeing the result would be that extra bonus. I think the error is on the Ethereum side (maybe no candidates to validate it anymore?). I logged a bug report.
update: this works. Infineon support replied on my bug report. I did not supply enough gas. See comments for the results.
I learned a lot. Really. Installing my own blockchain. Understanding blockchain and smart contracts. Generate transactions and stepping through each part of the process.
How an Android App works. Debugging on a Smartphone. RFC technology and the industry standards + APIs. A bit of GOLANG. A lot.
Check out the links below to see the writedown of all of that. And:
Thanks for the opportunity to road test the kit !
Top Comments
Your smart phone reference provided a physical point to follow. Great job.
Hi Jan,
Excellent review! And your notes on Hyperledger Burrow will be super-helpful to many. These have commercial significance, definitely worth learning, and it's nice having the knowledge and tools…
A possible practical scenario, with blockchain and app would be delivery of goods with traceability.
Requirements:
- QR code on the box (or an embedded NFC token.
Deliverer and Receiver have a card.
Scenario…