The strongest misconception this part attracts comes from its own feature list. The PIC32MZ1024EFK064 carries the EF generation’s crypto engine — AES, 3DES, SHA-1 and SHA-256, MD5, HMAC — fed by a true random number generator, and clients regularly assume that a flash copy from it will include the cryptographic keys the product uses. Usually it will not, and the reasons are worth spelling out, because they change what a delivered image can and cannot do.
Where The Engine Ends And The Keys Begin
The engine is arithmetic hardware; it consumes keys, it does not store them. Keys live wherever the firmware puts them — compiled constants in the flash array, values written into SRAM at boot from a server or a provisioning tool, or nothing at all, when the product only ever verified signatures rather than decrypting payloads. On most boards the answer is the first: ordinary constants among ordinary data, extractable like any other bytes. On server-provisioned designs, the flash copy reproduces the algorithm but not the per-device secret, and re-hosted units behave correctly only after re-provisioning. The review pass reports which case applies, because the difference decides whether the deliverable is complete or paired with a provisioning step. The copy workflow page documents that finding format.
The K Letter In Context
Across the EF family the letters F, H, M and K mark silicon revisions of one uniform feature set — every EF die already carries the engine and the dual CAN controllers, so K is not an upgrade within EF; it is a stepping. The die itself is EF-standard: microAptiv UC at up to 252 MHz, about 415 DMIPS, seven-stage FPU for single and double precision, 32 KB caches, and 256 KB of SRAM behind a 1 MB program array spanning 0x1D000000 to 0x1D0FFFFF in 16 KB pages. Twin 80 KB boot panels carry startup code and the ECC-guarded configuration words. The family overview keeps EC and EF suffix rules from contaminating each other.
The Copy Workflow
Capture takes the six family regions; verification walks page checksums, structural checks, the ECC-context validation of all four configuration words, and a bench boot. For this part the review adds a key census: every call into the engine is traced to its key source, and the report states plainly whether key material was found in flash, referenced to external provisioning, or absent because the application never encrypted anything. A TRNG complicates none of this — its output is transient by design. The security analysis overview expands on key-location methodology.
One practical consequence deserves emphasis: re-hosted units in a decrypting design will pass every static check and still fail the first authenticated session, which is why the bench stage for this part includes a provisioning dry run wherever the client’s infrastructure allows one.
Verification Without Decryption
A useful number of products never decrypt anything. They sign firmware updates and verify them at boot, or authenticate accessories with challenge-response, and both flows use the engine in its verification direction with no secret that decrypts customer data. The key census classifies these cases explicitly, because they change the answer to the client’s real question: can the recovered image run elsewhere? A verify-only design re-hosts freely, public keys and all. A decrypting design with server-held keys re-hosts only after re-provisioning. Distinguishing the two before delivery sets expectations correctly, and it is one of the few places where the crypto engine’s feature list actually shapes the recovery outcome rather than decorating it.
Protection And Limits
One active-low code-protection word locks ICSP and 4-wire JTAG together once cleared; the only release is the chip erase that takes the image and its constants — including any keys — with it. Ownership verification precedes all work through the contact desk.
Where both flash panels disagree after an interrupted update, the recovery picture changes: the 1024EFM124 page handles that case.