I am writing an application which has an authenticity mechanism, using HMAC-sha1, plus a CBC-blowfish pass over the data for good measure. This requires 2 keys and one ivec.
I have looked at Crypto++ but the documentation is very poor (for example the HMAC documentation). So I am going oldschool and use Openssl. Whats the best way to generate and load these keys using library functions and tools ? I don't require a secure-socket therefore a x.509 certificate probably does not make sense, unless, of-course, I am missing something.
So, do I need to write my own config file, or is there any infrastructure in openssl for this ? If so, could you direct me to some documentation or examples for this.
Although it doesn't answer your question directly, if you are looking at this as a method of copy protection for your program, the following related questions may make for interesting reading.
Preventing the Circumvention of Copy Protection
What copy protection technique do you use?
Software protection by encryption
How do you protect your software from illegal distribution?
This is the solution I am going for atm. Unless of course someone comes up with a better one, or one that solves my specific problem.
I will put three files in /etc/acme/auth/file1 file2 and file3, binary files with randomly generates numbers for the 2 keys and the ivec, and do the same in windows but under c:\etc\acme\auth.
Related
I struggle with the licence of the software I wrote in C(the core) and C++(the GUI).
At the beginning I thought I'd use some crypto algorithm, but it was very easy to read the password stored inside the executable.
So to prevent hacks I decided to store all the valid serials inside the executable, my optimistic guess was there would be 1000 serials. No need to encrypt anything. But I read that it is possible to edit the executable, this means that if I write:
if(tb->is_demo)
{
//check limits
}
Somebody can by-pass it and write:
if(false)
{
//check limits
}
So, it becomes hard to protect my software, each solution that comes to mind, earlier or later there is a main if somewhere that can be bypassed.
The question are two:
Is possible edit an executable?
If yes, what can I do to avoid to get edited?
is possible edit a executable?
Without surprises, Yes.
if yes, what can I do to avoid to get edited?
You cannot completely avoid it. Big software development firms are working on the subject, yet their softwares (Professional software, games, ...) are hacked and used for free anyway.
What you can do is make the hack more expensive than your licence cost. You also can accept being "frauded". Or you can protect yourself by other means that technological ones (think law suits).
You may ask how to "make the hack more expensive than your licence cost?". This is off-topic on Stackoverflow. But be sure libraries answering that need exist. Now is the time to make your google skills pay ;)
Anyone can easily edit your executable so I would advise not to store all the valid serials in your program.
You could look into this open source project Open license manager
Another option is to store all your valid serials in a database on some server and create an API that you can make requests to whenever you want to check if a serial is valid or not.
You could use python and flask to create the API and the server
Yes, an executable can be edited. Many software have been cracked through this method. There are however two ways of doing this:
Hash editing
Through third-party software
It is possible to "avoid" them. You can either encrypt these files or you can lock the data from being streamed out.
In OpenSSL documentation for SHA512 there's written following recommendation:
Applications should use the higher level functions EVP_DigestInit(3) etc. instead of calling the hash functions directly.
What is the reason for that? It's safer? There is no explanation why I should use IT.
I want to make SHA512 hash and according to this recommendation, I should use for computing this hash EVP_* functions instead of SHA512_* functions. Or did I understand it wrong?
SHA512_CTX m_context;
SHA512_Init(&m_context)
SHA512_Update(&m_context, data, size)
SHA512_Final(hash, &m_context);
auto m_context = EVP_MD_CTX_create();
EVP_DigestInit_ex(m_context, EVP_get_digestbyname("sha512"), NULL);
EVP_DigestUpdate(m_context, data, size);
EVP_DigestFinal_ex(m_context, hash, NULL);
I asked the same thing and here is their answer
https://github.com/openssl/openssl/issues/12260
For a number of reasons. For example:
In some cases you get sub-optimal implementations with the low-level APIs vs the EVP APIs. An example from the "cipher" world (but the same concept applies to digests) is the low-level function AES_encrypt. If you call that you will never get the AESNI optimized version which may be available on your platform.
We want to encourage applications to use a consistent API for all types of digests/ciphers etc. This makes it much easier for everyone to update code as security advice changes. For example you mention the MD5 digest APIs. MD5 is no longer recommended. It's a lot harder to update your code to use some other digest if you've used the low-level APIs vs the high level ones. Looking into the future imagine some algorithm has some major flaw discovered in it that requires a rapid migration away from it to some other algorithm. We want the OpenSSL ecosystem to be as agile as possible to be able to deal with that.
The old APIs no longer fits architecturally with how OpenSSL 3.0 works. All algorithm implementations are now made available by "providers" in OpenSSL 3.0 - for example we have the "default" provider, the "fips" provider and a "legacy" provider. The low level APIs circumvent all of that which means we have to maintain 2 ways of doing everything (3 actually when you bring ENGINEs into the picture as well). This leads to unnecessary code bloat and complexity....which is definitely something you want to avoid in a crypto library. Ideally we would have removed the old ways completely - but that would have been too big a breaking change.
A few months ago I thought about adding AngelScript to my engine, which I will definitely do.
Now one thing I am worried about is protecting users source code. Indeed if I use AngelScript it's to make my game engine moddable (well actually the games I will make with it moddable), but even if I am an open source enthusiast, final commercial products must be protected, so my scripts source must be protected. Also I know some modders prefer their code to be protected.
The thing is, how do I do that? Encryption idioms? AngelScript bytecode? Knowing that one of the constraint is that all produced code is reusable, even if we cannot see the implementations.
Encryption is my first idea so if that's the thing you advice me to use, is there some better type of encryption to use (private/public key, encryption algortihm...)?
Thanks in advance for your answers !
I'm looking for a fast asymmetric cypher algorithm to be used in C++ program.
Our application accesses read-only data stored in archive (custom format, somewhat similar to tar), and I would like to prevent any modifications of that archive by asymmetrically encrypting archive index (I'm aware that this isn't a perfect solution and data can still be extracted and repacked using certain techniques).
Some individual files within archive are encrypted with symmetric cypher and encryption keys for them are stored within archive index(header). Which is why I want to encrypt archive header asymmetrically.
Cypher requirements:
1) Algorithm implementation should be platform-independent.
2) Algorithm should be either easy to implement myself or it should be available in library (with source code) that allows static linking with proprietary application, which means that GPL/LGPL/viral licenses cannot be used. MIT/BSD-licensed code, or public domain code is acceptable.
3) If cypher is available in library, ideally it should have small memory footprint, and implementation should be compact. I would prefer to use a C/C++ library that implements only one cipher instead of full-blown all-purpose cipher collection.
Originally I wanted to use RSA, but it looks like it is simply too slow to be useful, and there aren't many alternatives.
So, any advice on what can I use?
Okay, I've found what I've been looking for, and I think it is better than OpenSSL (for my purposes, at least).
There are two libraries:
libtomcrypt, which implements several cyphers (including RSA), and libtommath, that implements bignum arithmetics. Both libraries are in public domain, easy to hack/modify and have simpler programming interface than OpenSSL, and (much) better documentation than OpenSSL.
Unlike older public domain rsa code I found before, libtomcrypt can generate new keys very quickly, can import OpenSSL-generated keys, and supports padding. Another good thing about libtomcrypt is that it doesn't have extra dependencies (OpenSSL for windows wants gdi32, for example) and is smaller than OpenSSL.
I've decided to use RSA for encryption, after all, because (to me it looks like) there are no truly asymmetric alternatives. It looks like most of the other ciphers (elgamal, elliptic curves) are more suitable for symmetric encryption where session key is being encrypted asymmetrically. Which isn't suitable for me. Such ciphers are suitable for network communications/session keys, but it wouldn't be good to use that for static unchanging data on disk.
As for "RSA being slow", I've changed archive format a bit, so now only small chunk of data is being asymmetrically encrypted. Failure to decrypt this chunk will make reading archive index completely very difficult if not impossible. Also, I must admit that slowness of RSA was partially a wrong impression given by older code I've tried to use before.
Which means, question solved. Solution is RSA + libtomcrypt. RSA - because there aren't many alternatives to RSA, and libtomcrypt - because it is small and in public domain.
OpenSSL should do the job for you. It's open-source (apache license, so meets your license requirements).
It's widely used and well tested.
Use a custom RSA to sign the archive. Store the public key in the application and keep the private key in house. Now anyone could modify the read only archive, but your application would refuse to load the modified archive.
Check out Curve25519, which is elliptic curve crytpography implemented efficiently, and around patent problems.
It meets all of your requirements. See Here.
You can use it to encrypt, or to simply sign.
As a side note:
For integrity checking, a MAC should suffice unless you really need assymetric encryption.
How about MD5?
Yes I am aware that MD5 has been 'broken; - but most practical applications this is irrelevant.
Especially if the modified data would also have to be valid in the particular data format as well as have the correct MD5
EDIT:
MD5 is appropriate if you want to just ensure that data stored can't be changed (or at least you can detect it) but it doesn't hide the data. Note that if you must have the key in your app alongside the data it can always be extracted. There are techniques for hiding the key - a popular one is simply to put it inside a static resource such as an icon that can be linked easily.
I will soon be shipping a paid-for static library, and I am wondering if it is possible to build in any form of copy protection to prevent developers copying the library.
Ideally, I would like to prevent the library being linked into an executable at all, if (and only if!) the library has been illegitimately copied onto the developer's machine. Is this possible?
Alternatively, it might be acceptable if applications linked to an illegitimate copy of the library simply didn't work; however, it is very important that this places no burden on the users of these applications (such as inputting a license key, using a dongle, or even requiring an Internet connection).
The library is written in C++ and targets a number of platforms including Windows and Mac.
Do I have any options?
I agree with other answers that a fool-proof protection is simply impossible. However, as a gentle nudge...
If your library is precompiled, you could discourage excessive illegitimate use by requiring custom license info in the API.
Change a function like:
jeastsy_lib::init()
to:
jeastsy_lib::init( "Licenced to Foobar Industries", "(hex string here)" );
Where the first parameter identifies the customer, and the second parameter is an MD5 or other hash of the first parameter with a salt.
When your library is purchased, you would supply both of those parameters to the customer.
To be clear, this is an an easily-averted protection for someone smart and ambitious enough. Consider this a speed bump on the path to piracy. This may convince potential customers that purchasing your software is the easiest path forward.
A C++ static library is a terribly bad redistributable.
It's a bot tangential, but IMO should be mentioned here. There are many compiler options that need to match the caller:
Ansi/Unicode,
static/dynamic CRT linking,
exception handling enabled/disabled,
representation of member function pointers
LTCG
Debug/Release
That's up to 64 configurations!
Also they are not portable across platforms even if your C++ code is platform independent - they might not even work with a future compiler version on the same platform! LTCG creates huge .lib files. So even if you can omit some of the choices, you have a huge build and distribution size, and a general PITA for the user.
That's the main reason I wouldn't consider buying anything that comes with static libraries only, much less somethign that adds copy protection of any sort.
Implementation ideas
I can't think of any better fundamental mechanism than Shmoopty's suggestion.
You can additionally "watermark" your builds, so that if you detect a library "in the wild", you can determine whom you sold that one to. (However, what are you going to do? Write angry e-mails to an potentially innocent customer?) Also, this requires some effort, using an easily locatable sequence of bytes not affecting execution won't help much.
You need to protect yourself agains LIB "unpacker" tools. However, the linker should still be able to remove unused functions.
General thoughts
Implementing a decent protection mechanism takes great care and some creativity, and I haven't yet seen a single one that does not create additional support cost and requires tough social decisions. Every hour spent on copy protection is an hour not spent improving your product. The market for C++ code isn't exactly huge, I see a lot of work that your customers have to pay for.
When I buy code, I happily pay for documentation, support, source code and other signs of "future proofness". Not so much for licencing.
Ideally, I would like to prevent the library being linked into an executable at all, if (and only if!) the library has been illegitimately copied onto the developer's machine. Is this possible?
How would you determine whether your library has been "illegitimately copied" at link time?
Remembering that none of your code is running when the linker does its work.
So, given that none of your code is running, we can't do anything at compile or link time. That leaves trying to determine whether the library was illegitimately copied onto the linking machine, from a completely unrelated target machine. And I'm still not seeing any way of making the two situations distinguishable, even if you were willing to impose burdens like "requires internet access" on the end-user.
My conclusion is that fuzzy lollipop's suggestion of "make something so useful that people want to buy it" is the best way to "copy-protect" your code library.
copy protection and in this case, execution protection by definition "places a burden on the user". no way to get around that. best form of copy protection is write something so useful people feel compelled to buy it.
You can't do what you want (perfect copy protection that places no burden on anyone except the people illegally copying the work).
There's no way for you to run code at link time with the standard linkers, so there's no way to determine at that point whether you're OK or not.
That leaves run-time, and that would mean requiring the end-users to validate somehow, which you've already determined is a non-starter.
Your only options are: ship it as-is and hope developers don't copy it too much, OR write your own linker and try to get people to use that (just in case it isn't obvious: That's not going to work. No developer in their right mind is going to buy a library that requires a special linker).
If you are planning to publish an expensive framework you might look into using FLEXlm.
I'm not associated with them but have seen it in various expensive frameworks often targeted Silicon Graphics hardware.
A couple ideas... (these have some major draw backs though which should be obvious)
For at compile time: put the library file on a share, and give it file permissions only for the developers you've sold it to.
For at run time: compile the library to work only on certain machines, eg. check the UIDs or MAC ids or something
I will soon be shipping a paid-for static library
The correct answer to your question is: don't bother with copy protection until you prove that you need it.
You say that you are "soon to be shipping a paid-for static library." Unless you have proven that you have people who are willing to steal your technology, implementing copy protection is irrelevant. An uneasy feeling that "there are people out there who will steal it" is not proof it will be stolen.
The hardest part of starting up a business is creating a product people will pay for. You have not yet proven that you have done that; ergo copy protection is irrelevant.
I'm not saying that your product has no value. I am saying that until you try to sell it, you will not know whether it has value or not.
And then, even if you do sell it, you will not know whether people steal it or not.
This is the difference between being a good programmer and being a good business owner.
First, prove that someone wants to steal your product. Then, if someone wants to steal it, add copy protection and keep improving your product.
I have only done this once. This was the method I used. It is far from foolproof, but I felt it was a good compromise. It is similar to the answer of Drew Dorman.
I would suggest providing an initialisation routine that requires the user to provide their email and a key linked to that email. Then have a way that anyone using the product can view the email information.
I used this method on a library that I use when writing plugins for AfterEffects. The initialisation routine builds the message shown in the "About" dialog for the plugin, and I made this message display the given email.
The advantages of this method in my eyes are:
A client is unlikely to pass on their email and key because they don't want their email associated with products they didn't write.
They could circumvent this by signing up with a burner email, but then they don't get their email associated with products they do write, so again this seems unlikely.
If a version with a burner email gets distributed then people might try it, then decide they want to use it, but need a version associated to their email so might buy a copy. Free advertising. You may even wish to do this yourself.
I also wanted to ensure that when I provide plugins to a company, they can't give my library to their internal programmers to write plugins themselves, based on my years of expertise. To do this I also linked the plugin name to the key. So a key will only work for a specific plugin name and developer email.
To expand on Drew's answer - to do this you take the users email when they sign up, you tag a secret set of characters on the end and then hash it. You give the user the hash. The secret set of characters is the same for all users and is known to your library, but the email makes the hash unique. When a user initialises the library with their email and the hash, your library appends the characters, hashes it and checks the result against the hash the user provided. This way you do not need a custom build for every user.
In the end I felt anything more complex than this would be futile as someone who really wanted to crack my library would probably be better at it than I would be at defending it. This method just stops a casual pirater from easily taking my library.