DIY Blockchain

[time]

We sell a service that is metered, with a running balance currently stored on a prepaid Smartcard. The balance gets debited as you use the service, until it is exhausted and you need to buy a new card. It's reasonably secure, but we have to burn a balance onto the cards and ship them around the world, which is a real pain.

We are considering a variation on this where we somehow recharge the card remotely. However, there is a 100,000 write cycle limit on the card EEPROM, which a customer could exceed in a few months with our current metering approach.

It would be simpler to just store the balance, encrypted with other info, directly on each customer's PC.

• For recharges, I'm wondering about employing something similar to the basic blockchain concept. What I'm envisaging is that a customer PC will generate a request for a recharge. The encrypted request token (file) will include the history of previous debits and recharges.
• The request token gets transferred to a remote server, via email or whatever transport medium is available.
• The remote server matches the packaged history against a customer register. If that's in alignment, the server stores the new info and generates an encrypted recharge token specific to that customer and that snapshot of their usage/recharge history.
• The customer installs the recharge token, which is matched against the original request and history.

The reason to include the history each time is to avoid the same recharge being applied twice. You could probably achieve the same effect with a hash or something.

The obvious way to crack this method is to backup the customer PC when the balance is exhausted, then apply a recharge. When the balance is exhausted again, restore the PC from the backup, change the date, and reapply the first recharge - ad infinitum. Or just restore it back to when the balance was full.

In practice, we also have a PLC type device attached to the PC and we could view counters in its NVM (non-volatile RAM) to check alignment with the PC. I'm sure you could crack this if you had enough knowledge and skill, but I'll bet that's in considerably shorter supply than PC hacking expertise.

So, does any of this make any sense to anyone? Can you think of something similar? Can you point out glaring weaknesses?

 

[jtr1962]

We are considering a variation on this where we somehow recharge the card remotely. However, there is a 100,000 write cycle limit on the card EEPROM, which a customer could exceed in a few months with our current metering approach.

How many bytes of EEPROM does the card have, and how many are needed to store the balance? I ran into a similar problem on a bike computer I'm currently working on. It's conceivable if I stored the ride data in the same locations I might eventually run into the EEPROM's write limit. However, the ride data only takes up 12 bytes and the EEPROM size is at least 256 bytes. Therefore, I programmed it to store the data in a different location every time the device goes to sleep (usually at the end of a ride). In theory, that extends the write limit by a factor of over 20.

Anyway, you might want to consider some form of wear leveling before going the route of storing the data on the customer's PC.

 

[Chewy509]

Anyway, you might want to consider some form of wear leveling before going the route of storing the data on the customer's PC.

This (assuming you can get that level of access to the card), or look at another card with higher write cycle limits.

FYI: The Feitian smartcards we use at work have 500K+ write cycle endurance...(and these are the cheap ones).
https://www.ftsafe.com/Products/PKI/Standard/Specification

 

[time]

I'll see your Feitian and raise you an ACOS5. Also 192kB with 500k+ write cycles, as well as RSA 4096 and SHA 512.

Any comments about relying mainly on software?

 

[Chewy509]

OK, There so there are two issues here:
1. Ability to update the contents of the card from a file (increase the balance).
2. Limited write cycle on the current card.

I'll attempt to address both separately:

Ability to update the contents of the card from a file.

This one is pretty easy to deal with using PKI. On the smart card (I'm assuming you're using a smart card with builtin VM which you can run you own applets), you create a 'recharge balance' applet.
The applet, relies on a defined structure of the payload being presented, in that is:

1. Has a data payload (encrypted using pre-shared keys, typically AES 256). This payload includes:
   1. The customer details.
   2. Recharge amount.
   3. Payload sequence number.
   4. Card UUID/GUID (optional - see below).
   5. Some other details for validation (optional - see below).
2. Has a digital signature. (The digital signature covers 1, typically RSA 4096+ or NIST P521 ECDSA).

The recharge applet then:

1. Checks the digital signature and confirms it's signed with a known private key (the applet only needs the corresponding public key).
2. If so, then decrypts the payload, which includes a sequence number. If the sequence number contained in the new payload, is equal to or less than, (or not in expected sequence of numbers), as the existing sequence number as already stored on the card, the applet rejects the new payload. (This is what avoids a replay attack).
3. If the sequence number is greater than the existing sequence number (or in the expected number sequence), then we apply (write) the new data payload (customer details, new recharged balance, etc).
4. In addition to the serial number, you could use additional details, like the UUID/GUID of the card (you do that this), the last 2 transactions (date timestamps, values), etc to add further validation points, in addition to a sequence number.

On the server side (the application generating the new payloads), simply needs to know:

1. The pre-shared keys for encrypting the payload. (can be stored on a PKCS11 HSM to avoid leaking).
2. The private key to sign the payload. (can be stored on a PKCS11 HSM to avoid leaking).
3. The last sequence number used to generate the last payload loaded onto the card. (so it can generate the next expected sequence number)
4. and optionally, any other verification elements, (last few transactions, the card UUID/GUID which can be provided as part of the request to the server).

If you need to update the public keys on the card, use a similar technique to the above, but instead of the payload being a new recharge amount, it's the new public keys for the signer.

The above is fairly robust, in that an attacker needs to:

1. Obtain the private key to sign the payload.
2. Obtain the pre-shared key to encrypt the payload.
3. Determine the last sequence number used and know how the new value is calculated (could be incremental, could be part of a random sequence).
4. Determine the card UUID/GUID. (If used as validation points).
5. Determine on how to extract the transactional history. (If used as validation points).

Further, you can (and probably should) create an appet on the card that generates a request token data block, that is sent to the server as well rather than relying on a desktop application to generate the request token. (Using an applet to generate the request token, partially solves points 4 and 5 above as well).

So no block chain required, and replay attacks are difficult, and if applets on the card to validate incoming payloads and generate recharge requests data tokens, then the desktop/PC point is rather mute.

For additional security, I'm assuming you're setting custom PINs/passphrases on the card to ensure only you guys can write/create/read/delete applets off the card?

Limited write cycle on the current card.

As discussed, write leveling (if available) and switching to another card with a high write cycle count is the easiest without changing card readers etc. Otherwise, you could look at using RFID based smart cards (Amtel sell a few that spec 1M+ writes - https://smartcardamerica.com/product/at24c64-card/).

 

[time]

That's gold, thanks.

The card is already setup with its own software to debit the balance - their target market is simple financial cards.

For additional security, I'm assuming you're setting custom PINs/passphrases on the card to ensure only you guys can write/create/read/delete applets off the card?

The cards have different states, one of those being a 'manufacturing' state that enables full access. That is permanently disabled before shipping.