Application Locking using Asymmetric Encryption

ab · 2017-03-18 16:57:55

A common feature request for professional software is to prevent abuse of published applications. For licensing or security reasons, you may be requested to "lock" the execution of programs, maybe tools or services.

mORMot can use Asymmetric Cryptography to safely ensure that only allowed users could run some executables, optionally with dedicated settings, on a given computer.

The dddInfraApps.pas unit publishes the following ECCAuthorize function and type:

type
TECCAuthorize = (eaSuccess, eaInvalidSecret, eaMissingUnlockFile,
eaInvalidUnlockFile, eaInvalidJson);

function ECCAuthorize(aContent: TObject; aSecretDays: integer; const aSecretPass,
aDPAPI, aDecryptSalt, aAppLockPublic64: RawUTF8; const aSearchFolder: TFileName = '';
aSecretInfo: PECCCertificateSigned = nil; aLocalFile: PFileName = nil): TECCAuthorize;

This function will use several asymmetric key sets:
- A main key set, named e.g. applock.public and applock.private, shared for all users of the system;
- Several user-specific key sets, named e.g. userhost.public and userhost.secret, one for each user and associated computer host name.

When the ECCAuthorize function is executed, it will search for a local userhost.unlock file, named after the current logged user and the computer host name. Of course, the first time the application is launched for this user, there will be no such file. It will create two local userhost.public and userhost.secret files and return eaMissingUnlockFile.

This is the forum thread for this blog article.

werewolf · 2017-03-18 20:45:18

From cracker point of view, no matter how cryptic or heuristic protection algorithm is, the weakest thing here is ECCAuthorize function:
it may be simply* patched to return 0 (TECCAuthorize.eaSuccess)
* depends on other protection measures
If it is used as only protection it will fail the job on first cracker.
I share opinion that soft must be pleasant enought for user to pay for it
Of course if user have some spare money for this =)
From author point of view there must be harmony of protection level vs your soft "real" cost.

ab · 2017-03-18 21:11:25

The ECCAuthorize is just one part of the protection.
Above it, you build your own system.

The idea is that you supplied some needed information as aContent: TObject output, encrypted as JSON within the .unlock file.
If you let ECCAuthorize return 0, the system won't work.

The feature was setup on our side not for licensing reasons, but to reduce the spread of some internal tools, which give access to sensitive information on our servers.

werewolf · 2017-03-18 21:40:35

ab wrote:

The idea is that you supplied some needed information as aContent: TObject output, encrypted as JSON within the .unlock file.
If you let ECCAuthorize return 0, the system won't work. :)

Well, that changes everything: return 0 and {"godmode":"on"} in aContent =)
What is the difference with "strong" https request of the same content?

ab · 2017-03-19 08:37:01

It works offline, and certificate don't need to be installed on the client (if by string https you mean mutual authentication) -- which is a not obvious task under windows.

The main idea is also that the unlock file is tied to a given user and computer, with no reuse on another place.
With no compromise during the file exchange.

edwinsn · 2019-07-12 08:15:15

werewolf wrote:

ab wrote:
The idea is that you supplied some needed information as aContent: TObject output, encrypted as JSON within the .unlock file.
If you let ECCAuthorize return 0, the system won't work.
Well, that changes everything: return 0 and {"godmode":"on"} in aContent
What is the difference with "strong" https request of the same content?

I think you misunderstand the purpose of the approach @ab is introducing here, It's the Code Signing's task to protect the EXE file from being tampered.

edwinsn · 2019-07-12 08:21:13

@ab,

I'm just starting looking at `ECCAuthorize`, my question is, will it decrease the security level if I pass empty string '' for all the `aSecretPass`, `aDPAPI`, `aDecryptSalt` three parameter?

I want to simplify things, since this approach is based on asymmetric encryption I think that's enough - I'll keep the 'app locking private key' secretly and that'll be enough. Am I wrong? Thanks.

ab · 2019-07-12 09:24:58

aSecretPass is meant to authenticate the user at runtime.
You may indeed pass a constant here if you don't need this feature.

Other parameters are expected to be constants in the code. No need to store them.
They are meant to customize the encryption for a given application context, to reduce forensic scope.

So passing '' is pointless - just pass some non constant empty strings in your code.

I have enhanced the documentation about this. See https://synopse.info/fossil/info/4890596a9c

edwinsn · 2019-07-12 10:32:01

Thanks @ab, as always, your help comes fast!

Ah I see! Assuming in the scenario of implementing a 'software activation' system, it seems that the `aSecretPass` parameter is perfect suitable for accepting the serial number the customer purchased?

For `aDPAPI` and `aDecryptSalt`, I just had an idea - it seems that ExtractFileName(Application.ExeName) can be a good idea, because that can prevent the bad people from changing the program's file name

PS, you meant "some non-empty constant strings", right

werewolf · 2019-07-12 15:47:17

