你好。
我想了解 KW47 平台上 ELEMU(EdgeLock 消息单元驱动程序)和 LTC(LP 可信加密)在使用上的区别。
我目前的理解如下:
ELEMU
・通过请求专用网络安全核心来执行加密操作,由于密钥可以存储在隔离的安全环境中,因此具有很强的防篡改能力。
・由于需要与安全核心进行通信,因此可能不适合对延迟要求非常严格的应用程序。
・它支持 LTC 提供的所有加密算法,并且还支持 LTC 无法处理的算法,例如 ECDH。
・还可以利用安全启动集成等安全相关服务。
因此,我的理解是,ELEMU 更适合需要高安全性的加密操作。
长期护理
・通过直接控制 LTC 硬件加速器寄存器来执行加密操作,从而实现极低的开销和高性能。
・支持的算法仅限于硬件加速函数,例如 AES、DES、HASH 等。
・钥匙无法存放在安全的隔离环境中,因此其防篡改能力低于安全核心所提供的防篡改能力。
因此,我的理解是,LTC 更适合对延迟敏感的处理或涉及临时密钥(如会话密钥)的使用场景。
如果上述理解正确,那么是否可以说 LTC 相对于 ELEMU 的主要优势在于性能/延迟,并且如果能够满足时间要求,那么 LTC 可以完成的所有事情也可以通过 ELEMU 完成?
或者,是否存在某些功能限制、支持的算法、硬件访问限制或其他因素,使得 LTC 在某些情况下成为首选或必需的选择?
感谢您事先的指导。
你好,
希望你一切都好。
ELE 消息单元 (ELE_MU) 是应用核心与 EdgeLock Enclave (ELE) 安全核心之间的通信机制。通过此接口,主机处理器可以向 ELE 请求加密和安全相关的服务。除了加密操作外,ELE 还提供安全的密钥管理功能,包括密钥生成、导入/导出、安全密钥存储以及为非易失性存储生成加密密钥块。
更多详细信息请参阅KW47 网络安全参考手册第 9 章。
LTC(LP 可信加密)驱动程序提供对 KW47 硬件加密加速器的直接访问。这条路径提供了更低的软件开销,因为应用程序直接与硬件加速器 API 交互,而不是像 ELE_MU 那样通过安全核心进行通信。LTC 硬件支持加速 AES、DES、HASH 和 PKHA 等算法。(参见KW47 API参考手册)
所以你的理解总体上是正确的,最终取决于你的具体实施需求。如果低延迟和最小的软件开销是您的主要目标,那么 LTC 将是首选方案。但如果网络安全边界和密钥生命周期管理是重要的考虑因素,那么 ELE_MU 通常是更好的选择。
此致,
索菲亚。
嗨,索菲亚,
感谢你的回复。
很高兴得知我的理解总体上是正确的。
关于 LTC 和 ELE_MU 之间的延迟差异,我还有一个问题。
我理解实际性能差异取决于所使用的加密算法、与安全核心的交互次数以及正在处理的数据大小等因素。由于我无法提供具体用例的详细条件,因此,即使只是一个粗略的指导原则或对预期延迟差异的一般性描述,我也希望得到。
例如,与网络安全核心通信的开销是否通常比实际的加密处理时间大得多,从而导致延迟比 LTC 高出几倍甚至几十倍?
或者,在大多数实际应用场景中,加密处理时间本身是否会占据整个执行时间的大部分,使得 ELE_MU 引入的额外开销相对于总处理时间的百分比而言较小?
即使是高层次的指导原则或定性比较,对于了解 ELE_MU 何时会对性能产生显著影响也十分有帮助。
感谢您事先的指导。
你好,
对于由此造成的不便,我深表歉意。目前尚无任何文档提供对 ELE_MU 和 LTC 之间延迟差异的比较或定性指导。
虽然 ELE 加密引擎针对安全执行而非速度进行了优化,但对于具体的性能指标,建议在特定目标条件下对 KW47 硬件进行直接测量。
关于 KW47 上的 ELE 功能或加密操作,最相关的指导可在 KW47 安全参考手册中找到。
此致,
安娜·索菲亚。
你好,索菲亚,
感谢您的回复。
我知道目前没有可用的文档来比较 ELE_MU 和 LTC 的延迟,也没有定性地描述它们的延迟特性。
在这种情况下,我将在实际的 KW47 硬件上评估性能,并直接测量延迟,以便更好地了解两种实现方式之间的差异。
再次感谢您的帮助。
此致,