The First Line of IoT Defense

Introduction

Within the next few years, IoT (Internet of Things) will likely have permeated every aspect of our lives. Although it is still in its infancy at present, its rate of expansion, adaptability, ingenuity and scope is startling. Due to its sweeping reach and unfathomable impact, it is not easy to wrap our mind around this IoT revolution. We will only focus on how it affects us individually as consumers and homeowners. This is not much more than a lengthy rant on the subject.

First we'd like to advocate that turning your house into a smart home or enjoying other IoT benefits involve certain understanding and skills, without which your security and your personal privacy can be easily jeopardized. Introducing unattended intelligent devices into your life is not to be taken on lightly. Think about those autonomous self-driving cars, which have done over 10-million miles road test and are still not considered ready for prime time. Although not as drastic as hopping in a driverless cab, introducing IoT devices into your sweet home is not as simplistic as hanging a dumb clock on your wall.

Chief among the concerns of introducing IoT devices into our home and daily life is the lack of readiness of the Internet. The Internet has been designed and evolved around our simple browsing requirements for web sites that provide ordinary non-critical information such as those offered by Google, Facebook, snapchat, nytimes.com, Amazon, and the likes. For emergencies and other purposes, we don't use the web; we dial 911 (emergency), 999 (ambulance), 997 (fire), 993 (traffic police), et cetera. Unfortunately, the IoT PR machines are waving at us the shining promises of other critical services without mentioning the necessary behind-the-scenes support like those for 911, 999, 997, and 993. Take for example some already deployed smart home apparatus such as locks for the front door or the thermostats for the heater. Any design flaws or malicious tampering may leave your door wide open or produce serious fire hazard, among other undesirable consequences. Due to their critical nature, the reliability and security concerns of those things to us personally ought not to be any less than that for 911, 999, or 997, combined. Clearly as it stands now the Internet lacks that level of trustworthiness, and yet some of us brave souls install them without an inkling of what is at stake and merrily enjoy the all too convenient remote access from the Internet without giving careful thought on protections.

This article attempts to remind some of us of those weighty issues ahead on the eve of widespread IoT deployment. From the point of view of required IoT infrastructure support, the Internet is simply not ready. Its deficiencies may be outlined as follows:

  1. Reaching your IoT devices: Internet favors service providers and enterprises who can afford the cost of owning network resources such as public IP addresses, dedicated or leased lines, firewall equipment, remote access appliances, and the administrative staff for managing those resources. For consumers browsing the Internet as clients, the network support for the upcoming intelligent personal "things" they are about to own, which turn out to be servers, either does not exist or is offered at an unaffordable cost or unmanageable complications. Currently there isn't even an easy way to address those personal things, let alone access and control them. The IoT revolution is about to turn this server-centric Internet backbone on its head.
  2. Getting there reliably with proper delivery priority: This involves the appropriate actions by the network transport that service the fire alarms or matters of life and death differently from other browsing traffic. This category of hard problems of real-time QoS (Quality of Service) has been plaguing the Internet for decades. It is simply not supported by the Internet as it stands now.
  3. Accessing them securely: It is closely related to issue 1 above. Even if we have a way to address our personal things and reach them somehow, the security issues must be addressed as well. This issue actually has been solved adequately by most private enterprises that deploy VPNs (Virtual Private Networks). The urgent matter now is how to popularize the enterprise VPN solution to the rest of us in order to safely own and operate our things.
  4. Designing them intelligently: Scenarios unaccustomed to in traditional IT applications: auto-open for door locks.

Shortchanging IoT Security

