Friday, September 4, 2015

Security of the Internet of Things (IoT) Part II

This is the second in a planned series of three posts on the subject of the "Internet of things" (IoT).  This one will treat the security of the "thing" itself.  It is about how to ensure that the appliance can be used safely, how to protect it from outside interference, and how to use it to protect its data.

The problem of securing appliances is much more tractable than that of securing more open and general purpose systems like operating systems and browsers.  It should not be difficult to develop purpose-built appliances that do only what they are intended to do.  This idea is supported by the experience that we have with mobile computer (specifically iOS) "apps;" Most are orderly and well-behaved.  While there are millions that are connected to the Internet, only a handful have been turned against it.  While the attack surface of an iPhone might be quite large, that of an individual app is very small.  The value of a successful attack against an app is usually limited to that app.

While there have been reports of misuse of apps, they have been far more limited than our experience with PCs might have led us to expect.  While the number of mobile computers will soon exceed the number of more general purpose computers, the security problems have been much more limited. We have seen nothing approaching the kind of security problems that we have seen with Windows or Linux based personal computers.

The implication is that we can build safe things.  The fear is that we will not do so.  The fear is based in part upon the recent history with other kinds of computer systems.  It is amplified by reports of so-called "security researchers" who have found and reported on things that were not secure.  While we may have done okay with iOS, our experience with browsers has been frightening.  Even computers that are otherwise secure can be compromised by duping or baiting a user into simply pushing a button.

Let's look at the iOS experience to see what we might learn about how to build secure things.  First, things should run in a closed environment, either dedicated hardware, like a router, or in an environment isolated from other things like that provided by iOS.  Second, it should have a limited and easily understood application or use.

The app makes the device into an application only machine.  Unlike a personal computer, it does not present the function to make persistent changes to its own programming.  While it is a programmed device, it is not a programmable device.  The underlying computing functionality is hidden from the user.  The user should not be able to see or control the file system, write or execute an arbitrary program, or even make persistent changes to data by any means other than by operating the thing.

The program for the thing should be  written in an appropriate language and using an appropriate systems development kit (SDK).  One does not have to know the features of the iOS SDK to know that it makes it easier to do things right than otherwise.  If that were not so, we would not have well over a million apps with so few problems.

The thing should hide its computer from the network.  As with the user interface, the thing should hide its file and operating systems from the network interface.  Said another way, it should not answer on any standard "ports," but only those specific to the use or operation of the thing.

The thing's software should not present a multi-user interface.  As with the app, possession of the thing should be both necessary and sufficient for its use.  While many iOS apps do require "login" it is not for use of the app itself but to authenticate the user to a multi-user network application.

While the personal computer expects and supports late changes to its own programming, the app does not.  Late changes are made by replacing the app with a new version of itself rather than patching the existing one.  This is facilitated in part by the fact that the app is small and self-contained.  It is required because the limited function of the app does not contain the capability of making late and persistent changes to itself.

We should not conclude that building secure or "securable" things is easy but it is fair to conclude that it is possible and definitely easier than general purpose computers. However, while most "things" will work pretty much as intended, given the number of things and the number of sources, there will be broken things sold. Some of these will be in sensitive applications like healthcare, transportation, and banking.  These failures will not be seen as exceptions but as typical of the Internet of Things and maycause more fear, uncertainty, and doubt than diligence and care.

Monday, August 3, 2015

Security of the Internet of Things (Part I)

This is the first of a contemplated three posts on the subject of the Internet of Things (IoT).  In this post we identify the space and the potential,security issues.  In subsequent parts we will make recommendations to address the issues.  Comment, feedback, explication, and even argument are invited.

As the cost of information technology falls and the wireless Internet becomes more and more ubiquitous, we are witnessing the emergence of smart appliances, "things," that are connected to the public networks.  An early example was the smart printer; we have been living with these for almost a decade.  Others include baby monitors, front door monitors, lighting controls, and home security devices.

