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.
>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.
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.
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?
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?
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.
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.
[+] [-] sitkack|11 years ago|reply
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.
[+] [-] Scoundreller|11 years ago|reply
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
[+] [-] aortega|11 years ago|reply
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.
[+] [-] bronson|11 years ago|reply
Too true. I want this on a T-shirt.
[+] [-] Animats|11 years ago|reply
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
[+] [-] sitkack|11 years ago|reply
No electronic voting machine is that secure.
[+] [-] schoen|11 years ago|reply
[+] [-] jordigh|11 years ago|reply
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"?
[+] [-] moyix|11 years ago|reply
[+] [-] username223|11 years ago|reply
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."
[+] [-] effdee|11 years ago|reply
> 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?
[+] [-] ams6110|11 years ago|reply
[+] [-] _cudgel|11 years ago|reply
[+] [-] pain|11 years ago|reply
War habits throw words around about sensitive information but barely begin to describe the emotional depth of domestic-international relations, violence, and abuse.
[+] [-] codeshaman|11 years ago|reply
[+] [-] nullc|11 years ago|reply
... NSA provided backdoors and are prevented from writing our own firmware to run on our own systems.
[+] [-] azinman2|11 years ago|reply
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...
[+] [-] navait|11 years ago|reply
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.
[+] [-] unknown|11 years ago|reply
[deleted]
[+] [-] geekingfrog|11 years ago|reply
[+] [-] Rumford|11 years ago|reply