Category Archives: networking

The SIOT Trust-Mark

Look for a SIOT trust-mark

The SIOT Security Trust-Mark

On 29 July 2014, HP released the results of a study claiming that 70% of the most commonly used Internet of Things (IoT) devices contained vulnerabilities. Furthermore the devices averaged 25 vulnerabilities per product.
(see )
So, since Gartner is anticipating something like 26 billion units installed by 2020, there is little doubt that users will be suffering from a myriad of IoT information security and privacy problems well into the next decade. Fortunately, it is still possible to do some things that will reduce the extent of this problem.

While having a complete understanding IoT information security problems is beyond the capability of IoT device users, many will appreciate the value of purchasing devices with a trust-mark. For example when someone buys an electric appliance that has the UL® trust-mark on it, the buyer understands it’s less likely that this product will electrocute someone. Similarly, buyers could come to believe that an IoT security trust-mark will mean that the marked device is less likely to be hacked, less likely to be used to hack other devices, and/or less likely to disclose someone’s personal information.

Devices that come with an IoT security trust-mark would need to meet a standard, and, as with the UL® mark, these standards would need to be verified by an independent third party.   Many things could be included and tested according to such standards.   Here’s a list of some of the things that might be included along with a brief description of each:

Active Anti-Tamper: FIPS 140 is a NIST standard that describes security for many commercially available cryptographic devices with varying levels of security. The highest level includes physical active anti-tamper capabilities that will cause keys and other critical security parameters to be erased whenever the physical boundaries of the device are penetrated.   There are many technologies that can meet these requirements, and many are not that difficult to implement. Similar anti-tamper standards can be applied to IoT devices.

Trusted Boot: Most PCs contain a device called a Trusted Platform Module (TPM). This device can be used to help ensure that the code executed while booting has not changed from one boot to the next.   If the boot code has changed from an authorized version, the TPM makes it possible for other devices to stop trusting the changed system.   Trusted IoT devices should have hardware for verifying the device has booted into a trusted state.

Removeable Power: Many cell phones today, have removable batteries, and many people have realized that this is a strong security feature. By removing the batteries from a cell phone, a user can be relatively certain that he has disabled any spyware that might be running on the phone, spyware that might be listening to the user’s conversations or reporting on the user’s location.   A user of a trusted IoT device should have the ability to stop trusting that device by removing the power source.

Independent User Control of Physical I/O Channels: Similarly, a user, not wanting to completely disable his device, might wish to be sure certain I/O functions are not activated. For example, the user may want to disable the camera function, the GPS function and the microphone function while retaining the ability to listen to music. By providing hardwired switches certified to disable specific hardware I/O function, a user can rest assured that these functions won’t be secretly activated by some malware lurking inside the trusted IoT device.

Host Based Intrusion Detection: For several years now, host based intrusion detection software has been available for desktop machines and servers. It is time to recognize that IoT devices are hosts too. There should be software running on the trusted IoT device so that one can detect when that trust is no longer appropriate.

Automatic Security Patching: Today, the time between the release of a critical security patch and the release of malware that exploits the associated vulnerability can be measured in hours.   The reality of the present situation is that the existence of a critical security patch means your system is already broken. Consequently, the automated application of security patches is necessary for desktops and servers. Automated security patching for trusted IoT devices will also be necessary.

Independent Software Security Verification: To a certain extent, trusting a software companies to develop secure code is like trusting a fox to guard a hen house. This is because the pressures on software developers to make marketing windows, to release code and to get paid frequently overpower discussions about the appropriate levels of security needed for operating the end products safely.   The resulting security problems are then left for others to solve. Because of this, various information security standards depend on independent software security verification. While this can be expensive, free services like “The SWAMP”
( ) offer the hope that independent software security verification can be done cheaply enough to motivate standardization.

User Defined Trust Relationships: When an IoT device enters a home, there may be very good reasons why it will need to communicate with other devices inside or outside of that home.   That does not mean that the new device should have the ability to communicate with all other devices. Consider the recent Target hack. The point of sale terminals were attacked by first gaining access to a system used to manage heating, ventilation and air conditioning.   Likewise, it might not make sense for your home’s air conditioning system to be able to talk with your home’s electric door locks.   It seems that giving users an easy way to manage what systems are allowed to talk with other systems could help quite a bit here. How to do this effectively may take some creativity, but one could imagine users having a tool, perhaps a wand that they could tap on one device and then tap on another device, to establish or dissolve the trust relationships between devices.