Perhaps an even earlier example was the ATM  While early ATMs used proprietary operating systems, protocols, and network connections, at some point they began to use Windows, Internet protocol, and Ethernet connections because this was the cheapest way to build them. We now have wireless ATMs and wireless point of sale devices.  Other examples include the Nest thermostat, the smart TV, the Chromecast, and smart watches.

One particularly interestiing example is the Samsung Smart Refrigerator that "will allow you to browse the web, access apps and connect to other Samsung smart devices – opening up a world of interactive communication and entertainment."  Note that none of these functions has anything to do with keeping food fresh.  They certainly distinguish this refrigerator from others but it appears that they are included mostly because this is a cheap way to do so.

Perhaps the most ubiquitous thing to date is the mobile computer, popularly called the "smartphone." It is interesting in part because of its ubiquity, in part because of the number of different things that it implements.  Each of the hundreds of thousands of its application is a different thing, everything from toys to banking machines.  Because of its falling cost and increasing power, we use it for things that we could hardly contemplate as recently as a decade ago.

These are real world examples but the technology is now so cheap that we must expect to see an accelerating flood of smart connected "things."  There will be smart things that are not connected, but connection will be so cheap and add so much value that most will be part of the Internet of things (IoT). While we are going to speak of "things" in the abstract, keep the examples in mind because they have things to teach us about the impact that they will have on our lives and our security.

There are at least three security issues associated with the IoT.  The first is that malicious actors will take control the of the thing and misuse or abuse its application to do harm to the owner or user of the device.  The favorite example is that of an implanted medical device instructed to kill its user.  This example is supported by so-called "research" that concludes that many early connected medical devices have implementation-induced vulnerabilities that might be exploited for malicious purposes.  More about medical devices in a moment.

The second security issue is that the underlying computer functionality or capacity of the device might be taken over to participate in attacks against other entities in the Internet.  The things might be co-opted into "botnets" and be used in denial of service attacks or brute force attacks against passwords or encryption keys.

The final security issue is that instances of problems, no matter how sparse will be used to sow fear, uncertainty and doubt about things in general.  Take the example of smart printers, that is most of the printers that have been sold in the last decade.  Millions of them have been sold by a half a dozen or so manufacturers for prices ranging from as little as a hundred dollars to thousands.  They are used to scan, print, and store our most sensitive data along with the potential to leak it.  Collectively they present a huge attack surface.  However, the number of reported attacks is exceeded by the number of  attack scenarios and "proof of concepts" dreamed up by "researchers" and reported by the media.  At least so far, "things" and their applications dwarf the problems associated with their use.

While the conversion of "things" to malicious purposes makes for dramatic Hollywood scenarios,  most devices will not be vulnerable to either takeover or malicious use, much less both.  However, all those that are vulnerable to takeover can be exploited for their computer function or capacity. This function and capacity can be compromised and turned against the host network for a variety of attacks ranging from simple,spoofing through denial of service to brute attacks against passwords and cryptographic keys.  It is this that we will argue is the most serious risk.

Saturday, May 9, 2015

On the Resilience of the Power Grid

The power generation and distribution system, for short "the grid." is an interesting system in a number of ways.  One of these is that, within fairly narrow limits, the supply must equal the demand.  There is a small amount of slack but little storage.  Supply decisions are made by utilities in 500 KWH increments while demand decisions are made by individuals 150 W at time.

Obviously such a system benefits from scale.  At least within limits, the more sources and uses in the system, the easier it is to achieve the necessary balance.  In order to achieve the scale, all providers and users,p within a geographic region embracing many large and small states, are connected in a market network.  Any supply, a generator, can be directed to any user.  Suppliers with excess capacity offer it for sale to all other suppliers in the grid.  Each supplier may buy from any other, and will do so,  as long as that suppliers offer is lower than his own marginal cost of generation.  

This market is highly automated and very efficient.  Not only does it provide a low average cost for all customers but it also provides reliability.  A utility that has a component, for example, a generator, failure, can use supply from any of its peers.  However, in the short run, the loss of supply may create an imbalance between supply and demand.  Other components may be momentarily overloaded.  Since a sustained overload might ultimately cause a component to fail in a destructive manner, components are designed to either shed load, e.g., from damage.   Within limits the system can absorb multiple simultaneous component failures, and re-balance, while maintaining, service to most users.

