I have a nRF5240 BLE chip which supports NFC Type 2 and Type 4 tag emulation protocol stack.
Is it possible to emulate a Contactless Card like Visa payWave or Mastercard PayPass which has Magnetic Stripe Data on it ?? If yes how?
Your scenario is similar to HCE application which runs on phones. There are certain protocols that dictate how to respond to terminal commands(in hardware terms). If your chip is able to communicate with terminal then you need software to communicate with terminal. When your card is in distance of contactless terminal certain apdu commands sent to card to start a transaction. if you could code correctly you can get almost similar behaviour as PayWave or PayPass application.
During transaction, terminal could send your transaction to verify online then you have to know Issuer(Bank) keys. There is a small chance(offline limits are not exceeded) that you could get offline transaction but you have to know Issuer Certificates(it is based on RSA and dynamic values). This is harder to crack then online transactions, online keys.
Yes you could get your complete PayWave or PayPass card but you could not breach security.
Related
I have a USB-PD question. I am working on a project that will use USB-PD (via USB-C connector) to charger devices, for example a laptop, tablet, mobile phone, etc. Think if this as a "Shared Capacity Charger" where the total available power is being distributed between a few devices. There is another team that will be coming on board that will be responsible for the USB-PD HW and protocol implementation, but they are not available yet, hense the question here.
So the question: Over the typical USB-PD protocol, is there information available about the device being charged such as a UUID of the device, battery capacity of the device, current % charged (with periodic update during charging), number of charging cycles, etc.
I would like to keep history of devices charged and, when charging, their current charge level. This would then be provided to the user. I just don't know if this type of data part of the USB-PD protocol (and typically implemented if optional), or if we would need to implement an app to run on the devices being charged to provide the information by other means outside of the usb-pd protocol?
Any help in understanding the typical information about the power sink device normally available in the USB-PD protocol would be greatly appreciated.
USBPD 3.0 protocol allows you to query the battery charge.
For example:
enter image description here
Unfortunately, manufacturers of Power Banks with Power Delivery software set the type to this device as a power supply (but not a battery), so the Power Bank itself considers that it is a power supply and cannot give Charge Status.
Here is example:
enter image description here
enter image description here
Here is the reason:
enter image description here
I would like to use bluetooth for authenticating a user (bluetooth device).
My first idea was to use iBeacon which would be weared by a user. If that user would approach authenticating device (central), that device would use MAC/UUID/Major/Minor of iBeacon to identify the user. Unfortunately it is possible to clone iBeacon and so more advanced approach is required.
Does BLE has some mechanism for that? One option would be that central device would connect to peripherial one and use some PKI to authenticate it.
Or maybe there is something for this purpose already in BLE protocol.
Is these some well known solution for this?
The FIDO2 standard includes a variant where a Bluetooth device acts as a secure key. Google's Titan Security Key is such an implementation (or rather of the older U2F specification).
The Bluetooth specific part is found in the CTAP2 specification. But it is quite some work to implement it and there is no reference code for Bluetooth.
The overall protocol with a private and a public key and a challenge/attestation procedure will still apply for a simpler implementation.
BTW: FIDO2 is not very wide spread yet but many companies are working hard to implement it. I think it will prevail - but mostly without external security keys such as USB dongles and Bluetooth device. It will be successful with fingerprint readers and face recognition technologies built into all future devices, be it smart phones or laptops.
Is it possible to use the free GPS service to send other types of data such as plain text/XML/HTML??
E.G. systems for taxi companies - each car has in it a box which receives and sends information to and from the controller/ dispatch, back in the office. The driver can view all bookings and accept them, as well as tell the controller when the customer has been picked up and when they have been dropped off.
Is this all possible via the free GPS service? Or would the system's manufacturer have to pay to to rent a private satellite? Or would the system be using something similar to a mobile phone network? I would think it would be one of the first to options, as constant reliable signal is vital.
I know the question above is pretty open, and it's not what I'm too desperate to have answered...I just want to know if it is possible for me to build a device with a GPS receiver and have it send text and XML via the free GPS service?? (I want an admin to operate a team of employees from a browser, like with a taxi fleet management system).
No, GPS is a chip with an antenna that can receive only Location data.
It is not possible to send data via GPS.
All that devices that drivers, taxies, busses, tolling system use, send their data via mobile phone network.
So a device needs such a communication chip and a sim card.
Then you can send what you want.
I used a 3G(WCDMA) mobile data modern, which dail up in embedded linux, sometimes I find the USIM card is out of balance, so it can't dialup normal, I just search the modern manual to find the AT command can be help.
I use command called "SYSINFO", but it doesn't work.
whether or not it have a method to judge the USIM status which is out of ballanace.
You will need to dial a USSD command. This is different for each operator.
For example, on Vodafone UK it's *#1345# - on other networks it can be *100#
Depending on your modem, you will need to send
AT+CUSD=1,"*100#",15
or
AT+CUSD=1,"*100#"
How to get the phone number of the device in Symbian?
According to the GSM specs, only the IMSI is required to be available on the SIM card.
The actual phone number MSISDN is stored on the HLR database in the operator's network and does not need to be available on the SIM card or transmitted to the phone.
So no matter what technology you are using (Symbina, Java ...) you can never count on being able to consistently get your own phone number from the device or SIM. You might be lucky if the operator stores it on the SIM or if the phone provides the user with a possibility to enter it manually, but it does not have to be this way.
As Pat has said, although there are APIs for accessing the "own number" slot on the SIM, rarely in my experience is this slot filled.
The usual strategy for obtaining the phone number for a connected application is to send an SMS as part of a verification process. Either:
Programatically send an SMS from the handset to your server (lots of good SMS gateway interconnect providers out there). The SMS will arrive at your server 'from' the number of the handset (or the SIM to be more correct). Of course the SMS should contain some token so the server can link it with a given session/user.
This has the advantage that you don't need the user to enter their own phone number (which is fraut with subtle difficulties given few folks understand how to format numbers in E.164 format). One disadvantage is that the process can cost your user money (one SMS).
Have the user enter their phone number (web site or on the handset) and connect to your server, passing that phone number. Have the handset then wait for an SMS to arrive that you send from your server. If this SMS does indeed arrive, you have verified the phone number they entered as correct and valid. Obvious disadvantage is that this relies on the user to enter their number correctly - again, given the plethora of ways of writing phone numbers around the world, its not as trivial as it sounds to normalise numbers to E.164....
Alas, neither of these methods are bullet-proof, particularly because SMS is an unconnected transport. Depending on GSM network load, the load of your gateway provider, phase of the moon and direction of window blowing an SMS can take a second to a month to arrive (yes, I do have experience of the latter). The mean delivery time is often in the seconds, but you do have to play with the operation timeout and might have to tweak it on a geographical and GSM network basis.
[And no, don't rely on delivery reports - even more unreliable than SMS delivery]
FYI: Actually i have found this.
http://www3.symbian.com/faq.nsf/AllByDate/100335073FFD8FEF80256E3200571A49?OpenDocument
But the fact is, the phone number is not always stored in SIM. The operator chooses to do it or not!
You can't. Afaik.
Check this discussion:
http://discussion.forum.nokia.com/forum/showthread.php?t=65117
It is not generally possible to get the MSISDN from a Symbian device (or BREW, or any other platform). We've tried.