Whilst this question has obviously been asked before, year's have gone by since then. Apple has released a new NFC spec in that time and further software updates indicate more speculation in this area.
A smartphone has an NFC chip. Is it possible to harness this to take an EMV payment from a contactless card or eWallet? This would obviously require an installed EMV kernel to securely process the payment and possible a means of accessing the secure layer for any PIN entry.
As much as this may seem like an ambiguous question, clearly the hardware is capable. Is it possible / legal / licensed in anyway yet. There is a service that claims to be working on it called PHOS.
Quite obviously, SO is not the right place for such a question as it's unrelated to programming. There's quite a lot of discussion regarding the topic and answers also will tend to be opinion based.
Up to this moment, it hasn't been possible on Apple (due to closed ecosystem, not hardware incompatibility) and became allowed for Android. Technically it's been possible for a while already, but regulations made consumer grade devices incapable of acceptance - they are still quite terrible in the physical aspect as they are not designed to either handle entries securely as well as generate the electromagnetic field according to EMVCo requirements as to the shape and operating volume. Payment schemes have generated as list of special criteria for solutions based on consumer grade devices and the company you mentioned is one of many that have been working on it. There certainly are already some production deployments with limits that have been set by the schemes.
There might be changes in Apple approach (especially as they acquired a company dedicated to such solutions) or not. This is just speculation. The fact is that consumer devices tend not to be as good as dedicated hardware but only time will tell if this stays true. Security research is ongoing, we shall see the results and how will that affect companies policy and further development in the area. It's just too early too tell.
Related
Problem Statement: Track an anonymous user to persist state (or lock out of a feature after a timer) on a device that has visited a website. This would need to work with cookies disabled, across browsers, including visits in incognito mode. This also would need to be device specific, 2 computers within a home network would have 2 independent timers.
I have seen this applied in a few scenarios with the most recent being the NBC Olympics with the stream timer. This has so many uses for "free no sign-up trials" while not giving away everything or limiting features in "try before you buy". Any ideas would be appreciated!
For this you would need to employ a cross-browser fingerprinting (or device fingerprinting) technique.
Related research
I recommend you read the paper (Cross-)Browser Fingerprinting via OS and Hardware Level Features by Yinzhi Cao, Song Li, and Erik Wijmans, which has an associated demo implementation of 2 of the techniques described therein.
Another good paper I found on web fingerprinting techniques which you should read if you're interested is Web-based Fingerprinting Techniques by Vítor Bernardo and Dulce Domingos.
The (in)security of device fingerprinting
The basis for device fingerprinting is collecting a variety of features from the client device which are indicative of the device/OS of the device, and are stable across browsers. Collect enough and the combination of these features of one user will very likely be unique among all users.
Most features useful for device fingerprinting can only be measured on the client (with JavaScript), and then need to be communicated back to the server, either raw or as a hash. Due to this, device fingerprinting as a security measure relies also on your ability to obfuscate the JS doing the fingerprinting and the corresponding network traffic communicating the fingerprint. If a user can figure out how the fingerprint is being collected and/or sent back to the server then they can spoof it to circumvent any protections you've put in place based on it.
Features that can be fingerprinted
Useful features to measure include (but are not limited to)
GPU rendering artefacts
anti-aliasing method
OpenGL driver varying interpolation
texture sampling
Installed fonts and writing systems
Text rendering minutiae
anti-aliasing
subpixel rendering
kerning, tracking and leading of particular fonts can indicate subtle variations due to different installed versions
In terms of low hanging fruit, there are Web APIs such as Navigator.hardwareConcurrency which expose details about the underlying hardware directly, however many browsers now disable or spoof this feature in order to avoid its use for fingerprinting.
The more features you collect the more solid your fingerprint, as long as they don't vary across browsers on the same device.
Conclusion
Ultimately, there is no be-all and end-all to device fingerprinting since it's a very complex topic with many potential approaches and a constant arms race with browser vendors trying to prevent fingerprinting techniques and developers trying to find new ones.
If you're looking for an out-of-box solution, there are currently a small handlful of open source and commercial browser and user fingerprinting services out there such as FingerprintJS (which is both). Though it does seem that many device fingerprinting solutions are not sold as standalone functionality but instead as a part of a fraud prevention system (such as SEON) or similar.
(The following is just opinion)
Overall it's my view that device fingerprinting is an iffy solution to locking out features, and a better solution is to make the signup process for an account as quick and easy as possible (though perhaps the free account could be used in combination with device or browser fingerprinting to temper abuse of the free trial system)
During the past weeks, I developed and published a small OS X utility app that sells for ~$3 in the Mac App Store. However, due do French export laws for apps that include encryption mechanisms, the app is not available in the French app store.
(It ships and uses libssh2 and implements SCP over SSH, and therefor does not use "encryption mechanisms that are provided by the operating system" - the registration process for that is all in French and neither Apple nor the French government seems to be able to help with that.)
As I got a bunch of emails asking why the app is not available in the French Mac App Store by now, I thought about offering a non-MAS version of the app. Coming to my initial question, I'm not sure if I want to spend time on implementing any kind of license key check etc., or just offer that version completely without DRM / license checks as it surely will be cracked either way. (The Mac App Store version is available as a torrent for quite some time now, so whoever wants to steal the app will do no matter what I finally do.)
So, I'd like to ask you guys how you handle this, or how you would handle this if you were in my situation? Spend time on implementing a license key check that will be cracked either way, or just offer a non-DRM version that'll sell in France to make everyone happy?
Thanks.
Disclaimer: Original thread from HN (https://news.ycombinator.com/item?id=7796397)
Update to finish this up:
I finally decided to implement a license validation for the Mac App Store version that is very hassle-free for the user. In the best case, he doesn't even notice this, in the worst case (where no receipt is found within the app bundle) the app will trigger the storeagent to download the receipt and then successfully relaunch. Pretty simple.
For the non-Mac App Store version (which I've introduced because of the French App Store issue explained above) I stick with a 3rd-party contractor who handles all the licensing for me.
I guess this way is a good tradeoff between security and positive user experience. Thanks for your input.
In my experience, if you are going to sell the software, you should consider a very lightweight license checker. As you pointed out, people will break your DRM if they are sufficiently motivated, so you can't hope to prevent intentional piracy. However, having a simple system that reminds users who download the software online that they should pay for it (and if it makes sense providing a basic trial system) is a reasonable approach.
However, don't spend too much time implementing the system, and make sure you thoroughly test the key system before every release, because trying to explain to users that you accidentally made it impossible for them to use the software that they have paid for is something you never want to do.
Bigger than the question of whether it's going to be hacked is whether the overhead of managing the licensing will overwhelm the profit. For example, I've seen people with very inexpensive apps basically have a checkbox for users who bought the app in order to turn off the reminders in trial versions. Very shareware-like, but considering the cost and potential review hassle of a problem with licensing, it might be worth considering that approach.
If you want to put in a bit more effort, there are a couple of open source libraries, including Aquatic Prime that provide more sophisticated protection , but require integration with whatever type of online store you are using. Since it's reasonably widely used in the community, store systems like FastSpring provide built-in integration with it. Also, it looks like the open-source Potion Store supports it out of the box. I've not used it personally.
Beyond that, my experience is that they are a large pain to create/debug/support and unless your app is expensive enough to require special features like partial-enabling, expiring licenses, region testing, real-time revocation, etc., it is likely not worth the effort to do anything custom.
I'm very interested in developing NFC apps, which may or may not interact with mobile devices. But right now, I am starting fresh and would like to know if there is any development toolkit available to start toying with APIs and libraries.
My point is, I don't have a phone with NFC and I would like to develop something and test some ideas. Can I buy an NFC chip for testing, some dev kit of some kind, without actually buying an entire smartphone?!?
It would be nice to test some ideas and proof of concepts before investing hundreds of dollars. The mobile app for smartphones could certainly be developed later.
If your budget is limited, I would recommend searching for a second-hand Nexus S or a similar device (perhaps even a damaged device, with a cracked screen, as long as it is functional). This costs probably about the same amount of money as a reasonably decent NFC development kit (or less, for a damaged device) and will serve your needs much longer.
Another option would be to just buy a contactless reader that is supported by libnfc, such as SCL3711.
In any case, you probably also want to buy a handful of empty NFC tags. If you are really serious about this, it may be worth investing in tags that are not the simplest and most limited in functionality. In that case, you could go for MIFARE Classic-based tags or DESFire-based ones; these are generally available on-line.
You may also be able to acquire some (used) public transport tickets, library book tags (from discarded books), ski-lift passes, old access control badges, etc. to experiment with. Often you cannot write to such tags, but they may still be nice for experimenting.
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 10 years ago.
I asked a question about a good book for this topic.
It's not getting many replies, so maybe there aren't any good books (although I find that strange; I must go search Amazon for myself).
In the absence of a book, maybe there is a good framework, some good URLs, or just general advice.
As I asked in the other question:
I am looking at several projects, all
with roughly the same functionality.
Some instruments collect some data (or
control some functionality). They
communicate by Internet
(Ethernet/wifi/GPRS/satellite) with
a database server which stores the
measurements and provides a browser
based means of querying the data,
producing reports, etc (and possibly
also allows control of the remote
equipment).
Can anyone recommend a good book
describing an approach to developing
such a software architecture, keeping
it generic, which tools, languages.
test methods, etc to use?
For "book", please substitute "framework, some good URLs, or just general advice".
This is a very common system pattern. Who can advise?
I have written a complete SCADA system (excluding the custom instrumentation hardware). The system was designed to be generic to allow the creation of new hardware models, instruments, and data collection - it was not written like so many SCADA systems for an individual company/plant but is used internationally for thousands of companies/plants.
I was the sole developer/designer with one member of management overseeing and guiding the project. It took longer that way, but it was doable. We looked at other SCADA specific systems/frameworks already out there and decided that since our units were custom, it would be easier and more flexible to write the system from scratch leveraging existing development frameworks and 3rd party components. Looking back, this worked out really well for us because we had the time and skill, but this is generally not the best solution depending on your business/contract model.
I am no longer with that company, however, they still use my software exclusively and I left on excellent terms. I would be happy to answer any general questions you have and to help point you in the right direction.
System Architecture
Here is a high-level overview of what the system consisted of:
Custom Cellular devices that had generic inputs to accommodate multiple instruments of varying types (analog, digital, pressure, amperage, floats, etc.)
UDP/TCP packets of custom format were sent by the units across the cell network (GPRS) to our servers (Windows Server 2003 R2). Information was sent regularly for reporting, and on customizable state changes that could be programmed at the device or online (the configuration sent over the cell network).
A custom Multi-threaded .NET application using TCP/UDP Listeners that grabbed incoming packets (Several Hundred-thousand a day), deciphered custom headers, and routed the packets without further interpretation to the correct database (Some clients required their own standalone system)
A Microsoft SQL 2005 database that acted as the brain for the entire system. Packets were interpreted using CLR functions and automatically triggered alarms (as configured), compiled reports, and kept a full history
A custom .NET application to handle alerts by placing phone calls, sending SMS messages, and sending emails. The phone logic was handled by an Intel Dialogic Card over analog lines using a combination of recorded prompts and Text-To-Speech.
3 ASP.NET sites:
Customer facing site that allowed them to manage their accounts/sub users, track alerts, configure units and alerts, chart data, map devices, export reports, etc.
Sales site that allowed the distribution of material to sales people, tracking of individual devices, device health reporting, etc.
Internal management site that allowed the creation of customer accounts, the configuration/build of units, and all other administrative features as required.
There was also a custom internal monitoring system to verify the health of the system and to alert technicians of problems as necessary since the system needed 24/7 uptime.
In addition we created an iOS app, a mobile site, and a custom web service/client (API) to allow the retrieval of customer data directly by customers to allow them to integrate our solution with their existing (usually custom) SCADA systems.
Those are the components we used and they worked. Doing it again I would change a couple of things. I would use Windows Server 2008 R2, SQL 2008 R2, and instead of a Dialogic card I would use Microsoft TellMe using VoIP. I would also use Silverlight instead of ASP.NET. I really like ASP.NET, but Silverlight can give a much better presentation and can be used outside of the browser as necessary - a common request from SCADA operators.
The sites all used 3rd party components so that charting, and tables didn't have to be written from scratch. There are some SCADA specific components (largely Java based) out there. However, we found most of them to be crude, ugly, or way too specific to be used in our generic system (also expensive! It was easier and more flexible to customize a gauge/charting package to "make" our own).
As mentioned, the brain of the system was the database. This was done because Microsoft SQL is a pretty awesome, well supported product designed for extreme uptimes with great backup and performance options. We were also really impressed with the .NET CLR integration that was possible allowing our custom .NET code to run as a part of that process. The units we were supporting came in a variety of models and could be configured to use any combination of instruments and so keeping the database flexible was key. We used a lot of normalization!
One thing that really helped was to use Recursive CTEs to fake the existence of data when the values were still the default. We did this to save space in the database, but this also enabled us to introduce a layer of abstraction in the database that allowed the queries to be flexible as well.
We had messed with OPC in the past but found it too inflexible, difficult, and irritating for our needs. That was a few years ago though, and I haven't looked at it since.
That is a long and very general answer to your question. I can't give you specific code or go into extreme detail since that information is property of that company, but I can answer some design questions and point you towards frameworks/tools we found helpful. My main advice would be to break everything down into separate components and employ the black box model on each so that individual components can be swapped out/improved as necessary. The scope of the project can seem overwhelming otherwise. Let me know if you have further questions or would like more information, good luck!
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
We plan to sell a Windows portable application. By 'portable' I mean that it can be run from any Windows computer without installing it. For example from an USB stick etc. However the application while (theoretically) it can work anywhere, is targeted to LAN environments.
What solutions do you see that while keeping this advantage (in a more or a lesser degree) to still make money from it?
PS: The application is/will be written in Delphi.
If you are offering your product for sale and not for free, then you will most likely make money from it. If what you are asking is how to maximize the income and prevent piracy, then that is a more specific question.
The key to making money with software is to make the purchase route less painful then the piracy route. Usually the biggest hurdle to purchasing software is the price tag (but not always, some people just will never buy software and always pirate, but you can't do anything about that). And the biggest hurdle to piracy is some sort of DRM scheme, which is actually the second largest hurdle to purchasing software. Often times DRM only annoys the legitimate purchases, while the pirated version has all the DRM removed with less effort then you spend to put it in. Thanks to the wonder of electronic duplication, once the DRM is removed, then everyone can have a DRM free copy.
So you want a solution that only annoys illegitimate usage, but not legitimate purchases. This is much harder to do then expected.
Depending on the price tag for your software you might consider deploying it on a keyed USB drive (i.e. Dongle or USB stick with some special key). Then it is portable, but only on the hardware you provide. The user never has to worry about a secondary authentication scheme, and the DRM only becomes an issue when the hardware (which is harder to duplicate) is changed.
You say that it is only for a LAN environment, which doesn't necessarily mean that the computers will have internet access (and if they do, they probably have a proxy requirement) which means "phoning home" will be problematic. If you want the product to only be used on a specific LAN then you might require a license server to be installed on the LAN. Then the software could always check with the license server to make sure it is authorized. That won't work if you want it to run on multiple LAN's though.
Conversely if your price is low enough then most companies and people would rather buy the correct licenses and not risk the piracy. In actuality, depending on your clientele, most people will prefer legitimate licenses when they can, and DRM can actually discourage them from buying licenses.
Some alternatives:
Use a dongle, where the user of the software must plug in the dongle before your application can work.
At startup read a configuration file and if this is invalid or missing, halt the application or reduce its functionality. The configuration file should contain information about the user or company that licensed your software, and also a checksum to prevent users from changing the file. With such a file, serious companies are less likely to distribute this configuration files to others. Of course, you should then create one such configuration file per user that licenses your software.
Optionally, include specific computer information (type, memory, bios date, system guid, ...) that prevents the application from being run on other computers.
Make sure you make money from the service you can deliver, not only from the software you are selling. This service can include: providing upgrades, taking suggestions for improvements, assisting with problems, helping with domain-specific knowledge, ...
You can use some sort of license file and a "phone home" option that makes sure the same license is not used at more than one place concurrently.
If you have a large ordfer, you could try to get a memory stick with a special serial number and/or value in it that you can read out in the software (eg the exe must reside on a special memory stick)
Please note that a lot of users get quite annoyed by these things (we've used the first option)
Also please note that if commercially interesting, your app will be hacked. Make sure the effort someone has to take outweighs the profit the could make
One approach that also helps some is by custom branding. Each copy you sell would have compiled into it the name of the company it was sold too, which can be displayed as part of the splash screen as well as the about screen (along with a button to view the license terms). Most often this branding is done by using an external file which contains the information encrypted that when placed in the same directory as the executable is used to unlock the application as well as possibly provide additional functionality.
Unfortunately with todays software firewalls, most of the simple solutions to disallow running multiple copies on a network are not practical while still maintaining true portability, or requiring internet access to a server that you fully control.
Yes, piracy is a problem, but if you continue to offer great support and there is an additional "visible" benefit to purchasing, you can help offset this in your favor.
If you need trial protection, you can count uses/days if you have any sort of database where the user will have invested time and data, and won't want to lose it. Just encrypt the counter and place in the database somwhere. The user can then only reset the trial by wiping out the database. Depending on the type of app, this may be effective, or not.
Another approach is to not have a portable trial at all, but offer it as an incentive for purchase. i.e. conduct the trial on the desktop, and when they purchase a license, they get a license key that allows it to run on portable devices.
I recommend the PortableApps.Com framework for launching your app. It's free. You need to make your "launcher" open-source, but not your app itself. You can still run on a bare drive, if you follow their pattern.