However, this design means that the grid is vulnerable to "cascading failures," in which the failure of one component may cause the protective shutdown of other components.  While the resilience of the system is continually improving, there will always be an upper bound to the number of simultaneous component failures that the system can tolerate.  When that threshold is crossed, apparently about once a generation, the system is designed to shut down in an orderly and non-destructive manner.  These successful shutdowns enable the system to resume normal service in hours to tens of hours. Such successful shutdowns will continue to be described by politicians and the media as "failures."  The designers and operators of the network will continue to think of them as successful "power grid security."

Notice that once the system has shut down, it must be restarted in a systematic way such that supply and demand are both added back to the system in such a way as to sustain the necessary balance between supply and demand.  Said another way, we cannot simply turn everything back on at once. This is complicated by the fact that many using components draw significantly more power at start-up than they do while up and running.  It is easy to imagine that restarting all the air-conditioners and refrigerators in a neighborhood at the same time, takes dramatically more power than sustaining them as they cycle on and off in normal operation.  While most components will restart automatically, some may require manual operation.  The more extensive the outage, the longer the re-start will take.  
Within limits we can increase the reliability of the grid by adding redundant capacity and automatic controls. Redundancy increases cost and drives down revenue per component.  Therefore, there is an economic limit to the amount of redundancy we will add.  As we add redundancy, we must add more automatic controls; redundant components and controls increase the complexity of the system.  At some point that increased complexity begins to cause more failures than it prevents.  A mean time to failure of infinity implies infinite cost; long before we reach that point, somewhere about a mean time to shut down of the entire grid of about twenty years, we will stop. 

Notice that even these massive shut downs are less disruptive than such natural disasters as ice storms where many homes may be without power or heat for days to weeks. 

Monday, May 4, 2015

Chip and PIN Compared to Chip and Signature

As we begin on the long process of changing credit cards from the obsolete magnetic stripe technology to smart (EMV) "chip" cards, there has been a lot of criticism of the decision of the credit card issuers not to implement "Chip and PIN."  Much of this discussion has asserted that "Chip and PIN" is more secure than the chosen chip card and signature strategy.  Apparently this position is so obvious that it has stifled analysis.

I assert that Chip and PIN is only marginally more secure than Chip and Signature. It protects against the fraudulent use of lost or stolen cards. However, fraudulent use of lost or stolen cards is only a small portion of the fraud. The largest part uses counterfeit cards; chips resist counterfeiting.
For both the individual and the issuer, the best protection against fraudulent use of lost or stolen cards is to report the card lost or stolen. The individual is now protected against any use of the card. The issuer will revoke the card and is now protected against any online use of the card.
Note that the effectiveness of revocation depends in part upon the market. In the U.S., where most transactions take place online, it is very effective. In markets where the infrastructure is less robust and many transactions take place offline, revocation is less effective. Thus in the U.S. issuers are opting for Chip and Signature while in other markets Chip and PIN is chosen.
Note that only the issuers know what the losses are for fraudulent use of lost or stolen cards is, that is, how much fraud might be reduced by the use of a PIN on all transactions. It is fair to assume that they know what they are doing.
Some have asserted that, in the absence of the PIN, security will rely upon clerks to reconcile a signature on the transaction document to,the reference signature on the card.  For most routine transactions we do not rely upon the clerk to verify the signature or even to touch the card. While in some places we still sign a chit, at checkout stands we sign on a little tablet (I hate them.) No one ever checks the signature unless the transaction is disputed. Said another way, at least in the U.S.,
we rely mostly on possession of a current card to authenticate most transactions; both signatures and PINs are backup and there is little to choose between them?

Sunday, February 22, 2015

On Trust

Steve Bellovin wrote:

I'm not looking for concrete answers right now. (Some of the work in secure multiparty computation suggests that we need not trust anything, if we're willing to accept a very significant performance penalty.) Rather, I want to know how to think about the problem. Other than the now-conceputal term TCB, which has been redfined as "that stuff we have to trust, even if we don't know what it is", we don't even have the right words. Is there still such a thing? If so, how do we define it when we no longer recognize the perimeter of even a single computer? If not, what should replace it? We can't make our systems Andromedan-proof if we don't know what we need to protect against them.
When I was seventeen I worked as a punched card operator in the now defunct Jackson Brewing Company.  I was absolutely fascinated by the fact the job to job controls always balanced.  I even commented on it at the family dinner table.  My father responded. "Son, those machines are amazing. They are very accurate and reliable.  But check on them."  Little could either of us know that I would spend my adult life checking on machines.

At the time when the work was being done on the TCB, Ken Thompson wrote his seminal response to the Turing Award in which he asserted that unless one wrote it oneself in a trusted environment, one could not trust it.

Peter Capek and I wrote a response to Thompson in which we pointed out that in fact we do trust. That trust comes from transparency, accountability, affinity, independence, contention, competition, and other sources.

I recall having to make a call on Boeing in the seventies to explain to them that the floating point divide on the 360/168 was "unchecked." They said, "You do not understand; we are using that computer to ensure that planes fly."  I reminded them that the 727 tape drive was unchecked, that when you told it to write a record, it did the very best it could but it did not know whether or not it had succeeded.  The "compensating control" in the application was to back-space the tape, read the record just written and compare it to what was intended.  If one was concerned about a floating point divide, the remedy was to check it oneself using a floating point multiply.

In the early fifties one checked on the bank by looking at one's monthly statement.  Before my promotion to punch-card operator, I was the messenger.  Part of my duties included taking the Brewery's pass book to the bank every day to compare it to the records of the bank.  As recently as two years ago, I had to log on to the bank every day to ensure that there had been no unauthorized transactions  to my account.  Today, my bank confirms my balance to me daily by SMS and sends another SMS for each large transaction.  American Express sends a "notification" to my iPhone for every charge to my account.

In 1976, for IBM, I published Data Security Controls and Procedures.  It included the following paragraph:

Compare Output with Input 
Most techniques for detecting errors are methods of
comparing output with the input that generated it.
The most common example is proofreading or
inspecting the context to indicate whether a
character is correct. Another example, which
worked well when input was entered into punched
cards, is key verification in which source data is key
entered twice. Entries were mechanically compared
keystroke by keystroke, and variances were flagged
for later reconciliation. 
Said another way, while we prefer preventative controls like checked operations and the TCB, ultimately, trust comes late from checking the results.

I often think of the world in which today's toddlers will spend their adult lives, the world that we will leave to them. My sense is that they will have grown up in a world in which their toys talked and listened and generally told the truth, but that every now and then one must check with dad.

Friday, February 20, 2015

Fraud Alerts

Recently Bank Info Security raised the question of whether fraud alerts can be used to garner customer loyalty.  I suggest that this is the wrong question.

In a world in which merchant, bank, and insurance systems are routinely breached by nation states and rogue hackers and in which hundreds of millions of credit card numbers, PINs, social security numbers, e-mail addresses, and dates of birth are freely traded for pennies in both white and black markets, it is hardly a question of "fraud alerts and customer loyalty."

I prefer to do business via proxies like PayPal, Amazon, and Apple Pay, that hide my credit card and bank credentials from the merchant.  However, I use my American Express card exclusively because all transactions to my AmEx account are communicated to me in real-time via the American Express app on my iPhone. Both AmEx and I understand that this is essential to our mutual security. It is not a mere convenience or customer loyalty gimmick.

Kenneth Chennault, CEO of AmEx, speaking before the President's "Cyber Security" urged that the regulation forbidding the use of SMS for this purpose be relaxed.  This regulation that was intended to discourage nuisances is in fact resisting a necessary use.

