【问题标题】:SQL Server Consistent Column EncryptionSQL Server 一致性列加密
【发布时间】:2015-05-15 09:44:51
【问题描述】:

我有一个相当简单的 SQL Server 要求,我有一个 int 类型的列,并且我想加密该列,因为用于加密该列的函数每次调用时都应该生成相同的值.

上下文

  1. 我的系统有 2 个用户角色源角色、目标角色
  2. 源角色用户生成具有以下结构的表 ID => 整数 元数据列 => varchar
  3. 我的系统将生成带有混淆 ID 的源表的副本
  4. Target 角色用户将有权访问生成的表并可以添加/更新元数据列,但他们不应该知道明确的 ID

我的试炼

  1. 我已经尝试ENCRYPTBYKEY 使用身份验证器和不使用身份验证器,但是每次我调用该函数时,它都会生成不同的值,这在某些情况下可能是有益的,但我的不是其中之一 :)
  2. 我也尝试过使用ENCRYPTBYASYMKEY 并且出现了相同的行为,每次调用的输出不同
  3. 我还发现这个forum post 提到 SQL Server 正在使用随机初始化向量

我的问题是,考虑到该函数将用于加密具有数百万条记录的表,有哪些可能的解决方案可以满足我的要求。

【问题讨论】:

  • 您的真正要求是什么?为什么相同的值?您是否将加密与散列混淆? 使用加盐的对称加密被认为是不安全并且根据定义被破坏。原因非常简单——有人可以创建加密字符串的映射并通过简单的查找恢复原始数据。 为什么当你可以简单地使用原始密钥解密时你想要相同的加密?

标签: c# asp.net .net sql-server encryption


【解决方案1】:

实现我的要求的可能解决方案是什么

没有。

TLDR;

现代加密必须满足几个属性,每个属性之一是Semantic security。通俗地说,语义安全意味着如果您有加密的消息,您将无法获得有关纯文本消息的任何附加信息。但是,您的要求与此直接矛盾,因为通过访问足够多的加密消息,可以得出纯文本的含义。这就是德国机器 Enigma 在第二次世界大战期间被破解的方式(他们重复使用了密钥,而您想修复 IV。结果是一样的 - 可以显示纯文本)。

为此目的,Initialisation Vectors 已被发明并且必须使用。

你会怎么做?其实有两种选择:

  • 明确您的要求
  • 使用不暗示语义安全的映射,例如(1 -> 9478、2 -> 9572 等)。如果您只是试图混淆 ID 之类的内容,则此选项很有用,例如您不想让公司有多少产品待售一目了然。

【讨论】:

  • 感谢@oleksii 的回答我已在我的问题中添加了上下文部分,因此如果您可以提供更多支持:)。
  • @HossamBarakat 你是不是把加密和散列混淆了?
  • @PanagiotisKanavos 感谢您的注意,我同意您的观点,我的情况与哈希更相关。我正在考虑为输入列创建哈希并将该值保留在映射表中并控制该表的安全权限,您怎么看?
  • SQL Server 有一个HASHBYTES 函数,不过如果没有加盐的话,可以通过查找表猜出原始值。
  • @HossamBarakat,不确定您是否需要散列,但盐的重点不是不为攻击者所知或隐藏。知道盐就OK了。盐渍的重点是每条记录都不同,这样可以防止彩虹攻击。你可以阅读更多关于盐的信息here
【解决方案2】:

您必须编写自己的加密功能才能执行此操作,但您为什么要这样做,imo 可能存在安全风险

【讨论】:

  • 您能否详细说明为什么这可能是安全风险?并且关于我的加密可以提供示例,参考,...考虑到性能要求
  • 任何每次创建相同值的加密都可以很容易地被其他人解密。这取决于您的数据库的用途,以及有人闯入和暴露数据的可能性。 Google 应该能够为您提供代码示例
  • 据我从en.wikipedia.org/wiki/Deterministic_encryption 了解到,如果加密数据的用户与解密数据的用户不同(这是我的情况),那么不会有数据泄漏可以让用户知道使用的算法是什么,对吧?
猜你喜欢
  • 2011-06-05
  • 1970-01-01
  • 2012-05-06
  • 2012-08-23
  • 2011-01-10
  • 2017-04-19
  • 1970-01-01
  • 1970-01-01
  • 2013-09-22
相关资源
最近更新 更多