Trustedflow相关问题

[tarantula-leo]

1. TEEU - TRUSTEDFLOW的迭代过程做了什么，看官网文档介绍是加了授权之类的管控措施，主要工作是在这一块么？
2. 如果数据持有方和TEE方在同一机构时，CapsuleManager及TEEAPP是否可以通过恶意手段获得所需数据，例如在TEEAPP部分，如何保证可信APP是没有恶意的？TEEU中可通过多控制器的模式保证各方执行代码是相同的，作为数据持有方可以保证代码按预期去执行，在Trustedflow内看有授权机制，如允许使用OP_XGB算子，包括使用CapsuleManager进行认证，但是如何保证该算子的执行逻辑是没有恶意的？或者说让数据持有方信任。
3. 后续规划是否会废弃Authmanager、TEEU，使用CapsuleManager+TEEAPP进行替代？

[zhouaihui]

1. TEEU的定位是secretflow的密态设备，适合和其他设备进行混合编程，潜力在于可结合spu+TEE，FL+TEE等混合技术路线。TrustedFlow的定位是纯TEE路线，即所有计算都是在TEE内部发生。TrustedFlow的主要工作是跨域管控，保障数据持有者在数据出域后依然可以决策其使用。
2. 如何让用户信任代码是TEE领域内的核心问题之一，从设计上来讲，数据持有者是需要自己去review代码的安全性。开源本身也是一种手段，通过开放代码，公众可以审核代码是否存在恶意行为。实践中也不限于开源，比如合作方可以定向开放代码互相review，或者寻找可信的第三方来对代码进行背书。
3. 第一个问题解释了TEEU和TrustedFlow定位的差别，所以两者都会存在。后续计划会把TEEU使用的 AuthManager与CapsuleManager合并。

[tarantula-leo]

1. TEEU的定位是secretflow的密态设备，适合和其他设备进行混合编程，潜力在于可结合spu+TEE，FL+TEE等混合技术路线。TrustedFlow的定位是纯TEE路线，即所有计算都是在TEE内部发生。TrustedFlow的主要工作是跨域管控，保障数据持有者在数据出域后依然可以决策其使用。
2. 如何让用户信任代码是TEE领域内的核心问题之一，从设计上来讲，数据持有者是需要自己去review代码的安全性。开源本身也是一种手段，通过开放代码，公众可以审核代码是否存在恶意行为。实践中也不限于开源，比如合作方可以定向开放代码互相review，或者寻找可信的第三方来对代码进行背书。
3. 第一个问题解释了TEEU和TrustedFlow定位的差别，所以两者都会存在。后续计划会把TEEU使用的 AuthManager与CapsuleManager合并。

感谢解答，对于第二点中，Trustedflow数据持有方review或者通过开源的方式是不是只能说明，有可用的可信APP代码，但是如何保证TEE方使用的与其一致呢，有没有相关管控措施？另外这个问题在TEEU中是否不存在

[zhouaihui]

TEE中度量值通常用于表征实际运行的二进制等，TEE厂商一般会提供相应的度量值replay工具，用户可以自行编译源代码得到二进制然后通过工具获得度量值。比如实际得到的度量值与预期的不符合，说明代码可能不一致。
这里面也存在比如确定性编译等挑战，也有研究提出把编译过程嵌入到实际运行过程中。

[tarantula-leo]

TEE这块有实际应用么，其中的安全性有没有比较难去解决的或者说用户体感不好的点？