IoT Security is an oxymoron, at least for now. This assessment may be harsh but quite symptomatic of the current mad dash for IoT deployment. Security breaches and hacks are well documented and predicted to cause $6 trillion in damages by 2021[Gartner]. If you need more convincing, do a simple Google search and get a flavor of those bad cases against smart household "things" that have occurred. This ever more serious hacking of IoT devices will affect our lives as never before, with incidents already involving cardiac devices, baby heart monitors, webcams, jeeps, and obviously the Mirai Botnet attack which helped launch the largest DDoS attack[IoTHacking] in Internet history, thanks to the expanding number of smart devices. This is not even counting the harms they will cost us in the loss of our privacy. Those innocent-looking networked IoT devices will have access to data that can be intensely private, e.g., when you sleep, when your children come home from school, what your door lock pin code is, what you watch on TV or other media, and who and when others are in the house. Our home is our castle, our last line of defense, whereas the IoT revolution is launching the final assault on our home front and doing it from the inside out. "Identity theft" on the Internet thus far has been mostly attacks on our financial identity, which without doubt will mutate quickly into that of our personal identity as well. This issue of privacy protection is not something we can procrastinate on and just hope for the best. We must recognize that loss of personal data is permanent and irrevocable. There is no recovery once the information on our life escapes from us into the thick of the "Internet". For the most part there is no second chance as far as the privacy hacking goes.

However, even with those cautionary tales circulating widely, there is no shortage of kamikaze vendors and consumers plunging themselves blindly into the fray, ill-prepared, and ignoring many of the hard-won insights from traditional network security.

Harvard professor James Mickens gave an excellent keynote at the USENIX Security Conference in August, talking about the social aspects of security, IoT, machine learning and the Internet. In his captivating and amusing style, the caution against mindless IoT deployment is loud and clear, which is partially reflected in the following funny snippet from his presentation:

Quoting Professor Mickens and all the security experts, the best and minimally required security protection is "TLS, the only good thing we have". There is no shortcut yet to be invented. It is wishful thinking that any encryption schemes without the vigor of TLS may survive the cyber attacks launched against our devices 24x7. The fact that some inexpensive IoT devices are not capable of conducting TLS effectively doesn't justify its shortchanging the security protections. A chain is only as strong as its weakest link; deploy TLS or suffer the pain of regret. If a smart device does not offer security to the level of TLS, it simply is not ready for deployment.

The Ai-Fi.net infrastructure, based on the same set of technologies like many other security suites, is not much more than what is contained in the elemental TLS cyphersuite . Ai-Fi.net just weaves those one-dimensional TLS constructs into protective shields so we may safeguard all our personal assets from unwanted intrusions. Without this layer of insulation we are simply running naked.

For the better part of this write-up we will be reviewing the infrastructure issues confronting the IoT deployment, with the security question as the first and foremost challenge. The remaining will be looking into those "smart locks", the best of breed IoT devices that our industry has to offer. Those locks are literally the first line of defense for our homes. We will report on how those locks are ill-designed and why, based on studies by highly qualified research labs in the country.

To prepare us for the advent of IoT, Ai-Fi.net offers a partial but crucial defense, which is aimed to reinforce your first and last line of network protection for your personal space and your home in order to fend off the irrevocable loss of our privacy. We will offer an "domain" infrastructure, based on a clever design of end-to-end TLS fabric and its equivalent, through which you can fence in all your valuable assets, that hopefully will be adequately protected and remain in your possession even if they are attacked. It is our opinion that without this first and last line of defense, all other measures are futile. With it, intrusions are well defended against and at the same time we can be a bit more relaxed in knowing collateral damages are confined within private domains without the peril of personal data escaping into the darkness.

The protection through private domains can be simply illustrated as follows:

A domain is a network demarcation that separates your private possession from the rest of the Internet. It may consist of multiple "branches" so the domain demarcation line can be extended to cover many geographically separate areas. All your IoT devices are enclosed within some branches, each of which is completely shielded from the public Internet traffic except a few ingress/egress points guarded by Ai-Fi.net APs (Access Points). It allows only authorized traffic to enter after rigorous authentication. Once authenticated, the roaming devices may access all the branches within the domain as if they are interconnected through internal LAN (a.k.a. intranet). Each domain has a complete and private IPv4 address space to work with.

Threat Model and Security Perimeter

