Tag: infosec

INSIGHTS | January 13, 2009

Blackhat USA 2009 Poll – Rev Eng Class

By IOActive

During last years Blackhat and Defcon conferences, several individuals asked me about possibly giving classes on the security model of commonly found microcontrollers.  Jeff Moss’ group setup a poll here.  Given today’s Silicon technology has become so small yet so large, it would be best to determine which architecture and which devices everyone is most interested in.  The current poll will determine which brand micro to target (Atmel AVR or Microchip PIC) and after this is decided, we will need more input to narrow the class down to a few devices of the chosen family.

While the classes are not cheap, all participants will learn and understand the chosen targets security model.  Armed with such knowledge will help you to understand and recognize potential risks in future design work allowing you to avoid the possibility of compromise (and I suppose this would also enhance job security :).   Full mosaic blowups of the targets, decapsulated devices, use of a probe station and all users will “modify” the security model of their devices themselves (unless they ask for some help).  I don’t believe such a class has ever been given and seating will be limited per class.

Feel free to comment here but Blackhat really needs the feedback.

Thank you,

-Christopher Tarnovsky

INSIGHTS | February 13, 2008

Atmel CryptoMemory AT88SC153/1608 :: Security Alert

By IOActive

A “backdoor” has been discovered by Flylogic Engineering in the Atmel AT88SC153 and AT88SC1608 CryptoMemory.

Before we get into this more, we want to let you know immediately that this backdoor only involves the AT88SC153/1608 and no other CryptoMemory devices.

The backdoor involves restoring an EEPROM fuse with Ultra-Violet light (UV).  Once the fuse bit has been returned to a ‘1’, all memory contents is permitted to be read or written in the clear (unencrypted).

Normally in order to do so, you need to either authenticate to the device or use a read-once-given “secure code” as explained in the AT88SC153 datasheet and the AT88SC1608 datasheet.

For those of you who are unfamiliar Atmel’s CryptoMemory, they are serial non-volatile memory (EEPROM) that support a clear or secure channel of communications between a host (typically an MCU) and the memory.  What is unique about the CryptoMemory are their capabilities in establishing the secure channel (authenticating to the host, etc).

These device includes:

High-security Memory Including Anti-wiretapping

64-bit Authentication Protocol

Secure Checksum

Configurable Authentication Attempts Counter

These device includes:

  • Multiple Sets of Passwords
  • Specific Passwords for Read and Write
  • Password Attempts Counters
  • Selectable Access Rights by Zone
  • High-security Memory Including Anti-wiretapping
  • 64-bit Authentication Protocol
  • Secure Checksum
  • Configurable Authentication Attempts Counter

Section 5 of the datasheet labled, “Fuses” clearly states, “Once blown, these EEPROM fuses can not be reset.”

This statement is absolutely false.  UV light will erase the fuses back to a ‘1’ state.  Care must be used to not expose the main memory to the UV or else it too will erase itself.

We are not going to explain the details of how to use the UV light to reset the fuse.  We have tried to contact Atmel but have not heard anything back from them.

Reading deeper into the datasheet under Table 5-1, Atmel writes, “When the fuses are all “1”s, read and write are allowed in the entire memory.”

As strange as it reads, they really do mean even if you have setup security rules in the configuration memory, it doesn’t matter.  The fuses override everything and all memory areas are readable in the clear without the need for authentication or encrypted channel!  The attacker can even see what the “Secure Code” is (it is not given out in the public documentation, nor with samples).  Atmel was even kind enough to leave test pads everywhere so various levels of attackers can learn (entry to expert).

Our proof of concept was tested on samples we acquired through Atmel’s website.  Atmel offers samples to anyone however they do not give out the “Secure code” as mentioned above.
  • The secure code of the AT88SC153 samples was “$D_ $F_ $7_”.
  • The secure code of the AT88SC1608 was “$7_ $5_ $5_”.

We are not going to show you the low nibble of the 3 bytes to make sure we don’t give the code out to anyone.  This is enough proof to whoever else knows this code.  That person(s) can clearly see we know their transport code which appears to be common to all samples (e.g. All die on a wafer contain the same secure code until a customer orders parts at which time that customer receives their own secure code.).  A person reading this cannot guess the secure code in because there are 12 bits to exhaustively search out and you only have 8 tries ;).

