Re: Public-key CD-KEY protocol (comments welcomed)

From: Mark Borgerding (mark_at_borgerding.net)
Date: 02/01/04 

Date: Sun, 01 Feb 2004 15:00:10 GMT

I'm not sure why your software requires the two stages (initial &
subsequent verification). If that is a requirement, I'd suggest viewing
them as two separate problems.

For the first stage:
As you noticed, PK offers zero advantage over symmetric crypto for the
first connection. The truncation makes verification impossible without
the private key.

Anything short of the full PK signature cannot be verified. You might
look into elliptic curve cryptography to get the key length down a bit.
  Although even the shortest ecc curve suggested by the eccdsa is 163
bits. If you're encoding it base36 then you need 32 chars just for the
signature.

If you can't use the full signature, you could just truncate an HMAC
rather than jump through the PK hoops. It would be simpler and faster.

As for the second stage:
(do your users need to connect every time they use the SW?)
the complete signature you are sending back is just a token that can be
verified. It does not need to have any connection to the initial CD key.
If you went with an HMAC for stage 1, you could define the token as
the CDkey + PKsigned(CDkey).

- Mark Borgerding

Xavier wrote:
>
> - The five first characters of the CD-KEY are arbitrarily chosen to
> represent a unique ID.
>
> - This ID is signed by the private key (SHAH, then RSA). The signature
> is translated by table correspondance into an alphanumerical character
> chain.
>
> - This translated signature is shortened to the 20 first characters, and
> added to the unique ID to form the complete CD-KEY.
>
>
> To verify the CD-KEY:
>
> a) If this is the first connection :
>
> * The client sofware connects to a central secured server that has
> both the private and public RSA key.
>
> * The server signs the unique ID contained in the CD-KEY and compares
> the resulting signature to the second part of the CD-KEY.
>
> * If the two are identical, it sends the complete signature to the
> client, that records it.
>
> * The client goes to b).
>
> b) If this not the first connection, or if a) has been completed :
>
> * The client software connects to another server, that only has the
> public key available.
>
> * The server receives the complete signature (not just the CD-KEY)
> from the client and tries to decrypt it using the public key. If it
> succeeds, the login is allowed.
>
>
> The benefits of this protocol would be that :
>
> - The CD-KEY creation protocol uses well-known algorithms instead of
> home-made and easily crackable ones.
>
> - The private key only needs to be known by a single server with very
> low hardware requirements, as it is only accessed once for every client
> software installed. It can then be more secured and the effect of a DoS
> on it would have less impact, as only new users would be denied access.
>
> But I need feedback about this protocol, as the size limitation on the
> CD-KEY itself (which has to be entered manually by the user) does not
> allow to use an entire signature for the first authentification. I do
> not think this is very harmful (we will never have full security with
> only 25 alphanumerical characters), but I would appreciate points of
> view about this issue.
>
> Any comments welcomed !
>

Relevant Pages

  • Re: Symantec AV signature corruption
    ... The vendor response on this issue may have been a bit light on detail ... Users logged in in the morning and applied dodgy sigs. ... Had to write script to manually rollback to last signature, ... Client accepted sigs silently, and effectively had zero viruses in the ...
    (NT-Bugtraq)
  • Re: how can we restrict what certificate WSE will use?
    ... > X509SecurityTokenManager to verify the request is from a trusted client. ... >> decrypte and signature validation process. ... >> in a request signed with his valid private key, ...
    (microsoft.public.dotnet.framework.webservices.enhancements)
  • Re: C : how to export raw YUV to a file ?
    ... > message body, ignoring all other headers, and it would be fine. ... especially if not all of the signing parties are signing the entire ... able to verify the original author's signature. ... not in any client I'm familiar with. ...
    (comp.programming)
  • Re: Digital signatures
    ... (A signature can be marked as non-exportable, ... document as John Doe and you trust it without any other verification ... Import and sign that key on your keyring. ... not checked out in any other way, then you'll get the big fat WARNING ...
    (Fedora)
  • Re: how can we restrict what certificate WSE will use?
    ... you mentioned 'since his private key is not valid so, the signature of his ... in a request signed with his valid private key, and since his public key is ... > As for the question on the X509 certificate verification in .net ...
    (microsoft.public.dotnet.framework.webservices.enhancements)
Quantcast