Physical Security

No defense is absolutely secure; security is a relative concept. The level of security of any instrument must be evaluated in the context of its designed utility against identified threats. Without qualifying the question, it is not meaningful to ask how many locks are required in order to secure our front door. It involves two variables: the perceived threats that might be launched against our home and the value of the assets inside our home to be protected. Our house door is probably not as well guarded as that of a bank's or a crack dealer's.

Physically breaking into a house is drastic enough to be a deterrence in itself. We probably will think twice about opening our front door to this guy in the picture above. Additionally, the logistics for planning a physical attack is quite involved nowadays and not surprisingly difficult to pull off, as our communities are studded with surveillance apparatus. The physical nature of the heist, the widespread use of security cameras, and the advances in forensics make it nearly impossible to commit a perfect crime. Not surprisingly, the risk of getting caught or the "clearance rate" in crime statistics, although low in non-violent property crime, is not negligible at around 13%[Crime].

On the other hand, nearly 700 million people in 21 countries experienced some form of cybercrime in 2017 (Source: Symantec)[CyberCrimeRate]. Strangely enough, there is no official statistics on the "clearance rate" even mentioned in any official reports. It's safe to say that the clearance rate is so low that there is no point in collecting the statistics. Most victims are very happy just to recover from the aftermath of the attacks, let alone help the crime fighters catch those perpetrators from alien territories like Nigeria, China, or Russia. As long as there is little bloodshed or heads bashed in, the pressure in solving them would remain minimal. Cyber crimes do pay, quite handsomely at a very low risk and near zero clearance rate[CyberFacts] at this point.

Simply put, the physical means in defending against cyber crimes can be quite effective. For securing your smart home, this first line of defense involves two steps:

  1. Create a security perimeter to fence in all your smart devices
  2. Restrict all traffic in and out of the perimeter through a well guarded AP (Access Point) with firewalls.

In Search of Security Perimeter

Adopting physical protection and connecting all household devices to our home router using only physical cables will create a "demilitarized" perimeter that thwarts wanton break-ins. Unfortunately, as the wireless connections are introduced, convenient as it may be, any physical security goes out the window. Once wireless devices are brought in, your household LAN is no longer physically secure and any kind of malicious hacking could be set in motion from all directions.

Obviously this is an oversimplification. Physical cables may be cut and disabled, much easier than shutting off the wireless or cellular connectivity. Burglars are known to shunt houses with wireless alarms and cameras that connect to home security companies through cellular networks. However, modern wireless gadgetry comes in a great number of varieties and introduces a completely new set of risks far more sinister than petty thefts. We must recognize that wireless means may be useful under many isolated application scenarios, but must not be used as the infrastructure building block because of its inherent vulnerability to open exposure. If wireless connectivity is the only option available, such as in the situation where a large number of IoT sensors are deployed, the security requirement must be carefully assessed with the understanding that physical security may no longer be taken for granted. Physical boundaries or strict confinement within a seemingly enclosed perimeter are not necessarily secure. Wireless intrusion is borderless.

Instead of searching for the unreliable physical security perimeter, Ai-Fi.net adopts the Deadbolt framework (more details later) that affords wireless connectivity but with stringent requirements in building a "soft" security perimeter. A device is considered inside the security perimeter when:

Artificially Intelligent Cyber Attacks

Artificially Intelligent Menace

[HackerBot]

injection of intelligence into "things"

the shear number and immense possible coverage of deployment of those "things"

no apparent leadership forming over the horizon

IoT security is more challenging with wider attack surface

Ever wondering why it is so involved to accomplish certain trivial tasks through the Internet, such as setting up a personal website, accessing your PC or smart appliances at home or getting a file from your work. To get to the bottom of these questions, we need to dig a bit deeper into the seemingly almighty Internet, which apparently is not capable enough for us ordinary netizens.

