有关mysql持久化安全性问题的一些疑问

[oceanqdu]

现在假设有这样一个场景：三个机构分别为alice（用户）、bob（用户）和carol（云厂商或TEE算力提供方），其中alice和bob提供数据，carol提供TEE机器。 在此情况下capsulemanager以及teeapps两个容器均由carol部署在TEE机器中，现在假设capsulemanager使用了mysql进行持久化配置。 https://www.secretflow.org.cn/zh-CN/docs/trustflow/0.4.0b0/quick_start/step1#id14 配置如下：

storage_config:
  storage_backend: "mysql"                                 # storage backend: mysql, inmemory
  db_url: "mysql://root@localhost:3306/capsulemanager"     # db url
  password: "********"                                     # db password

scheme: "RSA"                   # Asymmetric key generation method, SM2/RSA

enable_inject_cm_key: true                              # enable inject cm key
cm_private_key_path: script/certs/cm.key                   # cm private key path
cm_cert_path: script/certs/cm.crt                          # cm certificate path

那么在配置持久化的过程中需要配置mysql的数据库创建相关的表，以及其他操作。此过程均由carol进行操作，因此carol可以访问mysql数据库，同时carol拥有cm_private_key，那么是不是认为carol可以获得数据库中存储的alice和bob的密钥？因此carol也可以对alice和bob存在的teeapps密文数据进行解密？在此情况下如果云厂商想要窃取alice和bob的数据能否实现？

[zhongtianq]

你的理解是正确的。

enable_inject_cm_key这个选项只是为了方便调试或者demo体验使用的，可以看到我们的默认设置是false。正式的服务上是不允许以注入的方式来配置cm的公私钥的。 正式服务上，可以由capsule manager这个应用启动时自己生成，也就是默认配置中的false。但是正如文档中所说，这会带来高可用的问题，即不可恢复。并且如果capsule manager是多个副本部署，还涉及到副本之间的密钥同步问题。

因此，在隐语的密算云服务上，我们会使用另一个服务AECS（https://github.com/SOFAEnclave/enclave-configuration-service ）来进行TEE 应用（包括capsule manager）公私钥的管理。这个服务部署在SGX环境中，使用sealing机制来持久化保存应用的公私钥。 大致流程如下图：

开源版本中为了简化上手成本，我们不引入这一依赖，可以用注入密钥来进行体验，或者使用单点部署由应用启动时生成密钥。

[oceanqdu]

@zhongtianq 感谢您的解答，我还有一些疑问。关于上图您说的使用服务AECS来进行密钥的管理，假设以capsule manager为例来模拟密钥管理使用过程，您看下以下过程我理解的是否有问题。

  1.管理员在AECS中为capsule manager注册应用基线（这个管理员我理解为是之前假设中的carol或者云厂商）
  2.AECS生成capsule manager的公私钥（公私钥存放在哪里？是使用sealing机制封装在TEE中？）
  3.capsule manager服务在启动的时候需要生成一对临时的公私钥，当capsule manager需要使用AECS中生成的公私钥时，首先 
  生成自己的远程认证报告，然后将远程报告以及临时公钥发送给AECS。
  4.AECS验证capsule manager的远程报告并校验capsule manager的应用基线（这个应用基线应该怎么理解？应用基线是怎么 
  校验的？应用基线是用来标识capsule manager的？）
  5.AECS使用capsule manager发送来的临时公钥对公私钥进行加密并生成自己的远程认证报告
  6.AECS发送远程认证报告以及加密后的公私钥给capsule manager
  7.capsule manager验证远程认证报告并解密公私钥

在上述过程中capsule manager的公私钥均由AECS生成并管理，AECS以及capsule manager均部署在TEE中，与mysql持久化的问题类似，怎么保证管理员无法获得AECS生成的密钥？

[zhongtianq]

过程理解基本没有问题。 应用基线包括应用名、应用的度量值等内容。 管理员只能在生成公私钥之前设置应用基线，AECS一旦生成公私钥，即使是管理员也无法获取到公私钥，只能由对应的APP获取。生成的公私钥会由sealing机制加密保存在AECS的持久化存储中。 由于sealing机制暂时没有在TDX等机密虚拟机中支持，因此AECS还是以SGX模式部署。

另外，对于不太复杂的系统，也可以让应用副本之间双向RA来进行APP密钥的同步，如下图流程：

[oceanqdu]

@zhongtianq “管理员只能在生成公私钥之前设置应用基线，AECS一旦生成公私钥，即使是管理员也无法获取到公私钥，只能由对应的APP获取。” 这是靠sealing机制实现的吗？在生成密钥的时候用到了对应的APP度量值等内容来保证管理员无法获得？

[zhongtianq]

@zhongtianq “管理员只能在生成公私钥之前设置应用基线，AECS一旦生成公私钥，即使是管理员也无法获取到公私钥，只能由对应的APP获取。” 这是靠sealing机制实现的吗？在生成密钥的时候用到了对应的APP度量值等内容来保证管理员无法获得？

准确来说sealing是持久化存储的时候用到的技术。 AECS是一个SGX应用，它在收到请求后随机生成了一对公私钥，并与应用基线进行绑定。 AECS只会向满足应用基线，能够提供对应远程认证报告的应用分发这对公私钥。 sealing的技术保证了AECS在加密存储这对公私钥的时候仅能被AECS这个应用解密，对管理员来说存储的内容是无法解密的。

[oceanqdu]

