Skip to main content
shopping_basket Basket 0
Login

I'm sorry..... my fridge is spamming you !

peterjfrancis
7
Mechanical & Thermal Consultant, CFD & FEA , mechanical design, electronics hacker , IoT hacker, pilot - full size and RC , motorcyclist

Comments

November 24, 2014 14:09

Thanks Edewede, In fact we briefly met at an IOT event held near Oxford earlier this year, and I remembered your intriguing presentation that promoted my comment. I'll check out your new paper. We've also created and collated lots more IOT based content that can be found in out IOT Design Centre. http://www.rs-online.com/designspark/el ... -of-things.

Pete

0 Votes

November 24, 2014 12:32

Hello all.

Interesting 'niche' conversation going on here. *Thanks for the mention Pete W. You don't know me, I don't know you but finding my paper mentioned in the context of real-world problems and solutions is a 'Yippee!' moment for me. Thanks.*

Speaking of Responsibility in the Internet of Things era, I prepared another research paper last year titled "Do Not Pass the Buck: the Need for Responsibility Modelling in the Internet of Things"

"http://www.researchgate.net/publication/263652001_Do_Not_Pass_the_Buck_the_Need_for_Responsibility_Modelling_in_the_Internet_of_Things"

Check it out when you have a minute.

I think this DesignSpark blog highlights something many in the IoT/Smart Environments community are quickly waking up to: 'responsibility'. Responsibility in future networks does not yet receive as much attention as all the other areas viz a viz security, privacy, protocols, speed, cost, etc. Good job.

0 Votes

July 7, 2014 10:40

Hi Bradlevy,
Thanks for your comments , it seems my blog has prompted some discussion.
Your examples of relatively simple systems having potentially serious consequences are excellent . I hope this sort of thing is being covered by up coming engineers whilst studying.
I've certainly tried to raise awareness of these issues whilst designing products , even the relatively simple decision of what constitutes Fail Safe for a fan controller.
For an IT server cooling application fail safe requires the fans to run at 100% if the controller fails or loses comms whereas in a Heating and Ventillating application it is generally accepted that fail safe is 0% .

We should not take these types of decisions lightly , it may 'only' be a door lock or Christmas light controller but the effect of some decisions are crucial.
The tools already exist for making these decisions and validating designs against them , such as FMEA , decision registers to more complex processes.

0 Votes

July 6, 2014 03:32

I thought Spam didn't need to be refrigerated?

All jokes aside, data security is indeed very important in the embedded world.

We need to think about what data a device makes available, who it makes it available to (intentionally or unwittingly / unwillingly), and the consequences of that availability.

We also need to be careful (as Boss points out) to prevent unintended communication, (and communication to unintended recipients).

Just as important for many devices is security on the receiving end. It might not be too big a deal if our holiday lights respond unintentionally to a command from a neighbor's system. But if it is a stairwell light, or room light that helps you avoid bumping into furniture, accidentally responding to a command from a nearby system at the wrong time could be more than an annoyance - it could endanger a life.

Likewise, susceptibility to unauthorized commands can allow thieves to determine if there is really someone home when the lights are on. If thieves turn the lights out remotely, at least one light is likely to come back on as soon as someone home finds a switch. But if nobody is home, the lights will stay out. Older garage door openers used a fixed code which could be determined by interception, or discovered through brute force methods, giving a thief access to the home. Newer units adopted rolling code strategies, which meant the code changed each time it was used, making interception relatively useless.

Hazards are not limited to unauthorized commands. They can also come from sensors and data sources within and outside the system. Smart power grids bring benefits from coordination between power producers and consumers, allowing all to share from reduced costs due to reductions in peak demands. But, if not implemented with due security, also provide a path for disruption via spoofed data. If persons with ill intent are able to impersonate the power grid interface, they could cause the smart thermostat to keep a cooling system's compressor off continuously, posing a hazard to an elderly person in a hot desert climate.

I've worked on software and hardware for a variety of systems, from energy management, to agricultural / turf irrigation, to power plants, to IC test equipment. All of these application areas have circumstances that can result in damage if the control systems blindly trust data and command sources. From ruined pumps or blowers, ruined crops or golf greens, to melted equipments and burned components, the hazards vary with the application area, but all can be costly.

Likewise, Google and auto manufacturers are exploring making vehicles more autonomous. This certainly has some benefits. As does increased communication between vehicles, allowing a smoother and safer traffic flow. But technologies like these need to be implemented with care. They need to consider not only the conditions reported by sensors, but how secure those sensors are against being fooled, intentionally or unintentionally. An automated traffic system can result in significantly improved traffic flow, saving time and fuel. But it needs to be robust against sensor failures or intentional interference that could result in false readings. We humans are certainly imperfect drivers. We sometimes don't notice the light change as promptly as we should, delaying other drivers. But some of the "human delay" in moving also incorporates safety margins against the unexpected. Car manufacturers have been adding sensors that help us detect unexpected circumstances we need to take into account. But some unexpected circumstances (mechanical failures, for instance), can't always be sensed / predicted ahead of time. Autonomous systems need to be careful that they don't "optimize out" safety buffers between vehicles to the point that everything runs smoothly and oh so much more efficiently until a mechanical failure in one vehicle causes a chain reaction involving many vehicles.

