undefined | Better HN

0 pointsNullabillity6y ago0 comments

> - Apple’s Secure Enclave processor

That's only referred to as something that is explicitly not supported.

> - Able to test the implementations against each other

Surely they could have done that anyway, since SC implements the CK API. Or they could have disabled the CK backend for all release builds.

0 comments

3 comments · 1 top-level

simonh6y ago· 2 in thread

EDIT: it looks like my reading of this was incorrect. A careful reading of the source I think makes it clear SwiftCrypto avoids any use of the specialist hardware on Apple platform. My apologies for the confusion.

—— original (incorrect) comment

It does not say Secure Enclave is not supported, it says this:

“ a subset of the API is built around using Apple’s Secure Enclave processor to securely store and compute on keying material. Apple’s Secure Enclave processor is not available on non-Apple hardware: as a result, Swift Crypto does not provide these APIs.”

So if secure enclave is available it specifically _is_ used to implement some functionality, but this is implements in other ways on other platforms. However the APIs for secure enclave itself are not exposed in either implementation.

NullabillityOP6y ago

According to your quote, CK has some APIs that depend on the enclave, but SC does not support those APIs.

It says nothing about whether any other SC APIs use the enclave behind the scenes (but I doubt it, there's not much point in bothering with the enclave if the CPU has access to the key material).

jayrhynas6y ago

I think the point he's trying to make is that the CK implementation of the APIs common to CK and SC may (or may not) make use of the secure enclave, and that's one reason to have different implementations.

j / k navigate · click thread line to collapse