| Invasive attacks for extracting the UID depend on exactly how it's 'implemented in hardware'. It could be a total lie, and hardwired or masked-rom per-revision (but I doubt that, too easy to discover) It could be in a one-time programmable block somewhere that gets provisioned during manufacture - a flash block/eeprom with write-only access (externally at least), or a series of blowable fuses, or even laser/EB-trimmed traces. All of those 1-time prog methods are susceptible to the person operating the programmer to record the codes generated, although managing and exfiltrating that much data would make it rather tricky. The method of storage also influences how hard it is to extract through decapping and probing/inspection. If I had to design something like this (note: not a crypto engineer), I'd have some enclave-internal source of entropy run through some whitening filters, and read from until it meets whatever statistical randomness/entropy checks, at which point it is used to seed & store the UID into internal EEPROM. That way, there's no path in or out for the key material, except when already applied via one of the supported primitives. Then you need to protect your secrets! Couple of layers of active masks (can they do active resistance/path-length measurements instead of just continuity yet? That would annoy the 'bridge & mill' types :)) Encrypted buses, memory, and round-the-houses-routing is also pretty standard for the course, but I'm sure it too could be improved on. IIRC there was someone on HN who was working for a TV smartcard mfgr who was reasonably confident they'd never been breached. Curious what he'd have to say (without an NDA :) ) |
My understanding here is that this Enclave is just a specific part of the overall die, so they're somewhat constricted in the crazy-fabtech methods they might otherwise be able to consider.