Hi everyone. This is turning my phone into a skimming device and post solutions. We'd like to
introduce ourselves briefly. I'm Eliana Barrio Nuevo. I'm a security engineer and security
researcher at UTN. I am from Cordoba, Argentina, and this is Dan Borgogno. Hi, I'm a security
engineer. I'm a security researcher. There are Twitter tags if you want to follow us.
Uh, we are trying to protect data and people through a new type of risk, uh, risk management.
Then we're pricing, uh, saving insurance, saving companies from bankruptcy after a cyber
attacks through advanced, uh, risk analysis. Uh, this is the agenda. Well, we'll talk about why
we chose these devices, these solutions. Which are the security concerns that we found. And
how we hacked them by taking different paths, such as network trafficking, and, uh,
traffic analysis, application analysis, Bluetooth, hardware, and so on. Go ahead. So,
what are, uh, digital wallets, and what, what's MPOS and how everything is connected? Well,
digital wallets are a way for you to have your money stored in your, in your phone basically. You
can receive money, you can transfer money, or you can do operations with your money. Uh, the
problem comes when you have a business, you want to receive payments from anyone. For example,
you are trying to, to get payments from a guy that doesn't have the same wallet, or may have a
credit debit card. So, these devices basically what they do is they allow you to interact with
credit card information and to receive the data that you need to make a payment. And they're
connected through Bluetooth. These solutions are widely available in Argentina, so that's why we
try to, to analyze them. And as you can see, they are pretty common. There are a lot of, of
devices that are out there. Uh, we have very different, uh, digital wallets, and all these
devices have, uh, different providers. So, you can see in the bottom that there is a lot of
providers, VBOS, MagicBOS, Stripe, Dspread, and amongst others. So, um, you need to keep in
mind that you have the, the, the manufacturer and the digital wallet implementator. And the one
thing that you need to keep in mind as well is that the attacker right now might be the, the
digital wallet owner. So, you have this evi- you have this business and you're trying to
receive payments. When you are receiving a payment, you need to protect the client data from
the guy that's paying and using his credit card to, to give you money. So, right now the
attack surface, uh, it's a little bit bigger. And we would use these devices to, to assess
them. Is the, in the first case is that they are sending very critical information over
Bluetooth, which is credit card information. So, uh, we might, uh, uh, we might, uh, uh, uh, uh, uh,
you, you might know that Bluetooth, uh, 4.0, it's very vulnerable. You can do a shy
hacker attacks and you can do a lot of stuff with Bluetooth. So, our first question was, uh, how
secure is this? It's really secure. You can really see the critical information from the air or
not. Is that difficult? On the other hand, uh, we saw that, uh, differently from the, the
components or the, the inputs that have a, a specific system embedded in it. When you're
trying to use your mobile application with those devices, you can control the, the, the data
flow. You can control the payment process. And this is really, uh, it's a big problem because right
now you can try, amongst other things, to make a reply attack. You can try a different
payment. You can show the client, uh, one amount of money and then charge it for a bigger amount
or something like that. So, we tried to figure out how vulnerable is that the, the, the
critical owner, the, the digital warning owner can manipulate the, the payment flow.
And the thir- third thing is that we have a really wide attack surface. You can hack data
entry. You can hack the hardware. You can hack the firmware. You can hack the Bluetooth. You
can do shy hack over Bluetooth. You can have manipulation of the application. You can reverse
an SDK that, uh, a third party is provided to you to integrate with your digital wallet. You
can manipulate network traffic. There's a lot of things and you need to implement security
measures on each one of those steps. So, the attack surface is really big. So,
as you can see, this is a simple graphic. Uh, all those are attack points, right? So, you can
try to get the critical information, for example, in each one of those points. So, the other
thing that you need to understand is what are the features that these, those devices provides.
Um, these devices, uh, allow you to read EMV, which is the, the chip from the credit card. You
can read the MAC string information which is the black stripe in the back of your credit card. You
can read NFC and you can read the, uh, the, the, uh, the, uh, the, uh, the, uh, the, uh, the, uh,
I mean, receive NFC, NFC payments. And those devices allow, uh, firmware updates over the
air. They receive, over the air, uh, key updates because this will be played later how the
case system marshals works. And they have Bluetooth, uh, low energy, and EDR which is the
$3 guru. And they support pretty much every, uh, payment standard. And you need to keep in
mind that to understand, uh, what we've done, uh, a, is that this devices encrypt some
critical information to be sent to the backend and they are not just passiveidiot that uh,
the way this is done is by a key management system um a protocol which is called the UKPT.
Basically what this device eh have is a specific key you have as a um um a wallet
provider you have a master key and for each one of the devices that are going to the market you
will generate a specific key which is called the EPEC and this key will be embedded in the
firmware and then in for each transaction that we'll try to do you'll try to generate a new
key a session key to encrypt this information and when this information gets to the backend
cypher with a triple desk the backend system will try to generate the same key based on the
device itself and the transaction that is occurring. So there is no interchange of the key
but this is a cypher uh cypher channel between the device and the backend. So after that the
best the transaction went eh it's it's get done. Another thing that I didn't understand is
that the information provides uh the uh the uh the uh the uh the uh the uh the uh the uh the
notice of all of those stuff amongst them you can read max stripe you can DMAX yep is uh...
aistarit eh it's it's a fixed data you can clone it it's not something that you can change.
Um you have AMB data which is uh specific protocols that allows you to make payments but
they have another additional cypher link over it. I will lift you up into a tapes but you need to
know that that is a different products and study to get a precalóst także you get form a
credit card. So moving on to network traffic. One most important vaccination feature in connect
we started analyzing one of the cases,
one of the application vendors
that interacts with this device.
And well, we intercepted the traffic.
We actually realized that we can read and modify
any data traveling on the requests and the responses.
We use Frida, Objection, Meet and Proxy,
Burp Suite, and well, any proxy.
And we can control the whole payment flow.
And we can capture the encrypted information
that comes from this device.
And we can try different use cases,
such as reusing data, reconstructing information.
Well, we had to break the SSL pinning,
so we use Frida scripts running with Objection and a proxy.
And here we have the first use case,
which is data reconstruction.
We have seen that this particular application
was managing information.
We have obtained information from the backend
that wasn't used at the front end.
So we have seen that.
That is the encrypted information,
the credit card number and the CVV and expiration, et cetera.
But the backend returns the same information
and non-encrypted.
So there you see the first,
a numbers of the credit card number and the DNI
and the last four numbers and expiration date.
So, well, that data wasn't being used at front end.
So we should try to reconstruct
the complete credit card number.
So how many attempts should I do?
Nearly 9,000, right?
But to get these four numbers that we are meeting,
we should do only 999 attempts
because the credit card number follows a specific structure
that can be validated with that script, for example, right?
So we should do brute force
and then we get these four missing numbers.
And then we have the whole picture to make payments,
malicious payments, so.
So even though the critical data was strong,
only in cipher, when the response for each one
of the payments came through,
you can get this data to reconstruct any critical information.
Well, this is the next obvious case,
which consists of reusing data.
TUKPT states that the key,
the transaction key should be used once
and then should be discarded.
So what if we resend a request that has the encrypted information
with this key traveling in the request?
What if we resend the request after a valid payment?
It should fail following the standard,
but here we have the process.
We initiate the transaction.
The customer makes a payment on the device.
We capture, by analyzing the traffic,
we capture the request.
The transaction goes well, is accepted,
but then when the customer leaves,
the store, we started with triggers,
another payment with our cards,
but then we replace the request with the credit card
information that is encrypted,
but we have saved it previously.
And then we make another payment.
So you should keep in mind that there's a gray area
between the responsibilities of the device provider
and the digital wallet owner.
So these things comes to get in the gray area
that no one wants to take the possibility of,
well, about the things that you should do,
and you should not do with the data.
And here we are positioned as merchants.
We are the attacker merchants.
So here's demo of the replay attack.
So we have two phones with two different applications,
and we are trying to make a payment
from on the first digital wallet, capture the data,
and then we open a second digital wallet
with a second device,
and we'll try to dummy credit card payment,
and then we'll replace this credit card damage data
with the previous one,
and you will see that we have a successful transaction.
So right now, everything's connected to midterm proxy.
I already done a transaction.
So the payment went through.
So sorry, this is a pierce payment, already connected.
I'm getting the traffic from midterm proxy.
I just received the encrypted credit card information
from the first payment.
Again, don't bother about getting this data.
It's all fixed, so you won't be able to use it.
But once the, right here, I'm using a simple identification
number that you need in Argentina to make a payment,
and you will see that the transaction, it's approved.
So the client left the store, goes to her home, pretty happy.
He paid $0.55, and I'll turn off the Wi-Fi
and leave everything on the side, and I'll use a different,
different account in another phone.
I'm getting the information, the green information
that shouldn't be used to resend for another payment.
And saving this data, just in a text file.
That's cipher data.
You can see the key SN, which is a transaction key,
which allows you to generate on the back end the new key
to save this data.
And right now I'm turning the phone, Wi-Fi,
to make another payment.
That's a dummy card.
This salary expired.
And I use it to make an initial payment.
So right now, I'm just saving the traffic,
and I will replace this data.
So turn on the device.
Make another payment for a bigger amount.
That's about a dollar.
And right now you'll see that I'll trigger the device, but I will capture the information on network traffic,
I will replace the information with the previous one,
and I resume the traffic, and you'll see that right now I need to again input another data.
This is not valid, so I just can input whatever you want, and you'll see that the intersection went through.
There are more things, wait a minute. So you can see that right here, we have
the, sorry I was trying to show you, oh man.
It was the second transaction and the wallet from the customer with a
with a
valid payment.
Yeah, you can see right here, we have the two payments from the same client, and the second payment was never
actually executed, and it was
charged. So,
going back to the presentation. Okay, well, let's move on to application analysis. We have seen network traffic, and now
we are going to hook the methods from the SDK,
SDK, sorry, and
we have the SDK and the device interacting with the application.
So, we try to manipulate the objects, the instances related to the encrypted card information
coming from this.
So, we are abusing TUKPT implemented here, and
remember that
we have this case in which we cannot reuse the key because this was fixed,
this was reported and fixed, we shouldn't use again the same request, but
encrypted card information shouldn't be used again, too. So, we are the ones interacting with
the SDK and the device, so we can manipulate and get as many keys and as many encrypted card information as we want.
This was theoretical.
We thought about it last year, we tested this year, and it worked. So,
how it works?
We initiate a transaction,
the customer is going to pay,
taps the card on this device, we capture
that encrypted card information, and we try to make the payment fail.
So, in the second attempt from the customer, we are sending to you the previous card information,
and in this second attempt from the client,
we are capturing also that information and we are saving it on memory. And then when the customer leaves, we are
going to pay again with this second tap that we captured, and
the transaction will be accepted. This is a little script that we developed to run with Objection.
We hooked the method, the serializer that triggers the request that completes the operation, the payment, and
we enumerate all the instances related to the objects,
the credit card information that comes from here, and
well, we can save on an array, or send to a server.
And in the first attempt, we are sending GMI data in order to make the payment fail.
And, well, that method returns this GMI data at first instance,
and then we are sending the previous card information that we are saving in each tap.
And, well, we are sending the information to a server if we want.
And,
well,
in order to understand this process, we have two requests. The first one that initiates the payment,
and the second one that completes that operation with an operation ID that is got from the first request.
Now in the demo, we are showing you the request and responses, but
I wanted to make it clear that we are not manipulating the traffic.
We are only manipulating the instances at runtime. We are manipulating and hooking the methods of the SDK. So,
let's start the demo.
Well, we are starting the application. The customer is going to pay.
We are pairing the device. This is the first step. We are capturing the information,
but we are sending GMI data in order to make the payment fail.
Well, we are completing the DNI,
for legal reasons.
And then we are triggering the first request, starting the payment with valid data.
But the second one
is GMI data because we want to make the payment fail, right?
So,
then
there's an error and we say to the customer, hey, let's try it again.
We have captured this valid information from the customer.
We are sending the credit card. And in this second time, we are capturing also the credit card information,
but we are sending the previous one from the first step that we have captured.
So, completing again.
Legal data.
And then we are sending,
well, starting the payment again, because this is a valid transaction.
We get an operation ID, which is needed to complete the transaction later with this second request.
And then we are sending the payment.
And then we are sending the previous card information that we have saved.
And this wasn't used.
Well, we have triggered
now the malicious payment. The customer leaves the store, really, really happy.
Then we trigger another payment
as an attacker, as a merchant attacker.
We start the operation.
We get the operation ID from the first request.
And then we are sending this previous card information from the customer, which is encrypted.
I don't need to know
where, what is the,
what the credit card number is, or the CVV. So, we completed a payment.
So,
here we have a valid transaction.
And the customer will see a second payment.
But,
just to clarify,
we tried to manipulate the price, but this was validated at backend.
So,
and the, the price was the first one that the customer paid previously.
So, that was the demo.
And the second one.
And well, just to, in order that you understand,
how the script is,
this is a script running with objection.
We are capturing the first step,
but we tamper the method, the serializer,
and we send the GMI data.
Yeah.
We are saving card information.
We are linking it to a server.
And this is the second tab when the customer tries again.
But we are sending the previous one, right?
The first one.
Well,
this is the attacker tab, and we are sending
the second tab from the customer.
It's a little, a little strange, but we are sending previous data.
And the payment goes well.
So, let's move on to Bluetooth.
So, Bluetooth analysis.
We don't open the, all the devices.
There are mainly four.
And all of them share pretty much the same Bluetooth chip,
which is the iChip YC1021.
This, if you go to the data sheet,
you'll see that this device supports Bluetooth 3.0 and 5.0.
And you might know that Bluetooth low energy is quite vulnerable.
You can do shy hacker attacks.
You can do laser attacks.
You can do a lot of stuff.
So, we have, we have a test application
that some of these providers allow you to use.
To interact with the device and to see
if the device is working properly or not.
So, we had this application to make it work with Bluetooth low energy.
And we used VideoJack, which is a tool that we love a lot.
Using three micro bits connected to a USB hub,
we were able to sniff all the advertisement packets.
And we tried to, we were able to sniff critical information from a payment.
And you can see in the left,
there is the application itself,
testing application.
It will show you the same information,
cipher information that we sent to the backend.
And will be deciphered at the end.
And you can see in the right,
the Wireshark analysis.
And you can see the same information
is being shown on both sides.
So, we are, we are,
we are sniffing the same information
that is being sent to the backend.
So, the Bluetooth is not adding any,
adding any ciphering over the traffic.
But,
we will try to do the same attack
against all the digital wallets.
We weren't able to do it,
to do it because,
mostly because all of them use a Bluetooth EDR,
which is the 3.0.
And it's based on the pairing mechanism.
So, to see what is the data that is sending now,
over Bluetooth EDR,
we were able to get the HCI debug log
from Android.
And doing, we ran a lot of analysis
over this traffic.
And we found out that the same data
is traveling over the HCI.
But, since Bluetooth EDR
is adding another layer
of ciphering,
you cannot get this information from
just sniffing Bluetooth 3.0.
And if you will,
were able to do it,
you'll need a really expensive tool,
but doing just a little bit of research
over these devices,
you'll see that the first time you try to
pair this device to your phone,
you will be shown with
a numeric comparison.
Numeric comparison is basically a pairing method
where you show the same 6 digit number
on the device,
on the phone,
and you need to click accept
on those devices.
I don't know if you see what's the problem.
You don't have any screen in those devices.
You have no way to see or to know
what are you pairing to.
So, we tried to do
a man-in-a-mill attack.
Basically, what we created
is just a very simple script
where you use
a single Bluetooth adapter
and basically doing a Bluetooth analysis
over the traffic, we found out that
all the traffic information was sent
over Bluetooth with an SPP protocol,
which is basically serial over Bluetooth.
It's just transmit and send data.
That's it.
You need just one channel.
And we created
a simple script which is trying to listen
based on a regex
to see if there is a device
that is turned on.
Other thing that you need to keep in mind is that
for each transaction, you need to turn on the device
because it turns off itself
after 3, maybe 5 minutes.
So for each transaction, you need to turn it on
and it accepts connection from
pretty much anyone because again,
you don't have any way to pair it correctly
with any other device.
So,
the script, what it does is trying to
start listening in the air,
it just connects as fast as it can to the device
and then it starts emulating the same device
and provides the same SPP protocol.
So, that's the setup. It's pretty simple.
You have on one side the device turned on,
a Raspberry Pi with Python
and then the mobile application
will try to connect automatically
to the device that we are emulating.
So,
this is demo.
This is one digital wallet.
You can see right here
that that's the remote desktop
for the Raspberry Pi.
We start the
money in me attack.
You can see that it's already
saw the device.
It's connected to itself and right now it's emulating
the same device.
So, I just
enter to the mobile application
at the digital wallet.
I go to try to make
payment
and right now those devices
are paid, but
you'll see that
everything works
pretty good. Right now you can see
all the traffic information
between the application, the Raspberry Pi
and the
MPOS device.
Right now I'll try to make a payment and you can see
all the information right from
the air on the money in me attack.
So,
the payment mechanism
doesn't allow you to know
what are you actually paying to.
The device doesn't know where it's paying to
and the mobile application doesn't know.
So, what can we do with this?
With the money in me attack, we can do
basically
we can try to do a
max stripe stealing.
Since the device
is connected from the main one,
you can try to do an over the air update
or an EPEC update
which is the key that itself.
Or you can try to do a
pass which is pretty much the same as Juliana shown
but on Bluetooth level.
You try to force a bad payment,
you try it again, you save
the data from the two
manipulations and you send just one
and the other it's already
valid to make a second payment.
But I wanted to show you
a little big
a little thing of
this is the second
try that we've done
with money in the meal attack.
This is another digital wallet
and we charge just a small payment
and I know you might be able to
see something quite interesting.
Again,
the car owner
and the guys that run the store
doesn't know that this is a money in the meal.
So, right here you can see that
everything is working properly.
I used an NFC payment
and everything is working correctly.
But it's just really different.
I'll try the max type.
And again, this data from the max type
this card is already expired on the wallet
but this information should be ciphered.
There's no way this information is traveling
in plain text.
Right?
So, here's another payment
and you can see right there
this is the plain text
max type information
from the app.
So, basically you can go to any site
you can go to any store
using this solution
sit there and start receiving
critical information.
You can go with this data
and emulate a card with MaxPoof.
So, uh,
moving forward
um
hardware analysis.
We are not hardware hackers, disclaimer.
We're trying to be, but these are the four devices
that are right now available in Argentina.
We talked about
and we saw that
they share the same principles amongst all of them.
You have the smaller ones
which doesn't support NFC
and the bigger one that supports NFC, basically.
So, uh
what are the valuable points? I mean, what kind of
do I get as a
low-level hardware hacker from this?
Well, the first thing that I think is
really interesting to have is the critical information
that is traveling on the devices.
Uh, DMC or
EMB tokens are also
data to make a payment. So, if I get
this information, I could go
make payments. Uh,
the firmware might be really interesting to find
bugs and hack other devices.
The APK, which will
allow me to decipher my own
data and then make
other payments. Or maybe the UART logs
will allow me to see a few
logs that might be
leaking important information.
But, you can see right here
this is really basic.
This is the connectors and things that you might
find in these devices. You have
a Bluetooth connector, an EMB connector, we connect
to the chip, a controller,
a mic stripe, which is pretty much a tape head
connected to an amplifier,
and in the back, well, you can see
the amplifier and the EMB front end
and, of course, the Bluetooth
uh, I don't know if you can see it already.
Uh, but in the bigger devices
you might find, again, Bluetooth,
a microcontroller. Uh, we found out
that this is a flash memory. Uh, we
suspect this, this is where the firmware is stored.
Uh, we have as well
a tape head, a battery controller, and
an EFC front end, of course, to interact
with NFC. So, this is
something, this is a very basic diagram
on what are the main components
that all these devices will have.
So,
we went to, for the long-hanging fruit
and after running
a few analysis stuff, we found
that the device was still working
all open. So, do you have any
anti-tampering measures? And that's a
must. When you have a credit card
or credit card reader or whatever
payment system, you need to have anti-tampering
measures to avoid anyone
to just hook in
the data bus and start stealing information.
Why? Because you have
clear text traffic between each
one of your components. You have the
controller which provides you
with a little bit of cryptography,
but in the meanwhile,
between the data struggling
from the peripheral and the controller
you have clear text traffic. So,
we went for the long-hanging fruit
and we tried to
to get the maximum
information from a simple swipe, which
is pretty much like a common
schema. That's pretty much what it is.
So, um, that's the
that's the amplifier.
It's connected to the tape head and
we connected an oscilloscope to the tape head
and you can see in the left that
you have a waveform, which
is the encoding for the credit card
information from the mic stripe.
And you can see that
the shape is very specific.
So this is what we saw on the oscilloscope.
Pretty much the same shape.
This data is on clear text traffic.
So, we got the
data. We tried to create a
schemer. A schemer will try to get
this data and transmit it over the air
wherever you can. Disclaimer,
this is overkill, of course.
Don't get angry.
There's another way to do this. I'll show you, but
we used
BluePill, which is an Arduino
with a specific chipset that
allowed me to have really high rates
of analog reads over
the data that is being sent
between the tape head and the
controller. And we were sending all
this data on raw data
over the Bluetooth, which is again
overkill. And we were receiving this data
with a Raspberry Pi
connected to a bomber gun.
We just advised that, amongst other
things, allow you to emulate critical information.
So we created a little script
for both these things.
Raspberry Pi will decode the data.
We'll create the specific
data that needs to
be sent to the bomber gun over serial and the
bomber gun will emulate this data.
So, here's the demo.
Here's the test application.
Open device is working right now as it is.
Here's the
hardware input implant
and that's the receiver.
And that's another
critical receiver. Basically to see
that the same information that we have sent
are the same ones that we are emulating.
So right now I'll try to make
a swipe.
And you'll see that all this
information right now has been sent over Bluetooth.
This is all
the data points.
And right now you can see that
right at the bottom, that's the track 2
of the decoded data.
And this data is being sent
to the bomber gun that is in the bottom.
You can not see it right now.
And right now I'm emulating the data and you can see that
pretty much the same. Not pretty much.
The same data, the track 2
that we were able to send over the air.
Again, this is overkill.
This is an easy way to do this.
But this is what worked for us.
And this is just to show you
that the device is still working by
itself. Right now you can see that
the hardware input, again, because we are not
hardware hackers, is creating a lot of noises.
So when I
try to make a payment
of coffee, it will fail.
But if I disconnect the hardware input
you'll see that
everything will work.
I just deconnected the device
and you can see that you're receiving the same
encrypted data. What this device is supposed
to do when it's open, it should wipe
out all the keys and you should be able to
decipher any data.
So this is a big deal because
you don't know if you're paying
even though the network traffic or the Bluetooth
traffic might not be tampered,
you don't know if there is anything embedded
in the device.
So this is what the
schema implant looks like. It's
quite big. It's huge.
The receiver you can see on the left
and you can see the transmitter on the right.
It's pretty big. But we
found out that there's another way to do it.
We used a very simple 433
RF transmitter
connected directly to the
energy input of
the same device and we were
able to make a few
swipes and transmit the same data
to our receiver and
you can see that's quite small. The thing that
we weren't able to decode this data
correctly because there's a lot of noises
and these devices are not
that good at transmitting
nice information over there.
So the last thing that
the last analysis working on
one of those digital wallet companies
we saw that
you should keep in mind that it's a
trust chain between the device
and the backend because since the
same key is being generated on both
ends, all the data is
trusted between each one of the points.
So
in most of digital wallets you have
these fraud prevention
systems where you're trying to make the same
payment over and over and if you
fail three, maybe four times
your critical might be blocked.
So we were seeing that
we heard about
a lot of clients complain about
payments that they never had done
and we were seeing that
there was a lot of
tryout payments for a bigger amount of
money and all failed.
And pretty much
every payment was the same. The data from
the payment, the critical was the same but
they were changing the CVV number which is
a secure number embedded inside the
MAC information.
So we tried to replicate this
to see what the fuck is going on
and we found out that
we created
a MAC spoof. We didn't have the
back then and we tried
to do the same execution. Just
trying to change the CVV number
and we found out that
the application behaved really
differently even though the credit card
was blocked. The
application behaved differently
if the CVV was correct or if it
is not. So if the CVV
was not correct
the application showed you something and if
it was correct it showed you a different thing.
So the
attacker once he get to the right
CVV number he waited
for the client to unlock his card and
then he would go up there and make another
payment. So this is a
problem mostly related to
the trust chain between the devices
and the gray area between
the responsibilities of the
device provider and the credit
and the digital wallet
vendor.
Well, final
thoughts.
Companies should
use encrypted end-to-end
solutions that implements
anti-tampering
measures and
it's important to read
manual to know how to implement
also the
TUKPT standards
in this case.
And
use data should be denied for
no reasons.
And it could be good
if an expiration or
TTL could be added
to this encrypted
card information in order that no one
can reuse it later.
So you have seen
that we can save information
using another opportunity.
Another way to
associate with a signature
or
I don't know, something that
the accounts with the device
and device ID or
the imposed information
and additional things
that you can add.
One thing, we
think that one of the most critical
things is that you can manipulate data.
So as Elena said, we
think that you should
digital sign everything that you're
sending to the back end to make sure that
the client is not manipulating the data.
That's really difficult to do. Sometimes you might
find in Android that you can do pretty much
whatever you want with your application.
On the other hand,
you should have any
auto bounce pairing method.
Because again, these devices
if they intend to be chipped
and you don't want to add a screen, you need to
provide another way to avoid
money in the media attacks. So auto bounce pairing
might work with those devices
because you can pair them
with NFC for example.
So that might work.
And there is no way for me as an attacker
to make a money in the media attack.
As itself.
Or you can add a
screen to the devices just to
be sure that you're paying to the right device.
We think that
this problem is quite
dumb. I mean, it's really easy to
fix it, but
it might be related to the implementation
and the design of the solution by itself.
So these are the
repositories. The money in the media is called
Pretiado.
They post the
hardware implant. Again, we are not
hackers, so sorry if you see
things that you might not like.
And the card injection is the
repository for the
scripts.
And we would like to thank a few friends of ours.
Adriano Perroneo, Marino Marino,
and Joaquin Marilla
for helping us and giving us recommendations
and tips to sort of things.
So thank you. We're open
to questions.
Thank you.