Encryption & Licensing: The Algorithms Were The Easy Part

The DevOps team tasted blood.

We built a product.

Then two customer questions completely changed its architecture.

1
2
3
4

1. How do we stop a customer from copying the product to ten servers?

2. How do we encrypt backups without locking customers out
   of their own data?

At first glance, these looked like encryption problems.

They weren’t.

They were trust problems.

The Constraints Changed Everything

DevOps-Genie runs inside the customer’s environment, not ours.

That single decision changes everything.

There is:

  • No phone-home licensing
  • No cloud control plane
  • No access to customer databases
  • No remote password reset
  • No “let me log in and fix it”

Their infrastructure.

Their firewall.

Their rules.

Then came another challenge.

Customers own their backups.

So if the customer encrypts the backup…

…and loses the key…

Who helps them recover?

11 PM.

Production outage.

Now what?

We Rejected Two Designs Before Choosing The Third

Option 1

Customer-only encryption

1
2
3

Customer Key
      |
Encrypted Backup

Advantages:

  • Excellent privacy

Problem:

  • Lose the key.
  • Lose the data.

Option 2

Vendor-only encryption

1
2
3

Vendor Master Key
        |
Encrypted Backup

Advantages:

  • Simple recovery

Problem:

  • The vendor can decrypt every customer’s data.

Not a trust model we wanted.

Option 3

Dual-envelope encryption

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

                 SQL Backup
                      |
                AES-256-GCM
                      |
              Random Session Key
                      |
        +-------------+-------------+
        |                           |
Customer Envelope           Recovery Envelope
(Customer Key)               (Master Key)

The backup is encrypted once.

The session key is encrypted twice.

One envelope belongs to the customer.

One exists solely for controlled recovery.

The customer remains independent.

Support remains possible.

That became our architecture.

Licensing Needed Integrity. Not Secrecy.

A license contains:

  • Customer name
  • Expiry date
  • User limits
  • Feature flags

None of these are secrets.

So encryption was never the requirement.

The requirement was:

Nobody should be able to modify the license without our knowledge.

That immediately ruled out encryption.

Integrity was the requirement.

Confidentiality wasn’t.

Digital signatures solved the problem.

Ed25519 turned out to be exactly what we needed.

The customer can read the license.

The product can verify it.

Nobody can change it without our private signing key.

Looking Back…

The algorithms were almost the easy part.

  • AES-256-GCM
  • Ed25519
  • SHA-256
  • Go’s crypto libraries

Those are proven building blocks.

The difficult questions were architectural.

  • Who owns the keys?
  • Who owns the backups?
  • Who can recover data?
  • What happens if a customer loses access?
  • Where should trust begin?
  • Where should it end?

If I had to build this system again…

I would start with those questions.

Only then would I choose the algorithms.

Because algorithms are implementation details.

Trust is architecture.

This article continues the DevOps-Genie journey.

Article 1

The DevOps Team Tasted Blood

Infrastructure engineers became product builders.

Article 2

We Built The Product. We Forgot The Locks.

The cryptography we had to learn.

Article 3

Encryption & Licensing: The Algorithms Were The Easy Part

How those lessons became a real architecture.

Full technical breakdown with code and implementation details: https://www.uk4.in/posts/encryption-licensing-how-we-built-it/

The DevOps team tasted blood.

We learned cryptography.

In the end, we discovered that the real challenge wasn’t encryption.

It was trust.

#DevOps #Security #Encryption #ProductEngineering #Skillmine