Everything needs a firewall. I'd like my own local wifi MiTM proxy that my devices connect to, running privoxy all of the time. Those devices should run inside of a VPN, they run inside of the matrix.
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.
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.
> 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
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.
Use an FPGA and much larger eeprom to implement CoW, writes succeed, but the user can switch back to an earlier version. Pair it with a Nordic chip, https://www.nordicsemi.com/eng/Products and get your own short range OtA update/diff.
>I'd also like hashes of my firmware compared globally so I knew my firmware isn't special.
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.
We all know security isn't a binary relation. Step one is to know you aren't specifically targeted and keep your attack surface low. Your analysis leads to a paralyzing fatalism, which might have been your intent.
Hardware manufacturers actually do pay money to try and prevent some attacks(the main problem of course is that preventing side-channel attacks has a performance cost) The article even notes hardware manufacturers worry about firmware attacks. Admittedly, a lot don't, and the race to the bottom on commodity hardware only encourages cutting corners on something customers don't pay more for.
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.
I guess I'm much more worried about "the cloud" aggregating lots of people's data on connected machines where hackers can score big with a single vulnerability. The recently-exposed NSA firmware hacks seem like they require per-target effort, and since I'm neither wealthy nor wanted by Mossad, I don't see myself being worth that effort. (EDIT: e.g. stealing $20 apiece from everyone affected by the Target data breach equals big bucks, much more than bugging the firmware in my laptop and trying to clean out my bank account.)
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."
> 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?
What good is the source code if you can't build it and flash it to your device? What good is it if you can't verify that the binary firmware was built from the source you have?
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.
For an outline of how to secure embedded devices, see the technical standards of the Nevada Gaming Commission.[1] They've faced these problems for years, with the opposition being organized crime and gambling cheats.
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.
The firmware image is present on the computer requesting authentication. So the seed is sent to gaming machine to calculate digest at the same time the server requesting authentication runs the same algo on stored firmware image. Provided the initial seed is random, barring weakness in the hashing algo, there is no way to beat this check.
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.
There are three phases. First, the machine and its software have to be approved before deployment. That's done at Nevada Gaming Commission's lab in Las Vegas, and they require access to the source code. Here's the application form.[1] The applicant must
("Provide the Lab with all necessary hardware, software and documentation to reproduce
programming and executable software. This typically includes a PC that contains no operating system, along with an operating system and compiler that is submitted on OEM media or downloaded from a verifiable source approved by the Lab. The documentation must include procedures for installing and configuring the operating system, compiler tools, libraries, certificates and anything else necessary to reproduce programming and executable software.") The approved version's hash is computed at the lab, and that's what has to match on machines in the field. There's an official state program, the NVSGCB Hash Verifier, to check this.[2] It's a Windows program (yes, I know) which checksums media and has a file of all the approved programs and checksums.
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.
I love you are talking about it as betrayal, terms of emotional security/emosec that feel human and even compassionate, common parts of speech lost to technical difficulties to explain.
War habits throw words around about sensitive information but barely begin to describe the emotional depth of domestic-international relations, violence, and abuse.
27 comments
[ 20.2 ms ] story [ 852 ms ] threadIoT 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.
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.
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?
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.
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.
[1] http://gaming.nv.gov/index.aspx?page=269#techpolicies
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.
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.