Board index » delphi » Re: Encrypting lib.

Re: Encrypting lib.


2008-03-04 03:49:15 PM
delphi103
"Henrick Hellstr?m" <XXXX@XXXXX.COM>writes
Quote
Roger Lascelles writes:
>The poster was going to encrypt all his licence keys and store them in
>the executable or data file, with the decryption code included. That
>means a cracker could recover all the stored licence keys anyway, because
>the code would decrypt the keys one by one and compare each with the
>entered key!
>
>At least the hash method does not give away any actual keys.

Sure, if the cracker gets the actual license keys, they can be used by
anyone with the authentic software. The alternative is false keys that
have to be used with a patch that is applied to the software.
Unfortunately that advantage is of limited value. The OP said that the
actual keys would expire eventually, and when that happens the cracker
would have to patch the software anyway.

The keys shipped with the application (in a sqlite DB) are intended for
searching the corresponding date only.
Quote

>The users of this program are existing customers whose keys can be
>checked in the usual way, then the known good keys are "looked up" in the
>list to see if they get the date extension. Its just customer
>management, not high security.

The OP might want to correct me on this, but I think your assumption is
incorrect. I believe the OP wanted a mechanism that would allow existing
customers to use the general distribution of the software with their
existing keys. IOW the users of the program that contains the mechanism
would not only be existing customers, but everyone.

This is correct.
Quote
Now, of course, it might be the case that the OP is not concerned about
cracks, but only want a simple method that can be used for keeping honest
users honest. In such case, however, I'd argue that the absolutely
best approach would be to implement the check server side when the user
goes to check for updates. Should the OP consider that approach
inadequate, I think it is safe to assume that the OP wants software
protection that is not trivial to crack.

I don't want to spend too much time on anti-cracker at this moment.
 
 

Re: Encrypting lib.

"Henrick Hellstr?m" <XXXX@XXXXX.COM>writes
Quote
Roger Lascelles writes:
>Henrick, please slowly read the poster's original message. Perhaps, as
>an expert, you have read your own interests into the simple question of
>the original poster?

If I did, I'd have suggested he used our products, which are exactly
what he is asking for. <g>

However, after slowly reading his message I doubt what he is asking for is
what he needs. Of course I could be wrong and there is some missing piece
of the puzzle the OP has left out that would make me come to a different
conclusion. But 9 times out of 10 incremental changes to existing security
measures introduce vulnerabilities way more serious than the problem the
changes were set to solve. I have seen security professionals make the same
error and go out of business as a result.

Thank you all.
Henrick,
As you said earlier, keeping the honest customers honest is enough. Also,
since the DB will contain only the keys and the date, no registration name,
so even I store the keys in unencrypted way will be OK:) However the safer
the better as long as I can gain the security with a minimum effort :)
Thank you Henirck and Roger again, you are both very nice!
Edwin.
 

Re: Encrypting lib.

Edwin writes:
Quote
As you said earlier, keeping the honest customers honest is enough. Also,
since the DB will contain only the keys and the date, no registration name,
so even I store the keys in unencrypted way will be OK:) However the safer
the better as long as I can gain the security with a minimum effort :)
Unfortunately there are no easy answers. Steps that at first sight might
appear to increase security might actually not affect security at all,
or even reduce it.
One thing many people fail to consider, is that the main vulnerability
usually isn't that you reveal too much information, but that you fail to
ensure the integrity and authenticity of the information. While it is
impossible to calculate the pre-image x of a known cryptographically
secure hash function h(x), it is certainly no harder to replace a h(x)
value in a database than it is to replace an x value in a database.
One aspect I'd analyze carefully if I were you, is how hard it would
be for a new user to elevate his license privileges by changing his new
key into what appears to be an old key, and append a record
corresponding to that key to the database.
There are not unlikely a dozen other such aspects that you should look
into, just to make sure that your changes don't make your verification
functions significantly weaker. In conclusion, it might actually be less
work to distribute separate executables for old users and new users, or
to distribute new keys to all old users.
 

Re: Encrypting lib.

"Henrick Hellstr?m" <XXXX@XXXXX.COM>writes
Quote
Edwin writes:
>As you said earlier, keeping the honest customers honest is enough. Also,
>since the DB will contain only the keys and the date, no registration
>name, so even I store the keys in unencrypted way will be OK:) However
>the safer the better as long as I can gain the security with a minimum
>effort :)

Unfortunately there are no easy answers. Steps that at first sight might
appear to increase security might actually not affect security at all, or
even reduce it.

One thing many people fail to consider, is that the main vulnerability
usually isn't that you reveal too much information, but that you fail to
ensure the integrity and authenticity of the information. While it is
impossible to calculate the pre-image x of a known cryptographically
secure hash function h(x), it is certainly no harder to replace a h(x)
value in a database than it is to replace an x value in a database.

One aspect I'd analyze carefully if I were you, is how hard it would
be for a new user to elevate his license privileges by changing his new
key into what appears to be an old key, and append a record corresponding
to that key to the database.

There are not unlikely a dozen other such aspects that you should look
into, just to make sure that your changes don't make your verification
functions significantly weaker. In conclusion, it might actually be less
work to distribute separate executables for old users and new users, or to
distribute new keys to all old users.

