notes
Hopefully this doesn't lead to any red herrings. I haven't been looking at this stuff very long.
"arm.com" has some info on the processor.
TI licensed the processor design from ARM. It's an ASIC, not really a cpu chip.
You have to agree to a non-disclosure to see the docs on arm.com.
After reading about it, not sure that the dual cpu is actually getting used like folks think. There may be two systems actually running.
The arm docs hint that it may be the hash key that actually gets stored on the asic not a private key and that there may be more than one. TI may have designed in their own protocol which is the M-Shield trademark.
TI doesn't exactly give out much info on it. The ARM site is a lot more informative. It doesn't cost anything to access it other than giving away your email address and agreeing to the nondisclosure.
In particular look for these documents:
DDI0406C_arm_architecture_reference_manual.pdf
DEN0013B_cortex_a_series_PG.pdf (chapter 26)
PRD29-GENC-009492C_trustzone_security_whitepaper.pdf
You can also review the source code for the tablet.
See the following exerpts:
distro\x-loader\lib\board.c
image.image = 2;
image.val = 99;
SEC_ENTRY_Std_Ppa_Call ( PPA_SERV_HAL_BN_CHK , 1 , &image );
if ( image.val == 0 )
{
/* go run U-Boot and never return */
printf("Starting OS Bootloader from %s ...\n", boot_dev_name);
((init_fnc_t *)CFG_LOADADDR)();
}
distro\u-boot\common\cmd_bootm.c
function do_bootm
...
U32 SEC_ENTRY_Std_Ppa_Call (U32 appl_id, U32 inNbArg, ...);
\x-loader\board\omap4430sdp\omap4430sdp.c
...
There are several calls to the SEC_ENTRY_Std_Ppa_Call function.
One (or two) for each image block being loaded.
I think these are the calls to the security layer..
SEC_ENTRY_Std_Ppa_Call ( PPA_SERV_HAL_BN_CHK ,...
They took the crc32 validation out in various places in the code. I suspect that if it is a signed key that if the image doesn't process out to the end key, then the crc2 would have failed anyway.
Has anyone actually checked what the "key" is? Could it be a crc or checksum?
The "_BN_" I assume is for barnes and noble.
Looking at "omap4_hs.h", it looks like that function can do a callback into the secure area and execute up to 32 different functions, though I'm guessing from the list in the file that BN only added two - INIT and CHK.
There is also a reference in that file to "Development CEK". Could this be the private key? Not the hash, just one part of the key? I'm by no means up on crypto algorithms.
/*
Defines from MShield-DK 1.2.0 api_ppa_ref.h
Make sure these align with the existing services in PPA.
*/
// Number of APIs
#define NB_MAX_API_HAL 32
// command / api keys
PPA_SERV_HAL_CPAUTOLOAD
PPA_SERV_HAL_CPINIT
PPA_SERV_HAL_CPSWRV
PPA_SERV_HAL_CPMSV
PPA_SERV_HAL_CPREPORT
PPA_SERV_HAL_CPCEK
PPA_SERV_HAL_TEST_API
PPA_SERV_HAL_BN_INIT
PPA_SERV_HAL_BN_CHK
/* Development CEK */
#define CEK_3 0x01234567 //127_96
#define CEK_2 0x89ABCDEF // 95_64
#define CEK_1 0x11121314 // 63_32
#define CEK_0 0x15161718 // 31_0
Another question I have, what level of GPL does android use?
The simple fact that they linked in the M-Shield function calls may be enough to force the release of that source as well. The latest GPL has a pretty nasty copy left. It may be in that archive already too. I haven't gotten through much of it yet.
And is it true that this tablet has a different wifi chip and thus doesn't have the fm and bluetooth available to it?
The brute force idea might work except that you'd have to do it on a nook tablet. You have to validate a data block using that function call.
Figuring out how to automate it through that security layer might be a bit troublesome. If you could call that function directly, maybe, but I suspect that it is only accessible from one side of the architecture. But that might also be why the tablet has so much memory dedicated to B&N and not split evenly. Maybe the bigger chunk of the memory is all in the secure side?
I have to say the OMAP4 is a pretty neat layout. Has a huge potential for corporate ethical abuse but technically it really is cool. They are going through a lot of hoops to keep this tablet locked down. I found one whitepaper on the netflix issue. Netflix apparently has a whole massive requirements list and this was the first tablet to meet it. I'm not sure netflix isn't overvaluing their product. There are other ways they could have done this versus locking the whole tablet down. They could have put the netflix app as a service in the secure side and just signed that part of the application. They could have still allowed the secondary bootloader in the unsecure area to be whatever the user wanted. I don't think they thought through the ethical notions of it all. But maybe they did and they just want to control something like apple is doing. Apple was defeated once by a lower cost, open architecture. History will repeat itself. It's a shame B&N's didn't go that route instead. If it wasn't for this one issue, they would have had a much better platform to work from than the fire.
