Encrypt entire Django project and decrypt it in ram when starting server

[Om Khade]

I want to sell my Django product on a subscription basis to the client and set up the server on their server while ensuring that the code is not tampered with. For this I need a way to save the Django project in an encrypted format and Decrypt the files in RAM using a password that the client can get by sending a request to my licensing server.  

Is there a way to do this? our a better mechanism to deploy my Python project on client-server without them tampering the code.

[Ahmed Iftikhar]

Obfuscation can make the code less readable, but it won't provide strong security. There are Python tools like pyobfuscate that can be used for this purpose. However, keep in mind that this is not encryption, and determined attackers can still reverse engineer obfuscated code.
 While you can encrypt your code, it needs to be decrypted at runtime, which means the decryption key needs to be available on the client's server. This introduces a potential vulnerability. An attacker with access to the server might still be able to retrieve the decryption key.
 You can compile Python source code into bytecode (.pyc files). This makes it more difficult to read the code but doesn't provide strong security. Python bytecode can still be decompiled, and tools like uncompyle6 can be used to reverse the process.
 Instead of sending the decryption key directly to the client, consider having the client make requests to a licensing server. The server could respond with a token or key that is used for decryption on the client's server. This way, the decryption key is not directly exposed.
 Implement integrity checks within your Django application. Periodically verify that the code on the client's server matches the expected checksum. If modifications are detected, the application could refuse to run.
Sign your code and verify the signature at runtime. This helps ensure that the code has not been modified. However, the keys used for signing need to be securely stored.
Consider packaging your Django application within a container (e.g., Docker). This can provide some isolation and control over the runtime environment.

[Om Khade]

Thank you Ahmed for such a detailed information, yes we have a licensing server for managing the encryption keys and licence keys. 

I tried to find some resources regarding singing the code but couldn't find any available resources. Do you have any references that could be used.

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/af6291d7-620f-4132-93a1-f4e99f7d2a6en%40googlegroups.com.

[Om Khade]

Is there a way to decrypt the code in memory or run the Django project from the encrypted code without exposing the decrypted code to the client?

[Kasper Laudrup]

On 20/11/2023 07.25, Om Khade wrote:
> Is there a way to decrypt the code in memory or run the Django project
> from the encrypted code without exposing the decrypted code to the client?
>

No, of course there isn't.

In order to decrypt the data the client needs the key. You can try to
obscure it in various ways but in the end the client will still need the
key so that's fairly pointless.

Even if you were to be able to hide the key somehow, eg. providing some
TPM like hardware where only you know the key, the data would still be
available unencrypted in memory which sort of defeats the purpose.

Think about how huge companies with almost unlimited resources and
control of the hardware (eg. Sony Playstation) have tried something
similar without success.

Spend your energy on providing software your customers will be happy to
use instead and ignore that someone might be violating whatever terms
you distribute it under or let your lawyers deal with that.

Kind regards,
Kasper Laudrup

[Om Khade]

Hey Kasper,

We have a method to securely distribute the key for decryption in a way that the client won't be able to use it for decryption on his own but to run the Django project we will have to decrypt the code at some location, I want to make it hard for anyone to access it during this transition. In the end, I want to make it hard for anyone to bypass the licensing mechanism by making changes to the code or to understand the validation logic in place to detect code changes.

Thank you
Om Khade

[Kasper Laudrup]

On 20/11/2023 12.02, Om Khade wrote:
> Hey Kasper,
>
> We have a method to securely distribute the key for decryption in a way
> that the client won't be able to use it for decryption on his own but to
> run the Django project we will have to decrypt the code at some
> location, I want to make it hard for anyone to access it during this
> transition. In the end, I want to make it hard for anyone to bypass the
> licensing mechanism by making changes to the code or to understand the
> validation logic in place to detect code changes.
>

Sure, you can make it "hard" with different kinds of obfuscation but in
the end the client will still have access to the key since the client
has full control over the machine including reading whatever is stored
in memory.

You can make the validation logic so complicated that it's harder to
reverse engineer but that will without doubt introduce a lot of bugs and
annoyances for your paying customers while you haven't effectively
stopped anyone from accessing your keys anyway.

Security by obscurity and DRM doesn't work and it's not worth trying to
implement.

That's just my (and many others) opinion of course. If you want to try
to implement something that is logically impossible to do then by all
means go ahead.

Kind regards,
Kasper Laudrup