2

We are an IT startup which provides some clients with a Software Development Kit, which may be used by the client within a specific environment, according to some terms and legal agreement. Especially, the client could call SDK's public services and methods from its own source code.

For example, the agreements may require that the client may use the SDK only in ONE environment (in an application for example).

Thereupon, we would like to monitor the SDK to ensure that the client respects this constraint, and if he use the SDK in an environment he didn't buy the SDK for, we want to be able to block the access to the SDK, so he couldn't use it.

I do know that several companies implement such features for the frameworks and SDK they provide, but I couldn't find anything on the web on how to set up such a mechanism ...
We would like to use some standard solution, even it is a paid one, rather than building something from scratch ...

Thanx very much for anyone who could enlightens us !!!

Clarification/Update Our SDK does not provide web services, it provides only local methods which client may call after installing the SDK.
Actually there is only one http-request-based method in the SDK. It's the entry point of the SDK, a method which is called setUp() which takes essentially two parameters : client's username and password.
So foremost the client has to call this method, which check out his credentials through http request to our server. If the authentication succeed, then the client may use the SDK local methods, otherwise he cannot.

Edit I just discovered the concept of API key, at first I thought it would be a potential solution for this problem, but it appears that it doesn't suit the context of the issue I'm trying to solve, thanx to @Matthew.
Now I'm wondering if a license enforcement would be a suitable solution ?? Actually I am thinking about the way Aspose team handles the licenses they give to their clients. Following to this link, they seems to manage DRM rather tightly ...
And one last thing, what is the difference between a license and a product key ? Knowing the advantages and drawbacks of each of these solutions might help me a lot for choosing the right security system for my API.

