Encrypt content such that it can decrypted only by a specific application

Question

Is there a key management approach for the following scenario:

• Customer Alice uses an application S1 to generate a file. The contents are expected to be encrypted such that it can only be decrypted by someone who owns another application S2.

• Alice distributes the file publicly.

• Customer Bob owns application S2 and is able to decrypt the file.

In this case, Alice does not know Bob, and is not exchanging any keys with him directly. The key exchange is offline and between the applications S1 and S2!

How will application S2 store its decryption key? Obfuscating it in the binary is a bad idea. Let's say that using a key server is a non-starter in my scenario. Are there any other solutions?

Does any well-known product run into this scenario? How did they solve it?

Answer 1

True encryption means that a secret will be required to get original data back. Common secrets storage are:

• the recipient's brain (something you know)
• a smartcard of other HSM (something you have)

As soon as you go away from this secure encryption use case, you fall into obfuscation with 2 common ways:

• a custom algorythm - hard to securely setup and test, and hard to protect against reverse engeneering, please keep away from that
• a key hidden inside an application executable - hard to change if it were compromised, and hard to protect against reverse engeneering, not really better

If all you need is that Alice and Bob are not required to exchange any keys, you could use a central hub:

• application S2 is distributed in such a way that every customers receives a personnal asymetric pair of keys and the central app only stores the public part, ideally the pair should be generated client side, for example during an app initialization
• when Alice sends a message through S1, the message in encrypted with a random symetric key, and that key is securely transmitted to the central hub. A UUID of the message is transmitted to the recipient and to the central hub
• when Bob receives the message and the UUID, S2 application opens a secure channel (TLS) to the central Hub. Bob is authenticated with his private key as a legitimate S2 owner, so the hub accepts the request for the symetric key for the message identified by its UUID
• S2 can decrypt the message and Bob can read it

Limits:

• what is controlled is only the ownership of a valid key, if Bob turns evil and decides to sell copies of his keys, you cannot prevent it. Same if he does not turn evil but gets hacked
• if Bob finds that you S2 app is not what he wants and uses a third party app that mimics the interface you have no technical way to prevent it - but legal ways may exist...
• even if the central hub does not receive the messages, you have full control over S1 and S2, so you could easily get all exchanged messages - you must know it when you present your solution to customers