是否可以在SQL Server 2014中为.NET框架程序集创建非对称密钥？

Question

我正在Visual Studio中开发一个SQL Server数据库项目,它实际上是一个用户定义的函数.在这个项目中,我将Json.NET作为参考(使用NuGet).

我设法通过首先打开数据库TRUSTWORTHY ON(因为我的项目是UNSAFE)然后运行它来发布(并使工作)我的程序集和UDF到我的SQL Server实例:

CREATE ASSEMBLY [System.Runtime.Serialization] 
FROM 'C:\Windows\Microsoft.NET\Framework\v4.0.30319\System.Runtime.Serialization.dll'
WITH PERMISSION_SET = UNSAFE;

原来是Json.NET所依赖的程序集(如果我不这样做,我会收到错误)

与此同时,我读到了TRUSTWORTHY ON可能变得多么糟糕,我试图采用非对称键方式来避免打开它.

甚至在签署我自己的程序集之前,我知道我必须创建一个密钥, System.Runtime.Serialization因为我的项目依赖于Json.Net,而Json.Net依赖于它,但是当我运行它时,我得到了这个:

USE [master];
GO
  CREATE ASYMMETRIC KEY [SystemRuntimeSerializationKey]
    AUTHORIZATION [dbo]
    FROM EXECUTABLE FILE = 'C:\Windows\Microsoft.NET\Framework\v4.0.30319\System.Runtime.Serialization.dll';
GO

Msg 15468, Level 16, State 5, Line 3
An error occurred during the generation of the asymmetric key.

这对我没什么帮助.

那么是否可以为.NET框架程序集生成这样的密钥,或者它是否存在将TRUSTWORTHY打开的其他解决方法？

Answer 1

不，我从来没有找到实现这一目标的方法。用于签署 .NET Framework 程序集的密钥是 Microsoft 内部/私有的。尝试过的选项：

• 提取私钥/加载到 SQL Server：不可能，否则密钥将不是“私有”的。签名/强命名系统是有效的，因为外部人员不能声称他们签署了代码。

• 添加签名：我尝试使用该sn实用程序添加一个新签名。不起作用，因为：

  无法重新签署程序集 - 程序集的公钥与签名公钥不匹配。

  但是，即使这确实有效，也可能并不意味着将其加载到 SQL Server 中就可以工作，因为它与您作为资源添加到项目中的程序集不同。其他 .NET Framework DLL（如果有任何其他依赖项）只会知道原始签名。

• 删除当前签名并添加一个新签名：我尝试使用ILDASM反汇编System.Runtime.Serialization.dll，然后添加从创建的新私钥，sn -k然后使用 重新链接ILASM，但这一步失败了ILASM（我没有时间进一步调查）。

  但就像上面的选项一样，即使这确实有效，您也必须将 Json.NET 项目引用更改为System.Runtime.Serialization新的 DLL，重新编译它，然后将项目引用更改为新的 DLL，然后重新编译。但这只能让您能够干净地加载 DLL，如果它们具有需要原始 Microsoft 签名的外部依赖项，则不能保证它们能够正常工作。

本质上，如果您正在加载无法控制签名的 DLL，那么唯一的希望就是使用 进行反编译ILDASM并使用 重新编译ILASM，指定一个新snk文件，但如果链接到其他程序集，则这将不起作用正在重新编译什么。当然，.NET Framework DLL 就属于这一类。

简而言之：如果您正在加载不受支持的 .NET Framework DLL，那么您几乎需要设置TRUSTWORTHY ON.

但是：请记住，即使这确实可以通过非对称密钥或证书加载所有内容，但这并不意味着您不会遇到功能问题。这些库未经批准/验证是有原因的。其中的代码可以以您不期望的方式执行一些操作，例如将数据存储到静态字段。在 Windows 和控制台应用程序中，这不是问题，因为每个应用程序域只能使用一次。但 SQLCLR 使用共享应用程序域，因此多个 SQL Server 会话将共享这些静态变量。可能 Json.NET 库调用的方法没有使用那些不安全的东西，但我们无法知道，即使我们知道，现在我们也无能为力:-(。

我一直在考虑的一件事是跟踪不受支持的 .NET Framework DLL 中调用的方法，并假设它没有执行任何不安全的操作，从而将该代码直接复制到项目中。理论上，只要调用System.Runtime.Serialization不调用其他不受支持的 DLL 或执行“不安全”的操作等，就应该可行。但是，我还没有时间对此进行测试。