Anthem, the victim of the world's largest breach has offered to pay for fraud protection services for some of its customers, on an opt in basis. eBay, the victim of the second largest breach has not even done that. I think we need a law that requires all banks and credit bureaus to provide automatic notice of all activity to their subject's accounts on an opt-out basis.  While I am willing to pay for such a service, it really ought to be a cost to those who trade in data about me.

Rogue hackers, data brokers, and the intelligence agencies have all but destroyed the trust on which our commerce is based. Reliance upon periodic statements and late detection of fraud is no longer adequate. "Fraud alerts" are not a marketing feature,  In order to restore some order to our markets, "activity notices" need to become standard.

Saturday, February 7, 2015

Crypto Wars Redux

This morning, while researching another question, I found the following from Aaron Schumann to, quoting a post to the Risk Forum from me.  While written a quarter of a century ago, it might have been written this morning.
From: (Aaron Schuman)
Subject: Congress to order crypto trapdoor?
Message-ID: <1991apr11 .231215.19779="""">
Date: 11 Apr 91 23:12:15 GMT 
The United States Senate is considering a bill that would require
manufacturers of cryptographic equipment to introduce a trap door,
and to make that trap door accessible to law enforcement officials.
If you feel, as I do, that the risk of abuse far outweighs the
potential benefits, please write to Senators Joseph Biden and Dennis
DeConcini, and to the Senators that represent your state, asking that
they propose a friendly amendment to their bill removing this

I don't have exact addresses for Senators Biden and DeConcini, and
I hope someone will post them here, but the Washington DC post office
can deliver letters addressed to
Senator Joseph Biden Senator Dennis DeConcini
United States Senate and United States Senate
Washington, DC 20510 Washington, DC 20510

RISKS-LIST: RISKS-FORUM Digest  Wednesday 10 April 1991  Volume 11 : Issue 43
Date:  Wed, 10 Apr 91 17:23 EDT
Subject:  U.S. Senate 266, Section 2201 (cryptographics)
Senate 266 introduced by Mr. Biden (for himself and Mr. DeConcini)
contains the following section:
It is the sense of Congress that providers of electronic communications
services and manufacturers of electronic communications service equipment shall
ensure that communications systems permit the government to obtain the plain
text contents of voice, data, and other communications when appropriately
authorized by law.
The referenced language requires that manufacturers build trap-doors
into all cryptographic equipment and that providers of confidential
channels reserve to themselves, their agents, and assigns the ability to
read all traffic. 

Are there readers of this list that believe that it is possible for
manufacturers of crypto gear to include such a mechanism and also to reserve
its use to those "appropriately authorized by law" to employ it?
Are there readers of this list who believe that providers of electronic
communications services can reserve to themselves the ability to read all the
traffic and still keep the traffic "confidential" in any meaningful sense?
Is there anybody out there who would buy crypto gear or confidential services
from vendors who were subject to such a law? 
David Kahn asserts that the sovereign always attempts to reserve the use of
cryptography to himself.  Nonetheless, if this language were to be enacted into
law, it would represent a major departure.  An earlier Senate went to great
pains to assure itself that there were no trapdoors in the DES. Mr. Biden and
Mr. DeConcini want to mandate them.  The historical justification of such
reservation has been "national security;" just when that justification begins
to wane, Mr. Biden wants to use "law enforcement."  Both justifications rest
upon appeals to fear. 
In the United States the people, not the Congress, are sovereign; it should not
be illegal for the people to have access to communications that the government
cannot read.  We should be free from unreasonable search and seizure; we should
be free from self-incrimination.  The government already has powerful tools of
investigation at its disposal; it has demonstrated precious little restraint in
their use. 
Any assertion that all use of any such trap-doors would be only
"when appropriately authorized by law" is absurd on its face.  It is not
humanly possible to construct a mechanism that could meet that
requirement;  any such mechanism would be subject to abuse.
I suggest that you begin to stock up on crypto gear while you can still get it.
Watch the progress of this law carefully.  Begin to identify vendors across the
William Hugh Murray, Executive Consultant, Information System Security 21
Locust Avenue, Suite 2D, New Canaan, Connecticut 06840       203 966 4769

We fought this battle once and thought that we won the war.