Wrong RSA usage leads to key leakage

Hi guys,

just wanted to post here my experience. We use a keyfile licenser and an RSA key-pair to encrypt/decrypt that file.

We used to encrypt with the public key (from our servers) and decrypt with the private key (from the plugin). Private key is scattered in the binary and obfuscated.

Despite all of our measures, a notorious crack team was able to create a keygen and the license files coming from that keygen are encrypted with our keys.

My bad I didn’t know about, but it’s possible to devise an RSA public key if you have the private one.
The crackers have been able to reconstruct the private key, then generate the missing public key and use that to create license files that will be read by our licenser. They also bypassed almost all of our key integrity checks and other countermeasures, but the big problem lies in the fact that they can create a working pair just having the private key.

A bit of advice: if you are about to use RSA for offline activation, use the private key to encrypt and embed the public to decrypt. You cannot recover a private key from a public one, just the opposite.

2 Likes

That is a common mistake, good to point that out here. And it’s a strong reminder that obfuscation is not an appropriate measure for security.

If you are in for the race I would drop RSA and use e.g. libNaCl/sodium. They use much better cryptographic methods.

On the positive side: sounds like you’ve created an awesome plugin since they took all that effort :wink:

3 Likes

Thanks for the compliments :smiley: Yea, every now and then some teams release some of our products, but that’s the first time in years that a crack works fully.

Obfuscation is just one of the steps I’ve implemented in our licensing system. We have different ways to check the RSA key integrity and they are not triggering since they key is intact.

Since JUCE’s RSA implementation doesn’t seem to include signature/verification, you can just swap the keys and it’ll work fine, since you cannot get a private key from the public one.

I’ll look into sodium, thanks!

1 Like

Simple and avoidable mistake, but don’t beat yourself up. Even if you had been using RSA properly, ultimately they’d just have located and hacked the signature verification and integrity checks out one way or another. These audio crackers are an incredibly talented bunch that will go to extreme lengths to claim the win, since it’s an asymmetric war it’s loaded in their favour. They’ll have seen anything we smart DSP cookies can come up with, not many of us are (or employ) crypto wizards combined with reverse engineers combined with obfuscation experts. Some like the cat and mouse sport and play endless games with the crackers, but it’s kind of futile unless that’s your jam.

Most home-grown systems are not much more than an honesty-box based licensing approach unless you’re using a best in class third party protection tool-kit, such as that provided by Juce’s owners. Or maybe eLicenser, but they just gave up by the looks of it. Wibu isn’t looking as good as it used to either.

Even then, all you’re really doing is increasing the half-life of the inevitable compromise. If you do a particularly great job, maybe they’ll hand you an honourable mention in the NFO of their dishonourable package, but the score only ever ticks up on one side. You just need to get enough time without there being rampant piracy on your work to establish your company and a good reputation for what you’re offering, most people that were actually willing and able to pay are probably not so interested in many of the cracks which are becoming increasingly root-kit like to beat the latest protections, which is sort of everything that the freedom loving people stand against in life anyway. Doing what you can to avoid a key-gen is probably a good idea though, you at least want people to have to hunt down a crack rather than you paying for the bandwidth as well!

1 Like

Exactly. And they only crack, you need to make it safe AND deliver an awesome product in the fist place, so it’s really not a fair game.#

What I read the eLicenser is still around, but no longer available for third parties (and might vanish with future versions, that was not made public).

1 Like

VSL I heard were moving to iLok, which I’m happy to draw my own conclusions from.

1 Like

Good to hear. At least physically the iLoks are much more durable than the eLicenser.

I’ll stay out of the rest of the debate, since it is way too opinionated IMHO.

Sorry for the OT, let’s go back to RSA public and private keys :slight_smile:

1 Like

WIBU has been opened like a can just few days before our products has been released by the same team… and that team surely knows what they are doing. I’m beating myself up a bit, because the mistake was silly and I could gain some days. But now I know what the mistake was and I can implement countermeasures. The goal is not to make the product uncrackable (that’s pretty much pointless imho), but making them give up because it’s not worth the effort.

My 2 cents!

2 Likes

I doubt you would have gained any days with a team like that.

1 Like

Focus on features and updates, that keeps them busy and makes the legit users happy :slight_smile:

1 Like

Never say never :wink: Few years ago they released our entire catalogue, while now they have to manually crack each format for each plugin from scratch, so they just released a small selection.

@daniel: yea, that’s correct. I usually focus on that, but right now that huge mistake must be fixed.

1 Like

Don’t feel too bad about your mistake: I’m aware of products that did everything by the book, embedding only public keys in the distributed executables, and yet they have been cracked with a keygen anyway.

The crackers did so by replacing the public key in the executable with another one from a pair generated by them, whose private key was used in their keygen to generate seemingly valid license files.

They topped that by bypassing every integrity check on the executables itself (some sort of handmade digital signing) and removing the calls towards the license server that periodically checked that the license files on disk were actually matching existing licenses.

2 Likes