对于包含敏感信息的数据库的基于字段的加密,我考虑了以下设计:
在数据库中,有一个表,其中包含用户智能卡的所有公钥和使用每个用户的公钥加密的全局对称密钥。其余的敏感数据是用对称密钥加密的。
如果数据库被破坏,数据安全吗?
另一种可能的解决方案是,在所有智能卡上另外存储相同的全局RSA密钥,并使用此密钥与RSA-KEM一起加密所有合理的数据。缺点是,这使得在生产设置中更改全局密钥变得更加困难,因为所有的智能卡都必须被替换/重新编程。
你认为如何?
发布于 2012-02-27 09:48:40
存储相同的对称密钥加密多个方式并不是问题,但对每个客户端使用相同的密钥是问题,除非您在客户端之间具有非常高的信任程度,因为它使客户端能够解密彼此与服务器的通信。
为每个会话生成一个新的对称密钥将更加安全,然后使用客户端非对称密钥对其进行加密,并将其存储在会话期间。
发布于 2012-09-15 08:56:31
一个被两个人分享的秘密不再是真正的秘密了。
用对称密钥K加密数据,然后用每个收件人的非对称密钥加密K,这意味着让接收方访问所有用K加密的数据;“所有数据”包括将用K加密的数据。这种加密方法是安全电子邮件(例如OpenPGP)的正常情况,但关键是电子邮件是“一击”,每封电子邮件都是用自己的、特定的、随机的K加密的。
有了数据库,事情就变得更多毛了,因为数据库是一组随着时间推移而演变的数据。通过给每个用户提供K,您可能不仅允许他们读取数据库内容,而且还允许他们读取以后将添加的未来内容。这不一定是一个问题:只要给定的用户能够访问数据库,他就可以(至少在理论上)将所有数据转储到自己的文件中,并且没有办法让他“忘记”数据。然而,从长远来看,这需要关键的更新。
例如,假设在某个时候,您希望将对数据库的访问授予一个新用户。这很简单:简单地用新用户的RSA密钥加密K。删除用户的双重操作更为复杂。由于不能强迫用户忘记数据,所以最好的方法是拒绝访问新数据(在用户删除后添加的数据),这意味着选择一个新的K‘与K不同(而且K’不能从K中计算,所以我们正在讨论从零开始选择一个新的随机K‘)。因此有两种选择:
第二种方法使存储变得更简单,并具有“驱逐”已删除用户的好处(在攻击模型中,我们假设被删除的用户注意复制他能够复制的所有数据,但如果没有,那么就显式地将他踢出cis尼斯)。但是,使用第二种方法进行的密钥更新可能会非常昂贵,这取决于它们的频率和数据库大小。第一种方法更通用,允许细粒度访问控制(例如,使某些子集的用户可以访问数据)。
undefined有许多支持函数(作为SQL级别)来实现这些功能(但是,要注意的是,微软关于加密元素的文档有一种重新定义术语的恼人倾向,有时突然出现在文档本身的中间)。
发布于 2012-06-18 13:43:18
我的理解是,OpenPGP和许多其他密码系统正是这样做的--它们在许多地方存储一个对称密钥,每个地方都使用不同的公钥加密。每个人使用自己独特的私钥提取一次对称密钥,然后使用对称密钥解码其他内容。
“https://crypto.stackexchange.com/questions/2666/hash-decrypts-key-key-decrypts-cipher-why”
“https://crypto.stackexchange.com/questions/1680/information-leakage-from-the-ecryptfs-filesystem”
但是,这些系统假设,如果每个提取对称密钥的人都可以读取使用该密钥加密的所有内容,这是可以的。
在您的情况下,情况似乎并非如此,所以我同意JGWeissman:为每个会话生成一个新的对称密钥,然后使用用户智能卡的公钥进行加密并发送给用户。只在会话的持续时间内将新的对称密钥存储在两端。
我不清楚这些“敏感数据”是否只是几个共享文件,每个文件都应该可以读取,而不是所有用户都应该能够读取;或者这些“敏感数据”是否是数据库中的一个或多个字段,每个字段只有用户(可能还有一两个其他人)才能读取。
假设这是每个用户的非共享数据,实际上是数据库中的字段,那么每次更改这些字段时,我都会这样做。
https://security.stackexchange.com/questions/12205
复制