Recently, on 10 September 2014, The International Workshop on Secure Internet of Things (SIOT 2014, see ) conducted its meeting in Wroclaw, Poland.   This was only the third such workshop.   So, SIOT standardization is still far from being where it needs to be.  What will actually go into a set of IoT Security standards is not yet known. Likewise, an IoT Security Trustmark is not yet available.   Hopefully, some of the ideas suggested above will start to find their way into trusted IoT devices. If not, we can surely expect the same sorts of security problems that have plague our PCs and web servers, to appear all over again in the Internet of Things.

Is a Smart Toilet in Your Future?

HAL smart toilet

Is a smart toilet in your future?

When personal computers first appeared to on the market, there weren’t many people asking whether cars would have embedded computers. Today, a luxury sedan has somewhere around 60 embedded computers.  Yes, the Internet of Things is expanding, and that means we’ll be seeing more and more smart devices. Devices like these will also be communicating with each other so that they may work together to bring us more advanced information age benefits.

So, will toilets eventually have embedded processors?   Why change a good thing?  Why add a processor that will need software updates?  Why add electric power to a convenience that can function just fine without electric power?  These are very reasonable questions, and here are 5 possible answers.

1)   A smart toilet can include an automatic flush function.   A flushed toilet is always more presentable that an un-flushed one.  So, having an automatic flush function ensures that toilets are presented in the best possible light.  Self-flushing toilets already exist and can be found in public restrooms.  Assuming this functionality becomes popular in the home, the power needed for other smart functions will be available.

2)   A smart toilet can measure usage patterns.  By measuring how long someone is taking on the toilet, the smart toilet could remind the user to avoid taking too much time.  This could be done with and audible alert or more discretely by sending a text message to the user’s smart phone, reminding the user of the possible health consequences of prolonged toilet use.  To send this information by text messages, the smart toilet would need to identify the user.

3)   A smart toilet can measure a user’s regularity.  Once the smart toilet can identify the user, the smart toilet can also measure the regularity of the user, reporting trends and suggesting possible dietary changes to improve regularity (e.g. drink more fluids, eat more fiber, etc.).  In order to perform this function properly, the smart toilet might also need to communicate with other toilets.

4)   Similarly, a smart toilet could measure urinary frequency.  For male users, this function could be useful for detecting enlargement of the prostate.

5)   A smart toilet can also measure other healthcare information.   When traditional toilets are flushed, useful healthcare information is lost.  With more advanced sensors, a smart toilet can detect abnormal amounts of blood, or biochemical changes in the waste.   This can be helpful in the early detection of cancer.

Of course, there will probably be resistance to the idea of smart toilets. Some, perhaps most, people won’t like the idea of toilets recording their bathroom habits or having access to their healthcare information. Still, there are some practical and, perhaps, life saving benefits to be gained.   Consequently, when Smart Toilets start appearing, the manufacturers will need to assure their customers that these devices are secure and that their personal healthcare information will be kept private.   If buyers are convinced, smart toilets might eventually become more popular than the dumb toilets on the market today, and that’s an enormous market.

A smart toilet that’s already on the market…

Video of a smart toilet getting hacked…

How long will the Internet last?

Both were built to be robust

Will the Internet last as long as the Pyramids?

When one looks at a timeline of the 7 wonders of the ancient world…

it is the striking to note that the first wonder built, the Great Pyramid of Giza, is the only wonder still standing.  It is also striking to consider that, while the Great Pyramid of Giza stood for over 4500 years, the period of time when all seven of the ancient wonders stood simultaneously lasted only 21 years.

Today, different groups of people have assembled different lists of the seven wonders of the modern world.  Most of these lists are of civil engineering wonders, but some lists include wonders from other branches of engineering.

If you were to make your own list, perhaps you would include the Internet.  The Internet is made up of other modern technological wonders, including the computer, the microcomputer, operating systems, and telecommunications systems.  It is powered by a global energy distribution system,  and has developed a mutually dependent relationships with many energy distribution systems.

Will the Internet last as long at the Great Pyramid of Giza?   Like the Great Pyramid of Giza, the Internet was designed to last.   In part, its strength is due to its distributed design.  It has become so large, so self-healing,  so redundant and so distributed that is never entirely down.  Of course, there always some parts of it that are not working quite right.

Back in 1998, a hacker named Peiter Zatko, aka Mudge, claimed before the United States Congress that it was possible to take down the entire Internet.

Whether one believes that something like this was possible then (or might still be possible today), the idea that large parts of the power grid or the Internet could encounter long duration outages should be considered.  This is because the operation of either currently depends the operation of the other, and many lives now depend on both.

