pull down to refresh
20 sats \ 2 replies \ @gnilma 16 Jul 2023 \ on: Questions about CoinKite satscard bitcoin
The Satscard FAQ might shed some light to your questions.
From the FAQ
So, once a slot is unsealed (WIF private key known and readable from the card), it cannot be sealed again and the funds are always accessible as long as you know the private key.
To use the next slot, you can add your own entropy to the new private key associated with the new slot, so I don't think any sophisticated actor can access future slots, because even if they could guess the private keys of new slots, they could not guess the additional entropy new owners will add. And it's as secure as elliptic-curve cryptography used for pre-taproot private-public key pair generation.
The point of the satscard is that it is a bearer asset. Whoever has possession of the card can access funds already on the card. But it seems that if you pass it onto someone else, you no longer have access to future slots available on the card.
I read the FAQ. I guess what I don't understand, and they don't seem to be very detailed about, is how the person receiving the satscard as payment knows that I didn't access the current slot, thereby copying the private key and essentially perpetrating a double-spend. They say that unsealing a slot causes a permanent change to the flash memory which would prevent double-spend, but how? How is this permanent change implemented and how do I prevent someone from working around it?
reply
In order for you to access the current slot and copy the private key, you need to unseal the current slot. During an unseal, the card changes its memory, namely flagging that the current slot had been unsealed and the new user can easily check that with cktap or Nunchuk. So yes, like what you said, changing the flash memory which shows the new user that a slot was unsealed.
If you want to understand the inner workings, you should check out the Coinkite tap protocol GitHub. Start with the README.md file and I suggest you give the Tap Cards Protocol doc a thorough read.
But in an attempt to shed some light your question, I'll quickly point you to look at the Satscard only commands, namely the unseal command and the dump command.
When you use your card reader (on phone or computer) to send the unseal command to the card, the card changes its own memory and marks the current slot as unsealed, and also returns the spending information back to the reader.
You can check any slot in the card by using the dump command. If a slot had been unsealed by accident or any other means, the card will let you know via the tampered return field.
The tampered field is only present (and True) if the slot was unsealed due to confusion or uncertainty about its status. In other words, if the card unsealed itself rather than via a successful unseal command.
There's an emulator if you want to play around with it without having to unseal a real card slot.
Pointing you again to the FAQ, you can use cktap command-line software and a USB NFC card reader connected to your computer to check and see if the card had been tapered with. Or if you trust their partners, Nunchuk supposedly checks the card's validity.
How do I know I'm seeing a real SATSCARD?
There are a number of ways to verify the card:Tap on it and view the verification page. Use cktap command-line software. Use it with a SATSCARD-ready mobile wallet.
And more FAQ sections that I think are quite relevant to your question.
How do I know the manufacturer doesn't know the private key?
When creating a new slot, you have the option of providing a 32-byte chain code. That chain code, plus a private key picked by the SATSCARD, are combined using the BIP-32 standard to derive the payment address (m/0).
You can use the chain code you provided and the public part of the SATSCARD's key (shared even when sealed) to derive the payment address. Matching this address with the one given by the card means you can be sure the SATSCARD used your entropy (the chain code). Even if the SATSCARD was using a fixed private key, access to the funds is not possible since the chain code is unknown to anyone else.
More about this in the key picking whitepaper.
Couldn't SATSCARD be generating private keys that look random but are all from the same HD (BIP-32) tree they control?
No. Each customer provides their own chain code for entropy. Before making a deposit, a customer can verify SATSCARD incorporated the chain code entropy when generating the keys. At the factory, we use the Bitcoin block hash of a recent block as the chain code; this is also unpredictable since it's a product of the Bitcoin mining process.
In contrast, the original OPENDIME required you to unseal before verification. You also had to track all 256 bytes of entropy during ownership.
If I get a SATSCARD initialized by someone else, they will know the chain code (32 bytes) used, so maybe they know the private key?
No. The SATSCARD itself always provides 256 bits of high-quality entropy into the same process as BIP-32. The device carefully picks its contribution to the private key, using a TRNG certified by the card maker. The chip's hardware is certified to Common Criteria evaluation assurance level 6 (EAL6). That process covers the TRNG's operation and most of the crypto math we use.
What if I make a malicious SATSCARD?
Each SATSCARD made by Coinkite carries a certificate, signed by our factory. Like the X.509 certificate chain for OPENDIME®, it can be traced back and verified in the field.
The Python code in cktap will always verify the certificate chain when speaking to a SATSCARD.
Verification does not require Internet access.
What about an active MiTM attack or relay attack over NFC?
A man-in-the-middle can't change what you're doing with the card. ECDH (Elliptic-curve Diffie-Hellman) is used to encrypt key values like the card verification code (CVC) required to modify the card or view keys. Similarly, when being read from the card, the private key is encrypted with ECDH.
reply