The Zippie smartcard is a NFC enabled device which serves the following purposes in the Zippie platform.
First, it is used as a secure element for signature confirmation as an execution step which enables operations such as large value transfers. This signature confirmation may be used, for example, in combination with a personal multisig contract for one-time transaction confirmation. For this reason, the use of the smartcard should not be confused with a hardware wallet, as the card is not used directly as a private key storage device.
Second, the Zippie smartcard is used to enable the recovery of master seeds without the need for other wallet types. The data is encrypted and requires a 256-bit value key to be decrypted. The communication between the card and the reader also records the number of trials for data decryption. Both act as a proxy PIN for recovery of data.
The Zippie smartcard uses the contactless capabilities of the JavaCard standard, which allows the emulation of an NFC tag and generate dynamic content every time the card is scanned.
We will cover both uses of the smartcard in more detail below [section].
The reference cards used by Zippie are ACS ACOSJ 40K dual interface cards. These cards support JavaCard 3.0.4 and Global Platform 2.2.1. For further details on the JavaCard specification see [link].
When scanned, the contactless smartcard secure element exposes the following three elements inside an URL [https://card.zippie.org/v1/#foo], where the portion behind [#] is not sent to the server, but can be read in-browser:
A “recovery” public key A random-per-scan nonce and R and S from a secp256k1-signed nonce, similar to eth_sign signature method. The public key “confirmation” the previous element was signed with. This allows the reader side to figure out ‘v’
The user’s mobile device then scans the card to open the above mentioned URL. Then, a web browser side code selects how to use the confirmation signature. For example, this may require using the signature inside a personal multisig to allow large transaction amounts.
Please note that Android devices have an embedded reader, while iOS requires a different NFC reader to carry out this process.
The following flow illustrates the use of the smartcard for signature confirmation:
To obtain the seed recovery, the smart card reader talks to the smart card through the communication unit (i.e. APDU). Upon this request, the user can ask the smart card to decrypt the data encrypted against the “recovery” public key. To decrypt, the user needs to provide a 256-bit value (AES key), which hashes to a “key” hidden in plaintext. The same plaintext captures how many trials can be done for decryption. So, the number of trials and the bit-value act as a proxy for a PIN number to recover the smart card seed.
The above process enables easy recovery of master seeds without the use of other wallets.
Please note the use of the APDU for communication between the reader and the smartcard only works for Android devices. [Suggestions on iOS?]
The following flow illustrates the use of the smartcard for seed recovery:
Allows user to add a Zippie ID against a smart card
Register card > read card Check zippie cards (fetch) (Home) Check account migration/addition (multisig) Add card (if exists) to add new account (multisig) Check card (if required) and read card at create blank check (blank checks)
How many trials is the user allowed to recover the seed?
What happens if the user has exceeded number of trials?
How can I decrypt the data stored in the smartcard?
- To decrypt the data that is encrypted against the recovery key, the user may use an NFC enabled device (i.e. smartphone) or a smart card reader supporting the interface used by the smart card (ISO 7816 dual interface).
How vulnerable is the Zippie card to unsecure communication risks? E.g. relay attacks