Encrypting software?

[GreenAce92]

I'm in the process "eventually" of designing a combined-navigation system for an autonomous drone and I would like to sell the software however I don't want one person to buy it, and then release it for download somewhere...

So I'm wondering if it is possible to encrypt the software, then using a one-time key, decrypt it, the one time part is important, any thoughts?

I read about XOR cyphers.... sha257, md5, bcrypt, other stuff which may not be relevant to this particular case but... any thoughts would be appreciated

 

[visioneer]

I'm in the process "eventually" of designing a combined-navigation system for an autonomous drone and I would like to sell the software however I don't want one person to buy it, and then release it for download somewhere...

So I'm wondering if it is possible to encrypt the software, then using a one-time key, decrypt it, the one time part is important, any thoughts?

I read about XOR cyphers.... sha257, md5, bcrypt, other stuff which may not be relevant to this particular case but... any thoughts would be appreciated

What is exact meaning of the one-time key?
Are you selling source code or binary executable code?

Anyway, if you want to protect from others except the whom will buy, you can use public key cipher like PGP?
If you want to sell a binary for single(one-time) use, send a programmed microcontroller with security fuse.

visioneer

 

[BradtheRad]

Don't know specifically, but perhaps you can create things to check for each time your program starts up? Things that only you know about, and which denote a genuine installation:

* hardware configuration
* how a component answers a data request
* volt levels
* presence of secret auxiliary files
* file exactly the expected length
* program's location in memory
* length of memory occupied
* particular data found in particular memory location
Etc.

For instance, Windows will display an error 'The configuration has changed' if it thinks that copy of Windows is starting up on a different computer than the one it was licensed on.

the one time part is important

Then you probably are aware that your software must be easy to use, or people will look to something else.

Avoid altering things on someone's computer which could result in disabling it.

Find out whether you need to take out insurance, in case you get sued.

 

[Dan Mills]

The fundamental problem shared by almost all purely software based protection schemes is that by definition you have to supply the decryption key at some point before the user can run the thing.... And at that point all bets are off (The user can run in emulation and just dump the decoded binary).

Place some critical (and non trivial) part of the functionality in a secure microprocessor and blow the code protect fuse, then copies of the main application do you no good without the all important chip (Which is at least difficult to copy, and can be a USB key).

Given sufficient determination anything can be copied, but if you pick a processor typically used in security critical applications (With stacked metal grids, and all the other tricks) you can make it expensive and time consuming to reverse.

Regards, Dan.

 

[guttinasrinivas]

I totally agree and would go Dan Mills' approach. There are ways to generate signed certified software, no lock is break-proof. By using a secure processor or locked down binary, the problem is made harder to solve. In contrast, buying the software should sound cheaper (both in terms of time and money).

I would make the code modular, incremental and deliver value for money to further discourage cracking the delivered software.