U-he Copy Protection/Licensing System Discussion

[surreal]

It is going to be a keyfile. The keyfile stores the license holder's (chosen) name and email address, plus all serial numbers, the date of issue and a few watermarks to verify the legitimacy of the keyfile itself.

The format of the keyfile will be PNG, and when opened in a picture viewer, it'll look like a credit card, displaying the above name/email/date and a list of all the licensed products.

It's elegant. It's simple. It will look pretty.

(we're inspired by Plogue on this, who have been using "license cards" for years)

Now why does Native Instruments not think of such a system? Excellent move!

[elxsound]

...But what for the effort? It will be cracked anyway. Why not slightly modify the current scheme? Would that have the same effect for you?

It *is* a slight modification of the current scheme. The serial number does not need to be typed down anymore, it's in a file. Part of it is that the serial is going to be longer, as it is essentially going to be created not just based on the user name but also the email address. Therefore, it would be very difficult to type down, and the license card is just more comfortable to use. It's hopefully reduce need for support and make life easier.

A third modification is that on top of the serial number there will be dozens of checksums embedded, each with their own salt, but only one of these checks is performed by any generation of products. Such that, if crackers find out which salt is used in the check embedded into, say, Hive 2.1, they won't know which check and salt we're using in Hive 2.2, such that even if they crack the license card for one product, the next update will invalidate it. And as the license card contains all licenses for all products, people will have to download a complete set of cracks, should they want to update a single plug-in.

I other words: A lot less work for us. A lot less work for our legit users. A lot more work for crackers, packers and downloaders.

I think this is all I've ever wanted (with regard to protection methods).

[Synthack]

........

[DarkStar]

It is going to be a keyfile. The keyfile stores the license holder's (chosen) name and email address, plus all serial numbers, the date of issue and a few watermarks to verify the legitimacy of the keyfile itself.

The format of the keyfile will be PNG, and when opened in a picture viewer, it'll look like a credit card, displaying the above name/email/date and a list of all the licensed products.

It's elegant. It's simple. It will look pretty.

(we're inspired by Plogue on this, who have been using "license cards" for years)

+1 for this approach.

One question - what happens if I drop the email address (e.g. by changing my broadband supplier) and want to use another? Can I request / generate a replacement .PNG?

[Urs]

One question - what happens if I drop the email address (e.g. by changing my broadband supplier) and want to use another? Can I request / generate a replacement .PNG?

Yes of course. The usual way is to contact support, have the address changed, then download a new license card and you're good to go!

(if possible, do it before you lose the address so we can verify your identity that way... otherwise we'll ask for purchase invoices or other things only you would know, I don't know what the actual procedure is)

[DarkStar]

[uselessmind]

One thing the paranoid prepper in me can do with serial numbers saved as text is not only make copies but also make high res images diplaying the serial.
So if the company in question is out of business, and the backed up serial files and images are slighty corrupted i might still be able to get the serial from the images even if a pixel here and there is now a bit different.
I cant do that with those plogue license cards.
All in one serial for all products i have come to like a bit though.

[midi_transmission]

It is going to be a keyfile.

Thank you! was kind of afraid when I first saw this post.
Gave up on anything that requires online authorization years ago.
Which was one reason I tried Uhe plugins, Yeah now I'm hooked.

Same here. Got a short moment of shock and was afraid to read of any server involved online requirment, but was very glad when I read this. I have a lot of the ploque software as well and the png is as easy to use as any key file or serial number.

[Urs]

no online anything.

[midi_transmission]

One thing the paranoid prepper in me can do with serial numbers saved as text is not only make copies but also make high res images diplaying the serial.
So if the company in question is out of business, and the backed up serial files and images are slighty corrupted i might still be able to get the serial from the images even if a pixel here and there is now a bit different.
I cant do that with those plogue license cards.
All in one serial for all products i have come to like a bit though.

You need to have a solid backup strategy for digital in general. I don't think your fear is needed when you have a good strategy with multiple backups. And your workaround doesn't help in case of a hardware failure, only against some cases of silent corruption.

I have for example at least 4 external drives. Two external drives for regular backups in alternation. And two for long-term that I update about every 6 month in alternation. With a good backup software it's not much effort. For the most essential data it's recommend to have an additional encrypted usb drive at a different secure location. Or to have a strong encrypted (use trusted open source for that) cloud backup.

[DavidEkl]

Couple of questions

there will be dozens of checksums embedded, each with their own salt

Did you look at keypair signing instead of salting? If so, interested to know why you decided against it

Such that, if crackers find out which salt is used in the check embedded into, say, Hive 2.1, they won't know which check and salt we're using in Hive 2.2, such that even if they crack the license card for one product, the next update will invalidate it.

Does this mean we’ll need to get a new card when we get the update from Hive 2.1 to 2.2?

[Urs]

Couple of questions

there will be dozens of checksums embedded, each with their own salt

Did you look at keypair signing instead of salting? If so, interested to know why you decided against it

Such that, if crackers find out which salt is used in the check embedded into, say, Hive 2.1, they won't know which check and salt we're using in Hive 2.2, such that even if they crack the license card for one product, the next update will invalidate it.

Does this mean we’ll need to get a new card when we get the update from Hive 2.1 to 2.2?

1. I don’t know what key pair signing is, not in that is context. I have to look it up. The point of salting in this context is that we can hand out many, many checksums/hashes without running in a chance to reverse them.

2. No new key required. It’s the point of it. A way to expire cracked keys without much effort.

[DavidEkl]

1. I don’t know what key pair signing is, not in that is context. I have to look it up. The point of salting in this context is that we can hand out many, many checksums/hashes without running in a chance to reverse them.

I’m referring to public/private key signing (RSA etc). Sign the license data with the private key, verify with public key. That way the only key you’d have to include in the assembly of the VST would be the current public key (per VST, for all products, or both types), then verify the license card hash with that public key

Edit: not trying to sell anyone on this, just wondered if it had been considered, and now explaining what i meant

[Urs]

Ah, yes, ok.

The problem is that if the key to decrypt is included in the binary, crackers see this as an invitation to swap it for their own key. In that case it doesn't matter whether it's a private key or a public key - the information is accessible and easy to forge.

I think RSA etc. are commonly used in copy protection [edit: serial/keyfile based, not online activation, that is] with a complete misunderstanding of how these things are designed to be used. Typically public keys encrypt and private keys decrypt. So anyone can securely create a message that no-one can read unless they have the private key. That's how email encryption works and certainly also the lock icon of the browser. While there are methods using public keys to decrypt, they are certainly always used in a way where the origin of the message can be verified, and thus swapping the key pair does not make sense.

In software protection, to my understanding, none of this keeps crackers from cracking anything. It may pose a nuisance, but that's about it.

Hence, we have explored ways to use cryptographic hashes in our copy protection. These are designed to be one way only. Much like a checksum can be valid for multiple sets of data, a cryptographic hash has no unique tie between cypher and payload, hence the hash offers no clue as to the looks of the original data. We use this mechanism in a very out-of-the-box way of thinking, as we include only a fraction of those hashes in our software. As we swap those fractions over the years, the crackers never see the full hash and thus stand no chance to create a traditional keygen.

Unfortunately, after more than ten years they figured out an angle to partially circumvent our technique by un-blocking serials that were blocked when they were leaked with a brute force attempt. So our answer to that is to make these hashes multidimensional, preventing collisions in brute force attempts and to add an extra layer by providing (secretly salted) hashes of the hashes themselves.

[DavidEkl]

Cool, thanks for the response and explanation! I was under the impression that you had to have some kind of hash/salt represented in the code/assembly, and that was the reason i figured perhaps public/private key would be safer. It seems you’ve already considered that angle a long time ago!

Sounds very interesting, and would love to learn more, but obviously you can’t leak implementation details haha

Thanks Urs