对于包含敏感信息的数据库的基于字段的加密，我正在考虑以下设计：
在数据库中有一个表，其中包含用户智能卡的所有公钥和用每个用户的公钥加密的全局对称密钥。其余敏感数据使用对称密钥加密。
如果数据库遭到破坏，数据是否安全？
另一种可能的解决方案是，在所有智能卡上额外存储相同的全局 RSA 密钥，并将此密钥与 RSA-KEM 一起使用来加密所有敏感数据。缺点是这使得在生产设置中更改全局密钥变得更加困难，因为所有智能卡都必须更换/重新编程。
你怎么认为？
存储相同的对称密钥以多种方式加密不是问题，但是为每个客户端使用相同的密钥是，除非您在客户端之间具有异常高的信任度，因为它使客户端能够解密彼此与服务器的通信。
为每个会话生成一个新的对称密钥会更安全，然后使用客户端的非对称密钥对其进行加密，并在会话期间存储。
超过两个人共享的秘密不再是真正的秘密。
用对称密钥K加密数据，然后用每个接收者的非对称 (RSA) 密钥加密K，意味着让接收者可以访问所有用K加密的数据；“所有数据”包括将用K加密的数据。这种加密方法是安全电子邮件的正常情况（例如使用OpenPGP），但关键是电子邮件是“一次性的”，并且每封电子邮件都使用其自己的特定随机K加密。
有了数据库，事情就更复杂了，因为数据库是一组随时间演变的数据。通过将K分配给每个用户，您可能允许他们不仅现在读取数据库内容，而且还可以读取稍后将添加的未来内容。这不一定是个问题：只要给定用户有权访问数据库，他就可以（至少理论上）将所有数据转储到自己的文件中，并且没有办法让他“忘记”数据. 但是，从长远来看，这需要密钥更新。
例如，假设在某个时候，您希望将数据库访问权限授予新用户。这很简单：只需使用该新用户的 RSA 密钥加密K。删除用户的双重操作更加复杂。由于您不能强迫用户忘记数据，因此您能做到的最好的方法是拒绝访问新数据（用户删除后添加的数据），这意味着选择一个不同于K的新K'（并且K'不能是可从K 计算，所以我们正在讨论从头开始选择一个新的随机K'）。所以有两种选择：
设置您的数据库格式，以便可以使用用于该记录的键K的标识符来标记每条记录。每次密钥更新意味着创建一个具有新标识符的新K ，并在每个新添加或修改的记录中使用该新标识符。维护所有加密K的存储库（按标识符和用户索引）。在使用时，每个用户使用目标记录上的标签访问存储库，从而获得用于解密记录的密钥K。
当密钥更新时，数据库中的所有数据都用旧的K解密并用新的K 重新加密。维护每个K（由用户索引）的加密版本的存储库。
第二种方法使存储更简单，并且具有“踢出”已删除用户的好处（在攻击模型中，我们假设已删除的用户小心地复制了他可以复制的所有数据，但如果他没有复制，则踢他出明确顺好）。但是，使用第二种方法的密钥更新可能非常昂贵，具体取决于它们的频率和数据库大小。第一种方法更通用，允许细粒度的访问控制（例如，使某些用户子集可以访问数据）。
Microsoft SQL Server有很多支持功能（作为 SQL 语言级别）来实现这些东西（但是，请注意，Microsoft 关于加密元素的文档有重新定义术语的令人讨厌的趋势，有时会突然出现在文档本身的中间）。
我的理解是 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：为每个会话生成一个新的新对称密钥，然后使用用户智能卡的公钥对其进行加密并发送给用户。仅在会话期间在两端存储新的对称密钥。
我不清楚这个“敏感数据”是否只是一些共享文件，每个用户都应该能够阅读，但不是所有用户；或者如果这个“敏感数据”是数据库中的一个或多个字段，每个字段只有用户（可能还有一两个其他人）应该能够读取。
假设这是非共享的每用户数据，它是数据库中的有效字段，每次更改这些字段时，我都会