The inner workings of Secure Boot key and Nvflash

What is Secure Boot Key and how does it work?

I’ve been getting lots of questions about this, so here is some simple background:
The secure boot key is an AES128 encryption key that can used to encrypt various data on the flash memory. It’s a generic nvidia tegra2 thing, that the manufacturer can optionally use to make their device more “secure”.
When the SBK is set, it’s stored in a one-time-programmable “fuse”. This also means that now that the key is out, they can’t change it on already released devices, only new devices.
When the tegra2 starts up, the AES key is available to the hardware AES engine only. E.g. not even the bootloader can read it back! However, the bootloader can *use* the key to encrypt whatever data it wants through the hardware AES engine. And here is the explanation why the blob flashing method actually works! The bootloader checks for the blob in the staging partition and encrypts and flashes it as needed.
Once the bootloader is done, it clear the key from the AES engine which makes it impossible to encrypt or decrypt things from within the OS.

So what happens when it boots into APX/Nvflash mode?

The basic APX mode is stored in the BootROM and hence can never be changed. It appears to accept only a very limited range of commands, and each command needs to be encrypted using the SBK to be accepted. If it receives a command that’s not properly encrypted, it disconnects the USB and appears to be off. This is the dreaded “0×4″ error that people have been getting when attempting to get nvflash working.
It should be noted, that even with the SBK inputted into nvflash, most regular nvflash commands won’t be available. I’m still not entirely sure why (and I can’t rule out it will change).
What *is* available, is the nvflash –create command. What this command does is repartition and format all partitions, set bct and odmdata and send over all  needed partitions to the device (and encrypt them as needed). This means a full recovery is possible, but regular ability to flash e.g. just boot.img or read partitions off of the device is not possible at this point.

So what do we need for nvflash?

In order to get a working (e.g. –create) nvflash, we need a few bits of information as well as some files:

• Secure Boot Key
• BCT file (boot device setup, ram configuration and a bit more)
• ODM data (board-specific bit-field specifying various board settings. *Needs* to be correct
• flash.cfg (e.g. list of settings and names/identifiers of partitions.

On top of these files, we also need all the partitions, e.g. bootloader.bin, boot.img, recovery.img and system.img. Luckily, these partition files are available in official ASUS updates and can be extracted from the blob file using my blob tools :)
The first four peices aren’t readily available, but through lots of effort and a good deal of luck, we have managed to recreate the needed files. Secure Boot Key has already been released (note that this was by far the hardest!) and the rest will most likely follow over the weekend. Keep in mind that we want to keep this legal, so don’t expect us to release any ready-made packs for unbricking! We will however make the recreated files available. Since these are recreated and not actual ASUS files, there should be no problems with them.

source: http://androidroot.mobi/tf-secure-boot-key/