I should have written "dual Secure Enclave cores." I had wondered the same thing about it being paired to PHY when I was studying the M1 back in November. I came to the conclusion that the SSD and camera are coupled to the Secure Enclave and require high speed PHY anyway, so it makes sense to lay them out right next to each other.
Anyway, you might ask, "why dual core?" And my answer would have been for you to have a look at the M1 sample report from
systemplus.fr. However, it seems that they were just absorbed into another company-- and by "just," I mean that when I posted above (yesterday), their website still existed and the sample report was available. That no longer appears to be the case, so here are some relevant images I extracted from the M1 sample report:
But those images from the former systemplus.fr don't address my question: why are we even thinking there are two cores? They just assert there are two, based on... well, I don't know what they're basing it on. Apple's own documentation on the Secure Enclave and its capabilities makes no mention of two cores:
Secure Enclave is a dedicated secure subsystem in the latest versions of iPad, iPhone, Mac, Apple TV, Apple Vision Pro, Apple Watch, and HomePod.
support.apple.com
The blocks that these people have tagged as Secure Enclave in these images also don't look like a Secure Enclave to me. How would some random guy know what it looks like? I don't, but I do know what it
shouldn't look like, and in this case it's "anything as large as those blocks". The SE, including its CPU, should be tiny. There's no need for speed here. Even the M1's E cores qualify as fast, huge, and hot relative to the minimalistic microcontroller-class "ASC" cores used in the SEP and several other Apple Silicon subsystems.
Why small? Security engineers and analysts often talk about "attack surface", a concept referring to how much 'surface area' of the hardware or software is subject to potential attacks. One of the very best known ways to simultaneously minimize attack surface and make the design highly auditable / verifiable by formal methods is to keep it incredibly minimalistic. The Secure Enclave isn't designed for speed, it exists to be a hopefully impenetrable keeper of secrets.
So while I could be wrong about this, I don't think the Secure Enclave is a block big enough to easily pick out in these pictures.
Along those lines... the Apple doc I linked mentions that SSD encryption/decryption is performed by an AES engine
outside the Secure Enclave. There is a secured path for the SE to feed the AES engine key data, designed to make leaking that key to software impossible, but the SE itself is not in the datapath. (Reinforcing the point that the SE is a keeper of secrets, not a doer of work.)
You might then say "well those blocks must be the AES engines", but here again we have a case where the docs only mention one engine. There's only one internal SSD, no need for two. Also, here is where I get to bring actual personal experience to bear: I've implemented cryptographic blocks before and I wouldn't expect an AES256 engine to be anywhere near that big and complicated.