Trivia Quizzes: Part I

  1. Why am I using only private IP addresses inside my home? Why don't I get a public IP address so other people may find me.
  2. For browsing the net, why is the initiating or returning IP address of my browsing being shared with other homeowners and changing all the time?
  3. The Internet connection to your home is asymmetric, with the download speed typically outstripping upload speed commonly offered in the 30/5 to 100/10 ratio range, with the the latest Comcast gigabit cable at a grotesque 1000/3 download/upload ratio.

The obvious answer to all the questions above is the fact that home users of the Internet are traditionally considered "clients", who are freeloaders with very little to offer and therefore not important enough to have an independent presence on the Internet with public IP addresses. This is also why you need to sign up for an account on some social media in order to establish your social identity on the Internet or an account on Amazon in order to establish your electronic identity as a consumer. Currently the Internet has a platform-centric architecture with many Internet companies occupying most of the backbone resources. We'd like to consider ourselves as independent customers/consumers of various platforms, but this is more wishful thinking than reality. According to Bruce Schneier, an internationally renowned security technologist, called a "security guru" by the Economist:

[BSchneier]

As a consequence of this "Internet Feudalism", new advances of Internet technologies may not be directly applicable or adequately secured before the clear emergence of the winning feudal lords as rulers of the new technologies. The IoT revolution is clearly at this stage with the new possibility emerging daily of tempting benefits but without the comprehensive support of a ruling lord. This is why some new smart devices for the home are either not directly reachable or not sufficiently secured due to the lack of a comprehensive IoT infrastructure. There are many warring lords battling for supremacy in this arena with no clear winner in sight. If you are one of those brave souls, you may adopt several different smart home "frameworks", each of which is supported by some big companies such as Amazon, Apple, Google, or even Facebook. In that case you will have many different control apps on your cell phone, each having its own style and logo, with remote access capability and database only through their respective vendors. This level of complexity can only hinder the progress of IoT adoption.

Trivia Quizzes: Part II

With the current server-centric Internet architecture, more feudalistic than democratic, there are quite a few technical challenges if we want to throw off the shackles of those Internet companies, to be more decentralized and to move towards the next IoT revolution. We will be confronted with another set of trivia questions:

  1. Without the centralized social media like Facebook, are we going to lose our social networks that we have spent so much time in the past establishing them?
  2. With the centralized service platforms taking over all the service infrastructure and resources, how are we to reverse our role of passive clients and convert ourselves into active server providers? How are we to obtain the network resources required for this reversal so that our smart appliances in our smart home can be effectively managed?

For question #1, we simply need to have a new mindset towards our role as consumers of network services. Without losing much functionality, we can conduct our social networking in a "federated" fashion instead of the prevailing mode of gathering at a single behemoth platform such as Facebook. Actually this "federated" approach has been around for quite some time, with the email being the most familiar one. We choose to attach ourselves to a specific email service provider such as Gmail, Hotmail, or Yahoo Mail, and send or receive emails to others who may not belong to the same email service. To send an email to someone else not on the same email platform as your own, we simply name his/her email account ID with a suffix like so: "some-friend-of-mine@othermailserver.com". We don't require our friends and colleagues to sign up for the same email service platform before being able to communicate with us through emails. Similar federated social networking can be achieved, with "matrix.org" being the most successful and feature rich. Riding on the federated social network framework, you don't lose your friends and family on Facebook but gain additional contacts through other social networks fully insulated from Facebook. You can even roll your own "homeservers" to construct your own private social networks with 100% ownership without relying on anyone else.

For question #2, you need infrastructure support. Right now most of the resources on the public Internet are monopolized by a limited few who managed to occupy a disproportionately large amount of network resources, public IP addresses included, during the "land grab" phase of the Internet growth. Even the domain names are pretty much taken by those DNS grabbers.

Service Providers and IoT

The advent of IoT is about to turn the service-provider centric Internet upside down. The well touted shortage of IPv4 public addresses is a crucial issue only to service providers, who want to continue their monopoly on network resources and preserve the status quo without an inkling of what are going to transpire:

In other words, the arrival of IoT needs to bring with it the companion architectural changes required to make the next revolution of Internet services viable without sacrificing our security and privacy.

We at Ai-Fi.net firmly believe that based on many of the hard-won insights from traditional network security technologies the following principles provide the necessary cornerstones for the deployment of IoT:

  1. Although functioning as servers, most household IoT devices offer their services in a private setting. The traditional self-contained enterprise VPN is quite applicable to protect the smart homes by creating a security perimeter and operating within its confines. This architecture does not compete with traditional service providers for resources without aggravating further the shortage of IPv4 addresses. Each IoT world is identified and managed as an IoT domain, with its own private address space insulated from all other IoT domains.
  2. The mobile nature of the IoT devices poses a separate set of challenges. The many branches of a VPN must be allowed to relocate freely across many different service providers; an individual robot or drone must be able to roam over a wide area across many service providers as well, but still able to maintain its unique private identity so IoT Command and Control may reach them at any time. We want to be able to farm out our smart devices for designated missions and expect their safe returns some time later predictably.
  3. The network framework for IoT must allow the owners or operators of the domain to access those devices within it remotely securely.

We believe that Ai-Fi.net is correctly architected for the upcoming IoT challenges.

IoT Security

Introduction

Many device designers in the IoT arena may have extensive backgrounds in their respective fields, but they are less than adequate in deciding the security architecture for their application scenarios. They tend to underestimate the following highly critical consequences if the security issue is not correctly addresses:

Network Security and IoT

The goal of network security is quite straightforward: Deliver the correct messages from the sender to the receiver privately. Analytically the mechanism for implementing network security may be measured against the following requirements:

  1. Authentication: Both the sender and receiver must successfully pass the process of verifying their identity. (This is assuming the identity of the device has not been compromised. See the section below on device security.)
  2. Confidentiality: The messages passed between the parties are opaque to any third party. This must satisfy the "forward secrecy" such that any compromised session will not break the confidentiality of past sessions.
  3. Integrity: The delivered messages have not been tampered with or altered.
  4. Privacy: The "meta-data" regarding the delivery of the message, its initiator and its receiver is not discoverable or revealable to unintended or unauthorized parties.
  5. Availability: This is the opposite of DoS (Denial of Service)

The issues of availability or its related DoS attack are mostly resource related and beyond the scope of current discussion. We will delay the issue of privacy until later when we put the protection issues under its appropriate service provider contexts.

The requirements of authentication, confidentiality and integrity for exchanging messages among IoT "things" must not be short-changed. The seriousness of their compromise does not diminish because of their small size, low cost or lack of processing power. The security of an application deployment is as strong as its weakest link. These top three requirements are already realized in the standards based TLS, as previously mentioned, which is the only good thing we have.

