Basic Elements

Generally speaking, computing devices consist of a central processing unit (CPU), memory, and some kind of input/output (I/O). The memory typically includes some kind of nonvolatile storage (so there’s a program to run when the machine first powers up) and some kind of slower but more efficient backing store for longer-term storage. In a simpler universe, the CPU would fetch an instruction from memory, figure out what the instruction means, carry it out, and then go on to the next one. “Carrying out” the instruction would involve reading or writing to memory or an I/O device or an internal CPU register, and/or doing some mathematical operation. However, the universe is not that simple anymore. The field traded simplicity for speed (as I have to cover in the “dirty tricks” section of my architecture course): pieces of many instructions may be carried out at the same time and may be executed out of order or speculatively; parts of memory may be tucked away in smaller but faster caches.

I/O typically includes some way of interacting with a human (e.g., keyboard and display) and some kind of networking to enable interaction with other computing devices.

The hardware also requires software: the BIOS to run at boot time, application programs, and an operating system to provide a clean and hopefully protected environment for the applications.

Moore’s Law

An important part of understanding the long-term progression of computing is Moore’s Law. Despite its official-sounding name, it’s not actually a “law” (like those of Newton), and it’s not as well defined as one might like: ask two computing professionals, and you will likely hear two different versions.

Moore’s Law refers to a pattern observed by Intel cofounder Gordon Moore decades ago, at the dawn of the modern computing era. Every N years, the complexity of integrated circuits—measured in various ways, such as transistor density—doubles (see Figure 2-1). The pattern of growth has continued to the present day, despite regularly occurring reports that some fundamental physical or engineering limit has been reached and it cannot possibly be sustained. It’s also generally acknowledged that the continued existence of this pattern is in some sense a self-fulfilling prophesy: it can take several years to design the next-generation microprocessor, and the industry may start the design assuming a fabrication ability that that does not yet exist but is forecast to exist by the time the design is done. (Using a simile from American football, some¹ have quipped it’s “like throwing a Hail Mary pass, then running down the field and catching it.”)

Figure 2-1. Computation has followed the prediction of Moore’s “Law”: doubling every two years, power increases exponentially. (Adapted from WikiMedia Commons, public domain.)

When we step back and look at the progress of computing, the exponential growth characterized by Moore’s Law has several implications. The “current"-generation CPU keeps getting exponentially more complex. As one consequence, computing applications that might previously have seemed silly and impractical (because they would take far too much computing time and memory) become practical and commonplace. (The things done today by ubiquitous smartphones would have been dismissed as too crazy to consider had they been proposed as research projects in 1987—I was there, and I was one of the ones doing the dismissing.) We also get the flip side of increased complexity: large systems (especially software systems) are harder to get right and can have surprising behaviors and error cases.

Another consequence is that things get cheaper—particularly as previous-generation processors become repurposed in embedded devices. As an XKCD cartoon observed, even if you stay two steps behind the technology curve, you still see the same exponential growth—only it’s much cheaper! In the classroom, I’ve taken to borrowing a colleague’s trick: comparing the surprising prevalence of previous-generation processors to the surprising prevalence of “lesser” species, such as insects.

How IoT Systems Differ

By definition, most IoT devices will be embedded systems: computers embedded in things that don’t look like computers.

If one were to ask how embedded systems differ from standard computers, the initial answer would be, “they’re much smaller and don’t do as much.” To save money and because the systems might not have to do very much, the physical size and computational power might be limited. Systems that must run on batteries will also be designed to reduce power consumption. Systems that do not work directly with humans may skip the human I/O devices; systems without the need to interact with other systems may skip the networking. Systems that do not do very much may also skip the nonvolatile backing store (if there’s not much to store) or use semiconductor flash memory instead of disks; such systems may additionally have an OS that does not support much multitasking (if there’s not much to be done), or even skip the OS altogether.

However, thanks to Moore’s Law, this initial answer is starting to be less true, because “small, cheap” computational engines are also becoming more powerful. When it comes to prognosticating the future IoT, Moore’s Law has two somewhat different implications:

1. Thanks to the exponential curve, many IoT devices deployed in the future will be powerful, strong computational engines, by today’s standards. Indeed, we’re already seeing this creeping functionality and power in IoT devices, for instance, full Linux installations and network support and built-in web servers. (I recently discovered my Kindle reader has a web browser!)

2. IoT devices embedded in long-lived “things” will then fall behind the curve; by the standards current N years from now, the computing devices embedded in older refrigerators, cars, and bridges will likely seem quaint and archaic.

However, note that I opened this section with the qualifier “most.” A computer is a digital circuit that does things (certain inputs trigger certain outputs and cause the internal state to change), but structured in a particular way: one piece executing instructions coded as binary numbers stored in another piece. One can build digital circuits to provide such behaviors without the full Turing generality of a computing engine: indeed, this why Dartmouth’s Engineering School offers both a “Digital Design” course and a “Microprocessors” course. My soapbox conjecture is that, due to the incredible flexibility and reusability of standard components—as well as the computational nature of many of the tasks we want them to do—the IoT will mainly consist of computers, rather than noncomputational engines.

Another way embedded systems can differ from traditional computers is in their lifetime: a computer embedded in some other kind of thing needs to live as long as that thing. Greeting cards that play “Happy Birthday” don’t live very long, but automobiles and appliances may last decades, and bridges and electrical grid equipment even longer. Chapter 4 will discuss some of the relevant security issues arising from computational power, exposed interfaces, software complexity, and long lifetimes.

