Implant Payment via Replay?

I’m new here but I’m thinking ahead to what I think everyone is thinking about, payment via implant. I’m excited for the possibility of a future secure element implant but I also know US bank support is still lagging for things like Apple Pay. Some banks still won’t support it and I expect that we will get the same pushback for introducing implants into the system. I was watching a 2018 Defcon video about payment attacks and I was wondering if that could be our temporary solution. Let’s say an upcoming implant supports enough memory, processing, secure element, etc for payment but my bank says no. Could say a Java applet be made to allow me to capture 100 transaction attempts via a Proxmark3 and save them to the implant for replay later? That would effectively get the bank out of the picture. Maybe I couldn’t use the physical card in the meantime to stop a transaction counter but oh well. I’d accept that. It seems that many of these attacks rely on falling back to magstripe or other older protocols for simplicity of replay. Perhaps the data could be edited between the Proxmark3 and write to the implant to demand the fallback.

Anyways, I’m just thinking and I don’t know if anyone has already attempted a replay attack via implant. FYI, the video was Here. There is a demo at the 10:39 mark.

1 Like

A java card implant is in the pipeline, you will here it referred to as the Apex made by VivoKey.
This wiki has some info on the current state of payment implants in case you did not see it:

1 Like

The simple answer is “maybe”.

The longer answer is “maybe, depending on a lot of factors.” The key factor being replay attacks don’t work well because the terminal tends to use a nonce for encryption. If it was the old style visa/mc magstripe data emulation, sure that will work. But that’s very much no longer supported, because of this reason specifically.

Progress is happening on payment implants, the right way (also known as the slow way). I promise it’s high on our list.


Agree with @fraggersparks … in the EU this idea is definitely dead now… but in the USA, if you can get a terminal to accept your tap card (this is painfully difficult as they all work with apple pay but hardly any will read my citibank tap card) … then I bet you could still do a replay attack where you pull a number of transactions from the card and replay them one by one to terminals. In this way you could probably “load up” an implant with transactions from a card that you would otherwise never use, and replay them to terminals… but because the technology is shifting or has already shifted away from randomized or counter based cloning attack countermeasures to nonces and other forms of protection, this would be a nearly DOA project if it ever got completed in the first place.


Ok this has been picking any mind, so today I did some more research … particularly on SDA. I found an older video based purely on chip and pin (contact) EMV vulnerabilities, but the one bit of information that gave me pause was that SDA as a protocol is dependent on the chip in the card, and that “cheap” chips cannot do RSA or public key, so they use 3DES or AES (hence “static”)…

Sooooo… the reason this made me re-think my interest level in replay is that, unless it’s regulated in some way to require RSA (nonce) support, banks will always choose what is cheaper, not more secure. If the cost of fraud is less than the cost of secure RSA chips, then SDA will be supported.

While I don’t think this will work well or at all with Apple Pay and the like (not unless the merchant and processors support offline mode for this), I think the first stage is to see if something can be written for Android or an application for the ACR122U to test various bank cards to see if one could pull SDA transactions with simple counter based salts from the card… then the next step would be to attempt to load those transactions into and replay those transactions from an applet on a smart chip.


This is an older card scanned with an older utility and I tucked it away… the card is long dead so I don’t care about the security issues inherent in posting the full details, but this is the log;

javaemvcard_attempt_chase_blink.txt (17.7 KB)


Looks like non-EMV card.