Join Log in
Score:1
avatar Crypto

Best practice to create an old-style installation key

ps flag
vsz

All current best practices about creating and using cryptographic keys I've found, refer to creating an encrypted data out of raw data. However, there is (or at least was a few decades ago) a practice where a key is not used to decrypt or authenticate anything, it is used solely locally as a (very week) proof of ownership.

In the pre-internet days, when you bought a software, you got it on a physical media (floppy disk or CD) and there was a "key" physically printed on it, which you had to enter during installation. No internet connection was needed, there was no server which authenticated anything or checked whether the key has already been used. The installer only checked whether the key conformed to some rules which could distinguish valid keys from invalid ones.

Anyone could just copy the key from a legitimate owner and install the software without authorization, there was nothing preventing this practice, but such keys were still used because not everyone was doing it, therefore it prevented at least some part of the userbase from pirating it.

If done today, in a completely offline environment, how should such a key be ideally created? It should not be overly long, so that it can by typed in manually during installation, and there should still be millions of possible combinations. Yet it should be very unlikely that a small random change in a valid key results in another valid key.

A naive approach would be that half the bits of the key are a predetermined secret constant, the other half are random, but they are intermixed according to some logic, and a checksum is intermixed as well. Still workable for the intended purpose, and it was likely widely used. However, are there any modern, better approaches for creating such "offline installation keys"?

56
0 + 0
kelalaka avatar
in flag
kelalaka
Hackers will always find a way to bypass your key protection, as long as your application is viable. See in the gaming industry.
0
Reply
ps flag
vsz
@kelalaka : of course they do, I never said they don't, but unless 100% of the userbase relies on hackers, there will be plenty for whom it works. Just because a sufficiently motivated burglar could open any lock, it doesn't mean that we should never ever lock our doors.
0
Reply
Score:2
poncho avatar Crypto
my flag
poncho

However, are there any modern, better approaches for creating such "offline installation keys"?

There are two obvious approaches:

  • One is to use a Message Authentication Code (MAC); this is a cryptographical algorithm that takes a string and a secret key, and generates a 'tag'; the idea is that, without know the secret key, it is hard to generate another string/tag pair that validates.

So, what you would do as a manufacturer is select a random secret key (which you would insert into your products). To generate a 'product key' (label that is attached to the product), you would take a sequence number, run that through the MAC to generate a tag, and make the sequence number and the tag be the product key.

Then, when the product is installed, the user enters the product key; the software separates out the sequence number and the tag; it then runs the sequence number through the MAC (using the secret key that the manufacturer inserted), and compare that computed tag to the tag that was in the product key - if they match, you go ahead with the installation.

The upsides are that this is easy, and that length of the product key can be easily controlled (with a good MAC, say, HMAC, a 20 bit tag will make the probability of random guessing less than one in a million per guess - if that's not low enough, just pick a longer tag).

The downside of this is that if a good hacker pulls apart your product, they can extract the secret key, and then go ahead and generate their own product keys at will. There's been attempts at designing implementations that are resistant to this ("white box cryptography"); those have been found to be disappointing. However, if the effort involved on the attacker's part is more than the effort of just distributing the known good product key, it might be acceptable.

  • The other approach would be to go with a public key signature algorithm (with a short signature).

This idea is similar, except that the manufacturer generates a public/private key pair, and inserts the public key onto the device.

The manufacturer uses the private key to generate 'product keys'; on installation, the software uses its copy of the public key to validate the product key.

The upside is that we no longer have to worry about a hacker getting the ability to create new product keys - to do that, he needs the private key, and that's not on the device.

The downside is the length of the tag - even the algorithms with the shortest signature (which I believe is BLS) still has moderately long signatures (e.g. 256 bits for 100 bits of security); and unlike the MAC case, they can't be truncated.

There were companies that used signatures for their product keys - I expect they were in the minority.

0 + 0
ธงชาติไทย
Elon Musk
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.