copyright 2013 NetChime Research LLC,  All rights reserved.

Network Outage Finger-Pointing

What to do then your providers blame each other for a network outage

Network Outage Finger-Pointing

The Chief Information Officer had run into this sort of problem before.  His Network Manager was telling him that the leased line provider had an outage on Line AB.   The leased line provider was telling him that there appeared to be something wrong with Port 1 on Router A.   What he hoped would be a productive information-gathering meeting was turning into an exercise in finger-pointing with both sides indicating that they checked and rechecked their work.  So, quite seriously, the two sides were squared off, both convinced the other side had messed something up.

Sometimes it's hard to know where a problem originates.

There was a loss of connectivity between two routers

Because the Chief Information Officer had run into this problem before, he knew exactly what to do.  He proposed an experiment.   The idea was to connect Leased Line AB to Port 2 and Leased Line AC to Port 1.  If the problem remained on Lease Line AB and not on Lease Line AC, then the problem was with Leased Line AB.  If the problem moved from Leased Line AB to Leased Line AC, then the problem was with Port 1 of Router A.  Both sides eagerly agreed to experiment.  This was just the sort of evidence they needed to show that they had done their jobs correctly.  Of course, Router A’s configuration would need to be temporarily modified to maintain consistency with the IP addressing scheme in place.    Fortunately, this was a simple modification, and the Network Manager had the changes ready within 15 minutes.    All that was needed then was to swap the cables and reboot Router A.

To avoid finger-pointing, it is sometimes necessary to gather more information.

An experiment was proposed to isolate the problem

The result was that the problem remained with Leased Line AB.  Fortunately, the Leased Line Provider was a reasonable guy, and he was quick to accept what this new evidence meant.  He reviewed the provisioning of Lease Line AB for the third time, comparing each parameter with the parameters of Leased Line AC.  These two lines were supposed to be provisioned identically.  When he found one parameter that was not identically configured, he knew he had found the problem.  This was quickly corrected and full connectivity was restored to the wide area network.

The problem was with the provisioning of the leased line.

The experiment indicated the source of the problem

If the Leased Line Provider’s ego was bruised, he didn’t show it.   In any case, everyone was relieved that the problem had been solved.

copyright 2013 NetChime Research LLC,  All rights reserved.


The Hacker-Proof Automobile

The Information Security Analyst sat quietly in the audience.  He had driven for hours to hear this presentation, and he could barely believe what he was hearing.  The speaker, the head of a government organization, an organization responsible for protecting his country’s information systems, was downplaying the importance of automotive cyber security, comparing those worried about the situation to “Chicken Little,” running around and complaining that the sky was falling.  “Wow” he thought.  “Does this guy just not understand the situation, or is he pretending that it isn’t a problem for some reason?”    The analyst knew full well there was a problem, because he had read two important papers on the topic.

The first was titled “Comprehensive Experimental Analyses of Automotive Attack Surfaces.”  The second was titled “Experimental Security Analysis of a Modern Automobile.”   These two papers, both written by a team of researchers from the University of California, San Diego and the University of Washington painted a very different picture of automotive cyber security.  Not only did the papers point out that there were vulnerabilities.  The researchers demonstrated exploits against the vulnerabilities.  Three experiments were most notable.   First, they demonstrated that it was possible to hack a vehicle through a music file, which would play fine on a computer or a stereo system, but would deliver software updates to onboard computers called Electronic Control Units (ECUs) when played on a vehicle stereo system.  Next, they demonstrated that it was possible hack a car while the car was in motion, disabling the brakes at 40 miles per hour.  Finally, they demonstrated that multiple cars could be hacked and then commanded to respond to remotely issued commands in unison.  This was done while the cars were geographically separated by a large distance.

The authors left it to the reader to speculate what sort of major cyber-attack might be possible should some gifted hacker, terrorist group or some nation state decide to get very nasty.  The idea of millions of cars simultaneously losing the brakes while driving over 55 mph came to the analyst’s mind.  “Guess that means I’m chicken little” he thought.  “Well, at least I’m not running around claiming the sky is falling.”  Of course, he would do something about it.  He was planning to get another car.  This car would be cyber hardened because it would contain no ECUs.  This car would be a 1966 Corvette.

This car has no computers to hack.

The Hacker-Proof 1966 Corvette Stingray

Two important papers on automotive cyber security…

copyright 2013 NetChime Research LLC,  All rights reserved.