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.
Related
I am building an application in NodeJS + Express where teams can share information with one and other and chat (kind of like an internal messaging forum).
Sometimes there is a need for the team's clients to view and edit some of this stored information on a case by case basis (e.g. a client asks a question and wants to message back and forth with the team, using my app). I don't want the client to have to sign up for an account in this case.
I am thus wondering what is the most secure strategy for generating a URL where anyone with the URL can view and edit a document/POST data to my app within the confines of a single document, without signing in?
(I've seen a couple of posts on this topic but they're quite old and don't focus on this specific case.)
First of all, I can absolutely understand the benefits, but still it is not an optimal idea. However, I would like to summarize some thoughts and recommendations that will help you with the development:
A link like this should not be able to perform critical actions or read highly sensitive data.
Access should be unique and short-lived. For example, the customer could enter his e-mail address or mobile phone number and receive an access code.
If you generate random URLs, they should be generated in a secure random manner (e.g. uuid provides a way to create cryptographically-strong random values).
If I had to design this I would provide as little functionality as possible. Also, the administrator would have to enter a trusted email address and/or mobile phone number when releasing the document. The URL with a UUIDv4 is then sent to this channel and when the customer clicks on the link, he gets a short-lived access code on a separate channel if possible (on the same channel if only one was configured). This way you prevent the danger of an unauthorized person accessing the document in case a customer forwards the original URL out of stupidity.
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.
I have an S3 bucket containing objects that I want to share with users of a website. I know I can use something like Query String Authentication to provide secure access to the objects, but what if I instead make each object publicly-readable yet "hidden" behind a complex key (i.e. URL) containing a cryptographically-strong random number? If the containing bucket disallows listing of objects, there wouldn't be a way to guess or discover the URLs, correct? Or is there some security hole I'm overlooking?
Side note: my first thought was to use UUIDs in the keys, but I read that they can apparently be predicted, given a few previous instances. That said, I don't have an understanding of how easily that can be done. If it's non-trivial, I probably wouldn't worry too much about using them instead of a strong random number...
The problem is if the once shared URL gets into the hands of another user (say via sharing). If you ensure the URL is kept sufficiently secret, it is ok with this approach (say you return the URL to a user via https, and this user dont share it).
Any loophole here will cause a security hole - and here is where the query string based signature scheme is helpful, since the signatures are made to expire after a fixed time and so any re-sharing wont also harm you.
You can use UUIDs (ensure they dont end up duplicating, by regenerating another one if the new one collides). They are probably as difficult (or more) to guess as any other 8-letter password.
The standard way to do what you want is to generate pre-signed URLs for each of the objects you want to share. If you make them with a short lifetime, then they cannot be shared outside that time period. All of the AWS-provided SDKs have support for this feature.
I'm wondering whether a mechanism exists that allows client to client encryption. For example, when enabled, any information that is entered on one client can only be decrypted using a specific key.
Similar to how regular public key transactions work, but server agnostic.
A use case:
Everything on my Facebook profile is encrypted, and no body would be able to view that information (not even facebook). The users that I give the key would be able to decrypt that information.
This would allow complete control of data stored online.
The same idea can be applied for pictures uploaded to the internet.
One issue that I see is to have a practical mechanism to manage keys and a secure way to distribute keys to other users.
Has anyone done something like this before?
In case of Facebook I can imagine encrypting the data with OpenPGP keys into armored (text) format. Then you can place encrypted block to facebook or anywhere else. Other users would take the block, decrypt it on the client side and see it.
The same applies with other social networks and places where you can store some text block.
You can easily do encryption in some client application and even in Javascript (if you manage to make JavaScript load local user's keys somehow).
So I came across this new tag in HTML5, <keygen>. I can't quite figure out what it is for, how it is applied, and how it might affect browser behavior.
I understand that this tag is for form encryption, but what is the difference between <keygen> and having a SSL certificate for your domain. Also, what is the challenge attribute?
I'm not planning on using it as it is far from implemented in an acceptable range of browsers, but I am curious as to what EXACTLY this tag does. All I can find is vague cookie-cutter documentation with no real examples of usage.
Edit:
I have found a VERY informative document, here. This runs through both client-side and server-side implementation of the keygen tag.
I am still curious as to what the benefit of this over a domain SSL certificate would be.
SSL is about "server identification" or "server AND client authentication (mutual authentication)".
In most cases only the server presents its server-certificate during the SSL handshake so that you could make sure that this really is the server you expect to connect to. In some cases the server also wants to verify that you really are the person you pretend to be. For this you need a client-certificate.
The <keygen> tag generates a public/private key pair and then creates a certificate request. This certificate request will be sent to a Certificate Authority (CA). The CA creates a certificate and sends it back to the browser. Now you are able to use this certificate for user authentication.
You're missing some history. keygen was first supported by Netscape when it was still a relevant browser. IE, OTOH, supported the same use cases through its ActiveX APIs. Opera and WebKit (or even KHTML), unwilling to reverse-engineer the entire Win32 API, reverse-engineered keygen instead.
It was specified in Web Forms 2.0 (which has now been merged into the HTML specification), in order to improve interoperability between the browsers that implemented it.
Since then, the IE team has reiterated their refusal to implement keygen, and the specification (in order to avoid turning into dry science fiction) has been changed to not require an actual implementation:
Note: This specification does not
specify what key types user agents are
to support — it is possible for a user
agent to not support any key types at
all.
In short, this is not a new element, and unless you can ignore IE, it's probably not what you want.
If you're looking for "exactly" then I'd recommend reading the RFC.
The keygen element is for creating a key for authentication of the user while SSL is concerned about privacy of communication and the authentication of the server. Quoting from the RFC:
This specification does not specify how the private key generated is to be used. It is expected that after receiving the SignedPublicKeyAndChallenge (SPKAC) structure, the server will generate a client certificate and offer it back to the user for download; this certificate, once downloaded and stored in the key store along with the private key, can then be used to authenticate to services that use TLS and certificate authentication.
Deprecated
This feature has been removed from the Web standards. Though some
browsers may still support it, it is in the process of being dropped.
Avoid using it and update existing code if possible. Be aware that
this feature may cease to work at any time.
Source
The doc is useful to elaborate on what is the keygen element. Its requirement arises in WebID that maybe understood to be part of Semantic Web of Linked Data as seen at https://dvcs.w3.org/hg/WebID/raw-file/tip/spec/index-respec.html#creating-a-certificate 2.1.1
This might be useful for websites that provide services, where people need to pay for the service, like video on demand, or news website for professionals like Bloomberg. With this keys people can only watch the content in their computer and not in simultaneous computers! You decide how data is stored and processed. you can specify a .asp or .php file that will receive the variables and your file will store that key in the user profile. This way your users will not be able to log in from a different computer if you want. You may force them to check their email to authorize that new computer, just like steam does. Basically it allows to individualize service access, if your licensing model is per machine, like Operating System.
You can check the specs here:
http://www.w3.org/TR/html-markup/keygen.html