Of all the other CryptoMemory products, only the AT88SC153/1608 has this backdoor.  We have successfully analyzed the entire CryptoMemory product line and can say that the backdoor doesn’t exist in any other CryptoMemory part.  None of the CryptoMemory parts are actually as “secure” as they make it seem.  The words, “Smoke n’ Mirrors” comes to mind (It is almost always like that).  In this particular category of CryptoMemory, there are two parts, the AT88SC153 and the larger AT88SC1608.

Thus the questions-
    • Why has Atmel only backdoored this part (NSA for you conspiracists)?
    • Who was the original intended customer supposed to be?
    • Was the original intention of these devices to be used in a product that used some kind of cryptography?

If the above was true, was this device originally intended to be a cryptographic key-vault?

All these questions come to mind because the backdoor makes it so easy to extract the contents of the device they want you to trust.  Some of you may be familiar with the GSM A5/1 algorithm having certain bits of the key set to a fixed value.

Judging by the wording of the documentation, Atmel gives the appearance that CryptoMemory are the perfect choice for holding your most valuable secrets.

Give us your thoughts…

INSIGHTS | January 22, 2008

Security Mechanism of PIC16C558,620,621,622

By IOActive

Last month we talked about the structure of an AND-gate layed out in Silicon CMOS.  Now, we present to you how this AND gate has been used in Microchip PICs such as PIC16C558, PIC16C620, PIC16C621, PIC16C622, and a variety of others.

If you wish to determine if this article relates to a particular PIC you may be in possession of, you can take an windowed OTP part (/JW) and set the lock-bits.  If after 10 minutes in UV, it still says it’s locked, this article applies to your PIC.

IF THE PART REMAINS LOCKED, IT CANNOT BE UNLOCKED SO TEST AT YOUR OWN RISK.

The picture above is the die of the PIC16C558 magnified 100x.  The PIC16C620-622 look pretty much the same.  If there are letters after the final number, the die will be most likely, “shrunk” (e.g. PIC16C622 vs PIC16C622A).

Our area of concern is highlighted above along with a zoom of the area.

When magnified 500x, things become clear.  Notice the top metal (M2) is covering our DUAL 2-Input AND gate in the red box above.We previously showed you one half of the above area.  Now you can see that there is a pair of 2-input AND gates.  This was done to offer two security lock-bits for memory regions (read the datasheet on special features of the CPU).Stripping off that top metal (M2) now clearly shows us the bussing from two different areas to keep the part secure.  Microchip went the extra step of covering the floating gate of the main easilly discoverable fuses with metal to prevent UV from erasing a locked state.  The outputs of those two fuses also feed into logic on the left side of the picture to tell you that the part is locked during a device readback of the configuration fuses.

This type of fuse is protected by multiple set fuses of which only some are UV-erasable.

The AND gates are ensuring all fuses are erased to a ‘1’ to “unlock” the device.

What does this mean to an attacker?  It means, go after the inal AND gate if you want to forcefully unlock the CPU.  The outputs of the final AND gate stage run underneather VDD!! (The big mistake Microchip made).  Two shots witha laser-cutter and we can short the output stages “Y” from the AND-gate to a logic ‘1’ allowing readback of the memories (the part will still say it is locked).Stripping off the lower metal layer (M1) reveils the Poly-silicon layer.

What have we learned from all this?

    • A lot of time and effort went into the design of this series of security mechanisms.
    • These are the most secure Microchip PICs of ALL currently available.  The latest ~350-400nm 3-4 metal layer PICs are less secure than the
    • Anything made by human can be torn down by human!

:->

INSIGHTS | December 29, 2007

AND Gates in logic

By IOActive

As we prepare for the New Year, we wanted to leave you with a piece of logic taken out of an older PIC16C series microcontroller. We want you to guess which micro(s) this gate (well the pair of them) would be found in. After the New Year, we’ll right up on the actual micro(s) and give the answer :).

