Is that stuff legal to post on the forums, though? (The boot 2 disassembly file above)

Since the Boot2 is upgradeable, this means you could change the OS license key, and it appears you don't even need to go that far. The Boot1 is most likely capable (or maybe even some file in the system ) of forcing the boot2 to use a different key when loading the OS. That means two things:

1. If we discover the RSA key to the OS, TI could change it on us with a boot2 v2.5
2. If we can figure out how to force our own key, we could easily install our own OS!

Thoughts?

Well, the scheme is not unique for TI, it's used everywhere: PSP, Wii, XBox360, some phones, etc. The idea is that "recovery menu" is already non-trivial piece of code and so it's not a good idea to store it in ROM. ROM only contains boot1 which checks RSA signature of boot2 and then jumps to it - nothing else. So yes, if the RSA key of boot1 will not be broken TI can easily make it impossible to change anything by upgrading boot2 (this is what Nintendo does with Wii - not very successfully). The problem here is the fact that brute force will not work: you'll need a lot of power (US$100,000 prize was left unclaimed). There are a lot of research in this area and the general consensus says that we'll have some new clever algorythm capable of cracking 1024 bit key in the next 10 years or so (that's why serious cryptographers recommend to start switching to 2048 bit keys), but it's probably not a good idea to wait for it

the problem here is that many of us barly understand any of this.

Does anyone know the hash method used for signing the os/boot2? We could focus efforts on trying to crack the hash,if it is feasible.

So, could we attack boot2 by writing our own code, and appending more data to the end until we find something with the same hash as boot2?

So how hard would it actually be? Would it involve doing 2^256 trials, or is there a faster way?

Is it just me or is everyone here deaf? I'm not talking about cracking a current key, I'm talking about the possibility of the boot2 and boot1 allowing for other keys than the current one.

Sorry, my fault. Finally wrapped the mind around the question: the answer is so obvious to me that I never imagined that it's not obvious to everyone.

Here is the part I missed:

My point was that the Boot2 has another option for what key it uses than the default. The question lies in what accomplishes this change. It can't be the boot1, since it's read-only, and it can't be the boot2, since it is the boot2 whose actions change.

Sorry to disappoint you but there are probably just one key in boot1 and boot2 loaders (unless someone did huge mistake while building them). And the to change it you indeed must change boot1. And indeed it can only be done on factory which build these things.

The message about "Production Keys" is not for end user - it's for service center. If the Nspire does not say these messages then most probably someone took MB from prototype and put it in regular Nspire: service center is not supposed to repair such devices.

WTF? Who will need all this crap? Well, the hardware is not developed in a day, you know. And original TI-Nspire hardware was different from what you can buy today in stores. Take a look. These prototype devices are sold on ebay from time to time (there are couple of them right now) - and since they require different signature they are sold for cheap: you can not install a production OS on them (different key prevents it and even if you'll manage to overcome this limitation it still will not work because hardware is different). I don't know how boot log looks on these devices, but most likely it does not say "Using Production Keys".

Since this approach is pretty typical in hardware development I was sure it was discussed to death already... but now looking back I see that indeed it was never explicitly explained... at least not in this thread.

As for breaking the key...

So how hard would it actually be? Would it involve doing 2^256 trials, or is there a faster way?

Well, the fastest known way involves 2^253.5 trials which still makes it totally impossible. Better to find some other kind of weakness... perhaps something similar to what Nintendo did (they used strncmp to compare sha1sums so the attack become 2^8 trials, not 2^70+ trials).

Umm, calcforth, there are actually 3 keys for all the calc. One verifies the boot2, one verifies the OS for the CAS, one for the nonCAS.

Of course the boot message isn't for end users. We got it through a hookup to the expansion port on the bottom, that we found out happened to have an RS232 serial connection, and it just happened to automatically display boot debugging information through it.

Everyone knows about the CAS+ and the evaluation editions. They don't have anything to do with this, and I don't see why you bothered mentioning them at all.

I was never talking about breaking the key.


@Graphmastur

Yeah, these things are designed to be as collision-free as possible.