An IoT application has no business in getting deployed if these requirements are not met. This is a hard-earned lesson and must not become a point of contention. If you need more convincing, just review the history of "Wireless Security" (or rather "Wireless Insecurity" more appropriately), which underwent many revisions from the initial ill-defined Wired Equivalent Privacy (WEP) in 1997, to WPA, to WPA2, to WPA3, which finally reaches the TLS quality. All the diversions along the way simply reflect the wishful thinking of members of the Wi-Fi Alliance. ("Wishful thinking" is the only term to describe the follies: WEP was at the outset considered as the "Wired Equivalent" privacy, which can't be further from the truth.) Loads of useless standards-writing would have been saved if we just adopted TLS on the first day of launching the wireless hardware.

Furthermore, these security requirements all have well established implementation standards, exemplified in a few well respected open source projects such as OpenSSL, with clearly defined minimal level of resource demand to be satisfied.

The only possible trade-off is to define a security perimeter and withdraw their direct network exposure of those IoT devices. Within the confines of the security perimeter, delegate the protection responsibility to a few standalone relay proxies with sufficient resources as a firewall for conducting all security functions on behalf of those devices contained within. If an IoT device fails to satisfy the resource demand, namely too slow to run TLS, it must either reduce its network exposure (or not to be deployed) or delegate its protection to external relay devices or firewalls occupying strategic positions within the identified perimeter:

RequirementResource DemandRelayed or Proxied
AuthenticationPKI, with or without CAReduced to authenticating only with the designated proxy
Confidentiality3DAS, AES or equivalentsRetain the same encryption strength, or alternatively fence in the device behind firewalls
IntegrityHMAC-SHA256 or equivalentsRetain the same hash function strength, or alternatively fence in the device behind firewalls

IoT and Artificial Intelligence

You need a new mindset in order to turn your household into a smart home. IoT devices are used to achieve simple tasks such as motion-activated light switches, as well as complex tasks such as controlling the ambient temperature throughout the house based on weather conditions and presence status of family members. They will quickly move past the phase of being standalone apparatus and integrated into the sphere of intelligent households centrally managed by a smart controller. Without being part of this central household intelligence "multi-app" objectives[ProgramIoT] are not possible to achieve, which involve multiple devices and cross-device triggers. An example of such a "multi-app" is the implementation of the rule that triggers the opening of certain windows when the temperature exceeds a certain threshold and only when the man of the house is present and it is not raining. This example rule and many others like it require a centrally managed focus operating within the security perimeter. It will quickly evolve into an artificially intelligent agent to manage and protect us living under its care.

The flip side of the story is the fact that those much feared malicious hackers and bots out there are bound to evolve into artificially intelligent agents as well. The trick is to discover the necessary IoT infrastructure in order to win the arms race between us and all other evil forces.

IoT Security Proxy

There are two popular architectures for delegating security functions to independent external relay proxies:

  1. Perimeter AP (Access Point): A well defined physical perimeter may be demarcated to fence in all the IoT assets and to create the DMZ (Demilitarized Zone) to guard against intrusions. Those defense mechanisms in the DMZ become the security proxy.
  2. Controller AP: All devices are exclusively connected to a security proxy, the Controller AP. They answer only to the AP. The connections to the AP must satisfy all three requirements. On the other hand, no direct connectivity to any protected devices is allowed except conducting through the AP as the access proxy. This is how the exposure to external hacking is reduced, but not the strength of the required calculations to enforce authentication, confidentiality and message integrity. This is largely an improvement on scalability, bandwidth expenses and amount of calculations. Note that all the protected devices may be sparsely distributed over a large area in a LAN or even a WAN setting.

IoT Security Architecture

The protection of an IoT device may be outlined in three security architectures:

End-To-End Direct Command Control

Once deployed, your drone is fair game to anyone with a flight controller. If the drone is controlled by direct line of sight radio signals, all three requirements must be satisfied in order to safely connect the drone to the controller. If the drone is controlled through some cellular mobile networks, the security relay or proxy may be introduced.

The perils of IoT Firewall

Remote exploits are an old threat; traditional servers have faced these problems for decades. Smart home is straightforward to protect through tried and true traditional framework only if all the IoT assets are hardwired to the edge router. As the router itself is the only device with exposure to the Internet, all IoT assets are protected by the security guarantee within the physical perimeter. The firewall (namely the reinforced edge router) is the only point of possible intrusion. Remote exploits are an old threat; traditional servers have faced these problems for decades. There is no shortage in technology for this line of defense, tried and tested from decades past even in the Enterprise settings. The other issue is whether those fenced in devices are allowed to be accessed or not from outside the perimeter or from the Internet by authorized personnel. (Ai-Fi.net provides both sets of functions securely. )

However, modern day IoT assets are usually connected wirelessly either through short range BLE (Bluetooth), Zigbee, ZWare and the likes, or most probably through the convenient omnipresent Wi-Fi at home. Sadly, the convenience of Wi-Fi has come at a very high cost in its potential risk. It is both a blessing and a curse. Relying on Wi-Fi for connectivity at home or anywhere immediately rules out the possibility of adopting the simple "Perimeter AP" as the protection strategy and makes it necessary to upgrade it into the more involved "Controller AP" architecture. When wireless means are introduced, the physical security is out of the window literally. Many homeowners are still under the illusion that the Wi-Fi router can be secured within the confine of the home by hiding the SSID, locking down MAC addresses, reducing the wireless router's power or judiciously detaching the guest accounts from the main household[wifi-myth], which turns out totally ill-advised and ineffective. The LED based Li-Fi is a new kid on the block, which requires a line of sight to deploy and is not capable of penetrating the wall. Its attack surface is narrower but still may fall victim to wireless attacks.

As our homes abound with wireless networks, there is little chance of demarcating the smart homes with secure perimeters. All devices must be secured and locked down individually and connect to the Controller AP in a point to point fashion, which can be either through ethernet cables for physical security or through wireless transport that must be carefully programmed to ascertain TLS strength through software, with authentication carried out on both ends. Any device owner ignores this requirement during installation at its own peril. If deployed correctly, Ai-Fi.net is how the owner of the devices may reach his IoT assets individually over the Internet. The path to individual devices must all be mediated through the Controller AP.

Ideally there are additional heavy liftings that may be adopted in order to reach the next level of security. It is based on the latest security framework: Deadbolt.

Deadbolted Device Security

The prerequisite of Network Security is the soundness of the involved devices themselves, which may be compromised due to outdated software, control flow exploits, software misconfiguration or poor software design. A compromised device, the defect of which may not be immediately detectable, may continue to carry on its network functions seemingly normally without apparent flaws. This is one of the threats the Deadbolt security framework[DeadBolt] is designed to solve with the following architecture:

DeadBolt considers an IoT device to be trusted if (1) its software is up-to-date, protects against control flow exploits, and uses TLS to exchange network data, or (2) the device’s network interactions are mediated by software that is up-to-date, protects against control flow exploits, and uses TLS to exchange network data. DeadBolt ensures that, for each device in an IoT deployment, the device can only use the network if condition (1) or (2) holds. By ensuring this, DeadBolt protects IoT deployments from network-based adversaries.

Under the Deadbolt framework, the AP (Access Point) is TPM-enabled. For IoT devices, the TPM-enabled devices and devices without TPM hardware are separately handled in order to guarantee the IoT devices running the correct version of software or alternatively relying on the AP to protect their software releases and controls when the devices are too low-end to provide their own protection. For those lightweight devices, they must be either cabled directly to the AP or having TLS based communication channels that interact exclusively with the AP.

In summary, under the Deatbolt framework the security perimeter is constructed by subjecting all devices to the control of the AP as follows:

  1. Cable the devices physically to AP directly.
  2. Connect (by wire or wirelessly) the devices to AP and make sure that they answer to the AP exclusively.
  3. Carry out the access control at AP only.
  4. Guarantee the soundness of devices through TPM and fail-safe software upgrade or proxied through their associated AP.

 

 

Smart Locks

Locking and Unlocking Requirements

For the remainder of this write-up, we will use the smart lock for the front door as an example to demonstrate the complicated issues involved in deploying a smart device.

Briefly, a smart lock must be able to:

  1. Recognize or ascertain the identity of the owner or owners of the property. This authentication may be performed locally at the door or remotely through the Internet. It may further allow authorization by the owners to parties other than the owners, which require another round of authentication of the delegated parties.
  2. Execute commands issued by the authorized parties such as: unlock door, lock door, authorize access of non-owners, revoke access of non-owners, et cetera.

In this discussion we examine the digital means of carrying out these two classes of functions either locally or remotely. Physical means of locking/unlocking the door by keys, numerical PIN pad, and other physical means are outside the investigation here.

The devil is in the detail:

All the questions above need to be answered sooner rather than later. Our preference is patently evident. We wish for an integrated smart home with a single authentication scheme and a unique configuration database residing at a secure and private storage that are remotely accessible for secure command and control.

Domain Knowledge and Usability

For convenience, some smart locks offer automatic unlock functions so that the authorized personnel may not have to unlock/lock unnecessarily frequently when they are within the facility after initial authorized entry. Unfortunately this piece of convenience feature turns out to be a handful to implement correctly[SmartLocks].

This is not directly related to network security, for which Ai-Fi.net is not able to offer much assistance in this respect. However, we'd like to advise early adopters of IoT technologies: pitfalls abound while various approaches and suggestions in enhancing the usability of this very kind are proffered. IoT application scenarios are not usually "tried and true" under the traditional IT context, as those devices are new and not yet popular compared to the simplistic data processing tasks of traditional IT. Each new smart device or its associated app may become the weakest link in the IoT deployment. We'd simply suggest that at this junction it is better safe than sorry.

Cloud-Based Smart Devices

Most IoT frameworks on the market are all cloud-based proprietary solutions:

 AppleGoogleAmazon
Hardware CertificationHomeKit certificationAndroid ThingsAWS IoT Hardware Program
App for Command and ControlHome AppCloud IoT Provisioning ServiceAWS IoT Button
Cloud for Configuration Storage and Remote AccessiCloudCloud IoT CoreAWS IoT Core

Listed are three popular IoT platforms, each requires the full commitment of the IoT device manufactures for hardware and compatibility certification.

Take Apple's offerings for an example. Apple HomeKit is a well defined App, which lays down stringent and well defined requirements that all participating devices must satisfy and support, including hardware certification and partnership agreement. However, in order to control your accessories remotely, one needs to sign in to iCloud with Apple ID on every device. Then turn on iCloud Keychain and Home in iCloud Settings. This support for remote access to one's IoT devices is totally proprietary, centralized with Apple mediates everything and along with it all transactions involving your private data. This iCloud-mediated access is very typical of Apple's autocratic practices and clearly privacy-invading.

Smart Locks under Ai-Fi Control

However, there are a few issues not ordinarily addressed by traditional firewall technologies:

  1. Smart door locks must work even when the facility they are in lost power or were without power, in which case there must be a backup power source in order to operate.
  2. The facility may not have access to the Internet.

Under the condition that the smart door is properly powered independently from the facility itself when necessary, Ai-Fi.net App on the mobile phone supports the DGC (Device-Gateway-Cloud) model with the phone functioning as a gateway to the Ai-Fi.net, through which the admission to the smart door may be controlled via remote APs. The Device to Gateway link is either through the Wi-Fi with the mobile phone as the Wi-Fi AP or through BLE.

 

TBD.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

References

^[BSchneier] 2015 Bruce Schneier: Data and Goliath: The Hidden Battles to Collect Your Data and Control Your World*, W. W. Norton & Company. ISBN 978-0-393-24481-6

^[Bluetooth] Bluetooth: With Low Energy comes Low Security

^[Crime] Clearance rate

^[CyberCrimeRate] 10/2018 100+ Terrifying Cybercrime and Cybersecurity Statistics & Trends

^[CyberFacts]3/2018 12 Alarming Cyber Security Facts and Stats

^[DeadBolt] 8/2018 Deadbolt: Securing IoT Deployment

^[Gartner] 4/2016 Gartner Says Worldwide IoT Security Spending to Reach $348 Million in 2016

^[HackerBot] 8/2018 Hackers Don't Have To Be Human Anymore.

^[IoTHacking] 5/2017 The 5 Worst Examples of IoT Hacking and Vulnerabilities in Recorded History

^[ProgramIoT] 10/2018 Program Analysis of Commodity IoT Applications for Security and Privacy: challenges and Opportunities

^[Ratcheting] Advanced cryptographic ratcheting

^[SmartLocks] 3/2018 Smart Locks: Lessons for Securing Commodity Internet of Things Devices

^[wifi-myth] 10/2013 5 Wi-Fi security myths you must abandon now