An AND gate in logic is basically a high (logic ‘1’) on all inputs to the gate. For our example, we’re discussing the 2 input AND. It should be noted that this is being built from a NAND and that a NAND would require 2 less gates than an AND.

The truth table is all inputs must be a ‘1’ to get a ‘1’ on the output (Y). If any input is a ‘0’, Y = ‘0’.

There are 2 signals we labeled ‘A’ and ‘B’ routed in the Poly layer of the substrate (under all the metal). This particular circuit is not on the top of the device and had another metal layer above it (Metal 2 or M2). So technically, you are seeing Metal 1 (M1) and lower (Poly, Diffusion).

It’s quickly obvious that this is an AND gate but it could also be a NAND by removing the INVERTER and taking the ‘!Y’ signal instead of ‘Y’.

The red box to the left is the NAND leaving the red box to the right being the inverter creating our AND gate.

The upper green area are PFET’s with the lower green area being NFET’s.

After stripping off M1, we now can clearly see the Poly layer and begin to recognize the circuit.

This is a short article and we will follow up after the New Year begins. This is a single AND gate but was part of a pair. From the pair, this was the right side. We call them a pair because they work together to provide the security feature on some of the PIC16C’s we’re asking you to guess which ones 🙂

Happy Holidays and Happy Guessing!

INSIGHTS | November 3, 2007

Safenet iKey 1000 In-depth Look Inside

By IOActive
We received a lot of  attention from our previous article regarding the  iKey 2032. We  present to you a teardown of a lesser, weaker Safenet, Inc. iKey 1000 series USB token.

We had two purple iKey 1000 tokens on hand that we took apart-Cypress 24 pin CY7C63001/101 type USB controller is a likely candidate underneath the epoxy above

 

Cypress’ USB controllers run from a 6 Mhz oscillator and an 8 pin SOIC EEPROM might be beneath this smaller epoxy area

 

Once we took our initial images of the two sides, it was time to remove whatever was under the epoxy.

 

If needed, we can clean off the remaining epoxy

 

There was indeed a serial EEPROM underneath the bottom side.  Removing took some heat and we lost the cover to our oscillator during the process.

 

Opening the device revealed exactly what we suspected (we could sort-of tell by the 24 pin SOIC) being familiar with the Cypress family of processors. We discovered a Cypress CY7C63101.

 

The red pin denotes pin 1 of this Cypress CY7C63101

 

A 200x magnification photo of the die above shows a 20 pin version of the CPU used in the iKey1000 token.

 

The Cypress CY7C63 family of USB microcontrollers have serious security issues.  This family of  processors should not be used by anyone expecting their security token to be secure. Unfortunately, we’ve seen a lot of dongles using this family of CPU’s.

 

We successfully read out the CPU (using our magic wand again). Poking around the code looking for  ASCII text we found the USB identifier string at address offset $0B7: “i.-.K.e.y”

 

The code contained inside the Cypress CPU is always static between iKey1000 tokens.  The Cypress CPU is a One-Time Programmable (OTP) type device.  There is no non-volatile type memory inside except for the EPROM you may program once (hence OTP).  The only changes possible are within the external EEPROM which is a dynamic element to the token.  The EEPROM turned out to be a commonly found 24LC64 8K byte EEPROM.

 

Given the above, we can then assume that the iKey1032 is identical to this token with the except of replacing the 24LC64 with a larger 24LC256 32K byte EEPROM.  This is a logical assumption supported by Safenet’s brochure on the token.
Are you securing your laptop with this token?  We are not…
INSIGHTS |

In retrospect – A quick peek at the Intel 80286

By IOActive

We thought we would mix the blog up a little and take you back in time.  To a time when the fastest PC’s ran at a mere 12 Mhz.  The time was 1982.  Some of us were busy trying to beat Zork or one of the Ultima series role-playing games.  You were lucky to have a color monitor on your PC back then.

We happen to have a 1982 era Siemens 80286

If anyone is interested in donating any old devices such as an i4004 or i8008, please email us.
INSIGHTS | October 30, 2007

Safenet iKey 2032 In-depth Look Inside

By IOActive

Chances are you have probably seen one of these little USB based tokens made from  Safenet, Inc.

The one we opened was in a blue shell.

 

