How to verify a NFC tag was configured by me (DRM?) - nfc

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.

Related

How do I open a website on an iPhone using java card on an NFC-B card?

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.

Locked NFC tag can still be formatted?

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.

Customer email using .online tld is being rejected

I'm using DotNetKit 1.2.6.5 and SagePayIntegration.Validation() is rejecting a customer email that uses the new .online domain (eg: foo#bar.online) with
CustomerEMail is invalid.
Is this fixed in 1.2.6.7 or is the source code for SagePay.IntegrationKit.DotNet.dll available somewhere so I can fix it?
Despite access to the source code (many thanks to #DavidG) SagePay Support have confirmed that the actual Gateway does not support all these new domains - so even if I modified the DotNetKit it would still be rejected by the Gateway.
SagePay support were very helpful but ultimately the
"... email domain foo#bar.online is not yet supported on our gateway.
We run development sprints continuously and although there are some
domains we may not yet support, we look to in future, dependent on
impact and demand..."
The SagePay Integration Kit uses this regex to validate email addresses:
[a-zA-Z0-9!#$%&'*+/=?^_`{|}~-]+(?:\.[a-zA-Z0-9!#$%&'*+/=?^_`{|}~-]+)*#(?:[a-zA-Z0-9](?:[a-zA-Z0-9-]*[a-zA-Z0-9])?\.)+(?:[a-zA-Z]{2,4})\b
Which does unfortunately not allow extra long TLDs. Fortunately I have the source code for the kit and I've added it to my GitHub account (along with a bug fix which is why I had to get it in the first place as SagePay are not updating it). You can find it here:
https://github.com/WiredUK/SagePay.IntegrationKit
And the Regex you need to edit is this file:
https://github.com/WiredUK/SagePay.IntegrationKit/blob/801f61cf965c391a98a025aa632949719084cef0/ApiRegex.cs
For info, you need to edit the very last part of the expression from 2,4 (which matches 2 to 4 characters in the TLD) to allow more, for example 2,30.
Edit: And just because I can, I opened an issue and fixed it.

Is anyone able to perform Receipt validation?

Is anyone now online able to perform receipt validation in a Mac application?
Have you used the ASN generated files in the application?
Are you able to produce a sample receipt by automatic popup of the iTunes authentication?
The best way I know to check receipts is by letting Receigen generate the code - different for each new version. It's probably more secure than what you can develop in a reasonable time.
I have it working, but i am using open source code to do it.
Using this code in your main , and changing your app bundleID/version, it validates the receipt.
In this question you can see the code i used.
Mac App Store Receipt Validation Code?
I've got an example receipt at my question here (Can Purely On-Device In-App Purchase Receipt Validation Be Done With iOS6?). I've generated the ASN files and am trying to use them now. I used the compiler here. I'm not sure if it all works though, just starting testing in earnest now.
Chris.

File based Spring Security

I'm working on a Web Service project to provide data to a partner. Our app is really light weight and has only a handful of APIs. Because of time constraint and in-house pre-existing knowledge we went the Spring MVC / Spring Security path to serve those restful APIs.
At any rate this is a B2B project where we are expecting only that partner to hit our servers. So it seems a little over kill to modify are very small db schemas to add tables that would contain only 1 user access record for that partner...
Heard someone say though that it's possible to use an encrypted file, or at least a file where the password information is encrypted, instead of the database to hold the Spring Security user access information... Is that true? If it is can anyone point me to some references? I couldn't find anything relevant on Google at first glance... :(
Thanks.
http://www.mularien.com/blog/2008/07/07/5-minute-guide-to-spring-security/
See the '' under the authentication-provider; this allows you to use encrypted passwords (use sha). If you only have a single user and you wanted the information in an external file, then you could use a property file configuration placeholder to simply specify
${user.1.id} ${user.1.passwordenc},etc... kinda hacky, but it would work.
It's VERY possible. In fact, you can do it without coding; it's pretty simple to include the credentials directly in the XML defining the Spring Security stuff. You usually see this in examples, followed by warnings to "DON'T DO IT LIKE THIS!"
If in-house security is no big deal and you're not worried that your developers can see your password (as if they needed it, heh!) and no one else is likely to access your configuration files, then this is a quick and easy yet workable solution.
I'm going to post this, but I'm off to go dig in the Spring Security documentation for the example I was talking about I'll be back!
Update
Trever Schick was a bit faster with the example. I had a different example in mind but his code shows exactly what I was talking about. You define your security provider in the XML and provide user ID/password right there. There are a number of utilities available on the 'net for you to MD5 or SHA encode your password for you so you can cut and paste it into the file.
You need to implement a new org.springframework.security.core.userdetails.UserDetailsService that reads the user's information (username, password, enabled flag, and authorities) from a file. I don't know if someone already implemented it.

Resources