Are Your Devices Hardwired for Betrayal?
eff.org
eff.org
IoT is both wonderful and scarily dystopian.
I'd like my eeproms on those devices to have their write enable pins snipped, I'd like to know when someone attempts to reprogram it. I'd also like hashes of my firmware compared globally so I knew my firmware isn't special. Fuck serial numbers. Root yourself before you are rooted. Backdoor yourself so their firmware hacks fail. I have > 10 mems microphones within 20 feet of me. So probably do you. How many gates does http://opus-codec.org/ require? 600GB stores 5 years of continuous audio @ 32kbits. Serial EEPROMS already in your devices can store 10s of hours of audio, recording while suspended, while _off_. Nothing is ever off anymore. Instant on, soft switches, privacy traded so we don't have to watch dmesg.
http://www.mouser.com/ProductDetail/Spansion/S25FL512SAGMFI0...
I'd like all sensors to have an on-off switch that I control. I'd like phone to turn off when I tell it to, not just sleep. I'd like my batteries to have bluetooth connection that forces devices to be off, not just the power button I do not control.
We should assume every piece of hardware we own is backdoored and remotely controllable by any state level actor.
Too true. I want this on a T-shirt.
Better, I'd like my WE pin to be connected to a latch and a piezo electric buzzer, so I know that a write that I didn't expect took place, and I get to know about it to investigate. I'm thinking of doing this for some SOHO routers.
In the satelite piracy days, it wasn't unusual for people to MITM their WE pins on their firmware chips and put them on a switch to protect against updates.
When the satelite providers reconfigured their firmwares to do a test function that utilized the WE line (but didn't actually perform a write) to disable if a lock was detected, the pirates dreamed up a new EEPROM lock design that only prevented real writes and let the WE line test go through.
Here's one example: http://digitallock.tripod.com/1000digilock.htm
And how do you know what is your firmware? surely you don't ask the suspected firmware for a copy of itself. Do you extract from memory? how? maybe you can't. Anyway memory (flash, DRAM) controllers also are controlled via firmware. Do you trust your memory controller firmware to deliver the real firmware?
Do you compare it in your computer? do you trust it? do you trust the central hash database computer? do you trust the computers among the path?
Why comparing with others? you assume your firmware is special, but many firmware backdoors (I.E. home routers) affects all devices.
What you need is absolute control of the whole hardware manufacture and software chain, if you can pay a few millions for every computer like the military, then you can do it.
Typical rule:
Interactive gaming systems must be capable of verifying that all control programs contained on the interactive gaming system are authentic copies of approved components of the interactive gaming system automatically, at least once every 24 hours, and on demand using a method approved by the chairman.
Unless otherwise approved by the chairman, the authentication mechanism must employ a hashing algorithm which produces a message digest of at least 128 bits. The results of the authentication must be retained and be accessible for a period of 90 days. The interactive gaming system must provide a mechanism to visually notify the operator of any control program that fails an authentication. This mechanism must also require that an administrator of the interactive gaming system confirm any failed authentication with the system within 72 hours. Failure to confirm a failed authentication must require the interactive gaming system to automatically stop any gaming related functions.
Interactive gaming systems must provide, as a minimum, a two-stage mechanism for verifying all program components on demand via a communication port and protocol approved by the chairman. Unless otherwise approved by the chairman, this mechanism must employ a hashing algorithm which produces a message digest of at least 128 bits and must be designed to accept a user selected authentication key or seed to be used as part of the mechanism (e.g. HMAC SHA-1). The first stage of this mechanism must allow for verification of control programs. The second stage must allow for verification of all program components, including graphics and data components. The interactive gaming system must also provide the same two-stage mechanism for verifying all program components on demand via an operator user interface where the results are displayed on that interface.
This is same process as you computing SHA1 of a file you downloaded and comparing it with the SHA1 provided on the website, if you could also provide a 128 bit number as seed of the SAH1 to the website.
And yes, they look for hardware backdoors: (The chairman may require transportation of not more than two working models of a new gaming device to the new game lab of the board ... The lab may dismantle the models and may destroy electronic components in order to fully evaluate the device.)[3]
The second phase is the field check. In the days of standalone slot machines, the field check involved an Gaming Commission inspector plugging the machine's pluggable EPROM into a reader and computing its hash. Now it's tougher, but if the program is on some removable medium, it can be checked independently. Downloading updates is prohibited.
The third phase is logging. The logging requirements require logging all gambling and maintenance activity on logging media that survive maintenance. Every time a machine is opened, that's logged, too. In multi-machine systems, logs are kept both locally and centrally, and the central logging machine has to be physically inaccessible to the people maintaining the machines. If something funny is going on, there should be enough info in the logs to find out what, and who.
There are lots of specific requirements, from two-factor authentication to random number generator design and testing. There are many statements made under penalty of perjury. They even prohibit pop-up ads on slot machines, although advertising when the machine is idle and has no credit on it is allowed.
Just about everything they check for has been tried at some point by someone trying to cheat. They're up against organized crime. This isn't airtight, but it's far better than what we have now for embedded consumer software.
[1] http://gaming.nv.gov/modules/showdocument.aspx?documentid=27... [2] http://gaming.nv.gov/index.aspx?page=102 [3] http://gaming.nv.gov/modules/showdocument.aspx?documentid=29...
No electronic voting machine is that secure.
We don't need source code? We don't need GPLv3? None of this is important to truly own our computing?
"Hardware manufacturers could also release the source code", almost as an afterthought? Isn't this a "must", not a "could"?
1) GPLv3 defines all build scripts as part of the source code.
2) GPLv3 ensures that you can install the software you built yourself.
Signing is also useful, of course, but source code and free software seem like a more primitive prerequisite before code signing.
What good is signing if we are merely verifying the signature of malicious software? With source code, you can just build it yourself and don't need to trust any signature.
OTA firmware updates being signed would be a good thing, but I'd rather spend the time and energy keeping more things local, and avoiding the "internet of (broken) things."
> 2. Firmware updates must be signed.
> 3. We need a mechanism for verifying the integrity of installed firmware.
I wonder how many bricked devices (or devices malfunctioning in a creative way) it would take to convince hardware manufacturers that these are good ideas?
War habits throw words around about sensitive information but barely begin to describe the emotional depth of domestic-international relations, violence, and abuse.
... NSA provided backdoors and are prevented from writing our own firmware to run on our own systems.
Everyone that makes anything hardware related hires security people full time plus audits.
> So cost $$$ when you can just ship to market anyway since no one thinks about this for a $10 mouse
Have all firmware signed
> Because surely there won't be a cryptographic flaw in signature verification that the NSA can find, or keys to be stolen
Have devices report back
> Because once it's compromised I'm sure the NSA can't figure out how to report back otherwise, despite having already done so for the HDs.
Yah so umm, good luck with this one world. The only hope we have is that firmware is far harder and a giant diversity of devices generally exist...
But just because flaws in security are inevitable, that doesn't mean they aren't worth considering. It's some protection - it may be too expensive to break for all firmware. The NSA is hardly the only organization with an interest in doing so. Even if the NSA can break verification in it for no cost, it's better than NSA + criminals being able to.