Would you be OK with this way of verify a license?

Question

I have a XML file describing the name of the company the product is licensed for, the version and some extra information.

Looking something like this

<Licence>
  <Name>sdfsdf</Name>
  <Version>1.2.1.1</Version>
  <NumberOfServer>4</NumberOfServer>
</Licence>

I then sign this fiel using a private key and get

<Licence>
  <Name>sdfsdf</Name>
  <Version>1.2.1.1</Version>
  <NumberOfServer>4</NumberOfServer>
  <Signature xmlns="http://www.w3.org/2000/09/xmldsig#"&gt;
    <SignedInfo>
      <CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315" />
      <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" />
      <Reference URI="">
        <Transforms>
          <Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" />
        </Transforms>
        <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
        <DigestValue>M368eFB9ydifttSxX26sB6XiPV4=</DigestValue>
      </Reference>
    </SignedInfo>
    <SignatureValue>TTYP6d+zESn6/2PtL5ikN+7E9u8Njm32vYVyVANC5U0EGLBwS//3yPjUoBx3glJXHClzPQBQEUi0LJNauTFvo1IBYwLjAuaYGtleti4IXpjrQCVaIudETSv5Z7oB8+C/+nsqsC26fXf9vWxvaKXJJzcep88r0wIfVe31HSd18FU=</SignatureValue>
  </Signature>
</Licence>

I then ship the public key in the application and read the file to make sure they have the right version and "NumberOfServers" as the license key is for.

What are the downsides of this approach?

Thanks

Answer 1

What are the downsides of this approach?

Therein lies the problem of rolling your own. You will not know the downside until it has been tried in the field. For a casual application with a small user base this might work fine, but if there is enough motivation ( read $$$$ ) to break it then it likely can and will be broken. History shows us that. I would personally go with a tried a true solution. I have used LM-X from X-Formation in the past and it seems quiet reasonable.

Answer 2

One problem: an attacker can generate a key pair, a license, sign the license with that private key, then replace the public key in the application with their own. It might sound far-fetched, but it is the kind of thing thieves do.

If you are trying to protect something marketed to a dishonest demographic (for example, kids who haven't yet learned the value of integrity), dongles are more robust.

If you are selling to people or businesses that care about their reputation, this is sufficient to help them stay honest and keep track of their licenses.

Answer 3

What are you trying to protect against? Casual copiers or the more ingenious ones? (You can't protect from the best ones, any more than you can keep out the most proficient burglars.) How bad would it be if people used your software illicitly? Who's the target audience, startups or Fortune 500 companies? How much are you willing to annoy your legitimate users?

Offhand, thinking of breaking this scheme, I'd think about finding the public key and substituting another one using a hex editor, then modifying the XML and re-signing it. Alternatively, set up a license server environment with a fake company name (however you're getting it to check), or perhaps more than one to allow more licenses.

That's what immediately occurs to me, and I know very little about subverting license issues. I don't know if you've covered these problems or not.

And, as Shane C. Mason points out, unless you're an accomplished Black Hat, you don't know the vulnerabilities. I also would suggest treating this like crypto, and strongly suggest that you use a generally available and widely trusted scheme.

Answer 4

Microsoft has just posted a Virtual Lab - MSDN Labcast On-Demand: Add Security to Applications by Digitally Signing XML Documents

Answer 5

One thing I would suggest is rolling your own method of signing the XML file. I was originally using the SignedXml class for licensing, but then realized that it was incredibly easy for anyone to deduce what I was doing just by looking at the XML file itself (since the algorithms and such are specified).

So, instead, I combined each piece of data (customer number, license key, and version in my case), hashed it, and signed the result, rather than the entire XML file. Then I obfuscated it a bit more and added the data as a single "Data" element in the license.

Just by looking at it, it's impossible to see any kind of indicator as to what algorithms or processes I used. Of course, anyone could easily open my assembly in Reflector and see how it's being verified. However, since a copy of each license is kept on file, if I suspect that a customer has changed the license to give them more capabilities, I can verify their copy with mine and deny them any further support and/or take legal action.