Henrick,
Thanks. In fact I am not really very concern about the security. I have a
CRC check on the DB to avoid any unauthorized modifications. delivering the
new keys to the old users can be less work, but none can be 100% sure all
keys will be arrived, and this will disturb the users.
Your knowledge in this field is great :)
 

Re: Encrypting lib.

Edwin writes:
Quote
Thanks. In fact I am not really very concern about the security.
Oh, but I think you are, it is just that you have analyzed the situation
and came to the conclusion that some actions would not increase the
expected utility of the outcome. It all comes down to some bayesian
decision making:
S1 S2 S3
A1 O11 O12 O13
A2 O21 O22 O23
A3 O31 O32 O33
A4 O41 O42 O43
You choose A1 over A2 if eu(A1)=p(S1)*u(O11)+p(S2)*u(O12)>
p(S1)*u(O21)+p(S2)*u(O22)=eu(A2), etc. For instance,
* A1 could be that you implement serious software protection
* A2 that you implement the same license registration system as in A1
but spend less resource on anti-crack measures,
* A3 means that you implement no software protection at all, but
distribute a separate trial and require some less intrusive registration
for access to the full version,
* A4 means that the trial is the full version, i.e. you release it as
shareware.
Furthermore, S1 could mean that no one attempts to crack your program,
S2 means that someone does, but not the best brains, and S3 means that
the best best crackers in the community have a go at your program.
Presumably, when you say you don't care about security, you mean that
eu(A1) <= eu(A2), which would be the case if p(S1)*(u(O21)-u(O11))>
p(S2)*(u(O12)-u(O22)+p(S3)*(u(O13)-u(O23)), i.e. the initial cost
associated with implementing anti-crack measures would be greater than
the expected utility of such measures given the states where they
matter. However, I think it is important to note that the actions A1 and
A2 have the same impact on the user experience of honest users (contrary
to A3 and A4). The only reason to choose A2 over A1 would be that you
really think that the expected utility of A1 over A2 in state S2 and S3
would not out-weigh the expected utility of A2 over A1 in state S1.
Let's put it this way: How many of your users would you expect to use a
pirate version of your software if they found one, but purchase a
license if they didn't find a pirate version? How many of those users
would you expect to use a pirate version only as a form of extended
trial as an alternative to purchasing a license and possibly ask for a
refund later? How many would you expect to continue to use a pirate
version, even though they would be hypothetically prepared to purchase a
license? How many users would you expect to purchase a license only if
they first found a pirate version they could check out?
 

Re: Encrypting lib.

Henrick,
Thanks for your information. Yes, you are right, I care about the security,
but I would rather postpone the enhancement if it will take too much time. Now I
have to focus on the features :)
"Henrick Hellstr?m" <XXXX@XXXXX.COM>writes
Quote
Edwin writes:
>Thanks. In fact I am not really very concern about the security.

Oh, but I think you are, it is just that you have analyzed the situation
and came to the conclusion that some actions would not increase the
expected utility of the outcome. It all comes down to some bayesian
decision making:

S1 S2 S3
A1 O11 O12 O13
A2 O21 O22 O23
A3 O31 O32 O33
A4 O41 O42 O43

You choose A1 over A2 if eu(A1)=p(S1)*u(O11)+p(S2)*u(O12)>
p(S1)*u(O21)+p(S2)*u(O22)=eu(A2), etc. For instance,
* A1 could be that you implement serious software protection
* A2 that you implement the same license registration system as in A1 but
spend less resource on anti-crack measures,
* A3 means that you implement no software protection at all, but
distribute a separate trial and require some less intrusive registration
for access to the full version,
* A4 means that the trial is the full version, i.e. you release it as
shareware.
Furthermore, S1 could mean that no one attempts to crack your program, S2
means that someone does, but not the best brains, and S3 means that the
best best crackers in the community have a go at your program.

Presumably, when you say you don't care about security, you mean that
eu(A1) <= eu(A2), which would be the case if p(S1)*(u(O21)-u(O11))>
p(S2)*(u(O12)-u(O22)+p(S3)*(u(O13)-u(O23)), i.e. the initial cost
associated with implementing anti-crack measures would be greater than the
expected utility of such measures given the states where they matter.
However, I think it is important to note that the actions A1 and A2 have
the same impact on the user experience of honest users (contrary to A3 and
A4). The only reason to choose A2 over A1 would be that you really think
that the expected utility of A1 over A2 in state S2 and S3 would not
out-weigh the expected utility of A2 over A1 in state S1.

Let's put it this way: How many of your users would you expect to use a
pirate version of your software if they found one, but purchase a license
if they didn't find a pirate version? How many of those users would you
expect to use a pirate version only as a form of extended trial as an
alternative to purchasing a license and possibly ask for a refund later?
How many would you expect to continue to use a pirate version, even though
they would be hypothetically prepared to purchase a license? How many
users would you expect to purchase a license only if they first found a
pirate version they could check out?

 

Re: Encrypting lib.

Edwin writes:
Quote
Thanks for your information.
You're welcome, but it might be a stretch to call it "information". I'd
rather call it a reflection over how people in general tend to make
decisions about security features. As such, the primary value of the
bayesian formula is that helps people quantify their beliefs and
preferences and come to more rational decisions than they would by
making such decisions intuitively. (Intuition and risk assessment don't
mix: That is why card counters have an advantage at a {*word*2}.)