We have noticed a few different die revisions on various Microchip’s substrates that caught our attention. In most case when a company executes any type of change to the die, they change the nomenclature slightly. An example is the elder PIC16C622. After some changes, the later part was named the PIC16C622A and there was major silicon layout changes to the newer ‘A’ part. The PIC16C54 has been through three known silicon revs (‘A’ – ‘C’) and has now been replaced by the PIC16F54.
However, we’ve noticed two different devices from them (PIC12F683 and PIC18F1320) that caught our eye. The PIC12F683 changes seem purely security related concerns. The code protection output track was rerouted.
Our guess- They were concerned the magic track was too easilly accessable.
We will focus this article to the PIC18F1320 and consider this as a follow-up to our friends at Bunnie Studios, LLC. A few years ago Bunnie wrote an article about being able to reset the fuses of the PIC18F1320 to a ’1′ thus unlocking the once protected PIC.
Above:Â The original PIC18F1320 without extra CMP fill.
Above:Â The newly improvised second generation PIC18F1320 with fill patterns place over open areas.
You might ask yourself: What are they hiding? We’ll show you-
Above: This is a 500 magnification view of four fuse cells. The part contains three metal layers however, the top layer has been partially removed by wet-etching techniques. This allows us to see below in denser areas.
Above:Â The newly improvised second generation PIC18F1320 now has these cells covered aka Bunnie attack prevention!
Conclusion: Did they archieve their goal? From an optical attack, sort-of. They are not expecting the attacker to be able to selectively remove this covering metal. Stay tuned for part II of this report where we show you this area with the covering metal removed and the fuses exposed once again!
[...] very much enjoy the postings at Flylogic. They’ve actually got a very nice piece up on the PIC18F1320 which reveals new findings about a device that I have some prior familiarity with. I’m [...]
[...] See below a picture of the second generation PIC18F1320 die (same one you saw in Part I)- [...]
Amazing view covering Unmarked Die Revisions :: Part I! I enjoy your point of view.
whaooo you are the wizard. Very cool and impressive website. The best of all.
So far, I didn’t see much more information and results compared to well-known book on attack technologies published back to 2004 as here:
http://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-630.pdf
Not meaning to discredit Mr. Skorobogatov, we will address one issue about his document. Overall, it’s a very good paper for many.
Page 23, Figure 9 states-
“Figure 9. Hardware bus encryption module in Infineon
“SLE66 family smartcard chip [27] preserves EEPROM
data from being microprobed. 100× magnification”
This is an incorrect statement. I’m sure there are some Crypto guys out here who can make sense out of what I’m about to say:
Any data that is to be decrypted or encrypted in any memory on the SLE66 series processor is done so before ever leaving the main area of the CPU block. This means that in theory only the CPU or ALU (depending if it’s code or data being fetched) get to see the clear (plaintext) values. The main core consists of the CPU, MMU, and the Crypto block for bus security. A value encrypted is stored in that state and is never decrypted until it is read back by the CPU. This value can be code or data.
Data in the XRAM is also encrypted so where’s the logic block for that area because their drivers connect directly to the general bus they claim was layed out with a “Security optimised layout and layout scrambling“. There is only one cryptographic block called the “MED” (for bus encryption) present in the logic and it’s for both encryption and decryption of writes and reads from various memories (EEPROM, ROM, XRAM).
The area highlighted in a black box in that picture is the address decoder logic, high voltage control for erasure, write control, OTP control and so forth.
We’ve torn this device down to nothing and consider all SLE66′s ‘OWNED’. Yes, even the SLE66P with active mesh has succumbed to our needles
. We know everything we need to know about every area of the device.
one day you’ll get slash-dotted and then you’ll exceed your bandwidth – what will you do then? Happy Happy holidays!
[...] did Atmel cover the floating gate of the upper fuse with a plate of metal (remember the microchip article with the plates of the floating [...]
This is /excellent/ work. Every time someone asks me “why doesn’t DRM work?”, I end up concluding that .90 and .45 nm silicon is fairly secure, because “How many crackers can there be that have runtime on a scanning electron microscope?”. Now I have to re-write my spiel.
You’re proof that – combined with the increasing availability of used semiconductor research equipment for pennies on the dollar – even crypto in the silicon isn’t secure and that mandatory IP-holder-enforced key revocation schemes will just leave consumers of these devices holding pretty paperweights once someone sniffs the right key and releases it.
Thanks for the comments everyone! People have asked us if we really believe the CMP-filler was placed there for security purposes.
We do belive some of the filler was done for production reasons but we also believe they purposely covered the fuses and SRAM area for security concerns.
We’ve seen FLASH and EEPROM sells get covered by CMP-filler on other devices so why did they cover SRAM and FUSES but leave the large FLASH area as a “pit of glass” ????
Shouldn’t the flash have been covered too by some kind of a CMP-filler pattern?
We believe so. Think about it, the flash area isn’t considered a threat to Microchip. Leaving the flash uncovered means the worse case is UV erases the contents of the flash while the fuses have been covered rendering the part locked with a flash contents of FF’s if left long enough (5-15 mins).
:->
Can’t we magnify PC components from within PCs yet? So we could display the whole micro architecture on screen? Is it possible to aquire a piece of hardware that sends a pulse and you get a bounce back impression image? The PC basically magnifies itself. You could repair microscopic hardware components. The PC could do it itself!
To admin.
I did reverse engineering of MED algo for sle66322P. The algo is the Fejstell network with 4 iterations. But this algo does not match with algo of sle66xxx MED (earlier serie of sle66). I have not anough statistics to crack a sle66xxx algo, I have couple of encrypted dumps for chip only, but this dumps tell me that algo for sle66xxx is mush simpler and consist of 2 iterations only. Am I right in this point (i.e that earlier version of MED algo has 2 Fejstell network iterations only) ?
Sorry, you couldn’t have a PC fix itself that way because it is solid state. Now, if it was a liquid in a jar…
Could you please tell me how large the 8kB flash is in this device? Or as an alternative, could you please tell me how large 1k and 2k flash memories are in 5V and 3.3V microcontrollers?
Your assistance would be much appreciated.