Is there any ways, I can store some data in NFC storage element of android device using some special phonegap plugin? I understand, we can read/write nfc tag and can transfer the same from a android device to another android device using Chariot Solution phonegap-nfc plugin ( https://github.com/chariotsolutions/phonegap-nfc ). I need to know, is there any plugin for storing some data in nfc android device, Please advice! Expecting any sort of suggestions and comments. Thanks in advance
There are ways, but cryptographically protected, so you'll need permission from whoever is controlling the Secure Element (I am assuming that by "NFC storage element of android device" you mean the secure chip connected to the NFC frontend and antenna). The Secure Element is the same kind of chip as the ones used in smart cards (not a plain NFC tag), so you will need to know the keys to access it. They are usually very tightly controlled by the phone manufacturer.
Other phones do not have Secure Elements themselves, but connect NFC to their SIM card, which then becomes the Secure Element: in that case, keys are controlled by the mobile network operator.
Standards to access the Secure Element from the rest of the phone are published by the SIM Alliance.
Related
When connection to a custom BLE device from an app (android and ios) I have two options
a) first pair the device on the phone (like a headset or other devices) and then use it from the app to read and write data
b) without pairing on the phone, go inside the app, search for a device with a specific name or address, and just connect to it and read and write data.
when is one preferred over the other one ?
Its just when it needs to interact in the background or am I missing something?
The devices you see in your phones Bluetooth settings are Bluetooth Classic devices. There are some devices using both BLE and Bluetooth Classic which show up in the settings too, but the settings page is only for the Bluetooth Classic part of the device. Headphones for example are streaming music trough the Bluetooth Classic profile A2DP but might offer BLE services for additional features.
You always have to use a special app to communicate with the BLE part of a device. This could be an app provided by a manufacturer or a generic BLE scanner app such as nRF Connect.
As alexander.cpp already told you in his answer pairing (the exchange of keys) and bonding (saving of said keys) is not required for the communication with BLE devices and only needed if the device requires a secured connection.
Bonding (technically correct term for BLE, often called Pairing in non-technical speech) is mostly for security, we can send sensitive information because the receiver is verified and data is transferred in encrypted form.
Prefer to use bonding if the data is sensitive (means users feel uncomfortable if somebody they don't know receive their data). For example, I consider "current temperature = 25" as NOT sensitive. For detailed explanation, find "Bonding with a BLE device" in BLE guide by PunchThrough.
Also this is a good answer to a similar question: https://stackoverflow.com/a/42916081/10380092.
Your second question about background - no, bonding is not related to interaction in background.
So I downloaded Android pay and got it setup with my card only to find that my phone doesn't have NFC. How I missed this, I don't know.
I was thinking this: could you put and NFC tag on the back of the device and somehow rig it to work? If not, would it be possible to get NFC hardware to work with a device that doesn't have it?
You can attach external NFC readers via USB or audio port. Technically, these would not be drop-in replacements, so you'll have to go with special apps which make use of the readers.
I am developing an app that controls a product's operation. The communication is via BLE. My configuration is
App - Peripheral (iOS, Android)
Product - Central (uses Laird BT900 module)
iOS as a peripheral works fine (pairing and bonding) ; Android PIN pairing works fine, but subsequent bonding (or reconnect when in range) there are a lot of issues and termination of connection. I am using the supported list of devices for Android BLE and I also understand that there are many known issues that come with different manufacturers/chipset vendors
The issue I am getting is, as seen by nrfConnect, is with descriptors. Android app doesnt show descriptors when seen in nrfConnect whereas iOS shows. I do not know what is the difference
Is it a common practice to use a phone as a peripheral ? Or is it a risk - because this is a medical device.
Are there any best practices for Android as a peripheral ?
I have following back up plans in case Android issue is not resolved. I think following would work on any BLE supported phones without having any issues with the variability.
Plan A : PIN pairing on every connection with the product. This is the most secure and most annoying
Plan B : Implement just works pairing with a app layer password before taking control of the product.
Question : Is just works safe and encrypted ? Is it snoop-safe or MITM-safe ?
Thanks in advance!
A few thoughts from your questions:
1a. (From my Android experience) I think its uncommon to have the phone be the peripheral. To my knowledge all iOS devices support peripheral mode but only a very small subset of Android devices are able to support it. I say this because I've been experimenting with BTLE beacons using the AltBeacon library. From this work I have discovered that only certain Android phones can broadcast BTLE advertise packets. Given that BTLE advertising is the first step in initiating a BTLE session I imagine that this prevents many Android phones from being compatible with peripheral mode.
If all of your users can use an iOS device, then you're set, otherwise this may be a problem.
1b) I can't speak to the specific risk of using a mobile device with your medical device, that depends on what the medical device is doing and how you're using the mobile app.
2) See 1a
3) The specific encryption scheme you used is also based on your product's risk profile. I would say that Just Works is not an ideal solution. The just works pairing process is not snoop-safe and can be re-initiated via a MITM. Other than that I can't speak to the strength of BTLE encryption.
Short question: Can I read credit card information with a NFC capable Windows Phone 8?
Long question: How does NFC with credit cards exatly work? The card (or the phone with wallet function) receives a request via NFC and replies with the cleartext credit card information in some standardised format? The Wallet option then aditionally still props some comfirmation dialog before broadcasting the credit card information?
Or is there some handshake encryption going on before hand? Or is there some credit card specific secret code safeguarding the commuincation? Or is there some overlay protocol on NFC for payment? NFC ist just pushing a string over the air as far as know?
If it works, as I think it works, can I tell a Windows 8 Phone, through preferably C#, to read credit card information and display it to me (if the credit card has a chip inside)? Or does maybe Windows Phone 8 disallow access to the NFC reader, or some mystic payment protocol (if such a thing exists). My short web search was very vage on technical details, especially with some sites talking about carrier support for wallet systems, as if some keys would be fetched from somewhere in the web to secure the transactions? I can't really image something like that being standardised accross all credit card issuers.
Can someone give technical insight the way credit card data is transfered and if you can program a phone to read such data.
Contactless credit/debit cards certainly do use NFC (mainly ISO 14443-A, some mainly in France are ISO 14443-B), and their communication protocols follow an industry standard called EMV which has public specs available here: http://www.emvco.com/specifications.aspx?id=223 The cards speak the same EMV both over NFC/contactless as well as through the contact chip (eg the gold thing you insert into a reader) though payment networks tend to do things slightly differently depending on which interface is used (eg sometimes PIN not required via contactless for low amounts, whereas contact might always require a PIN). Also, certain aspects of the protocols are proprietary to the payment networks so the EMV specs don't fully describe everything.
If you search around there are various sites that give some examples of how to communicate with credit/debit cards some over NFC others with an insert chip card, but typically the commands will work the same regardless of the interface. You can buy a USB smart card reader that will do both NFC and insert/contact for http://blog.saush.com/2006/09/08/getting-information-from-an-emv-chip-card/
For Windows Phone you also can talk with credit cards as long as you have a Lumia 830/730/735 etc as the older devices (even the Lumia 930) have an older NFC chip where the driver doesn't support the smart card APIs. You can use the sample code here: https://nfcsmartcardreader.codeplex.com/ to learn how to send/receive APDU commands/responses to NFC cards though that project doesn't specifically have the commands you need for a credit card (though that other link does have the APDUs you need).
And credit cards generally all will let you read their PAN (the account number printed on the front), expiry date, and in some countries even the cardholder name (though in the US for privacy most banks tend to not expose it, instead returning stuff like "VALUED/CARDHOLDER" as the name) without any encryption or keys. It will not however return the CVV2 code printed on the back of the card, which is generally required by merchants to be able to place orders on the internet, and it also generally does not let you clone the card since there is dynamic/encrypted data required to do card present transactions at a physical merchant.
Short answer: No. It's unlikely Credit card would work with WP8.
Long answer:
RFID vs. NFC: As far as I know most credit cards don't have NFC. They have RFID. Which one could say it's a "predecessor" technology to NFC. RFID is mostly non-standardized, has longer range than NFC and only supports one-way communication. Whereas NFC is an evolving standard, can be used in 2cm-4cm range and supports two-way communication. So, WP8 does not support RFID but it does support NFC.
RFID on WP8: All that being said, there's a chance that WP8 could identify some RFID tags. You might be able read byte[] from specific RFID tags in specific WP8 phones. Obviously, that's not recommended.
Secure NFC: One last thing is that some very exclusive partners in some very specific regions will have access to "Secure NFC". Secure NFC is a superset of NFC and adds the feature to store & transmit secure information via NFC from WP8. For example Secure NFC can store a Credit Card number or a bank account number as part of the WP8 Wallet. However, That will only work in regions where the mobile operator issues a "Smart SIM" (SIM capable of running applets), where the developer can author Java based Smart SIM applets, where the developer has an agreement with the mobile operator to deploy those applets over-the-air, where those WP8 apps have been cleared with Microsoft for the WP8 store and where there are dedicated retail HW terminals that can read them.
Sorting out a bit of the above answer of JustinAngel:
RFID is not a predecessor technology of NFC
RFID covers various frequency bands of Radio Frequency Communication (e.g. HF and UHF)
NFC is Near Field Communication and usually covers HF (13.56 MHz)
Many standards fall under HF NFC: ISO14443-4, ISO15693, FeliCa, ISO18092, .....
NFC Forum is trying to unify things and uses NDEF messages to exchange semantic messages
contactless payment on credit cards is based on a contactless smartcard layer.
WP8 allows only exchange of NDEF messages
WP8 does not allow exchange on the contactless smartcard layer (ISODEP==L4==(T=CL))
see the windows proximity api for details or http://developer.nokia.com/Community/Wiki/Use_NFC_tags_with_Windows_Phone_8
Android however gives access to this ISODEP layer
I don't know what credit card information could be retrieved from an app. There is a secure element involved which handles cryptography and stuff. I don't think detailed information on Mastercard payPass or VISA payWave is freely available
Can I read credit card information with a NFC capable Windows Phone 8?
No, you cannot do that. NFC API on Windows Phone 8 is very limited.
May be Wallet API could help you somehow with your project, but this is not about NFC.
Also you could try to use Android devices with NFC, they have more powerful NFC API than WP8.
I wanted to create J2ME application, in which the application should work only with the SIM card that was used during installation. On SIM card (GSM) change the application should now work.
For achieving this, i thought of taking an signature of the simcard and save it in a persistent storage. On every start of the application the signature can be verified. Any idea of how to implement this.
Thanks in advance
The 'SATSA' (Security and Trust Services API aka JSR177) could be used from your J2ME application to communicate with the SIM. You could send '3GPP TS 11.11' commands to obtain the IMSI (select file DG_GSM, select file EF_IMSI, read binary).
Drawbacks are: (1) You're talking to the SIM on a relatively low level of abstraction (the ISO7816-4 layer); (2) Not all handsets support JSR177 at the moment.
I believe this is not possible. If it was possible with a specific phone it would not be possible in a generic way.
For ATT in US, for J2ME apps, the handset embeds "CarrierDeviceId" in the Jad file. This is unique per SIM card. So, if something similar is available to you, just read this Jad parameter the first time the app starts, save it to RMS or send it to server. Now each time the app starts, you can verify this number matches, and thus verify the SIM card is same.
You can also try obtaining the phone number that is tied to the SIM card and thus verify the old SIM is being used.