one advantage of NFC vs QR code is that unlike QR code which can be photographed and accessed from anywhere later, an NFC binds you to scan the NFC chip from close distance in order to access the info.
But, once scanned and your browser is ready to open the URL, what prevents the user from sharing the URL so that others can use it and access it remotely (or to use it twice, when already away from the NFC tag)?
My use case is to let a person who is physically near the NFC device, to submit some input, via a URL obtained from scanning the NFC.
However, I don't want to allow other persons to access that same URL, since this will enable them to submit data remotely (such as false data), and this will "contaminate" the info I'm trying to gather.
There is no way to dynamically change the URL as it is written once onto the NFC tag and that's it (to alter the URL every minute for example, the NFC must be re-written by physically accessing it, so this is not feasible).
I can't think of some extra token that can be applied here, since I can't physically pass such token to the user, and I also don't want to make it hard for the user to use the system, by introducing another security layer and ask him to make another action.
This is now possible using the new NTAG 424 DNA chipset, the feature you need is called Secure Unique NFC Message (SUN) which can generate a dynamic URL each time the card is read
https://www.nxp.com/products/rfid-nfc/nfc-hf/ntag/ntag-for-tags-labels/ntag-424-dna-424-dna-tagtamper-advanced-security-and-privacy-for-trusted-iot-applications:NTAG424DNA
The only way I can think of doing this is not with an NFC card but with an NFC enabled device running Custom Host Card Emulation (HCE) software (Possible on an Android Device and may be possible with a PC and USB card reader)
As the device is emulating an NFC card when another device comes in to NFC range the HCE device will respond as if it was a card and send out an NDEF message with the custom URL.
The URL will be visible in the browser that a standard phone will launch given the right NDEF message but these URL's can be one time use as once the HCE device has sent the NDEF message, it can use the time or another method to generate a new URL for the next time somebody tries to read it's emulated card.
I can think of other methods that would require custom software of the scanning device to work either to hide the URL.
Or I think it might be possible with some of the Advanced NFC cards you can run applications on the card to generate a unique URL for the NDEF message, but that is very advanced stuff.
Host Card Emulating is complicated but possible for a non specialist programmer. The only problem is the item you are leaving for people to scan needs to be secured and powered.
Update
As mentioned in my Comment that using a JavaCard could dynamically Generate the NFC Data and recent I came across https://github.com/OpenJavaCard/openjavacard-ndef which is the code for a Java Card to dynamically generate NFC Data.
Related
My desktop app is used by customers. A customer is a user with a License Key AND his computer's MAC address. The desktop application can only be used on ONE instance.
So when a user buys a license and registers it (meaning he downloaded, opened the desktop app, entered and submitted his license key), I will first retrieve his MAC address and then do a POST request to my API, /user with parameters in that way {license-key: "license_here", mac-address: "mac_here"} so these are saved into my database.
Now, how should I do to secure the API calls in the desktop app, once the user is registered?
Let's say a user wants to access his setting tab, should I provide {license-key: "license_here", mac-address: "mac_here"} as parameters to the GET request and check if it matches his License Key and MAC address in my database, and if it does, display all his settings retrieved from the database on the setting tab?
Or is there a more secure way to do that?
Another way I thought would be for example to hash the license key and the MAC address, concat them and use that an authentication token that I would use for each request.
I am using an API instead of saving locally because I will create a mobile app once I am done with the desktop app, and I will need to share information between both apps.
Using NodeJS with Express and MongoDB/Mongoose.
What you are doing is attempting to authenticate the computer using some data/knowledge that only it has (its MAC and licence key). This is easy to get around as an unlicensed computer can spoof the data and fool you into thinking the request is coming from an licensed computer. If you only transmit the license/MAC data then its possible for any other computer with the knowledge to also impersonate a licensed computer just by intercepting a single request - all the info required to impersonate is contained within the request.
You can't enforce uniqueness of a computer without specialised hardware. This usually takes the form of a dedicated microchip that contains a key or certificate. The data cannot be read from the chip, but the chip can be used to create a digital signature.
Without dedicated hardware the best you can do is to use a unique license key per computer and require all requests to be signed using this key. This relies on the key being private (the signature is sent with the message, not the key itself) and is no guarantee as you don't control the client computer.
Edit - How this works:
Issue a license key to each client. On your server, record each key you issue against the MAC address of the computer it is assigned to. You should probably collect the MAC address at the time of issuing the licence. Do not get clients to 'register' their license. Clients must use the key to sign each request they send and include the signature and MAC in each request. At the server you validate each incoming request by looking up the key using the MAC address and recreating the signature yourself. If the signature matches the one supplied by the client then you know its genuine. Remember - this is still not foolproof! I can buy one license from you and install it on any number of computers so long as I get them all to fake the approved MAC address. I can also give my key to my friends and have them fake the MAC address too.
I am making an app using NFC tags and I have to prevent the NFC tag from cloning. I have seen many other NFC tags which when tried to be cloned, shows a pop up message "Cloning is restricted, tag is secured by secret key", I want the same security for my NFC tag.
That depends on what type of tag you use and what level of protection against cloning you want.
NFC tags (as defined by the NFC Forum) have no protection against cloning. Such tags are intended as containers for freely readable data (so called NDEF messages). Anyone could read an NDEF message from one tag and duplicate it to another tag.
Many NFC tags also contain a unique identifier that is pre-programmed by the tag manufacturer and cannot be modified on normal tags. You could use this unique identifier to determine if a tag was issued by you (i.e. you know its id) or forged (i.e. you don't know its id). Instead of using a list of genuine ids, you could also create a digital signature over the tag's id and its data. THat way, you could find out if data and signature are used on a tag with a different unique identifier. However, all data can still be extracted from your tag. Therefore, you should be aware of the fact, that specialized hardware (e.g. Proxmark, etc) and ready-made tags are available where an attacker can change the unique identifier to the value of your tag's id. So this is certainly not perfect cloning protection.
You could use a contactless smartcard/tag that provides communication encryption and shared-key based access control (e.g. MIFARE DESFire). With this approach, you could store data that you do not want an attacker to be able to clone in a key-protected memory area. However, if you want to be able to read that data from within your app (i.e. without having an online backend that directly communicates with the card), you would need to store the key to access the memory area within your app. Consequently, in an offline scenario (i.e. key stored in app), an attacker might be able to extract that key and use it to clone the tag.
You could use a tag/smartcard that contains a secret asymmetric key and provides a command to sign a cryptographic challenge with that key. In that case, in order to verify if the tag is genuine, you could request such a signature from the tag for a random challenge and verify the signature against the tags corresponding public key. This would certainly be the most secure solution as you do not need to store any shared secret within your app. The only ready-made NFC tag solution (that I'm currently aware of) that provides such functionality seems to be Inside Secure's VaultIC. Though you could create one yourself based on the asymmetric crypto functionality of a contactless smartcard (e.g. a Java Card).
Note that for all of the above cloning-protection scenarios you would have to create an app that checks if a tag is genuine or cloned. By default NFC phones only use the information in (1) and therefore do not perform any such checks.
Yes it's possible meanwhile to prevent cloning a Tag.
There is a new tag called the NTAG 413 - which can generate a new NDEF message every single time you tap it. (using AES krypto) This way it's not necessary to have a seperate app installed on your smartphone. You can incorporate the encryption in the URL of a NDEF for example and the host server can encrypt it with the same key. In case of copy the server will recognize it.
Some companies already offer them in different form factors, for key cards (hotels or access). More info can be found in this link but it's german..
https://www.variuscard.com/plastikkarten/chipkarten/nfc-ntag-413-dna/
While the original answer was correct it's getting a little bit out of date. Michael's addition (Oct 10, 17) added the NTAG413. There's now another additional NTAG424 DNA authentication NFC chip, which works in the same way. HID's Trusted Tag works in a similar way and there increasingly others.
Essentially the chips create a new unique code based on a stored key on each tap/scan. Code can be verified from a server.
There is no guaranteed way to restrict the nfc tag from getting clone as all nfc tags are by default . Other apps use secret key with in a nfc tag but that also can be cracked.
I have asp.net web api used by mobile app. In facebook I see notifications like "access to your account from new device". I want to implement the same. Device could be connected to different wi-fi or 3G so to use ip addrress is not good. How to define access from new device and remember it for future in "trusted devices"?
You could look at a combination of pieces of data to uniquely identify see EFF's website on browser fingerprinting.
But the common approach is to set a cookie and check if it is present in future visits.
You need a unique identifier for each device.
In case of a computer it could be a mac address, if it's a mobile device they each have a unique identifier you could send together with the request.
You would then keep a list of these IDs on the API side and every time a request comes in, just check if that ID is in the list you already have. If not then there it is .. new device.
Here is another discussion which could be relevant to your scenario : What is a good unique PC identifier?
I'm working on a system that will require a user to log in on a device using an account that they created on a website. Authentication will be over HTTPS, so that is not an issue. The application running on the device will allow in-app purchase using a credit card linked to their account, so it's important that the login credentials are secure enough that it would be difficult to attack using brute-force. The only problem is that the device that the user will be using will have limited user input capabilities (essentially, arrow keys and a selection button).
In this case, a typical username/password may be too cumbersome to enter, also requiring the development of a on-screen keyboard that is navigable via the arrow keys. Users would likely end up creating simple passwords that are easily cracked. However, once logged in, the user will be using an access token behind the scenes so they may not need to enter their password very many times.
The first step is that the user will need to enter their username or ID number. Using a number may be easier to enter, but also easier to guess. I'm open to suggestions in this area as well.
Next is the process of entering a "password". So here are a few ideas that I have, but I'm not a cryptography expert so I don't know how to gauge the level of security.
User must first register the device. This might be a step that I require anyway, for extra security. The device would generate a key that is sent to the server and stored with the account. The key would be required when performing future authentication requests. The user would need to log into the website to approve the device. The device isn't going to have any sort of identifier, so unless you log in soon you wouldn't know if it was your device or someone else trying to spoof you. It would be nice to be able to create some sort of additional identifier, maybe a short code, phrase, or an image is displayed so you can know it's the same device that you just tried to register.
Since entering a text password may be too difficult, as long as the device is registered, maybe a 4 digit passcode can be used when confirming in-app purchases. This may be nice anyway to prevent other users of the device from using your account without your permission. However, if they are watching you enter your passcode, then it's not really good for that purpose anymore.
If registering the device is not necessary, instead of logging in with a text password, maybe the user is presented with images or phrases as options and they must choose the right combination of images/phrases that matches their account.
That's all I've got so far. What are your thoughts? How can I create an easy, but secure, login when in-app purchases are involved?
I have been dealing with limited user input capability scenario. Would you describe the platform your app running on?It helps to fit the solution according to the platform security model.
Update: I hope you are not considering multi-user per device scenario. So, I am assuming that there is one user per device. The second assumption is the device may have a unique serial number that can be accessible through some APIs and the serial number is registered on the server in advance.
At the initial stage, the user generates a random key through the device select button and the app confirms the success of key generation probably it display the serial number (the user may need to register the serial number for latter configuration). Behind the scenes, the app sends the new key with its serial number to the server. The server updates its serial number with the random key in the database entry. The device can block further key generation or may allow until it is finally configured with a dedicated user. The device also persist the serial number with the random key in the local database/file. The user is then login to their account through a web interface to configure the device. For logged in user, the server presents a list of available devices and the user can choose a specific one that belongs to her/him and set four digit pin code. The server performs the following:
Link the user account, the serial number, the random key (the one the device sent at the beginning).
generate a token
generate a key using pin code and the random key as a salt through Password based key derivative algorithm (PBKDF2)
encrypt the token using the key derived at step 3
Update database user row with the cipher token.
The user can sync the cipher token through the device select button. To unlock the app, user must enter the pin code through a simple numeric screen. The app uses the pin code and a random key (persisted at the beginning) and generates a PBKDF2 key and decrypt the token. PBKDF2 helps us to slow down the brute force a bit but it is possible to enforce time based or attempt based lockout as well. For instance after some trail, the app can drop the user credentials and force the user to configure from the scratch.
In my project, there will be about 500 Bluetooth devices installed over the city and about 20 PDAs used to update these devices.
The devices should be not be visible to anything except the PDAs and I'd like to avoid the troubles or pairing each device to each PDA.
Is there any way to pregenerate 10,000 link keys (for each device-PDA pair), knowing their device addresses, so that link keys for each of the devices could be uploaded all at once during the firmware upload process?
define a shared secret and use the mac-addresses as salt.
with this, you are able to generate a key, which is known on both systems.
or something like that :)
pseudo:
key = int(private part (shared secret) + public part (mac-address))