xboxscene.org forums

Author Topic: Efuses  (Read 1053 times)

justaguest

  • Archived User
  • Newbie
  • *
  • Posts: 1
Efuses
« on: April 11, 2006, 02:48:00 PM »

I post here to clarify a few things about efuses and their possible use.

The technology of efuses is not new, they were the basis of old one time programmable rom chips (OTP-ROMs), the predecessors of today's eeproms and flash chips. You could write these chips once once, by burning out bits with the writing voltage. When you were done with the programming, you could burn the write enable fuse and make the otp-rom a true rom. Until the write enable bit was burned you could erase the memory by burning all fuses of an already written address. (either to all zeros or all ones depending on the design) This technology is still in use in pic microcontrollers with one time programmable memory, but slowly gets pushed out by cheap flash based ones. But even some flash based ones have a write disable bit in their configuration range, that allows full write or even external read protection. The technology is good enough to be used as memory but the size of a classical efuse comes from the 20 year old process that was first employed them, so they are quite large compared to today's transistor sizes. The programming is usually done with a serial programming interface and once completed, it can not be undone.

Now for the uses of such circuits. They are used on today's intel cpus to disable certain features, lock clock frequencies and allow higher yields by allowing redundancy in certain circuits. On the normal ibm power cores, they are used to disable broken cache lines and activate the reserved backup lines. They can be used to deactivate certain computing elements too and to allow for a microcode patch. The ibm cell cpu has 8 i/o processors but only 7 of them are active. One is a manufacturing reserve, so if one of the 7 cores blow during manufacturing they can use the reserve one and still sell the cpu as a fully working one.

Another use for efuses is the secure storage of serial numbers and enrcyption keys. Once programmed the only way to read them would be to cut the chip and use an electron microscope to scan them in. This was reportedly done by some eastern european nations during the cold war.

What is needed for a secure cpu? A public/private keypair that is unique for every cpu, and the public part of the manufacturer key so they can issue bulk software. According to the ibm documentation, there is a possiblility that some parts of the cpu cache are never swapped out. The graphic chip reportedly uses this area for communication with the cpu. The so called hypervisor can reside in this memory area too. During the boot process, the cpu reads in a flash chip and decrypts it's contents with it's private key. The chip is encrypted with the cpu's public key, so only the cpu could read it. All normal memory contents that gets swapped out of the cpu's l2 cache into the system memory will also get encrypted with the same key or some faster symmetric block ciper based on the private key. The os that later gets loaded into the system can't decrypt data signed by the manufacturer. For this it has to ask the hypervisor. So the encryption is double, everything in ram is encrypted by the cpu key and every data that is on an inport media is encrypted by the manufacturer key. The os can't break the cpu key since it never sees it and can't break the manufacturer key, because the hypervisor never let's the os touch it. The hypervisor can even check the os and even every data file for consistency and refuse to boot it if it's not signed with the right key.

For secure network communications we need two keypairs. A private/public pair on each side and the other side's public key, so man in the middle attacks can be deteced. For normal public key exchange there is a fingerprint, but it has to be validated on a different channel, this is what certificate providers are for. If the public keys are exchanged during manufacturing there is no need for that. This model also allows device locked downloads, where the content is encrypted with the public cpu key, only allowing the content to be played back on the hardware that has the right key embedded. This technology is already in use by some mobile phone manufacturing companies like sony ericsson, but its usage is currently not enforced by network operators.

In the end, some speculations and some advice. First there is a high chance that the new cell chip, also made by ibm will have a similar strategy, since the hypervisor can allow unsigned content or even a full os (linux) to be run on a system, even along with trusted content. For the xbox360, a good example of this is the possibility of external flash connectivity for the playback of unsigned mp3s.