> ExtractFileName(Application.ExeName) can be a good idea
All your code can be changed. ;-)
Do not invent sec - rely on cryptography.
GUID here is something. It may be changed for Major releases etc.
There is no reason to prevent user from renaming executable. I think that relying on executable name is bad practice.

ab · 2019-07-12 15:56:54

Using the executable name is only one of the security measures involved.

edwinsn · 2019-07-12 16:18:11

werewolf wrote:

> ExtractFileName(Application.ExeName) can be a good idea
All your code can be changed. ;-)
Do not invent sec - rely on cryptography.
GUID here is something. It may be changed for Major releases etc.
There is no reason to prevent user from renaming executable. I think that relying on executable name is bad practice.

Agreed, actually after thinking deeper after my previous reply, I had the same conclusion with you

macfly · 2019-07-12 17:08:44

I've had many problems with this licensing issue, including the application has been hacked in the past.

It used a third party protection system and this is undoubtedly the easiest way to get the yout application hacked , I'm not talking about this resource of mormot, it was another ...

So I developed my own very tight verification system. And over time I had to adjust it to make it more relaxed.
Very hard verifications will cause many problems with users no doubt. More problems than solution.

Today I control the licenses online. Each time a user requests the registration the server checks how many requests it has made in the last x days and if it detects abuse it blocks, and warns me.

Everything is online without direct support team interaction.
Nowadays there is no way to leave the user waiting for the license to be released.

One tip I can give is to include something in the application that is private to the user and it does not make sense for them to share the registry data.
An online add-on is great for this.

The application should have multiple checkpoints, not just one.
And with random checks every x time.

I only release updates for properly authenticated/licensed users.
There is an updater in the application that checks and makes the updates, there is no other way to update without this.

Obviously the executable and installer must be digitally signed.

Lastly, not always having the pirated application is bad.
I remember that at the time it was pirated the demand for the system grew, and then I ended up converting almost all those who pirated as regular users.
But of course this depends a lot on the niche of the system.

edwinsn · 2019-07-13 08:08:26

@macfly, thanks for sharing, it's very insightful.

Re "Today I control the licenses online. Each time a user requests the registration the server checks how many requests it has made in the last x days and if it detects abuse it blocks, and warns me.", have you implemented any kind of "deactivation" operation for the end user?

macfly · 2019-07-13 15:02:22

For my scenario I do not need this deactivation.

The licenses must be renewed every 3/6/12 months (the user chooses), and while the renewal is being made the license is valid.

What I do is check whether the user is registering the same machine or not. Having a tolerance limit there.
So if the server detects abuse it notifies the user and me.

As I said, over time I had to leave the system more relaxed, because it was generating more problems than solution.

There are encrypted keys stored in the database, which are part of the license generation, that are generated by installation, that allow me to know if it is a new installation or a transfer to another machine. So the user can transfer the application from one machine to another without contacting the support. Obviously if there is no abuse in this.

edwinsn · 2019-07-13 15:29:20

I see, Your approach is a quite customized one. But I fully agree that the system must be tolerant.

edwinsn · 2019-07-25 14:16:49

@ab, one more question - does the 'KDFRounds' parameter for the encryption and decryption has to be the same?
I mean if the rounds are not the same, will it cause decryption fails?

ab · 2019-07-25 14:54:58

KDFRounds are used to harden the password, so yes, number of rounds should be the same.

mORMot Open Source

#1 2017-03-18 16:57:55

Application Locking using Asymmetric Encryption

#2 2017-03-18 20:45:18

Re: Application Locking using Asymmetric Encryption

#3 2017-03-18 21:11:25

Re: Application Locking using Asymmetric Encryption

#4 2017-03-18 21:40:35

Re: Application Locking using Asymmetric Encryption

#5 2017-03-19 08:37:01

Re: Application Locking using Asymmetric Encryption

#6 2019-07-12 08:15:15

Re: Application Locking using Asymmetric Encryption

#7 2019-07-12 08:21:13

Re: Application Locking using Asymmetric Encryption

#8 2019-07-12 09:24:58

Re: Application Locking using Asymmetric Encryption

#9 2019-07-12 10:32:01

Re: Application Locking using Asymmetric Encryption

#10 2019-07-12 15:47:17

Re: Application Locking using Asymmetric Encryption

#11 2019-07-12 15:56:54

Re: Application Locking using Asymmetric Encryption

#12 2019-07-12 16:18:11

Re: Application Locking using Asymmetric Encryption

#13 2019-07-12 17:08:44

Re: Application Locking using Asymmetric Encryption

#14 2019-07-13 08:08:26

Re: Application Locking using Asymmetric Encryption

#15 2019-07-13 15:02:22

Re: Application Locking using Asymmetric Encryption

#16 2019-07-13 15:29:20

Re: Application Locking using Asymmetric Encryption

#17 2019-07-25 14:16:49

Re: Application Locking using Asymmetric Encryption

#18 2019-07-25 14:54:58

Re: Application Locking using Asymmetric Encryption

Board footer