While a traffic system might not seem as ripe a target as an ATM terminal, it could still be seen as useful to some malicious people - especially if it was subject attack by spoofing a local sensor, rather than having to hack in to a centralized system.

The take-away from all this is that we need to be pro-active and creative in anticipating sources of failure (command/communication/control as well as hardware or environmental problems). Our goal should be like that of a doctor - first, do no harm. Question and authenticate data sources. Cross-check them for reasonableness. (Even though 3 degrees C might be within the valid range of an outdoor temperature sensor, does it make sense in the middle of summer? Probably not if you aren't in the mountains or far norther or southern zones.) Consider fall-back scenarios for human and equipment safety in case of communication or sensor failure. Build robustness into the hardware as well. Any critical protection circuits should be designed so if they fail, they fail safe - protecting the user at the cost of operation.

Sometimes a small difference in circuit design can result in much better robustness, and end up saving money in the end. That IC tester I mentioned had relays for connecting each pin of the IC to a data source, ground, or one of several power supplies. The original circuit (not mine) had nothing to prevent turning on more than one power supply relay to the same pin at the same time. When I joined the project, I added software safeguards to prevent inadvertent programming of that condition. But an occasional power glitch still could (and did) cause the relay drivers to come up in a random state. We eventually added a relay to the system that would drop out if a power glitch was detected, and keep the system off until it was manually reset, allowing a clean power-up. Even better would have been if the boards had been designed with exclusion logic (easily done with today's programmable logic chips) that prevented simultaneous power relay activation at the hardware level. Even years ago when that system was designed, the cost of the additional logic chip for protection would have been less than the cost of replacing even once the expensive pin driver chip that the stray relay activation would burn out. Let alone the cost in time to perform the replacement.

On the creative side, turn the tails on your design. Ask yourself, if you wanted to interfere with the system, how would you do it? Then build in safeguards.

There are professional organization that talk about these issues. One is the Association for Computing Machinery's Committee on Computers and Public Policy, and its Forum On Risks To The Public In Computers And Related Systems. (http://queue.acm.org/risksforum.cfm) This forum includes many real-world examples of system failures, which help you get broader understanding of the many ways systems can fail.

(And re: Spam, do refrigerate after opening. Electronic spam? Give it the cold shoulder!)

0 Votes

July 4, 2014 19:47

Hi Boss,
Thanks for the great comments.
I hadn't really though about 'self generated' security issues, and I love your examples of them

I think that the IoT security issues will be wide ranging and you have illustrated that I had missed a whole genre.
The possibility of unintentional data leaks are not confined to non professional programmers but at least the professionals should be able to apply coding standards and processes to alleviate the problem.
As for the non professional programmers they will have to try and up their game to meet the new challenge of IoT and all that comes with it.

0 Votes

July 3, 2014 07:08

Great article "IoT , Security and you", security (or lack of) and being hacked and creating a way into your private network is a major issue, but there is another:

Probably covered by "you" in the title if you are creating your own devices but it could be manufacturers as well, 'Simple program errors'. Some experience on this that translates to the IoT where simple errors causes others headaches:

1. My land line phone rang every 10 minutes or so for several hours, it was a FAX machine trying to talk to me! We couldn't communicate! How long would this go on? How could I track it down and put a stop to it? Fortunately it gave up before night time.....

2. My phone received text messages appointments and reminders from a doctors surgery every month. They were not for me in fact they were 300 miles away! The surgery could not search their database by phone numbers, they needed the patient name, which obviously I didn't have! The appointment time slots strangely did not fit in with their allocation slots so how could they locate the issue? Luckily after about 6 months I spoke to someone who realised it was a 'nurse appointment' who fiddled the times to match here requirements. Patient identified, phone number deleted! Hopefully not the other way round.

3. Where I worked some time ago approx 4000 staff started receiving an email every ten minutes "URGENT. Backup supply nnnn, battery #2 failure!", how long was this going to go on for? Luckily not for long, the intended recipient was not on holiday and his colleagues pointed out the error.

4. And a news item from a while back when a manufacturers satellite TV box model which phoned "Tim?" for an updated time during the night, got an error or had a firmware bug and phoned again repeatedly every 10 seconds, each call costing some 20 pence, the costs soon mounted up for many customers.

These just point out that as well as security concerns, the IoT will offer similar opportunities for program errors causing major nuisance issues for some people. So some thoughts if developing your own code:

1. Don't send SMS messages unless really essential.

2. If you do use SMS ensure you add your contact details.

3. Test you code and build in checks to ensure repeat transmissions and SPAM type effects can't happen.

You don't need to be hacked.........

0 Votes

July 2, 2014 12:02

Data Security of your personal IOT connected stuff is a massive issue. Elektor for example have released a solution called e-lock, http://www.elektor.com/e-lock.

There's also an intersting article wrtiien by Edewede Oriwoh, called the Thing Commandments which talks about things like responsibility, owenership and illegal access. http://www.sciencedirect.com/science/ar ... 0913008119

0 Votes

Related Content

DesignSpark Electrical Logolinkedin