i have developed a windows desktop application and it is ready for distribution. Target buyers are in the order of few hundreds only. Yet wishing to protect it from unauthorized use.
First idea was to use something like HASP key etc. Found costly for my case. Then googled about machine fingerprint etc to write my own code. Found mixed opinion about it. Especially the fact that it might not be that end-user-friendly when they upgrade hardware.
Why should the fingerprinting be from machine.. it could be from something else which is unique and yet connected to the machine (hoping sim card is unique), right.? Put a sim card on a usb reader and plug it into the system. The application shall read the sim card id for authentication. Assuming i supply the sim card and pre-code their ids in the application. Is this idea sane and possible?
Thanks, Chandra.
Related
I am trying to build a system with a raspberry pi that allows clients access into a building depending on their membership status. Right now, it uses QR codes, but I want to know if it is possible to add a feature where it uses some technology like NFC or RFID or Bluetooth to detect their phone or RFID card from at least a foot away and confirm they have a membership.
Someone told me I could use RFID, but I am only aware of that being used in short-distance applications, like a card on a hotel door. I am not sure about Bluetooth either, because the phone would have to connect to the pi first, right? Maybe there is something I don't know about. So please offer any suggestions. Thanks
I think bluetooth does good work for tracking user. Since it's the best to handle large distances than NFC and RFID these two technologies are used for low range scenarios, check this link.
In addition, you can check distance(using Proximity and RSSI) and membership status as well. but you need to know how to handle bluetooth connectivity with raspberry pi check this link. as well create an app on that mobile phone to use Bluetooth (depending which OS you're using for Android, iOS).
Regards,
what's the current use of java cards? The documentation is either really old or really sparse.
After googling for some time, this is my perceived idea:
eID: signing document hash with private key, issued by central authority (government) - signing legal documents
unique ID - identification (of person) by ID, protected by PIN and secured by TLS
java connected edition web application - I've not been able to find any documentation for the usage of this, except template applications in IDEs. Why are APDU's still used when there's this layer available? Is the application for this non-existent?
Despite all the new functionalities, I see they're only used as identification for a central repository/provider? And the TLS is used to secure communication between the card and backend server?
Thanks.
SIM cards are usually Java Cards, banking cards from Mastercard and Visa are usually Java card, and so are many others. ePassports can be build using Java Card. There are secure elements within readers that are Java Card. Driver licenses, driver licenses, digital tachograph cards, access control cards, cards holding PGP keys, etc. etc. etc..
There are billions of Java Cards, and Java Card is the only reason why Java was claimed by Sun to be on 3 billion devices (and note that they will probably not count Android as that officially is not Java). Currently the JCF (Java Card Forum) is also pushing Java Card forward as secure / programmable element to be used in IoT devices.
eID can be and usually is used more than for just signing documents. It is mainly used for authentication. It may also be used just to verify specific attributes of a person such as his / her age. And it can of course be used to decrypt information if an encryption key pair is present.
So no, there are many more things that Java Card can be used for.
As for the connected edition: it requires highly expensive hardware (smart cards are products that rely on high volume where every cent matters). Furthermore, a lot of protocols are specified using APDU's: you cannot just replace that with HTTPS to the smart card without respecifying the protocols.
ISO/IEC 7816-4 is a horrible standard - if you can call it that - but it currently is the only broadly accepted one. Java Card RMI has not caught on either; I don't see why the connected edition will suddenly change that.
I've patched android with SEEK for Galaxy S3 and after some struggle I'm now able to send APDUs to SIM card and get proper responses.
I want to place my own applet inside SIM but since there is no way we can get the access to do so, I start to wonder if there is anyway we can issue a java card to work like a SIM card. All I need is a java card that the phone can't distinguish from a SIM, no network coverage is needed and I know it is almost impossible to create a SIM that works OK with operator and gives network coverage.
The reason for all this is I need to send APDUs and work with my applet, but if I insert a java card instead of a SIM card in GS3, it gives me no access at all.
So my question is this:
Is it possible to issue a java card so that it looks like a SIM by the phone (and not the operator)?
or Is it possible to change android so that it gives needed access when there is a java card in it, i.e. RIL works as usual?
EDIT
Okay, I think I'll try to issue a Java Card with following properties:
First, it will have an auto selected applet (default applet) that from now on will be call fake-UICC.
Second, in fake-UICC we'll emulate the file system of UICC (according to http://www.in2eps.com/fo-uicc/tk-fo-uicc-mf.html).
Third, since different class is used for SIM APDUs (0xA0) so All APDUs sent from RIL will be directed to fake-UICC by JCRE, since class+instruction is not recognized by normal Java Card. e.g. 0xA0A4 is select for SIM but 0x00A4 is select command for Java Card.
In last step, we will try to send exact same responses a real SIM would send to each APDU.
Maybe it won't work but I think it's worth a try.
SIM Card (UICC) accessed through SEEK is not the only secure element you can use in your cellphone.
On the market there are other Java Card solutions: mostly based on microSD slot (provided e. g. by GoTrust or Feitian Technologies), which you should be able to access through SEEK.
Some cellphones (Galaxy S3 is not this case, unfortunately) are equipped with a special secure element slot, which you can insert common smart card (mostly by Oberthur) into and access through SEEK (see http://www.nfcworld.com/technology/embedded-secure-element-ese/ for some devices with this feature).
There is an interesting article about SE options: http://nelenkov.blogspot.cz/2012/08/accessing-embedded-secure-element-in.html
If you know some other vendors offering microSD Java Card products, please write them down in comments and I will add them to my post. This answer is not supposed to be any advertisement for the companies mentioned above.
Well, Actually I'm not sure if this solution works or not, and as dear #Vojta mentioned in the comments under his answer I would like to discourage people from the following attempts. It will be difficult, time-consuming and probably with no useful results. He knows a lot more than me in this field.
Anyway, as you wanted I posted my suggestion:
Each file in the system file of the SIM/USIM card is linked to a hexadecimal number as its addresses (AID). These AIDs are defined in GSM and ETSI standards (GSM 11.11 for example). You can write some Javacard applets to simulate that system file.
As SIM/USIM card's AIDs are shorten than JavaCard AIDs, you might need to choose a Java Card that support partial AID selection and use this capability to refer incoming command to its associated applet.
I think you can simulate all the system file inside a single applet also and then make that applet default selected applet.
If you had any success with this solution, please inform us. :)
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.