Connection to Other Computers

Will IoT devices be networked? Yes, it seems a bit ironic that something we’re calling the Internet of Things may in fact not involve networking, but the working definition we’ve been using—adding computational devices to everything around us—allows for that possibility. (Indeed, I recall a very elegant and effective “smart home appliance” pilot where computation added to the appliance could sense when the electric grid was stressed and adjust its internal operation appropriately without ever needing to talk to anything else.)

For devices that are networked, what is the physical medium of communication? The natural choices here are wire (e.g., the Ethernet connection in Figure 2-2) or radio. (To make things tangible, Figure 2-3 shows some inch-sized radio modules for IoT applications.) In the research world, a colleague of mine is even exploring the potential of using light as a medium, even in a dark room.

Figure 2-3. Example of small, inexpensive radio modules for IoT applications. (From Wikimedia Commons, Mark Fickett.)

When it comes to radio, it’s important to remember that electromagnetic radiation is not magic. Depending on the choice of power and wavelength (proportional to frequency), textbook-level analysis predicts signals from wireless networking will travel anywhere from a few centimeters to many kilometers. However, textbooks are not the same as the real world; an old-time engineer I worked with often ranted that young computer scientists would believe that if the spec said signals would travel 10 meters, then any device within 10 meters would receive them perfectly but any device beyond 10 meters would hear nothing. As anyone who has tried to make a cellphone call in Vermont or northern New Hampshire knows, it’s not that simple.

When discussing radio-based networking, it’s tempting to use the term “WiFi.” However, this is somewhat akin to using the term “Kleenex” for a facial tissue: the WiFi Alliance established the term for wireless networking conforming to certain (evolving) IEEE standards, but there are other approaches as well, such as Bluetooth (an example of closer-range communication) and ZigBee (which has been seeing deployment in industrial control settings). Many in the industry eagerly await the coming of 5G wireless networking, heralded to provide vastly greater speeds and increased reliability.

One interesting consequence of new wireless stacks and the shrinking packaging from Moore’s Law is that, initially, it can be hard to probe the wireless interface for security holes due to unplanned input (see “Instance: Failure of Input Validation”) because the interface is buried inside a larger module; the article “Api-do: Tools for exploring the wireless attack surface in smart meters” discusses some of my lab’s work in this space [5].

Beyond the physical medium itself, there’s the question of the protocols used to communicate. Again, “internet” in the term “Internet of Things” suggests to some that the IoT must, of necessity, use some flavor of the standard Internet Protocol (IP) stack. As with any engineering decision, there are advantages and disadvantages to this design choice—on the one hand, it’s nice to be interoperable with the known universe (i.e., the Internet of Computers). But on the other hand, incorporating the IP stack may incur performance and complexity costs that don’t fit within the constraints of the real-world application. daCosta [2] makes an excellent case for this latter point. (And, as Chapter 5 will explore, many IoT application scenarios may not require the fully general communication pattern of the internet.)

In the Internet Protocol, each device receives a unique address. The emerging IPv6 (which has been in the process of succeeding the current IPv4 for a decade or so) is often touted as a special enabler of the IoT because IPv4 only allowed for $2^{32}$ addresses (approximately 4 billion), whereas IPv6 allows for $2^{132}$—a factor of a trillion billion billion more.

The Backend

As discussed earlier, Moore’s “Law” is bringing exponential increases in semiconductor density; leading to increases in the power and storage ability of computing; in the complexity of what becomes “feasible” to realize in computer software; and in affordability. However, these trends affect not just small devices deployed in the IoT but also the big devices in the IoC. The computing industry has seen consequences in many areas: Cloud computing:: Giant (but virtual and remote) servers available for inexpensive rental. Big data:: Massive amounts of available data on which to compute. Big data analytics:: Increases in the sophistication of what can be feasibily calculated from these large data sets. Deep learning:: Increases in the sophistication of one particular family of approaches.

(A deeper explication of analytics and deep learning is beyond the scope of this book, but for an introduction, see Chapter 17 in my earlier security textbook [8].)

Other industries have been quick to exploit these consequences. To quote a McKinsey report [6]:

The data that companies and individuals are producing and storing [in one year] is equivalent to filling more than 60,000 US Libraries of Congress….

Big data levers offer significant potential for improving productivity at the level of individual companies…. For instance, Tesco’s loyalty program generates a tremendous amount of customer data that the company mines to inform decisions from promotions to strategic segmentation of customers. Amazon uses customer data to power its recommendation engine “you may also like …” based on a type of predictive modeling technique called collaborative filtering…. Progressive Insurance and Capital One are both known for conducting experiments to segment their customers systematically and effectively and to tailor product offers accordingly.

These transformations of “big” computing are relevant to the tiny devices in the IoT because they can be tied together. Connecting the IoT to the IoC lets the IoT take advantage of this big data backend, both by providing new sources of “big data” and by taking actions driven by the big data analytics. Indeed, the tie is so tight that a set of guidelines to bring security to IoT product development was recently issued—by the Cloud Security Alliance [1]. In their Harvard Business Review article [7] (discussed further in Chapter 7), Porter and Heppelmann see the IoT/IoC connection as a critical part of how the IoT will transform business (and, hence, the world). On the flip side, some lament the problem of digital exhaust: the fact that much of the data being generated by an instrumented world is not actually used.

Of course, the tie-in also lets us use all the fashionable buzzwords—IoT, cloud, big data, analytics—in a single sentence while keeping a straight face.