Public key crypto
"So you're saying that they would rather ship the kernel with a cryptographic key in the firmware and then rely on no-one ever managing to acquire it by, for example, subverting the supplied software or more involved hardware hacks."
Public key crypto doesn't work like that. You create a keypair e.g. A and A' which are mathematically related but from which it is difficult to derive A from A' or vice versa. You sign the binary with A and put A' into the firmware updater that verifies that the firmware is correct and valid before flashing it.
"There's a long history of products where such manufacturer measures have failed - it's like the Sheriff of Nottingham asking Robin Hood to look after his treasure chest while he goes on holiday, secure in the knowledge that the padlock is the best in the land."
Of course there is a history of failed products. That doesn't mean that all products have failed to protect themselves, or shouldn't take all appropriate measures to safeguard their integrity.
I've worked on set top boxes and from memory, these are some of the safeguards that got used:
1. Multi stage bootloaders. Stage 1 is baked into a ROM and validates second stage bootloader / firmware.
2. Signed firmware, to prevent tampering. Box won't flash firmware which is unsigned.
3. No serial port on board - pins are snipped or there is no circuit at all.
4. Strong root password, a long e.g, 30+ chars random password. So even if someone got access to the serial there is no login.
5. Port knocking. In the case of emergency you might need ssh access to a box so you protect it with a port knocker so ssh only comes up with the right sequence of port knocks.
6. ssh only accessible by blessed public / private key pair, not the same one used to sign the ROM. No key, no login.
7. /tmpfs runs from a RAM disk
8. All flash is encrypted at the hardware level
9. All flash partitions are read only
10. Flash cannot be partitioned without root access
11. No critical data of any kind is stored on USB, HDD etc.
12. Chipset stores IP tokens (that enable h264, VC1, dolby etc.) in special non volatile flash memory
13. Hardware assisted crypto for streaming content.
14. No listening ports of any kind if the device, or if they exist they only accept cryptographically signed commands.
15. Unique hardware identifiers and keys per box using during encryption so streaming data is not vulnerable to a class break.
16. Two way encryption on all streaming content, i.e. box would seek authorisation and obtain a key to decrypt content. If box was compromised, then it wouldn't be getting its key.
So hardware and software security all over the place. It doesn't preclude the possibility of bugs of course, or of some malicious employee revealing a key. But generally the purpose is to make it extremely hard and fruitless to hack the device.
Where does GPLv3 fit in all this? It doesn't. It would never get used or it would be worked around in some other way.
Biting the hand that feeds IT
