Xml 您同意这种验证许可证的方式吗？

我有一个XML文件，描述了产品许可的公司名称、版本和一些额外信息

看起来像这样

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

sdfsdf
1.2.1.1
4.

然后我用私钥签署这个文件，然后

<Licence>
  <Name>sdfsdf</Name>
  <Version>1.2.1.1</Version>
  <NumberOfServer>4</NumberOfServer>
  <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
    <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>

sdfsdf
1.2.1.1
4.
M368eFB9ydifttSxX26sB6XiPV4=
TTYP6d+zESn6/2PtL5ikN+7E9U8NJM32VYVANC5U0EGLBWS//3YPJUOBX3GLJXHCLZPQBQUEUI0LJNAUTFVO1BYU4IxPJRQCVAUIUDETSV5Z7OB8+C/+NSQSC26FXF9VWXVAKJZCEP88R0WIFVE31 HSD18FU=

然后，我将公钥发送到应用程序中，并读取该文件，以确保它们的版本和“NumberOfServers”与许可证密钥相同

这种方法的缺点是什么？

谢谢

这种方法的缺点是什么

---

这就是滚动你自己的问题。在实地试验之前，你不会知道它的缺点。对于用户群较小的临时应用程序，这可能很好，但如果有足够的动机（阅读$$$$）破坏它，那么它很可能会被破坏。历史告诉我们这一点。我个人会选择一个真正的解决方案。我在过去使用过，它似乎非常合理。

一个问题：攻击者可以生成密钥对、许可证，用该私钥签署许可证，然后用自己的私钥替换应用程序中的公钥。这听起来可能有些牵强，但这是小偷做的事情

如果你试图保护面向不诚实人口的东西（例如，还没有学会诚信价值的孩子），加密狗会更强大

---

如果您向关心其声誉的人或企业销售产品，这足以帮助他们保持诚实，并跟踪他们的许可证。

您想保护什么？随意的复印机还是更巧妙的复印机？（你无法防范最好的黑客，就像你无法防范最熟练的窃贼一样。）如果有人非法使用你的软件会有多糟糕？创业公司或财富500强公司的目标受众是谁？你愿意在多大程度上激怒你的合法用户

顺便说一句，考虑打破这个方案，我会考虑找到公钥并使用十六进制编辑器替换另一个公钥，然后修改XML并对其重新签名。或者，使用假公司名称设置许可证服务器环境（无论您如何检查），或者设置多个许可证服务器环境以允许更多许可证

这是我立即想到的，我对颠覆许可证问题知之甚少。我不知道你是否涵盖了这些问题

---

而且，正如Shane C.Mason指出的，除非你是一个有造诣的黑帽子，否则你不知道这些弱点。我还建议将其视为加密，并强烈建议您使用普遍可用且广受信任的方案。

Microsoft刚刚发布了一个虚拟实验室-

我建议您使用自己的XML文件签名方法。我最初使用SignedXml类进行许可，但后来意识到，任何人只要查看XML文件本身就可以推断出我在做什么，这是非常容易的（因为算法等都是指定的）

因此，取而代之的是，我组合了每一段数据（在我的例子中是客户编号、许可证密钥和版本），对其进行散列，并对结果进行签名，而不是对整个XML文件进行签名。然后我对其进行了进一步的模糊处理，并将数据作为单个“数据”元素添加到许可证中

---

仅仅通过观察它，就不可能看到任何关于我使用了什么算法或过程的指标。当然，任何人都可以轻松地在Reflector中打开我的组件，看看它是如何被验证的。但是，由于每个许可证都有一份副本存档，如果我怀疑客户更改了许可证以提供更多功能，我可以与我的客户核实他们的副本，并拒绝他们提供任何进一步的支持和/或采取法律行动。

是的。但我想到了这一点，我也会用一把钥匙来签署实际的装配，这将使它更难改变。谢谢，谢谢。这是一个小应用程序。仅限<100家公司使用。但我希望它能够在没有许可证的情况下下载并测试。它将被500家类似的公司使用。它的价格是2000美元左右，如果我也签署了大会，这将使更改公钥更加困难，我应该可以做我想做的事情。谢谢隐马尔可夫模型。。。好啊但是你为什么要“怀疑”这件事？您可以在运行时真正了解许可证的实际用途是什么版本？您真正能做的就是检查hased值是否与运行时具有相同输入时得到的值相同？如果我没弄错的话，我不认为这是我真正想要做的。我仍然使用密钥对数据进行签名，但不是对XML文件本身进行签名，而是以我自己的方式对数据的哈希进行签名。然后我使用Base64或其他东西对其进行模糊处理，并将其写入单个标记。原始数据（客户编号、版本等）仍在XML文件中，但我现在有一个签名，它不能仅仅通过查看XML文件本身的结构来验证（就像SignedXml类一样）。啊哈，我明白了！好主意，谢谢！这就是我要用的方法！看起来会很好用的。