RoadTest: Experiment with Blockchain Tech
Author: calistra
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?:
What were the biggest problems encountered?: 0) The documentation was slightly incomplete 1) The card was not designed to generate ethereum signatures. Fortunately the support team responded to my enquiries to explain the limitations. 2) The security could be improved These will be described in the review.
Detailed Review:
The first application I was considering creating smart ID tags that could be interrogated by a security system to sign a piece of arbitrary data thus proving that you possess a specific private key.
1) PIN CODE ISSUES
Unfortunately I found that the card design made this idea quite risky because the card only allows a single PIN code to control all functions.
A single PIN code unlocks
Thus, if I were to provide my PIN and tap my card on a compromised device that I expected to sign a transaction to prove my identity, that device could instead erase the key pair by overwriting it with a new pair. It would be an excellent idea to have seperate PIN codes for each function.
I signed a piece of data and ensured that the extracted public key matched the key recovered from the device.
This uncovered TWO issues
An ethereum signature comprises
2) R and S fields
This card generates either 32 or 33 bytes of data for R and S.
Sadly this was not documented beyond telling that there is a length field for each.
Reply from support
The support team verified that the field would be extended to 33 bytes if the leading bit were set thereby making the number negative.
This is based on the assumption that you are dealing with a language that does not support unsigned integers.
3) The missing V field
The card does not generate a V field. While it is possible to work around this missing piece of data, it makes your code clunky.
Reply from support
The team confirmed that this field was missing and that it would be a great idea to include it in the next software version.
Work Around
Since you can query the card to get its public key, when you sign data, you can test reverse engineering the public key from the signature and the data with varying values of V until you get a matching extracted public key.
Having implemented that method, on re-reading the Android code, I understood that method was also being employed by the android code sample.
Unfortunately, with so many error codes to choose from, it was decided to recycle a couple error codes with just slightly different meanings depending on the call being made thereby making an error logger more complicated to write
| Code | Call | Meaning |
|---|---|---|
| 6982 | Generate Signature | Global or key-specific signature counter exceeded (Security status not satisfied) |
| 6982 | Encrypted Key Import | Maximal number of key import calls exceeded (Security status not satisfied) |
| 6985 | Set PIN | Pin already set |
| 6985 | Several Others | Not authenticated with PIN |
With no documented way to add functions to the card, this is essentially a proof of concept or a demonstration of what can be done with Infineon's NFC cards.
This could be very useful out of the box for a wallet type application as long as you do not intend to use the card in an environment where it could be compromised but I do not feel that Infineon really intend it to have mass market appeal in its current form.
If you were designing for that market you would select a particular NFC tag and design specific firmware for it, however this would involve a far higher learning curve.
Code Samples (Go)
A library to expose some of the functions : https://github.com/DaveAppleton/cardSigner
