I'd like to know if I can limit what cards can be read with an NFC reader. Maybe with some kind of prefix on the cards, I could say e.g. "If the card doesn't start with 90H, reject it immediately."
To be clear, I want to restrict access in a way where even if the reader itself was plugged into another computer, it still couldn't be used except with cards that I've encoded myself. Could this be done via a certain configuration to the reader? I'd really like to know if it's possible before I dive into my project.
I'm using the ACR122U USB NFC reader with RFID cards. My goal is to use it with an online application to authenticate cards and grant access to certain services.
Typical smartcard readers are rather dumb devices that only take commands from a host system (e.g. PC) and use them to access (contactless) smartcards. Hence, you cannot reprogram the smartcard reader to deny access to certain cards. Instead, this is something you would need to do on the host side (and/or card side).
So you would typically write your application (that uses the ACR122U to access cards) in a way that it only talks to certain cards. Moreover, depending on the smartcard, you might also want to setup authentication keys that are only known to your application in order to prevent access to the card from other applications.
Related
I've my C# NET6 desktop application to send to customers, important functions have been removed and implemented on a server
I've my public server on which I want to auth desktop app(license, feature...), get its blob, process it, send back
I consider the C# app crackable whatever obfuscator/protector I'll use (but i'll use anyway), server is considered secure, i need a secure point at customer premise.
The idea is to use an usb dongle to bring up a secure and authenticated session between desktop app and server.
Requisites for the dongle are:
Be able to do AES128(at least) and/or RSA1024(at least)
EAL5+/6+ secure MCU (nothing that could be dumped with glitches or baths in acid)
dll and API to talk with
So far i've looked at various sw protection dongle, but:
some are 15years old mcu and not sure if still in business
most doesn't tell what mcu is inside, some are fast (but silly) stm32, some are slow 8051
the expensive ones are the most complex ones, i mean it takes days to read unclear documentation and see that i don't need 90% of the package (enveloper, mssql db for my 50customers...)
i don't need at all their C# enveloper, I want to use a thirdparty/specific protector with VM
So i've looked at usb tokens PKI, FIDO2, PIV....but:
FIDO2 allows customer to reset pin and cear all certificates, no good as i want to burn keypair inside prior to ship to customer
PIV not found any cheap PIV only usb token, some FIDO2 expensive has also PIV interface, but...
to talk to FIDO2 and PIV i would need all the overload bloat of libraries that i very dislike (and also needs admin right, which i want to avoid)
PC/SC usb token are the most lowlevel to use, mscard lib and do whatever, nice but.....ISO-7816-8,9 are not public, costs like 300bucks to eventually see that my card vendor implemented custom stuff
I've 0x80 blob to send to dongle to powmod() it, that's all, no x509, no pkcs11, no base64, nothing human, just need a powmod(data) or an aes_dec(data).
Any suggestions?
While this is no full answer, I would like to address some issues:
You may underestimate the complexity required. Obviously necessary is some specification, whether RSA or AES operation is required. This has to show up somewhere, either as command parameter or as a set-up command (between host and connected token).
Pure modular exponentiation is unlikely to reach the desirable level of security, since RSA depends on padding to exclude some kinds of attack.
You may not like PKCS 11 interface, but it is proven and known to introduce no security issues. This may require notable effort if done on your own.
Given the mentioned EAL levels, my guess would be, that you need a smart card chip with USB interface.
The MCU is pretty irrelevant: to get crypto operations hardened, you need special hardware (as cryptographic coprocessors). It has little influence, how old the architecture of the chip is, which feeds the bytes to those.
I am trying to develop a custom cryptographically secure protocol for authenticating through an RFID smart card, all I can find over the internet are generic info on how write static Tags into the card.
For my project I need for the reader to send a Challenge nonce to the card (fixed length random bytes), then the card should send back the challenge encrypted with the hard-coded key (for example with AES CBC) or an hash HMAC.
The problem is: how can I program the card to do such behavior? I can write the code to do so, but how to "flash" it to the card. Also the code for the reader is not a problem (I want to use an Arduino with a reader module).
And then has a passive chip enough power to do this kind of calculations or is better to use an active one, considering that the distance would be few centimeters, such as behind a door?
A passive tag can't do this. Those just hold serial numbers that they spit out back.
You need some smarter card. You have basically two choices:
1) Choose a general-purpose card that fit your needs
The authentication scheme you describe is very widely used, and implemented by virtually all general-purpose smart cards, whether with contact or contactless (RF) interfaces (or both). If you go this way, you don't need to program the card with your own code, you just need to get the specs and initialize the card with the key value you want by sending the appropriate commands. And actually, with these cards, there are often generic tools available to initialize them. Easy.
Mifare (by NXP), for example is very widely used, easily available, and cards are cheap (drawback: it is certainly not the most secure cards ever made). You could use Mifare Classic - with proprietary NXP security protocol - specs here (be careful, the reader must be compatible) or Mifare UltraLight C, with open 3DES crypto - specs here. There are other variants, as well (e.g. Mifare Plus, which uses AES). Just don't go for the simple Mifare Ultralight, which doesn't provide authentication means. You'll see that for all these type of cards, there is a builtin authentication scheme that can functionally fulfill your needs (it is actually a mutual authentication, so it does more that what you require, but it's fine).
FeliCa (made by Sony), ACOS3 (made by ACS - specs here) are other possibilities, although I'm less familiar with it.
2) Get programmable cards
There are some, but it is not very easy to find for contactless and they are very expensive. You can lookup:
BasicCard (ZeitControl), which exist with dual interface. Those cards are programmable in Basic, and there are some kits available (but I'm not familiar with it either).
JavaCard (any manufacturer), which is a standard, but those are hard to find for small volumes. A few online shops seem to have some, though. These cards are programmable in Java (actually a subset of Java). There are tools available for the development phase (from Oracle, or even as Eclipse Plugins, for example). Then, for loading your custom applet in the smart card, you need to get familiar with GlobalPlatform, which is another (publicy available) standard, describing the way applications are managed in a smart card. This would be too broad to describe in detail here, though. You can find resources on the internet, but this road is definitely the most difficult.
Note, that NFC just describes the communication method and tells nothing about the intelligence available on other side.
More intelligence is needed (the command you seem to look for is called EXTERNAL AUTHENTICATE in ISO 7816-4), but does not help for your range problem, since the weaker the field, the less power is available. The idea of having communication through the door will only work for doors which are so weak, that a high-tech electronic protection won't improve overall security. The maximum distance achievable with standard field strength (heart pacemakers and similar devices limit that one) with nothing more than air between suffices typically for something like 10 centimeters. So for me it seems that your reader has to be on the outside and needs to be mechanically hardened against tampering itself.
(What would help, is a "card" with its own power source, so the field is only required for communication. As far as I know, this is mostly provided by a sort of external sleeve.)
What dim fails to mention is the product group of so-called native cards, which are typically only programmable with significant manufacturer support (non-disclosure agreement, probably fee involved), but luckily contain functionality for most use cases already, in your case the commands Get Challenge and External Authenticate.
I have designed a BLE peripheral into a product. There will be an app developed (Android, Windows) but for now I am writing firmware to support the app in the blind.
We cannot have someone access the peripheral who is not authorized. To handle this I have a password stored in firmware.
There are seven custom characteristics, all but three of which are disabled upon initial connection. The password characteristic is write only of course, once the correct password is sent the other characteristics are enabled.
I have no experience with BLE until now so I have no idea if this scheme is reasonable or not.
Is there a bettor way to limit access?
Thanks
Rich
The Bluetooth standard defines the pairing/bonding concept with its corresponding encryption. Based on your specification it doesn't seem like it fits your needs.
You therefore have to come up with something on your own. How secure you make it is completely up to you. Your proposal is the simplest and most unsecure way of doing it. The most secure thing you can do is use some protocol created for these purposes (https://en.wikipedia.org/wiki/Password-authenticated_key_agreement) to create a cryptographic key which you then use for authenticated encryption when you later communicate with your device. You decide which way you want to go based on the security level you want.
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.
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.