Android Question NFC mifare card - read and write in the same operation

you can do as many operations as the card and physics will allow. the more
you try to do, the more risk of messing things up. if the tag is not held steady,
there could be a disconnect which might leave the card in an undesirable
state (eg, balance wrong).

reading a tag for its balance is normally a separate passive action.
as far as making a purchase and deducting the amount from
the balance, it is actually a built-in function designed expressly to avoid (as
much as possible) what might happen if the user draws the card away from the
reader before the transaction is complete. in other words, you (the user) don't
have to read the balance and then deduct some amount from it and write it
back. mifare handles it as a single operation.

normally you would keep a backup copy of the balance in case something
goes awry.

it's been a while since i posted my imaginary buspass app, but i remember it
fondly: https://www.b4x.com/android/forum/threads/mifare-classic-buspass.157825/.
you could initialize a tag with a balance, top it off, read the balance and
then "purchase" your bus ticket and have the amount of the ride (3 Slurn in
this case) deducted from the balance. brilliant! i used the mifare classic as
the nfc tag. i imagine it would have worked with other mifare varietals.
i amassed quite a collection of nfc tags for my little museum before moving on.

as a side note: i think the hardest part you will encounter is encryption. while
the classic and lite tags use a minimal kind, other tags do, and you may have a very
difficult time reading encrypted tags with android's standard nfc support. all of
this was a long time ago, but i distinctly recall never getting beyond a certain
stage with certain tags even when i had the keys. so if security is a concern
(which it should be when money is involved), the types of tags used for
encryption may not let you develop your app. just sayin'

Thanks for your reply. When I analyzed your library, that was the part I've noticed. It didn't suport any kind of encryption and the "add balance" method allowed only to pass a numeric amount not allowing the add encryption.

It would be possible to provide the source code so I could add encryption on top of your solution?

Thanks in advance.

there's encryption and there's authorization. authorization comes with mifare. encryption adds
layers of complexity, which - as i said - android apparently does not support out of the box.
if you research this, you will find numerous posts regarding the subject. that said, this all
occurred a couple years ago. it is possible things have improved. i wouldn't know.

i can't help with encryption, that is to say, the writing to and reading from mifare nfc tags.
it is a very complex, multi-step operation. the encryption is done on the tag. it is not
simply a question of encrypting some data and writing the bytes to the tag. that is trivial.
it is the tag which engages in a dialog with the reader. i never found a successful example.

Hi there

I was looking for something simple relatei with encryption.

insread of writing the actual balance in plaintext, write it in some form of base64 hashed string. Just that.

drgottjr said:

there's encryption and there's authorization. authorization comes with mifare. encryption adds
layers of complexity, which - as i said - android apparently does not support out of the box.
if you research this, you will find numerous posts regarding the subject. that said, this all
occurred a couple years ago. it is possible things have improved. i wouldn't know.

i can't help with encryption, that is to say, the writing to and reading from mifare nfc tags.
it is a very complex, multi-step operation. the encryption is done on the tag. it is not
simply a question of encrypting some data and writing the bytes to the tag. that is trivial.
it is the tag which engages in a dialog with the reader. i never found a successful example.

Click to expand...

mifare was used in its day precisely for maintaining a balance. they thought of it
before you. the balance isn't written in plain text in any case. there is nothing
stopping you from inventing your own system, but it won't be using what mifare
has already done. you wlll have x number of bytes of available memory to do
what you want with them: plain text, bitmap, audio, some secret code, whatever.
i believe mifare's built-in system is optimized for your use case. but the tag is
open, so you can do what you want.

The system you implemented for the "bus" example does what when you add the balance to the card? If you read the card with a generic reader, you'll be able to see or change the balance?

Thanks for the help.

i don't know which mifare tag you're using. in my case, i probably used a classic 4k. different tags, different actions. if you look at mifare documentation, you will see that it has an increment/decrement command for maintaining a balance (in a special record). when the card is put close to the reader, a prescribed amount is deducted from the balance (and the new balance saved). you initialize a balance by writing it to the special record. if you want to know what the balance is, you read the special record. if the balance is not enough to cover the cost, the reader app would reject the card.

generic readers can't generally read a tag which is not ndef-formatted. normally you would not ndef-format a bus pass (or similar), although you could devise a bus pass-type of application which used encryption and store the balance as an ndef message. the message would be plain to see but unintelligible. your reader would unencrypt the message do the calculations, encrypt and write a new balance back. but this is not what ndef was designed for. obviously, without your encryption key, nobody could understand what the message said, although they could use the card to read and write their own messages (ndef being open).

when not ndef-formatted, mifare has a number of authorization keys which allow access to the card. you can change those keys. they have read/write permissions for security. a generic reader wouldn't be able to read protected records. unfortunately, a flaw was discovered in mifare's "security" which explains why mifare isn't used anymore for this type of application. it's not exactly trivial to exploit the flaw, but its existence is known. even if somebody could read the card, the significance of the data is not necessarily evident (unless the bytes mask ascii text). all that is visible is bytes. and if i'm not mistaken, you can decide where you want to keep the special record that holds the balance.

it's a fun exercise, but serious security requires serious coding and usually serious development money and licenses.

After reading your answer, I'm almost convinced in doing a "cloud based" solution. I was trying to avoid that because the dependence on the internet is a point of failure for an entire event but the implementation is a lot easier becaus the only thing we would use from the tag is it's ID... all the rest would be controled on the cloud.

Do you see a different approach for the issue?

Thanks.

mastercard! sorry, somebody already thought of that too.
the topic of this thread had to do with reading and writing nfc tags . i tried to answer that. now we're in the cloud; i don't know what you're planning on doing there. or who's going to manage/implement it. if all you want from the tag is an id, then you don't even need nfc. you could use an encrypted qr code with the id. no physical card required. one less thing to carry or lose. airlines/trains don't bother with physical tickets.

better to start a new topic.