How can it be turned off? It can't be, but you can do three things:
-get a working singing key (possible for dev boxes only, they have a per box manufacturer key)
-get the release signing key (possible, but almost as hard as getting the same for a credit card system)
-break any of the keys (it's a hard problem!)
-clear out the keys to a known value (not possible electronically since usually there is a write disable fuse, but can be done with concentrated radiation, as already shown for simple sim cards)

The last option is only possible with high tech equipment, present only in some laboratories. But they can even copy the whole chip and make a flash based version of it. (so you can swap keys, like you can do with ethernet mac addresses)

The third option is possible with enough computing power, but it's currently unknown how much.

Thanks for reading this.
Logged

Morninglight

  • Archived User
  • Newbie
  • *
  • Posts: 49
Efuses
« Reply #1 on: April 14, 2006, 05:52:00 AM »

Nice first post m8  cool.gif
Logged

cr4ck3rj4ck

  • Archived User
  • Full Member
  • *
  • Posts: 126
Efuses
« Reply #2 on: September 25, 2006, 07:19:00 AM »

Bump for an amazingly insightful article.
Logged

mxeDiT10n

  • Archived User
  • Newbie
  • *
  • Posts: 11
Efuses
« Reply #3 on: October 04, 2006, 03:18:00 PM »

There are several more things "we" could do in order to expl0it the $Hype... check out my posts at the thread below:

http://forums.xbox-scene.com/index.php?showtopic=464722

The most important thing we need to begin investigating is the flow of information between LPARs & their resources ((i.e. bandwidth, memory, disk space, and disk response times)... Determine the inefficiencies within this management & we can begin to "unbalance" things in our favor.

Anything can be unbalanced.  (IMG:style_emoticons/default/cool.gif)
Logged

openxdkman

  • Archived User
  • Hero Member
  • *
  • Posts: 550
Efuses
« Reply #4 on: October 08, 2006, 10:55:00 AM »

If I understand well, each core encrypts/uncrypts on the fly all data coming in and out...
If encryption is strong, that means cycles are consumed for that "invisible" task, aren't they?

Then... can't we even gain more CPU power by just replacing this secured triple-core with another but unsecured CPU (one with similar pins)?

Logged

openxdkman

  • Archived User
  • Hero Member
  • *
  • Posts: 550
Efuses
« Reply #5 on: October 09, 2006, 10:38:00 PM »

Also, parallelism becomes more and more suspicious...
Two cores won't be able to perform heavy calculation on same set of data (let's say prepared pushbuffers)
They will have to work on separate sets of data (each one encrypted a different way by his dedicated core)

So replacing triple secured cpu with single unsecured cpu won't damage performance much I think.
That will open wide homebrew development that will take advantage of GPU ATI Xenos

All xbox 360 manufactured before mid-2007 (date when new cpus will be manufactured with smaller circuits size in order to reduce overheating - see recent official announcement) will be much less reliable over time, thus, available for heavy customization, including cpu replacement. I think it's an interesting path to study...

This post has been edited by openxdkman: Oct 10 2006, 05:39 AM
Logged

puppetmaster

  • Archived User
  • Newbie
  • *
  • Posts: 1
Efuses
« Reply #6 on: March 02, 2007, 10:42:00 PM »

Assuming the 360 uses the standard ibm9sf efuse ip it is actually possible to read the state of the efuses. It's standard test procedure to read the state of efuses during high temp wafer testing and save the number of blown fuses into registers part of the ip to use as a checksum. The required pins will definetly be bonded out. I've been out of the scene for probably 4 to 5 years, so I don't know how much progress has been made, but it would take a cpu pinout and a lab capable of applying the signals.

I've not sure if this is the proper place to ask, but how certain is everyone that an efuse is actually preventing the kernel from being downgraded? If the efuse actually did get blown, how is the cpu logic determining the kernel is below a certain version?
Logged

torne

  • Archived User
  • Sr. Member
  • *
  • Posts: 383
Efuses
« Reply #7 on: March 13, 2007, 07:46:00 AM »

QUOTE(puppetmaster @ Mar 3 2007, 05:49 AM) View Post

I've not sure if this is the proper place to ask, but how certain is everyone that an efuse is actually preventing the kernel from being downgraded?

Because if you remove R6T7 before upgrading, downgrading works.

QUOTE

If the efuse actually did get blown, how is the cpu logic determining the kernel is below a certain version?

The CPU doesn't: the kernel does. Pre-security-fix kernels will have been built to designate a certain efuse or combination of efuses to mean "don't run this kernel any more" - they check this early during startup and crash if the fuses are gone. The latest kernel will have a different efuse designated as its drop-dead switch, which could be blown by another, future update.
Logged

kalle_19

  • Archived User
  • Newbie
  • *
  • Posts: 36
Efuses
« Reply #8 on: March 17, 2007, 04:26:00 AM »

QUOTE(mxeDiT10n @ Oct 4 2006, 10:18 PM) *

There are several more things "we" could do in order to expl0it the $Hype... check out my posts at the thread below:

http://forums.xbox-scene.com/index.php?showtopic=464722

The most important thing we need to begin investigating is the flow of information between LPARs & their resources ((i.e. bandwidth, memory, disk space, and disk response times)... Determine the inefficiencies within this management & we can begin to "unbalance" things in our favor.

Anything can be unbalanced.  (IMG:style_emoticons/default/cool.gif)


But in this article they talk about being able to switch on or off the eFuses, but according to various xbox guys (xboxhacker) this eFuse can't be reversed...
Logged

caster420

  • Archived User
  • Hero Member
  • *
  • Posts: 938
Efuses
« Reply #9 on: March 18, 2007, 01:32:00 PM »

QUOTE(torne @ Mar 13 2007, 09:53 AM) View Post

Because if you remove R6T7 before upgrading, downgrading works.


Not exactly.  You have the ability to use an older kernel when you remove R6T3 (not R6T7).  However, you can't corrupt the upgrade patch to downgrade (once upgraded to 4552) and since the NAND is married to your system (cpu likely), it isnt currently feasible to flash another kernel to your NAND from another system.  So, unless you have a backup dump of a pre-4552 kernel from your system, you wont be able to downgrade at this point in time.

Caster.
Logged

Methadon

  • Archived User
  • Full Member
  • *
  • Posts: 149
Efuses
« Reply #10 on: March 27, 2007, 01:01:00 PM »

You just helped make me smarter. Wonderfully informative post.
Logged