programmersn
  • 33
  • 5
  • 2
    Possible duplicate of [Ensure web service only accessed by authorized applications](https://security.stackexchange.com/questions/42586/ensure-web-service-only-accessed-by-authorized-applications) – Xander Apr 06 '17 at 20:42
  • Actually my question is quite different, as we do not provide web services through the SDK. – programmersn Apr 06 '17 at 23:10
  • Is http://www.apiman.io what you're looking for? – HTLee Apr 07 '17 at 01:05
  • Thank you I'm checking it out. Do you know if there is any POC based on this tool ?? – programmersn Apr 10 '17 at 15:39
  • Digital Restrictive Management, has been proved to be unimplementable (there is always a way around), but is such a pain, that I would not be your customer. Why would someone pay to be tied up? – ctrl-alt-delor Apr 11 '17 at 22:07
  • From a naive reading of your current SDK, it actually sounds like it'd be trivial to get around - say, doing something like modifying the binary with a new cert, then just having the router point to a service that always returns true. Or just patching the binary so that it defaults to authorized and then don't bother to call the `setUp` method.... – Clockwork-Muse Apr 13 '17 at 23:30
  • @Clockwork-Muse So it seems to me like there isn't any way to effectively handle this problem ... And what about Licensing Systems ?? Why do so many companies bother with this complex cryptographic mechanism if all it takes to bypass it is, like you said, by "_having the router point to a service that always returns true_" or even by "_just patching the binary so that it defaults to authorized and then don't bother to call the setUp method_". So there isn't any viable solution for DRM out there ?? – programmersn May 19 '17 at 13:56
  • @programmersn - In the long run? I'm aware of **NO** DRM scheme that remains undefeated (where the user controls the machine, at least, and in many cases even in some limited-control situations, like game consoles). For games, most of the focus has been on increasing the time before the first crack appears (since most sales happen within the first few months). You have to put in a _lot_ of work to hide all the relevant activity in your code. DRM, at it's best, works like a real-world lock: it keeps the honest man honest, and only serves to slow the dishonest man down. – Clockwork-Muse May 19 '17 at 16:10
  • The primary reason most companies try to use DRM is because they're convinced they'll lose sales to pirates (and to be sure, there are people who would do so). This despite the fact that, especially with games, there have been a number of high profile cases where the pirated version worked better than the legitimate one, since it didn't have to deal with the DRM checks. These companies act like they're a bank shipping a safe to a thief's house, when they'd have a lot more luck (and probably save more money) if they just checked receipts at the store. – Clockwork-Muse May 19 '17 at 16:26

2 Answers2

7

It's essentially a legal problem - you want to control what is running on a client's device, which means you'll need the co-operation of the client.

For a company providing a web based API (e.g. your SDK does some kind of interfacing with your web based service, possibly by implementing some encryption, or special transport method), this is down to monitoring the service, looking for unusual patterns. You could bill on a per request basis (don't care where the requests come from, but if they suddenly start using more, you get more money). You could look for changes in key elements being sent (if you're suddenly getting data reflecting both Windows and Linux hosts, you can be fairly sure the client is using two copies on different systems, and block one).

In your case, though, based on the question as it stands now, you have no interaction with the individual requests (you interact once, when they initialize the framework, but then allow use through some method). It's like your SDK is an image file which the client has been asked to only use in one place. If the client copies it, you don't know. If they run it on a different machine, you don't know. If they run multiple applications on a single machine all using it, you don't know.

So, what are your options?

  1. Hardware dongle. Done properly, they restrict the use of software to a specific machine. This generally requires moving parts of your software into the dongle, else it becomes trivial to strip out any checking code from your software. This also doesn't prevent multiple applications on the same system from using the software - if it can legitimately be used from one, it's possible to copy the data being sent to the dongle from another.
  2. Change your model to be web/network based. Now you can see what's going on, but you may limit the uses of your software. Depending on what it does, it might not be suited for the latency this would introduce, or there may be limitations on where your client's data can be sent (e.g. EU data to US servers can be problematic, at times).
  3. Change your pricing model. Allow clients to use the software as much as they want, but charge more up-front. Make the software free, and charge on a support basis. Charge less, to encourage people to buy multiple copies if they use it in multiple places. These are all models that various companies use, to varying degrees of success.
  4. Be really selective with clients. If you don't trust your clients to abide by your licensing terms, the only really sure way to prevent abuse is to only let people you do trust have access. Require third party "running software" audits on client networks, looking for abusive use of your code. I've never seen a company succeed on a large scale with this model, but it can apply to some specialist areas, such as sensitive control systems.

Some big companies have used some of these: Microsoft, for example, uses ongoing web based authentication - after an initial check, Windows/Office apps ping home every so often to see whether they have been deauthorised. Red Hat charge for the software (but you can get most of it for free), but they charge more for the support, and they check licensing details with support requests. There are some specialist software packages (especially in academic fields) where you only get access to them after attending training on how to use it, which is essentially a form of being selective with clients - the theory is that it cuts down on "trivial" questions from new users. NXP (a large semi-conductor company) offer dongles for some of their development tools, on the basis that not all users have network connectivity.

Depending on how your initialization code works, it's even possible that a really unscrupulous client could simply look at the return value from your servers, and provide that themselves - this would be the case if the method returned a true/false response when provided with a username/password combination, but also if it returned some fixed or predictable value (hash of the current time, or a pre-determined string).

Matthew
  • 27,233
  • 7
  • 87
  • 101
  • Thanx for these informations. It has given me a much better understanding of the theory behind the topic. Could you give more details based on my edits ?? – programmersn Apr 10 '17 at 16:03
  • Already did :-) An API key won't help much here - unless you also look at the actual calls, how could you tell whether it was application A or application B calling the initialization function? Or even, if the client was really sneaky, a single app acting as a data source for multiple actual apps? – Matthew Apr 10 '17 at 16:12
  • Yes indeed ... Honestly I never thought the subject would be so complex ... I will check out what the init method actually returns, and will keep you updated !! Thanx a lot – programmersn Apr 10 '17 at 16:21
0

@Matthew 's answer above is very good, but omits a suggestion that has worked for centuries: contracts.

Write your sales contract to restrict usage in whatever way serves your business interests best, and in the contract state that you reserve the right to use web messages to monitor compliance with the contract, and provide for additional charges or contract termination for usage outside of the license terms. Consider including language reserving the right to remotely disable your SDK in case of non-compliance. Your lawyer should be able to draft an acceptable set of terms.

While you probably won't be obligated to specify all the data you'll possibly collect in the contract, you'll want to include encrypted identifying data such as the user ID, MAC, IP address, computer name, CPU serial number, installation ID#, contract/license #, application name, version, project/file name, date/time, # of lines processed, etc. These are all things that can be shown in court to help verify your claim that your software is being used beyond the terms your clients agreed to.

It's then up to you to monitor for changes in usage patterns that may indicate a contract violation. Instead of calling the corporate lawyer, though, I recommend first engaging your sales people to contact your clients and offer them license terms with increased capacity. It's generally more profitable to extend your clients a carefully worded sales pitch than to threaten them with lawsuits.

John Deters
  • 33,650
  • 3
  • 57
  • 110