 |
|
| Science Forum Index » Cryptography Forum » One-way license number... |
|
Page 2 of 3 Goto page Previous 1, 2, 3 Next |
|
| Author |
Message |
| Robert Scott... |
 Posted: Fri Oct 16, 2009 5:34 pm |
|
|
|
Guest
|
On Sat, 17 Oct 2009 00:43:30 +0200, Carsten Krueger <cakruege at (no spam) gmail.com> wrote:
[quote:999c36ee97]Am Fri, 16 Oct 2009 15:02:06 GMT schrieb Robert Scott:
The application
itself it protected from modification by the smartphone OS digital signature, so the
People who pirate the application altough crack the OS so the digital
signature is no protection.
[/quote:999c36ee97]
I'm not worried about a few pirates using my software on their cracked phones.
I am worried about a few pirates making it possible for many others with
non-cracked phones to use my software for free. |
|
|
| Back to top |
|
|
|
| Joseph Ashwood... |
| Posted: Fri Oct 16, 2009 5:36 pm |
|
|
|
Guest
|
"Robert Scott" <none at (no spam) dont-mail-me.com> wrote in message
news:4ad8832e.10538781 at (no spam) news.eternal-september.org...
[quote:0624f657c8]This is sort of a digital signature problem. However I needed a signature
(license number) that was
suitable for manual transcription - i.e. less than 30 characters. I think
this leaves out RSA. The target
is a smartphone application license activation. I have a smartphone
application that is a free
download, but needs activation to convert it from limited features to
full-featured.
I am considering the following approach:
[/quote:0624f657c8]
The approach is weak from beginning to end. In particular it is horribly
weak against differential cryptanalysis, I'm quite certain there's more but
differential was the most obvious to me. In addition, what you are trying to
do is impossible, at least the way you are trying to do it.
Joe |
|
|
| Back to top |
|
|
|
| Robert Scott... |
| Posted: Fri Oct 16, 2009 5:39 pm |
|
|
|
Guest
|
On Fri, 16 Oct 2009 15:17:09 -0700 (PDT), mike clark <mike at (no spam) netadv.net> wrote:
[quote:2b7cc2eff5]So what you are really saying is that you know the scheme is weak, but
you want to know how weak? Instead of judging how weak your system is
based on the skills of the reverse engineer, why not use something
that you can more easily quantify how weak it is. Remember Kerckhoffs'
principle. I'd look into using ECDSA, but at 66 bits there is only so
much you can hope for.
[/quote:2b7cc2eff5]
That's my point exactly. As I said before, I would gladly use RSA or ellipic
curve public key technology, but these license numbers must be entered manually
by the customer. My method may be pretty weak, but so far it is the only one I
see that satisfies this condition. |
|
|
| Back to top |
|
|
|
| Unruh... |
| Posted: Fri Oct 16, 2009 5:46 pm |
|
|
|
Guest
|
none at (no spam) dont-mail-me.com (Robert Scott) writes:
[quote:7a82da55fc]On Fri, 16 Oct 2009 21:52:58 GMT, Unruh <unruh-spam at (no spam) physics.ubc.ca> wrote:
Look. You have a "license checking subroutine" which you sent a query to and it
returns a yes/no answer. The pirate need only replace that with a subroutine which
returns yes for all questions (a trivial binary modification) At that point it
does not matter what your license checking software does.
Maybe you missed my very first posting, but this application is targetted at
smartphones with and OS-supplied digital signature chained to Verisign. The
pirates cannot modify the code without getting Verisign to re-sign it for them.
My experience has been that pirates are much more inclined to try to generate
license numbers than to modify the software itself.
[/quote:7a82da55fc]
If it is easier to generate license numbers then that is what they will do. If it
is easier to subvert the program then they will do that. They are not dogmatic.
They will do whatever works most easily. You seem to think that because you shoot
down one of my suggestions that this will somehow keep the pirates at bay. I am
not a pirate, nor do I have any influence on them. They do not heed any advice I
give them. I am however damn sure that if you try to cook up your own scheme, they
will break it, one way or another, and the easiest way they can.
You state that if you carefully descibe your scheme they will be able to break it.
Since themost careful description is the code itself, and since they have a copy
of the code itself, they have the description.
>Bob Scott, Michigan |
|
|
| Back to top |
|
|
|
| Robert Scott... |
| Posted: Fri Oct 16, 2009 5:49 pm |
|
|
|
Guest
|
On Fri, 16 Oct 2009 16:36:59 -0700, "Joseph Ashwood" <ashwood at (no spam) msn.com> wrote:
[quote:36cfad5bd6]"... In addition, what you are trying to
do is impossible, at least the way you are trying to do it.
[/quote:36cfad5bd6]
What subset of these requirements make it impossible?
1. License number less than 80 bits.
2. License number dependent on the device ID using a secret algorithm.
3. License number can be checked against device ID by algorithm within the app.
4. License checking algorithm does not revel my secret generation algorithm. |
|
|
| Back to top |
|
|
|
| Robert Scott... |
| Posted: Fri Oct 16, 2009 6:01 pm |
|
|
|
Guest
|
On Fri, 16 Oct 2009 16:44:32 -0700 (PDT), Fabrice <fabrice.gautier at (no spam) gmail.com>
wrote:
[quote:a9b3e78577]I hope you are not targeting iPhones 
[/quote:a9b3e78577]
No, Apple does not allow any private authorization schemes in the App Store.
[quote:a9b3e78577]I'm serious about my previous offer though, it would be a very modest
fee and any result would be confidential. I'm not out to extort money
from you (I'm assuming you are an independent developer with not much
money) but I'm not going to work for free on my week-end :)
Or I might take a jab at it just for fun, but then no exclusivity
[/quote:a9b3e78577]
I'll risk the non-exclusivity. Don't spend too much time on it. If it doesn't
occur to you what is going on right away, then just forget it.
[quote:a9b3e78577]
I wonder if your stuff would be covered by DMCA ...
[/quote:a9b3e78577]
I don't think so. It's just a home-grown puzzle. |
|
|
| Back to top |
|
|
|
| Greg Rose... |
| Posted: Fri Oct 16, 2009 7:18 pm |
|
|
|
Guest
|
In article <4ad9032e.1326312 at (no spam) news.eternal-september.org>,
Robert Scott <none at (no spam) dont-mail-me.com> wrote:
[quote:0a31540217]On Fri, 16 Oct 2009 15:17:09 -0700 (PDT), mike clark <mike at (no spam) netadv.net> wrote:
So what you are really saying is that you know the scheme is weak, but
you want to know how weak? Instead of judging how weak your system is
based on the skills of the reverse engineer, why not use something
that you can more easily quantify how weak it is. Remember Kerckhoffs'
principle. I'd look into using ECDSA, but at 66 bits there is only so
much you can hope for.
That's my point exactly. As I said before, I would gladly use RSA or ellipic
curve public key technology, but these license numbers must be entered manually
by the customer. My method may be pretty weak, but so far it is the only one I
see that satisfies this condition.
[/quote:0a31540217]
I'm late to this discussion, but I am struck by
the mismatch between your requirements and your
own proposed solution. You are asking for a
"signature" system, and people are suggesting a
public-key based system such as ECDSA; all good
proposals but you'll never get it down to 56 bits.
In the meantime you are proposing a (weak,
apparently) hash function based solution, when a
MAC is what you really mean. They are different
primitives, and if you care about the application
you should definitely *not* be rolling your own.
To meet the spirit of what you propose, you should
just take HMAC-SHA1(secret_key, unique data) and
truncate it to the size you want.
BUT, and it's a big but, this is not secure in
your context; any single individual can find the
key in your software and post it on the web, or
make available an app for signing arbitrary stuff,
or whatever. True digital signatures work in your
scenario but symmetric MACs don't.
Greg.
--
Greg Rose
232B EC8F 44C6 C853 D68F E107 E6BF CD2F 1081 A37C |
|
|
| Back to top |
|
|
|
| CatId... |
| Posted: Fri Oct 16, 2009 8:33 pm |
|
|
|
Guest
|
Bob Scott,
If you could use ECC, then you could have the server generate a
Schnorr signature of the given ID. With enough bits in the server
response, it would be impossible for anyone other than the server to
generate the signatures.
Since your application is for smartphone, you could have them enter
the credit card information on the phone over a secure tunnel with the
server. In this case a signature would not even be necessary since
the tunnel could only be made with the server.
If it cannot be real-time, you could have them enter the CC info on
the phone, encrypt it with the phone ID, send it to the server via
Email or something not-real-time, and then the server could respond
with a signature file. I've seen this done for a few Windows apps.
Otherwise I guess the user would have to enter the server response
which means that regardless of the scheme you use it can be cracked
(number of bits is too low).
The only advantage you have is that the code cannot be modified
easily, which means you can obfuscate the algorithm effectively. You
should probably spend a lot more time obfuscating since that is your
best bet at raising the bar for crackers.
I think your license key algorithm is probably just as good as any
other algorithm you could come up with. Again it would be nice if the
license server could send back a file that is larger than those 66
bits so you could have real signatures...
Hope that helps,
Catid
http://catid.org
--
--------------------------------- --- -- -
Posted with NewsLeecher v3.95 Beta 3
Web at (no spam) http://www.newsleecher.com/?usenet
------------------- ----- ---- -- - |
|
|
| Back to top |
|
|
|
| Joseph Ashwood... |
| Posted: Fri Oct 16, 2009 10:30 pm |
|
|
|
Guest
|
"Robert Scott" <none at (no spam) dont-mail-me.com> wrote in message
news:4ad905c1.1985140 at (no spam) news.eternal-september.org...
[quote:fb54cfbda2]On Fri, 16 Oct 2009 16:36:59 -0700, "Joseph Ashwood" <ashwood at (no spam) msn.com
wrote:
"... In addition, what you are trying to
do is impossible, at least the way you are trying to do it.
What subset of these requirements make it impossible?
1. License number less than 80 bits.
[/quote:fb54cfbda2]
Might be possible.
[quote:fb54cfbda2]2. License number dependent on the device ID using a secret algorithm.
[/quote:fb54cfbda2]
impossible to keep algorithm secret. Read up on Kerchkoff.
[quote:fb54cfbda2]3. License number can be checked against device ID by algorithm within the
app.
[/quote:fb54cfbda2]
device ID need not be real, can be quite easily faked. This is very common.
[quote:fb54cfbda2]4. License checking algorithm does not revel my secret generation
algorithm.
[/quote:fb54cfbda2]
completely impossible. Read up on Kerchkoff.
Your list of requirements is also massively incomplete, many of the
additional requirements that you have put in place are also impossible.
Like I said, what you are trying to do, is impossible, at least the way you
are trying to do it.
Joe |
|
|
| Back to top |
|
|
|
| Maaartin... |
| Posted: Sat Oct 17, 2009 2:32 am |
|
|
|
Guest
|
On Oct 17, 1:39 am, n... at (no spam) dont-mail-me.com (Robert Scott) wrote:
[quote:8a07f8c3cc]As I said before, I would gladly use RSA or ellipic
curve public key technology, but these license numbers must be entered manually
by the customer.
[/quote:8a07f8c3cc]
Must it? Is it not possible to let the user enter manually a couple of
digits (one time secret key) and let the phone obtain it's private key
from a server?
Is it not possible to send the private key via an sms? |
|
|
| Back to top |
|
|
|
| rossum... |
| Posted: Sat Oct 17, 2009 3:21 am |
|
|
|
Guest
|
On Fri, 16 Oct 2009 21:30:39 -0700, "Joseph Ashwood" <ashwood at (no spam) msn.com>
wrote:
[quote:a589ebe13c]"Robert Scott" <none at (no spam) dont-mail-me.com> wrote in message
news:4ad905c1.1985140 at (no spam) news.eternal-september.org...
On Fri, 16 Oct 2009 16:36:59 -0700, "Joseph Ashwood" <ashwood at (no spam) msn.com
wrote:
"... In addition, what you are trying to
do is impossible, at least the way you are trying to do it.
What subset of these requirements make it impossible?
1. License number less than 80 bits.
Might be possible.
2. License number dependent on the device ID using a secret algorithm.
impossible to keep algorithm secret. Read up on Kerchkoff.
Make that "Kerckhoff".[/quote:a589ebe13c]
You are of course correct Joseph. Trying to keep the algorithm secret
is a typical amateur mistake. You have to assume that an attacker
will know the algorithm.
rossum
[quote:a589ebe13c]
3. License number can be checked against device ID by algorithm within the
app.
device ID need not be real, can be quite easily faked. This is very common.
4. License checking algorithm does not revel my secret generation
algorithm.
completely impossible. Read up on Kerchkoff.
Your list of requirements is also massively incomplete, many of the
additional requirements that you have put in place are also impossible.
Like I said, what you are trying to do, is impossible, at least the way you
are trying to do it.
Joe[/quote:a589ebe13c] |
|
|
| Back to top |
|
|
|
| Robert Scott... |
| Posted: Sat Oct 17, 2009 7:02 am |
|
|
|
Guest
|
On Sat, 17 Oct 2009 05:32:09 -0700 (PDT), Maaartin <grajcar1 at (no spam) seznam.cz> wrote:
[quote:5845a2c140]On Oct 17, 1:39=A0am, n... at (no spam) dont-mail-me.com (Robert Scott) wrote:
As I said before, I would gladly use RSA or ellipic
curve public key technology, but these license numbers must be entered ma=
nually
by the customer.
Must it? Is it not possible to let the user enter manually a couple of
digits (one time secret key) and let the phone obtain it's private key
from a server?
Is it not possible to send the private key via an sms?
[/quote:5845a2c140]
I might be possible, but depending on your phone plan, you might be charged for
SMS messages. People look very suspciously on applications that "phone home"
from your smartphone - especially if the application itself has nothing to do
with connectivity, which is the case for me.
But I wonder how Microsoft does Windows activation over the phone. They have a
reasonably short license number, which is custom for each customer. They must
not be using any public key technology either. |
|
|
| Back to top |
|
|
|
| Mike Amling... |
| Posted: Sun Oct 18, 2009 7:52 pm |
|
|
|
Guest
|
Robert Scott wrote:
[quote:cb96ab3ca9]By the way, if anyone knows of an alternative to this system, perhaps using some kind of public key
digital signature with signatures no bigger than 66 bits, I would like to hear about it. Anyway, here
is the code:
[/quote:cb96ab3ca9]
The length of a normal ECDSA signature is 4 times the security
parameter. You can improve that ratio by using a Zheng signature. I used
Zheng signatures for software sold by the company I work for. It was
overkill for our situation, since every customer signs a contract.)
If eleven one-or-two-digit numbers are not overly burdensome for your
clients to enter, then you can get more security by using a bigger base
than 10. The expected number of digits that your clients enter is
(1*10+2*54)/64*11=20.2 decimal digits. 20 hex digits would get you an
80-bit signature. 20 base-32 digits would get you 100 bits. 20 base-64
digits would get you 120 bits, which could encode a Zheng signature with
a 39-bit security parameter, which is better than what you have.
--Mike Amling |
|
|
| Back to top |
|
|
|
| Robert Scott... |
| Posted: Sun Oct 18, 2009 8:30 pm |
|
|
|
Guest
|
On Sun, 18 Oct 2009 20:52:47 -0500, Mike Amling <mamling at (no spam) rmcis.com> wrote:
[quote:7030c79d9b]Robert Scott wrote:
By the way, if anyone knows of an alternative to this system, perhaps using some kind of public key
digital signature with signatures no bigger than 66 bits, I would like to hear about it. Anyway, here
is the code:
The length of a normal ECDSA signature is 4 times the security
parameter. You can improve that ratio by using a Zheng signature. I used
Zheng signatures for software sold by the company I work for. It was
overkill for our situation, since every customer signs a contract.)
If eleven one-or-two-digit numbers are not overly burdensome for your
clients to enter, then you can get more security by using a bigger base
than 10. The expected number of digits that your clients enter is
(1*10+2*54)/64*11=20.2 decimal digits. 20 hex digits would get you an
80-bit signature. 20 base-32 digits would get you 100 bits. 20 base-64
digits would get you 120 bits, which could encode a Zheng signature with
a 39-bit security parameter, which is better than what you have.
[/quote:7030c79d9b]
Thanks. I will look into an ECDSA implementation. |
|
|
| Back to top |
|
|
|
| Tom St Denis... |
| Posted: Mon Oct 19, 2009 6:09 am |
|
|
|
Guest
|
On Oct 17, 1:18 am, g... at (no spam) nope.ucsd.edu (Greg Rose) wrote:
[quote]In article <4ad9032e.1326... at (no spam) news.eternal-september.org>,
BUT, and it's a big but, this is not secure in
your context; any single individual can find the
key in your software and post it on the web, or
make available an app for signing arbitrary stuff,
or whatever. True digital signatures work in your
scenario but symmetric MACs don't.
[/quote]
My suggestion was more universal since even if a secure 56-bit hash
existed people would just byte-patch the code to jump around the
signature verification.
So really a simple MAC with secret+id (id being things like the user's
name, machine name, etc) is simple to build with known primitives,
keeps the honest people honest, and is no more or less secure than a
digital signature in this context.
The real "solution" to this problem is a different sales model. For
example, consider not releasing the software until you've made enough
money from previous engagements. So you'd start the chain with free
offerings [that you license to people for $0] then solicit
contributions under the premise that once you hit a threshold you'll
release the next hot version with whatever do-dahs. Then license that
to the contributors, sell "buy-ins" to new customers, and solicit
contributions from existing users until you hit threshold and repeat.
That way you're making money before you even release, and people will
only contribute so long as you're serving a useful purpose. So even
if you do face piracy you're not out that much.
Tom |
|
|
| Back to top |
|
|
|
|
|
All times are GMT - 5 Hours
The time now is Wed Dec 02, 2009 4:30 pm
|
|