We are testing NFC tags for public places with simple URL.
I have a NXP Mifare Ultralight EV1 card. Writing and reading worked as expected. Then I put desired URL on the tag and locked it. (permanent write-protection).
I couldn't write to it after, but I could still "Memory format" the tag (with iOS app NFC Tools).
This removed the URL but since the tag is locked, it won't allow me to write to it again.
Does this mean, I can't trully protect NFC tags and anybody with this app can format them?
Is this card unusable now?
Should I choose different NFC type to prevent this?
SCREENSHOTS: https://imgur.com/a/qJmXCdJ
From the Capability Container it looks like a Tag and with the Capability Container security set to prevent write access.
So at the hardware level setting this type of write access is irreversible BUT this type of Tag does not seem to be listed as NFC compliant but it does seem to be compatible with the NFC Type 2 specification.
The NFC Type 2 specification does not specifically say whether this protection should be enforced at the hardware level or software level BUT as this Tag is not listed as NFC Type 2 complaint in it's datasheet then this might be the cause of the funny behaviour as it only seem to be NFC Type 2 compatible.
So to answer the question "I can't trully protect NFC tags"
I would not use Capability Container security access field ("Lock Tag") to prevent writing even on a compliant card. Instead set a Password on the Tag and set the Password to protect write access.
This achieves the same end goal of normal users not being able to write to the Tag and is definitely implemented at the hardware level and not not reliant on specification that this Tag does not says it is complaint with (and that might be implemented in compliant software). But is also reversible IF you know the password.
To answer the question "Is this card unusable now?"
Unknown but likely you will get varied results with different hardware and software so best to not use this particular Tag.
To answer the question "Should I choose different NFC type to prevent this?"
As you seem to be writing NFC Forum specification NDEF data to the Tag it might be wise to use a Tag that is fully compliant to the NFC Forum's Tag specifications as this might provide better compatibility with all NFC Forum compliant reading hardware. A similar Tag that is fully compliant is the NTAG 21x series.
Update
I think the main problem with that card is page for the "Capability Container" comes blank from the factory and therefore could be used for other purposes. Which means the card hardware cannot be certain that a value in that page means lock the card, therefore it cannot implement that locking in hardware.
Where as a compliant card must come from the factory with a correct initialised "Capability Container" therefore the card can guarantee the meaning of these values and correctly lock the card if the right value is set.
Related
I am trying to use an OMNI from NFCRing to send a website to Apple and Android phones. I'm new to NFC so I don't really know what I'm doing.
So far I have attempted to build and install the full NDEF applet from OpenJavacardNDEF using version 20.01.23 of the GlobalPlatformPro API. Whenever I try to send ADPU commands to the card, however, the response is always 0x6D00.
Edit:
The APDU commands I have tried are 00000000, 00a4000c, 00a4000c02e10400, and 00b00150 all with the same response. I am trying to follow the protocol outlined in the applet's documentation but I may be doing something wrong; as I said I am new to this.
It looks like you are not doing the first step of actually selecting your Application, that protocol doc you linked only give you the details of how it can respond to each type of command once selected.
As you are trying to emulate a NFC Type 4 Tag I would read the NFC specification doc Section 5.4 is the most relevant.
But as a shortcut:-
The first ADPU to send is 00h A4h 04h 00h 07h D2760000850101h 00h
This is select the NFC Ndef App standard AID number (the D276... part)
If you look at the OpenJavaCardNDEF example client library on connect and performSelectApplet do just this.
Further APDU's are needed once the applet is selected, I would read the NDEF spec and or the example client library on which ones are needed to do what you want from the Tag.
I'm looking for a way to verify that an NFC tag was set up by me. so I will be selling products with an NFC NDEF216 tag inside. I will be preprogramming the chip with an NDEF message and write protection using a private password I will keep private. Now I'm looking for a way to verify the chip actually came from me so the app I'm building will only work with my stickers.
Where can I write some sort of identifier on the NFC sticker? I tried overwriting the serial number but that seemed to fail. I cannot use the PACK verification because in some cases the protection will be disabled. I read the NDEF216 manual but did not really find a good way to do this
Update: I ended up writing a predifined bytecode in the last bytes of the writable storage and securing it with a private code. this way i can check for the bytecode in the storage, if the bytecode is present, the product is valid.
Our site uses a content security policy with Braintree's implementation of 3D Secure.
There are multiple calls made by songbird.js (CardinalCommerce implementation of 3D Secure used by Braintree) to third party sites (such as kg668dbov0.execute-api.us-east-1.amazonaws.com, touchtechpayments.com, or arcot.com) which are not documented in the CSP requirements outlined by Braintree here https://braintree.github.io/braintree-web/current/.
These calls to third party sites don't seem to be documented anywhere on the web either, and seem to change at random. Every time there is an undocumented change it breaks our 3DS integration (iFrame doesn't load as the undocumented url is blocked by the CSP).
The urls seem to vary based on the card used (touchtechpayments.com seems to be the Revolut one, arcot.com seems to be HSBC), and I can see a couple others for French banks in our CSP violation report: https://bred.wlp-acs.com for Bred, https://bnpp-3ds.wlp-acs.com for BNP Paribas).
Does anyone know where I can find an up to date list of the content security policy requirements for songbird.js ?
I've created an issue on the braintree github page:
https://github.com/braintree/braintree-web/issues/497
My list so far:
3ds-secure.cardcomplete.com
ecclients.btrl.ro
bofp.erstebank.hu
www.clicksafe.lloydstsb.com
pay.activa-card.com
3dsecure-1.wirecard.com
3dsecure-2.wirecard.com
acssv.otpbank.hu
acs.sia.eu
idcheck.acs.touchtechpayments.com
sicher-bezahlen.sparkasse.at
secure5.arcot.com
I'm using James Montemagno's Plugin.InAppBilling library for Xamarin to do iOS and Android in-app subscriptions. It has worked mostly correctly so far, except that once in a while, on iOS only, InAppBillingPurchase.PurchaseToken comes back null from calls to PurchaseAsync and GetPurchasesAsync.
For example, in my Restore Purchases logic, I have code similar to this:
var purchases = await CrossInAppBilling.Current.GetPurchasesAsync(ItemType.Subscription);
// Sometimes we receive purchases with no PurchaseToken.
// Can't verify the purchase without a token.
var verifiable = purchases.Where(p => !string.IsNullOrWhiteSpace(p.PurchaseToken));
At this point, verifiable sometimes has a different count (0) than purchases (1).
So far, this has seemed to happen when the user purchased using either store credit or a gift card, and only on iOS.
Also, I'm not sure if this bears on the problem, but I am not using the overloads of PurchaseAsync and GetPurchasesAsync which take IInAppBillingVerifyPurchase, because I use server-side verification exclusively (no client-side verification). My workflow is to make the purchase, add the resulting InAppPurchase object to a queue for processing, and then send it to our server as a separate step, for validation and association with the user's account. However, if this is not a valid workflow or if it is known that sometimes PurchaseToken data will be available via IInAppBillingVerifyPurchase.VerifyPurchase but not attached to the InAppBillingPurchase objects returned from the methods above, I would certainly like to know about that. (For what it's worth, I've read the documentation and don't see anything that suggests this.)
Thanks in advance for any help.
Okay, I think I've learned enough to provide useful information for anyone else dealing with this issue.
First, I've figured out what Apple means by "iOS 6 style" and "iOS 7 style" receipts. These do not refer to the version of iOS that creates the receipts. (My up-to-date iOS 12 device still can and does generate "iOS 6 style" receipts.) Instead, these refer to two different receipt formats that were introduced in the respective iOS versions.
iOS 6 style receipts come from SKPaymentTransaction.transactionReceipt and contain information about one specific transaction. This field is now deprecated by Apple.
iOS 7 style receipts come from the app bundle, via the location named in NSBundle.mainBundle.appStoreReceiptUrl. These receipts contain a full manifest of all purchases ever made by the user. The receipts don't expire either -- you can always send them to Apple for validation (though, obviously, individual transactions contained within might show as expired in the response). These are the receipts you should prefer.
The reason this is important is that if you're using the Plugin.InAppBilling library, the InAppBillingPurchase object you get from calling something like PurchaseAsync contains the deprecated iOS 6 style receipt in its PurchaseToken field.
I'm still not sure why it is sometimes present and sometimes null, but seeing as the underlying source of the data is deprecated, it's probably safe to assume that this can and will happen. Therefore, it probably makes sense to cut over to the iOS 7 style receipts as soon as possible.
Note that when you call PurchaseAsync, if you specify an implementation of IInAppBillingVerifyPurchase, your IInAppBillingVerifyPurchase.VerifyPurchase method will receive the newer iOS7 receipt instead. However, the InAppBillingPurchase object returned by PurchaseAsync still gets an iOS 6 style receipt (if it gets anything at all).
Personally, I like the InAppBillingPurchase object itself. It has useful information packed into a convenient package. Since I want to keep the serialized InAppBillingPurchase objects in a queue so that I can retry validation if there are problems with our servers, connectivity, etc, what I'm doing is immediately replacing the PurchaseToken property with the iOS 7 style receipt that I manually retrieve from the bundle.
If you do this, be sure that your code handles the slightly different formats of the iOS 6 and iOS 7 receipts properly. (Our earlier attempts had some errors stemming from not properly understanding what these terms meant.)
I hope this is useful to someone out there. Good luck!
I want to create a straightforward extension for Firefox.
User hovers over some word on any page
Pull the dictionary definition of that word from a file inside the extension
Display it while still hovered
I am new to Firefox add-ons and WebExtensions, so here's what I'm wondering:
I want the dictionary file(s) used by the extension to be local, instead of referring to some online website each time.
Any given user might be interested in a different part of the entire dictionary (it contains entries in different languages, users might only want their own 1 or 2 languages) so I want to avoid forcing every user to download the entire dictionary base.
The way I have seen similar add-ons handle that before Firefox 5.* is that they offer the search-and-display add-on separately from the dictionary files which are each available as add-ons in their own right, only actually doing stuff if you have the master add-on installed.
However, none of those examples seem to have been updated for the WebExtensions API and do not support more recent versions of Firefox.
I have also been unable to find how to communicate between web extensions so far.
My question being, how can I share information between 2 or more coorperating extensions to achieve what I described.
And actually, if this seems really stupid for some reason I'm unaware of, do point out any more reasonable alternatives that allow me to handle the dictionary files separately from the main extension.
Possibly related questions I found:
Communicating between 2 Firefox Add-Ons (Cross-Extension Communication)
This one is from 2010 however, thus out of date as far as I could tell.
Mozilla Addon Development - Communicating between windows with different domains
Kind of a similar situation, but they want to pull the definitions from an online source, rather than a local one.
The closest thing I found on the Mozilla browser extension website is communicating between add-on and some native applications, not quite what I need I think.
Communicating between add-ons is a normal part of the functionality of runtime.sendMessage(), runtime.connect(), runtime.onMessage, and runtime.onConnect.
Both runtime.sendMessage() and runtime.connect() have as their optional first parameter:
extensionId
For runtime.sendMessage(), this is:
string. The ID of the extension to send the message to. Include this to send the message to a different extension. If the intended recipient has set an ID explicitly using the applications key in manifest.json, then extensionId should have that value. Otherwise it should have the ID that was generated for the intended recipient.
If extensionId is omitted, the message will be sent to your own extension.
For runtime.connect(), this is:
string. The ID of the extension to connect to. If the target has set an ID explicitly using the applications key in manifest.json, then extensionId should have that value. Otherwise it should be have the ID that was generated for the target.
Both runtime.onMessage, and runtime.onConnect provide a sender property or parameter, either with the message, or as part of the port. This parameter/property is a runtime.MessageSender which includes an id property which is:
id
string. The ID of the extension that sent the message, if the message was sent by an extension. If the sender set an ID explicitly using the applications key in manifest.json, then id will have this value. Otherwise it will have the ID that was generated for the sender.
Note that in Firefox, before version 54, this value was the extension's internal ID (that is, the UUID that appears in the extension's URL).