Safekey says, iKey 2032 is a compact, two-factor authentication token that provides client security for network authentication, e-mail encryption, and digital signing applications.”

As well, the brochure the link above takes you too states,  iKey 2032s small size and rugged, tamper resistant construction, make it easy to carry so users can always have their unique digital entities with them.”

Now we’re not really sure what tamper resistant construction has to do with making things easy for a user to carry around  but let’s get down to the good stuff.

 

We carefully decapsulated the epoxy covering the die buried inside the 24 pin SOIC part.  What did we find?  We found a Cypress CY7C63613!  We suspected it might be this part because of the pinout.   This is why scratching off the top of the part does not always help.  Even with the silkscreen scratched away, there are only a few possible candidates using this pinout.   Additionally, this CPU is very common used in  USB  applications.

 

Once the CPU was decapsulated, we performed some tests on the device.   After executing some tricks, the software contained internally was magically in our hands.

 

We looked for some type of copyright information in the software but all we found was the USB identifier string at address offset $3C0: i.K.e.y. .2.0.3.2

 

Now that we successfully analyzed the CPU, the protocol for communications to whatever is present under the epoxy is available to us.   At this point, we believe it’s more than a serial EEPROM because this CPU is not strong enough to calculate  asymmetric cryptographic algorithms in a timely manner.

 

Next we carefully removed the die-bonded substrate from the PCB:

 

With the die-bonded device removed and a little cleanup, we can clearly see the bondout pattern for a die-bonded smartcard IC. We can see VCC, RST, CLK, IO, and GND layed out according to the ISO-7816 standard which Flylogic Engineering are experts on.

 

After completely decapsulating the smartcard processor, we found a quite common Philips smartcard IC.   We will call this part from now on the Crypto-Coprocessor (CCP).

 

The CCP fits into place on the PCB.   It is glued down and then five aluminum wires were wedge-bonded to the PCB.   Aluminum wedge-bonding was used so the PCB would not need to be heated which would help them cut down the time required on the assembly line.

 

In preparation for analysis, we had to rebond the  CCP into a 24-pin ceramic dip (CDIP). Although we only needed five contacts rebonded, the die-size was too large to fit into the cavity of an 8-pin CDIP.

 

The CCP is fabricated by Philips.  It appears to be a  ~250nm, five metal layer technology based on the Intel 8051 platform.  It contains 32k of EEPROM, two static ram areas and a ROM nested underneath a mesh made up of someone(s) initials (probably the layout designers).

 

This CPU (The CCP is also a CPU but acting as a slave to the Cypress CPU)  is not secure.   In fact, this CPU is also all over the globe in GSM SIM cards. The only difference is the code contained inside the processor.

 

Some points of interest:

 

Point #1-  The ‘mesh’ protecting probing from the ROM’s databus outputs is NOT SECURE!
Point #2- A quick search on the internet and we came across a public document from when Philips tried to get this part or a part very close to this one common criteria certified. The document labels this assumed to-be part as a, “Philips P8WE5033V0F Secure 8-bit Smart Card Controller.“

 

Reading over this document, we find a block diagram on page 8.

 

“Security Sensors” as a block of logic.  That’s ironic considering we opened a gaping hole in their “mesh” over the ROM and the processor still runs 100% functional.

 

Point #3-  For such a “secure” device, Philips could have done a lot more.  The designer’s were pretty careless in a lot of areas.  Simply reconnecting the two tracks together will definately be helpful to an attacker.   A Focused Ion-Beam Workstation can make bond-pads for those two tracks that we can then bond out to the CDIP.  This way  we can short or open this test-circuit.

 

Now ask yourself if you are a potential customer to Safenet, Inc   Would you purchase this token?
INSIGHTS | October 26, 2007

Decapsulated devices

By IOActive
Recently at Toorcon9 (www.toorcon.org), some individuals asked to see images of decapsulated parts still in their packages. I dug around and came up with some examples. Click on any of the pictures for a larger version.

 

 

Above: Dallas DS89C450

 

 

Above: Microchip dsPIC30F6013

Using our proprietary procedures, all parts remain 100% functional with no degradation after exposing the substrate.