Sholes signing key leak explained
The Motorola(r) sholes platform uses a trusted bootloader environment. Signatures are stored as part of the CDT stored on the NAND flash. mbmloader verifies the signature on mbm before passing control. mbm verifies all other signatures before allowing the device to boot. There is a vulnerability in the way that Motorola generated the signatures on the sections stored in the CDT. This vulnerability is very simple. Like on the PlayStation 3, Motorola forgot to add a random value to the signature in order to mask the private key. This allowed the private signing keys of firmware for vulnerable phones to be cracked given a signature, public key and data SHA1 checksum.
The keys can be cracked using Mathematica. Read up on how the Elgamal signature scheme works.
TL;DR: k = s - sha1sum(data)
Above formula will yield signing keys on vulnerable phones due to motorola botching their signing keys.
What went wrong?
Signature and public key nonce values were zero which pretty much wiped out the equasion exposing the private key.
Keys
Not placed here due to Motorola legal.
Ok, what does this mean?
Please refer to the following table:
Boot chain component|Status
OMAP secure bootrom|secure
Secure keystore|replaceable (this CG must be signed by motorola's key)
mbmloader|secure, but irrelevant
mbm|secure, but irrelevant, replaceable but unnecessary
recovery|replaceable (signable by anything in keystore)
system|replaceable (signable by anything in keystore)
bootimage|replaceable (signable by anything in keystore)
[/table]I do not plan on doing any more work on this. But all information has been handed over to people who are working on this. Follow the FreeMyMoto people for their progress.
In theory, creating a packed SBF to update keystore and replace recovery should work without bricking your phone. My advice: do not replace mbmloader as that is dangerous. An earlier version of this advisory marked it as replaceable, I have decided to remove this claim as I cannot presently think of a way to do it safely.
Notes to recovery authors
Your recovery must update the signatures on the Codegroup Descriptor Table (CDT). If it does not, your recovery will brick the phone if you attempt to flash a custom ROM.
Notes on similar non-sholes platforms
I do not know if the information in this advisory is related to those phones or not. In general, anyone trying anything with the information in this advisory is doing so at their own risk.
Advisory history
- December 20th, 2010 — Motorola notified of keystore vulnerability. No response received from Motorola.
- February 20th, 2011 — Motorola notified again of keystore vulnerability. No response received from Motorola.
- February 27th, 2011 — Motorola notified that keystore vulnerability will be disclosed to public on March 20th. No response received from Motorola.
- March 20th, 2011 — Keystore signature generation vulnerability publically disclosed including private key leak. Response received from Motorola legal.