@zhongtianq 感谢您的解答，我明白了AECS的作用。我想和您讨论一下如果舍弃AECS考虑如下场景是否可行： capsule manager依然选择使用mysql进行持久化存储，但并不选择从外部注入cm key，而是在第一次启动的时候随机生成一对公 私钥来加密mysql数据库，并使用sealing技术进行加密存储。当capsule manager意外停止再次重启时，capsule manager去检查是否已存在sealing封装的密钥，若存在则使用该密钥对数据库进行加解密。这样是不是可以保证单点部署时使用mysql持久化的安全？在这里使用sealing技术保证了capsule manager在第一次启动时随机化生成的公私钥仅能被他自己获得，管理员即使可以访问数据库也无法解密数据。

[zhongtianq]

@zhongtianq 感谢您的解答，我明白了AECS的作用。我想和您讨论一下如果舍弃AECS考虑如下场景是否可行： capsule manager依然选择使用mysql进行持久化存储，但并不选择从外部注入cm key，而是在第一次启动的时候随机生成一对公 私钥来加密mysql数据库，并使用sealing技术进行加密存储。当capsule manager意外停止再次重启时，capsule manager去检查是否已存在sealing封装的密钥，若存在则使用该密钥对数据库进行加解密。这样是不是可以保证单点部署时使用mysql持久化的安全？在这里使用sealing技术保证了capsule manager在第一次启动时随机化生成的公私钥仅能被他自己获得，管理员即使可以访问数据库也无法解密数据。

这个问题可能需要有些背景补充。首先，TEE的CVM，也就是机密虚拟机是大的趋势，它的好处是使得TEE中的应用更加易于开发，也能运行的更稳定。然而遗憾的是目前的CVM（例如intel TDX）并不能支持sealing的能力。而我们的应用都会面向CVM模式开发，因此capsule manager就无法完全依赖sealing技术来做持久化存储的加密。

另外，sealing只能保证在同一个芯片的物理机上部署的副本可以加解密持久化的数据，对于跨物理机部署的其他副本，还是会涉及到密钥同步的问题。所以依赖一个中心（AECS）来统一管理应用的公私钥看上去是一个相对更可行的方案。

[oceanqdu]

#

这个问题可能需要有些背景补充。首先，TEE的CVM，也就是机密虚拟机是大的趋势，它的好处是使得TEE中的应用更加易于开发，也能运行的更稳定。然而遗憾的是目前的CVM（例如intel TDX）并不能支持sealing的能力。而我们的应用都会面向CVM模式开发，因此capsule manager就无法完全依赖sealing技术来做持久化存储的加密。

另外，sealing只能保证在同一个芯片的物理机上部署的副本可以加解密持久化的数据，对于跨物理机部署的其他副本，还是会涉及到密钥同步的问题。所以依赖一个中心（AECS）来统一管理应用的公私钥看上去是一个相对更可行的方案。

@zhongtianq 感谢您的耐心解答，现阶段如果想进行安全的持久化必须要借用一个中心化的AECS通过sealing机制来保证密钥安全。 我们现在使用的是海光的CSV来部署的capsule manager，在这种情况下是不是没有办法来安全的进行持久化操作了。

[zhongtianq]

这个问题可能需要有些背景补充。首先，TEE的CVM，也就是机密虚拟机是大的趋势，它的好处是使得TEE中的应用更加易于开发，也能运行的更稳定。然而遗憾的是目前的CVM（例如intel TDX）并不能支持sealing的能力。而我们的应用都会面向CVM模式开发，因此capsule manager就无法完全依赖sealing技术来做持久化存储的加密。 另外，sealing只能保证在同一个芯片的物理机上部署的副本可以加解密持久化的数据，对于跨物理机部署的其他副本，还是会涉及到密钥同步的问题。所以依赖一个中心（AECS）来统一管理应用的公私钥看上去是一个相对更可行的方案。

@zhongtianq 感谢您的耐心解答，现阶段如果想进行安全的持久化必须要借用一个中心化的AECS通过sealing机制来保证密钥安全。 我们现在使用的是海光的CSV来部署的capsule manager，在这种情况下是不是没有办法来安全的进行持久化操作了。

海光CSV是支持sealing的，参见：https://openanolis.cn/sig/Hygon-Arch/doc/865622217613776670

但是我们目前的代码中就没有针对它去写定制化的逻辑了。另外sealing的方式正如前面所说有物理机器的限制，在云上部署的时候可能会存在问题，这一点也需要提前考虑。

[oceanqdu]

海光CSV是支持sealing的，参见：https://openanolis.cn/sig/Hygon-Arch/doc/865622217613776670

但是我们目前的代码中就没有针对它去写定制化的逻辑了。另外sealing的方式正如前面所说有物理机器的限制，在云上部署的时候可能会存在问题，这一点也需要提前考虑。

@zhongtianq 我看文档里写的海光的sealing是支持对不同的csv虚拟机的密钥sealing，可以做到csv之间的密钥隔离，但是对于capsulemanager的情况是不是不太适用，在上述假设情况下，假设capsulemanager和teeapps部署在同一csv虚拟机中，即使将capsulemanager的密钥进行sealing，只要管理员能访问该csv那么也能同样得到密钥，通过询问海光的技术人员他们说只能做到不同CSV虚拟机之间的密钥隔离，这和AECS所使用的sealing机制应该不太一样。 同时还有有关海光csv中度量值使用的问题我新开了一个iusse也希望您能帮忙解答一下。 #30

[zhongtianq]

对，海光的隔离机制是在VM层，我理解这也是它们要推行kata模式的原因之一。

[oceanqdu]

谢谢老师的耐心解答