Categories
Building Trust Internet of Things (IoT) Privacy Security

The Internet of Things: Connecting the Dots to Become a Smart Consumer

According to a recent survey conducted by Consumers International and the Internet Society, 63% of consumers think the way Internet-connected devices collect data is “creepy.” The Trust Opportunity: Exploring Consumer Attitudes to the Internet of Things, which polled people in the US, Canada, Japan, Australia, France, and the UK, also found that 73% of consumers think people using connected devices should worry about eavesdropping. And yet, new connected devices are being introduced practically every day, and sales show no sign of slowing down.

The word “smart” is used to describe almost all of these devices. But is that right?

The marketing around the Internet of Things (IoT) has become almost non-stop. Smart-this will make your life better, happier, more efficient. If only you had smart-that, you would reap the benefits of the marvelous technological age in which we live. But this often leaves out key information consumers need to make real smart choices.

It’s really about connectivity. For instance, that smart oven is a computer that happens to get hot in the middle. These IoT devices are able to perform smart functions because they are connected to the Internet. And while the marketing focuses on features and functionality, it often glosses over privacy and security implications.

Just like any computing device, privacy and security are major concerns – and they’re never solved. They’re ongoing processes that involve continuous updates to fix bugs and security vulnerabilities.

As these devices are proliferating, they’re collecting data from and about us. They may collect a great deal of data, in many cases far beyond what users would expect based on their functions. This is not an accident. This data can help formulate a very comprehensive picture of our lives – our habits, preferences, health issues, location and travel patterns, and much more. This aggregate picture can be used for purposes we often don’t know about, much less approve of. This data collection can extend past the owners of these devices – to anyone who enters a home or business where they’re in use. Is that smart home assistant listening to and recording everything we say, in the guise of listening for the “trigger word”?

Which is why it’d be more accurate to describe these products as connected.

Given the risks, we have to be careful consumers. This means doing our homework and researching products and services – even asking questions of our friends when we enter their homes.

In reality, these are connected devices and should be treated that way. Smart? Maybe not. But we can be!

Ready to get IoT smart? Read Top Tips for Consumers: Internet of Things Security and Privacy.

Categories
Building Trust Internet of Things (IoT)

The Internet of Things: Why ‘Trust By Design’ Matters

As we have seen vividly in recent years, inadequate security and privacy protections in the Internet of Things (IoT) can have devastating impacts – on Internet users and core infrastructure. The high profile Mirai botnet distributed denial of service (DDoS) attack in 2016 was a dramatic example of the effects of poor security in IoT devices, and CloudPets connected teddy bears were withdrawn from sale by most retailers after it was revealed that millions of voice recordings between parents and their children were exposed. But the threats from these insecure devices don’t vanish when they are updated or recalled, since there is often a large number of them still in service, and still vulnerable.

Because of this, the Internet Society is particularly focused on improving the security and privacy of consumer IoT. As a rapidly growing area, it is especially vulnerable and has been exploited by malicious actors.

That’s why we’re encouraging manufacturers to adopt Trust by Design.

“Trust by Design” – an umbrella term that includes Privacy by Design and Security by Design – is an essential component of a healthy IoT ecosystem. It has significant implications beyond IoT for the health of the Internet as a whole, and all of its users.

The Privacy by Design concept was developed by Dr. Ann Cavoukian in the 90s in response to the growing and systemic effects of information technologies and large scale data systems. It has since become a foundational concept, underlying much of the work on privacy protection that has followed. There are 7 key principles:

  1. Proactive not reactive: preventative not remedial
  2. Privacy as the default setting
  3. Privacy embedded into design
  4. Full functionality: positive-sum, not zero-sum
  5. End-to-end security: full lifecycle protection
  6. Visibility and transparency: keep it open
  7. Respect for user privacy: keep it user-centric

While all 7 principles are essential, there is one we place particular emphasis on (especially with manufacturers): privacy embedded into design.

“Privacy measures are embedded into the design and architecture of IT systems and business practices. These are not bolted on as add-ons, after the fact. The result is that privacy becomes an essential component of the core functionality being delivered. Privacy is thus integral to the system, without diminishing functionality.”

There are several interpretations of Security by Design. The Open Web Application Security Project (OWASP) Foundation does a good job of explaining the fundamental principles:

  1. Minimize attack surface area
  2. Establish secure defaults
  3. Principle of Least privilege
  4. Principle of Defense in depth
  5. Fail securely
  6. Don’t trust services
  7. Separation of duties
  8. Avoid security by obscurity
  9. Keep security simple
  10. Fix security issues correctly

We believe proper security should be included at all steps of the design and architecture of IoT systems, not as an afterthought.

The Online Trust Alliance (OTA, an Internet Society initiative) IoT Trust Framework has 40 key principles that provide a set of guidelines for manufacturers as they design and develop products and services ­– with privacy and security as a top priority. Developed through a consensus-driven, multistakeholder process, this IoT Trust Framework is unique in two significant ways:

  • It takes into account the lifecycle issues associated with IoT products and services..
  • It addresses the entire ecosystem, holistically, including devices/sensors, mobile apps, and backend services. Most frameworks focus on just the devices, but a system is only as strong as its weakest link.

There is a great deal that we can all do. In particular, it’s important that:

  • Manufacturers take affirmative steps to improve the security and privacy of the devices they produce
  • Retailers understand the role they play and the impact they can have when they take these factor into account when deciding upon which products to sell
  • Consumers inform themselves, using credible sources, to understand the security and privacy aspects of IoT devices they are considering or already using
  • Policymakers and regulators look at the roles they can play and work together with other key stakeholders toward better outcomes

Learn more about Trust by Design and what manufacturers, retailers, consumers, and policymakers can do:

Categories
Building Trust Internet of Things (IoT) Security

Internet of Things Devices as a DDoS Vector

As adoption of Internet of Things devices increases, so does the number of insecure IoT devices on the network. These devices represent an ever-increasing pool of computing and communications capacity open to misuse. They can be hijacked to spread malware, recruited to form botnets to attack other Internet users, and even used to attack critical national infrastructure, or the structural functions of the Internet itself (we give several examples from recent headlines in the Reference Section, below).

The problem this poses is what to do about IoT as a source of risk. This blog post includes reflections on events that came to light in recent weeks, sets out some thoughts about technical mitigations, and sketches out the boundaries of what we think can be done technically. Beyond those boundaries lie the realms of policy measures, which – while relevant to the big picture – are not the topic of this post.

Why are we exploring this issue now? Partly because of our current campaign to improve trust in consumer IoT devices.

And partly, also, because of recent reports that, as a step towards mitigating this risk, connected devices will be subjected to active probing, to detect whether or not they can still be accessed using default user IDs and passwords. Here is one such report, from the IEEE.

We believe active probing raises practical, privacy, and security risks which ought either to rule it out as an approach, or ensure that other, less risky options should always be considered first.

Remote devices: control, ownership, and responsibility

Much of the power of a distributed denial-of-service (DDoS) attack comes from the ability to recruit devices all over the planet, regardless of the physical location of the attacker or, indeed, the target. One countermeasure is to make it harder for a malicious actor to gain remote control of an IoT device.

Gaining control of a device involves (or should involve) authenticating to it as an authorized user. IoT devices that either have no access control, or have access control based on a default password, have little or no protection against such a take-over. It is therefore often suggested that an early step towards securing connected devices is to ensure that users replace the default password with one that is hard to guess.

This step, though, is not without obstacles. Users are notoriously bad at choosing and changing passwords, frequently choosing trivial ones if they bother to set passwords at all, and of course, sometimes not even realizing that they should set a password in the first place.

Consumers’ behavior might also be based on an assumption that their devices are safe. They might assume, by default, that their Internet service provider (ISP) or connected-home solution provider is not supplying a device that puts them at risk through poor security – just as they might expect the device not to catch fire in normal use.

Multiple stakeholders, expectations and requirements

As you can see, we already have a problem whose solution may require action by more than one stakeholder:

  • Device manufacturers need to design their products to require some form of access control, and to prompt the user to enable it
  • Users need to have the awareness and discipline to use the access control mechanism and, if necessary, remember and replace passwords when needed
  • Users may, under some circumstances, assume that “someone else” is taking care of keeping their devices safe and secure

And all this has to be done in ways that reconcile the triangle of requirements, from which, traditionally, you can “pick any two.” The resulting control must be:

  • Secure (otherwise it has missed the point)
  • Usable (if it is too hard to understand or inconvenient, users will ignore it)
  • Manageable (it must be possible to repair, replace or update the control without compromising the usability of the device, or the security and privacy of the user)

In the IoT context, two further issues must be addressed.

First, whatever the solution, it must be affordable. Otherwise, “secure but expensive” products will tend to lose market share in favor of “insecure but cheap” competitors, and the risk represented by insecure IoT devices will continue to grow.

Second, the process as laid out above has a flaw, namely, “that’s not where we’re starting from.” Connected devices with poor security are already widely available and deployed in vast numbers. In those cases, it’s too late for manufacturers to design security into the product, so we need to look for alternative means to mitigate the risk of IoT devices as a threat vector.

Choosing the appropriate intervention

If the device has simply been designed without appropriate security mechanisms, and without the means to add them once deployed, and if it presents a significant risk to people’s security or well-being, there’s little to be done other than try to withdraw it from the market. (For instance, in 2017 German authorities issued a ban against a connected doll, on grounds that it was a de facto surveillance device, and could also put children at risk.)

If already-deployed devices can be secured by user action, the question becomes one of deciding how this can best be achieved. We think there will be a range of options, some more appropriate to different kinds of connected device than others.

General public-awareness campaigns, aimed at informing consumers about the importance of good password practice, may be ineffective or insufficiently accurately targeted to be relevant; but how do we increase the accuracy of such messages without intruding on users’ privacy?

Is it acceptable to target the buyers of specific kinds of device, or specific brands? Should ISPs have the means (or a duty) to scan their networks for those devices and alert their subscribers to the potential risks? Should they even test devices on their networks to see if the default password has been changed? As a last resort, and given the potential threat IoT presents to critical national infrastructure, do even governments have a responsibility in such cases, and is it desirable for them to intervene, either directly or through the ISP?

As the IEEE article notes, in comments from the Information Technology Center of the University of Tokyo, a large-scale initiative like this increases the number of stakeholders who must play a role. It will probably involve the government, an approved technical institute, and ISPs. It may mean governments have to reconcile conflicts between the actions they wish to take, and laws relating to personal privacy, consent, or unauthorized computer access. Those decisions are, as we noted, beyond the scope of this post, except to note that they increase the difficulty of ensuring that the “active probe” approach is manageable, legal and safe.

Conclusions and Recommendations

We recognize that circumstances will vary, and different situations may call for different approaches. Here is an indication of the range of interventions we think can apply. This is not an exhaustive list, but it serves to show that many options are available, and several may be needed.

  • Security by design. If all IoT devices were well designed in the first place, their risk would be greatly reduced.
  • Secure lifecycle management. Good design includes the ability to manage deployed devices over their whole lifecycle, including secure updates to firmware/software, and secure decommissioning. (This could imply that some processes and protocols need to include a “consent” step.)
  • Lab testing of devices. Assess new devices against quality criteria for security and lifecycle management, and provide feedback to manufacturers. This could extend to include certification and trust-marks.
  • General awareness-raising campaigns (e.g., encouraging users to change default passwords).
  • Targeted awareness raising/call to action (this might be based on the results of lab testing, in the form of a manufacturer’s “recall” notice for unsafe products).
  • “Passive” device targeting (e.g., an ISP can detect traffic that indicates an unsafe device, and sends an out-of-band alert to the user suggesting remedial action).
  • “Active” device targeting (e.g., an entity scans for device types known to have a security flaw, and notifies the user with suggested actions).
  • “Active probe” (e.g., an entity probes devices remotely to identify those that still have default passwords).

As this rough list suggests, many alternatives can be considered before embarking on something as potentially contentious as an active probe – and of the options listed, active probing would require the most effort in terms of governance, management, privacy/ethical impact assessment, and safety measures. Here are just some of our concerns with the “active probe” approach:

  • Doing this (or even attempting to) without the knowledge and express permission of the device owner, irrespective of the motivation, is a technical attack on that device.
  • The device owner has no way to distinguish a malicious attack from an “authorized,” legitimate one, and might therefore react inappropriately to a legitimate probe, or fail to react appropriately to a malicious one. This may give rise to unintended and undesirable outcomes. For instance, if users are warned via a general announcement that “legitimate probes will be conducted overnight on Thursday of next week”, hackers might interpret that as an opportunity to launch their own attacks, in the knowledge that householders are less likely to react.
  • It could result in the creation of a large database of vulnerable devices, which would be both a target and an asset for potential attackers. Creation of such an asset should not be done without caution and forethought.
  • It is even possible that an active probe could infringe the sovereignty of another nation: for instance, is it acceptable for a country to probe the connected devices of foreign embassies on its soil, as part of an initiative such as this?

Overall, our view is that the active probe approach carries the highest risk of undermining users’ trust in the Internet, particularly by breaching the normal expectations of the device owners and users, concerning privacy, ownership and control. We conclude that actively testing device security by attempting to log in using well-known default passwords should be a last resort, in light of a specific, identified threat, and used only when other alternatives are not available or practical.

In deciding which of the interventions is appropriate (and successful intervention may need a combination of measures), we recommend applying established principles from other, related disciplines of IT governance:

  • Necessity: is there a less risky, less intrusive way to achieve the same ends?
  • Proportionality: is the desired outcome sufficient to justify the potential safety and privacy impact of the intervention?
  • Consent: has the individual’s informed consent been sought and knowingly, freely given?
  • Transparency: is it clear to all stakeholders what is being done and why?
  • Accountability: are the outcomes measurable? Is accountability for the outcomes clear – including negative outcomes if something goes wrong?

We recognize that insecure connected devices represent a substantial and growing threat, and one that needs an effective response. However, we also believe that response can and should be graduated, based on evaluation of a full range of options and application of established principles of good governance.

Recent examples of IoT as an attack vector

Other resources

Categories
Events IETF Internet of Things (IoT) Open Internet Standards

Rough Guide to IETF 102: Internet of Things

The buzz around the Internet of Things (IoT) is only increasing, to the surprise of, well, no one. We are often asked what is happening in the IETF in relation to IoT and in this short post I’d like to highlight some of the relevant activities and sessions scheduled during the upcoming IETF 102 meeting in Montreal. Also check out the IETF Journal IoT Category, the IETF IoT page, the IETF IoT Directorate, the Internet Society’s IoT page, or the Online Trust Alliance (OTA, which became an Internet Society Initiative in April 2017) IoT page for more details about many of these topics.

The IETF Hackathon, held on the weekend preceding the main IETF meeting (July 14-15), includes projects directly related to IoT, with the possibility of more being added. More information is on the Hackathon wiki. Projects of interest include those relating to:

  • Software Updates for Internet of Things (suit)
  • Authentication and Authorization for Constrained Environments (ace)
  • IPv6 over Low Power Wide-Area Networks (lpwan)
  • Work on IoT Semantic / Hypermedia Interoperability (WISHI)

The Thing-to-Thing Research Group (T2TRG) investigates open research issues towards turning the IoT into reality. The research group will be meeting on Thursday afternoon in Montreal to report out on their recent activities. Their summary meeting agenda can be found here. As in the past, full details and latest info on their activities can be found in GitHub. Of particular note is the recent update of a key draft document: State-of-the-Art and Challenges for the Internet of Things Security.

Two recently chartered IoT-related working groups met for the first time as working groups at the last IETF meeting in March, and are tackling very serious problems. I am very pleased to see these moving forward:

I would like to draw your attention to two recently initiated activities:

In this edition of the Rough Guide I would like to highlight some recent work in SUIT, addressing hash-based signatures. (Description courtesy Russ Housley)

Today, RSA is often used to digitally sign software updates. In preparation for a day when RSA, DSA, and ECDSA cannot be depended upon, a digital signature algorithm is needed that will remain secure even if there are significant cryptoanalytic advances or a large-scale quantum computer is invented. The hash-based digital signature algorithm specified in [HASHSIG] is one such algorithm. The use of hash-based signatures to protect software update distribution will allow the deployment of software that implements new cryptosystems even if such advances break current digital signature mechanisms.

[HASHSIG] specifies the conventions for using the Leighton-Micali Signature (LMS) algorithm, and it is in the final stages of approval in the IRTF CFRG. [HASHSIG-COSE] specifies the conventions for these digital signatures with the CBOR Object Signing and Encryption (COSE) [RFC8152] syntax. The LMS algorithm is one form of hash-based digital signature; it can only be used for a fixed number of signatures. The LMS algorithm uses small private and public keys, and it has low computational cost; however, the signatures are quite large. The mechanism has broader applicability than SUIT, so a home that supports the broader perspective is desirable.

Ongoing work includes:

MUD

I also want to (again) point you to “Manufacturer Usage Description Specification” (MUD) which was developed in the Operations and Management Area Working Group (opsawg). MUD holds significant promise, and I am pleased to see that it is gaining some serious traction: The Internet Engineering Steering Group (IESG) recently approved it as a proposed standard.

From the abstract: This memo specifies a component-based architecture for manufacturer usage descriptions (MUD). The goal of MUD is to provide a means for Things to signal to the network what sort of access and network functionality they require to properly function. The initial focus is on access control. Later work can delve into other aspects.

Eliot Lear, one of the MUD authors, has written a great article about it for the IETF Journal: Managing the Internet of Things – It’s All About Scaling.

As I have noted in previous IoT Rough Guides, MUD also plays a significant role in the project – Mitigating IoT-Based Automated Distributed Threats – being developed by the US National Institute of Standards and Technology (NIST) National Cybersecurity Center of Excellence (NCCoE).

If you have an interest in how the IoT is developing and being standardized in the IETF, I hope to see you in person or online at some of these meetings during IETF 102. (Note that If you know you will be unable to travel to the meeting and would like to participate remotely, you must register as a remote participant. There is currently no fee to be a remote participant at an IETF meeting but registration is required. If you do not want to register, you may opt to listen to the live audio stream of the sessions instead.)

Schedule and locations subject to change. Please refer to the online agenda to confirm. All times Montreal Time: EDT (UTC-4)

6LO (IPv6 over Networks of Resource-constrained Nodes) WG
Tuesday, 17-July 2018, 13:30-15:30, Duluth Meeting Room
Agenda/Materials
Documents
Charter

6TISCH (IPv6 over the TSCH mode of IEEE 802.15.4e) WG
Wednesday, 18-July 2018, 13:30-15:00, Duluth Meeting Room
Agenda/Materials
Documents
Charter

ACE (Authentication and Authorization for Constrained Environments) WG
Monday, 16 July 2018, 09:30-12:00, Viger Meeting Room
Agenda/Materials
Documents
Charter

CORE (Constrained RESTful Environments) WG
Monday, 16 July 2018, 15:50-17:50, Duluth Meeting Room
Thursday, 19 July 2018, 18:10-19:10, Van Horne meeting room
Agenda/Materials
Documents
Charter

HOMENET (Home Networking) WG
Wednesday, 18-July 2018, 15:20-16:50, Centre Ville Meeting Room
Agenda/Materials
Documents
Charter

IPWAVE (IP Wireless Access in Vehicular Environments) WG
Monday, 16 July 2018, 13:30-15:30, Laurier Meeting Room
Agenda/Materials
Documents
Charter

LPWAN (IPv6 over Low Power Wide-Area Networks) WG
Thursday, 19 July 2018, 09:30-12:00, Centre Ville Meeting Room
Agenda/Materials
Documents
Charter

LWIG (Light-Weight Implementation Guidance) WG
Friday, 20 July 2018, 11:50-13:20, Duluth Meeting Room
Agenda/Materials
Documents
Charter

OPSAWG (Operations and Management Area) WG
Tuesday, 17 July 2018, 15:50-18:20, Blenheim meeting room
Agenda/Materials
Documents
Charter

ROLL (Routing Over Low power and Lossy networks) WG
Tuesday, 17 July 2018, 09:30-12:00, Duluth Meeting Room
Agenda/Materials
Documents
Charter

SUIT (Software Updates for Internet of Things) WG
Wednesday, 18 July 2018, 09:30-12:00, Duluth Meeting Room
Agenda/Materials
Documents
Charter

T2TRG (Thing-to-Thing) RG
Thursday, 19 July 2018, 15:50-17:50, Laurier meeting room
Agenda/Materials
Documents
Charter

TEEP (Trusted Execution Environment Provisioning) WG
Monday, 16 July 2018, 13:30-15:30, Viger Meeting Room
Agenda/Materials
Documents
Charter

Follow Us

It will be a busy week in Montreal, and whether you plan to be there or join remotely, there’s much to monitor. Read the full series of Rough Guide to IETF 102 posts, and follow us on the Internet Society blogTwitter, or Facebook using #IETF102 to keep up with the latest news.

Categories
Internet of Things (IoT)

Wouldn’t it be nice…if you could trust your device?

Wouldn’t it be nice if you could trust that your device is secure, so that it isn’t leaking your private data, becoming a bot and attacking other users, or putting you at risk?

We think so too.

By using their buying power to influence the market, combined with forward-looking, smart policies and regulations, governments can help build an Internet of Things (IoT) we can trust. With over ten billion IoT devices, applications, and services already in use, and the number of connected devices forecasted to jump to over thirty-eight billion by 2020, ensuring that governments take the right actions now around IoT security is critical.

Governments have important choices to make now to help ensure that IoT consumers are secure, innovation can flourish, and we can all fully benefit from IoT.

We are pleased to release IoT Security for Policymakers, a discussion paper to help provide a solid foundation for policymakers and regulators as they address IoT security. In the paper, we highlight key issues and challenges of IoT security, along with guiding principles and recommendations. While many of IoT’s challenges are technical, some of the most pressing are social, economic, or legal. There are countless consumers with little knowledge or information about IoT security, which constrains consumer demand for well-secured products over ill-secured ones. In addition, good IoT security is slow and expensive for manufacturers to develop, leading many to make security an afterthought. In many cases, there is legal uncertainty around accountability for IoT security, making it difficult to assign responsibility or ensure compensation for harm. IoT also presents important privacy challenges, however, those will be addressed in a forthcoming paper focused on privacy and IoT.

While none of these security challenges can be addressed by governments alone, there are important steps that governments can and should take now to make a difference. Our paper identifies some guiding principles and key actions for policymakers to take to help solve these challenges. Some of these actions are regulatory, like strengthening accountability by clearly assigning liability in advance. Others rely on the strong buying power of governments. For example,  changing procurement policies to emphasize security so that companies have greater incentives to produce IoT products and services with strong security features..

It is incumbent upon us all – policymakers, businesses, members of the technical community, and civil society – to ensure that IoT’s impact is a positive one by proactively tackling its challenges, while enabling its opportunities for all.

Please read and share our new paper, IoT Security for Policymakers, to learn about the challenges we face and how governments, policymakers, and regulators can make a difference. As the discussion paper continues to evolve, we welcome your comments at iot-paper@isoc.org.

Categories
Building Trust Events IETF Improving Technical Security Internet of Things (IoT) Open Internet Standards Technology

Rough Guide to IETF 101: Internet of Things

The Internet of Things (IoT) is an increasingly hot buzzword around the Internet industry and the broader technology and innovation business arenas. We are often asked what the IETF is doing in relation to IoT and in this short Rough Guide to IETF 101 post I’d like to highlight some of the relevant sessions scheduled during the upcoming IETF 101 meeting in London. Also check out the IETF Journal IoT Category, the IETF IoT page, the IETF IoT Directorate, the Internet Society’s IoT page, or the Online Trust Alliance IoT page for more details about many of these topics. See also this recent article in the IETF Journal: Internet of Things: Standards and Guidance from the IETF.

The IETF Hackathon, held the weekend preceding the main IETF meeting (17-18 March), will include at least four projects directly related to IoT, with the possibility of more being added. More information is on the Hackathon wiki.

The Thing-to-Thing Research Group (T2TRG) investigates open research issues towards turning the IoT into reality. The research group will be meeting on Thursday afternoon in London to report out on their recent activities. Their summary meeting agenda is here. As in the past, full details and latest info can be found in GitHub. Of particular note is a recent update of a key ID: State-of-the-Art and Challenges for the Internet of Things Security. Following IETF 101, there will be a joint meeting with the T2TRG, the Open Connectivity Foundation (OCF), and W3C Web of Things (WoT) Working Group on March 23 in Prague.

New Work

There are two newly chartered IoT-related working groups meeting for the first time in London, which are tackling very serious problems. I am pleased to see these moving forward:

Ongoing Work

The Constrained RESTful Environments (core) WG aims to extend the Web architecture to most constrained networks and embedded devices. This is one of the most active IoT working groups and they will be meeting twice in London, on Monday afternoon and Tuesday morning. They will be considering several Internet Drafts (IDs) including: CoAP Simple Congestion Control/Advanced, CoAP Management Interface, Uniform Resource Names for Device Identifiers, and Publish-Subscribe Broker for the Constrained Application Protocol (CoAP).

The IPv6 over Networks of Resource-constrained Nodes (6lo) WGfocuses on the work that facilitates IPv6 connectivity over constrained node networks with the characteristics of:

  • limited power, memory and processing resources
  • hard upper bounds on state, code space and processing cycles
  • optimization of energy and network bandwidth usage
  • lack of some layer 2 services like complete device connectivity and broadcast/multicast

They have some interesting work queued up, including discussion of a revision to RFC 6775 (Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)). They will be meeting on Thursday afternoon in London.

The IPv6 over the TSCH mode of IEEE 802.15.4e (6tisch) WGwas chartered in 2014 to enable IPv6 for the Time-Slotted Channel Hopping (TSCH) mode that was recently added to IEEE 802.15.4 networks. The 6top Protocol (6P) ID was recently revised and is in IESG last call on its way to adoption – it enables distributed scheduling in 6TiSCH networks. Among the interesting things on their agenda is planning for the next F-Interop 6TiSCH Interoperability event. They are meeting on Wednesday afternoon in London.

The Home Networking (homenet) WG focuses on the evolving networking technology within and among relatively small “residential home” networks. For example, an obvious trend in home networking is the proliferation of networking technology in an increasingly broad range and number of devices. They will be meeting in London on Friday morning and discussing several interesting IDs.

The IPv6 over Low Power Wide-Area Networks (lpwan) WG will be meeting in London on Wednesday morning. Typical LPWANs provide low-rate connectivity to vast numbers of battery-powered devices over distances that may span tens of miles, using license-exempt bands. There is a recently-published LPWAN Overview. They have a very useful overview draft, recently revised.

The IP Wireless Access in Vehicular Environments (ipwave) WG has as its primary deliverable a specification for mechanisms to transmit IPv6 datagrams over IEEE 802.11-OCB mode. For more about this very timely topic, there is a recently updated ID: IP-based Vehicular Networking: Use Cases, Survey and Problem Statement. ipwave will meet on Monday morning in London.

The Authentication and Authorization for Constrained Environments (ace) WG,as its name suggests, is concerned with authentication and authorization mechanisms in constrained environments, where network nodes are limited in CPU, memory and power. This is a critical issue for IoT, for obvious reasons. The proposed standard is the subject of a recently-revised ID. ace will meet on Monday morning.

Routing for IoT is tackled by theRouting Over Low power and Lossy networks (roll) WG which focuses on routing protocols for constrained-node networks. They have 2 meetings in London: Thursday morning and Friday morning.

Finally, in addition to the new protocols and other mechanisms developed by IETF working groups, IoT developers often benefit from additional guidance for efficient implementation techniques and other considerations. The Lightweight Implementation Guidance (lwig) WGis developing such documents and they will meet in London on Wednesday afternoon. The IDs CoAP Implementation Guidance and Building Power-Efficient CoAP Devices for Cellular Networks are useful resources. lwig will be meeting in London on Wednesday afternoon.

I also want to (again) draw your attention to a very interesting (Standards Track) Internet Draft being discussed in the Operations and Management Area Working Group (opsawg) which seems to hold significant promise, and which appears to be gaining some serious traction: “Manufacturer Usage Description Specification“ (MUD). From the abstract: This memo specifies a component-based architecture for manufacturer usage descriptions (MUD). The goal of MUD is to provide a means for Things to signal to the network what sort of access and network functionality they require to properly function.  The initial focus is on access control. Later work can delve into other aspects. The opsawg meeting will be held on Monday afternoon.

MUD also plays a significant role in the project – Mitigating IoT-Based Automated Distributed Threats – being developed by the US National Institute of Standards and Technology (NIST) National Cybersecurity Center of Excellence (NCCoE).

If you have an interest in how the IoT is developing and being standardized in the IETF, I hope to see you in person or online at some of these meetings during IETF 101. (Note that If you know you will be unable to travel to the meeting and would like to participate remotely, you must register as a remote participant. There is no fee to be a remote participant at an IETF meeting but registration is required. If you do not want to register, you may opt to listen to the live audio stream of the sessions instead.

Related Working Groups at IETF 101

Schedule and locations subject to change. Please refer to the online agenda to confirm.

** All times London Time: GMT **

6lo (IPv6 over Networks of Resource-constrained Nodes) WG
Thursday, 22 March 2018, 13:30-15:30
Buckingham meeting room
Agenda/Materials
Documents
Charter

6tisch (IPv6 over the TSCH mode of IEEE 802.15.4e) WG
Wednesday, 21 March 2018, 13:30-15:00
Viscount meeting room
Agenda/Materials
Documents
Charter

ace (Authentication and Authorization for Constrained Environments) WG
Monday, 19 March 2018, 09:30-12:00
Balmoral Meeting Room
Agenda/Materials
Documents
Charter

core (Constrained RESTful Environments) WG
Monday, 19 March 2018, 13:30-15:30
Richmond/Chelsea/Tower Meeting Room
Tuesday, 20 March 2018, 09:30-12:00
Viscount meeting room
Agenda/Materials
Documents
Charter

homenet (Home Networking) WG
Friday, 23 March 2018, 09:30-11:30
Sandringham Meeting Room
Agenda/Materials
Documents
Charter

ipwave (IP Wireless Access in Vehicular Environments) WG
Monday, 19 March 2018, 09:30-12:00
Sandringham Meeting Room
Agenda/Materials
Documents
Charter

lpwan (IPv6 over Low Power Wide-Area Networks) WG
Wednesday, 21 March 2018, 09:30-12:00
Viscount meeting room
Agenda/Materials
Documents
Charter 

lwig (Light-Weight Implementation Guidance) WG
Wednesday, 21 March 2018, 15:20-16:50
Park Suite Meeting Room
Agenda/Materials
Documents
Charter

opsawg (Operations and Management Area) WG
Monday, 19 March 2018, 13:30-15:30
Blenheim meeting room
Agenda/Materials
Documents
Charter

roll (Routing Over Low power and Lossy networks) WG
Thursday, 22 March 2018, 09:30-12:00
Park Suite Meeting Room
Friday, 23 March 2018, 09:30-12:00
Viscount meeting room
Agenda/Materials
Documents
Charter

suit (Software Updates for Internet of Things) WG
Monday, 19 March 2018, 13:30-15:30
Buckingham meeting room
Agenda/Materials
Documents
Charter

t2trg (Thing-to-Thing) RG
Thursday, 22 March 2018, 15:50-17:50
Blenheim meeting room
Agenda/Materials
Documents
Charter

teep (Trusted Execution Environment Provisioning) WG
Tuesday, 20 March 2018, 13:30-15:30
Balmoral Meeting Room
Agenda/Materials
Documents
Charter

Follow Us

It will be a busy week in London, and whether you plan to be there or join remotely, there’s much to monitor. Read the full series of Rough Guide to IETF 101 posts, and follow us on the Internet Society blog, Twitter, or Facebook using #IETF101 to keep up with the latest news.

Categories
IETF Improving Technical Security Internet of Things (IoT) Open Internet Standards Technology

Rough Guide to IETF 100: Internet of Things

The Internet of Things (IoT) is a major buzzword around the Internet industry and the broader technology and innovation business arenas. We are often asked what the IETF is doing in relation to IoT and in this Rough Guide to IETF 100 post I’d like to highlight some of the relevant sessions scheduled during the upcoming IETF 100 meeting in Singapore. Check out the IETF Journal IoT Category, the Internet Society’s IoT page, or the Online Trust Alliance IoT page for more details about many of these topics.

The Thing-to-Thing Research Group (T2TRG) investigates open research issues in turning the IoT into reality. The research group will be holding a half-day joint meeting with the Open Connectivity Foundation (OCF) on the Friday before IETF, and they will also be meeting on Tuesday afternoon in Singapore to report out on their recent activities. Included on the agenda is the upcoming Workshop on Decentralized IoT Security and Standards (DISS). This workshop will be held in conjunction with the Network and Distributed System Security (NDSS) Symposium on 18 February 2018 in San Diego, CA, USA. The DISS workshop will gather researchers and the open standards community together to help address the challenges of IoT Security. The Call For Papers for DISS closes on 8 Dec 2017.

In addition, T2TRG is undertaking ongoing work resulting from the Workshop on IoT Semantic/Hypermedia Interoperability in Prague held last July in conjunction with IETF 99.

The Constrained RESTful Environments (core) WG aims to extend the Web architecture to most constrained networks and embedded devices. This is one of the most active IoT working groups and they will be meeting twice in Singapore, on Monday afternoon and Tuesday afternoon.

The IPv6 over Networks of Resource-constrained Nodes (6lo) WG defines mechanisms to adapt IPv6 to a wide range of radio technologies, including “Bluetooth Low Energy” (RFC 7668), ITU-T G.9959 (as used in Z-Wave, RFC 7428), and the Digital Enhanced Cordless Telecommunications (DECT) Ultra Low Energy (ULE) cordless phone standard and the low-cost wired networking technology Master-Slave/Token-Passing (MS/TP) that is widely used over RS-485 in building automation. There is a very useful Internet Draft recently released, which should prove to be a good reference: IPv6 over Constrained Node Networks (6lo) Applicability & Use cases. They will be meeting on Thursday afternoon in Singapore.

The IPv6 over the TSCH mode of IEEE 802.15.4e (6tisch) WG was chartered in 2014 to enable IPv6 for the Time-Slotted Channel Hopping (TSCH) mode that was recently added to IEEE 802.15.4 networks. The 6top Protocol is defined in a recently revised Internet Draft, as a Proposed Standard. They are meeting on Monday afternoon in Singapore.

The IPv6 over Low Power Wide-Area Networks (lpwan) WG will be meeting in Singapore on Monday morning. Typical LPWANs provide low-rate connectivity to vast numbers of battery-powered devices over distances that may span tens of miles, using license-exempt bands. There is a recently-published LPWAN Overview.

The IP Wireless Access in Vehicular Environments (ipwave) WGs primary deliverable is a specification for mechanisms to transmit IPv6 datagrams over IEEE 802.11-OCB mode. For more about this very timely topic, there is a recently released Internet Draft: IP-based Vehicular Networking: Use Cases, Survey and Problem Statement. IPWAVE will meet on Monday afternoon in Singapore.

Security for IoT is addressed in several WGs including the Authentication and Authorization for Constrained Environments (ace) WG that is concerned with, as its name suggests, authentication and authorization mechanisms in constrained environments, where network nodes are limited in CPU, memory and power. The proposed standard is the subject of a recently-released Internet Draft. ACE will meet on Tuesday morning.

Routing for IoT is tackled by the Routing Over Low power and Lossy networks (roll) WG which focuses on routing protocols for constrained-node networks. Wednesday afternoon is the time for them to meet in Singapore.

Software Updates for Internet of Things (suit) (formerly known as FUD – Firmware Updating Description) – this nascent working group will hold a BoF on Monday afternoon. This is a very interesting WG that I am very pleased to see spinning up, tackling a very challenging and important problem. There are four Internet Drafts that provide a good overview. From the draft charter:

Vulnerabilities in Internet of Things (IoT) devices have raised the need for a secure firmware update mechanism that is also suitable for constrained devices. Security experts, researchers, and regulators recommend that all IoT devices be equipped with such a mechanism. While there are many proprietary firmware update mechanisms in use today, there is a lack of a modern interoperable approach of securely updating the software in IoT devices.

Finally, in addition to the new protocols and other mechanisms developed by IETF working groups, IoT developers often benefit from additional guidance for efficient implementation techniques and other considerations. The Lightweight Implementation Guidance (lwig) WG is developing such documents and they will meet in Singapore on Wednesday morning. The recently published Internet Draft CoAP Implementation Guidance should be a good resource.

I also want to draw your attention to a very interesting (Standards Track) Internet Draft being discussed in the Operations and Management Area Working Group (opsawg), which seems to hold promise, and which appears to be gaining some serious traction: “Manufacturer Usage Description Specification“ (MUD). From the abstract: This memo specifies a component-based architecture for manufacturer usage descriptions (MUD). The goal of MUD is to provide a means for Things to signal to the network what sort of access and network functionality they require to properly function. The initial focus is on access control.  Later work can delve into other aspects. The opsawg meeting will be held on Tuesday afternoon.

MUD plays a significant role in the draft project description – Mitigating IoT-Based Automated Distributed Threats – being developed by the US National Institute of Standards and Technology (NIST) National Cybersecurity Center of Excellence (NCCoE).

If you have an interest in how the IoT is developing and being standardized in the IETF, I hope to see you in person or online at some of these meetings during IETF 100. (Note that if you will be unable to travel to the meeting and would like to participate remotely, you must register as a remote participant. There is no fee to be a remote participant at an IETF meeting, but registration is required. If you do not want to register, you may opt to listen to the live audio stream of the sessions instead.)

Related Working Groups at IETF 100

Schedule and locations subject to change. Please refer to the online agenda to confirm.
** All times SGT – Singapore Time: UTC+8 **

t2trg (Thing-to-Thing) RG
Friday, 10 November, off-site
Half-day joint meeting with the Open Connectivity Foundation (OCF)

Tuesday, 14 November, 15:50-17:50, Padang
Agenda/Materials
Documents
Charter

6lo (IPv6 over Networks of Resource-constrained Nodes) WG
Thursday, 16 November, 13:30-15:30, Sophia
Agenda/Materials
Documents
Charter

6tisch (IPv6 over the TSCH mode of IEEE 802.15.4e) WG
Monday, 13 November, 15:50-17:20, Bras Basah
Agenda/Materials
Documents
Charter

lpwan (IPv6 over Low Power Wide-Area Networks) WG
Monday, 13 November, 9:30-12:00, Olivia
Agenda/Materials
Documents
Charter

core (Constrained RESTful Environments) WG
Monday, 13 November, 13:30-15:30, Sophia
Tuesday, 14 November, 13:30-15:30, Bras Basah
Agenda/Materials
Documents
Charter

ace (Authentication and Authorization for Constrained Environments) WG
Tuesday, 14 November, 9:30-12:00, Collyer
Agenda/Materials
Documents
Charter

roll (Routing Over Low power and Lossy networks) WG
Wednesday, 15 November, 13:30-15:00, VIP A
Agenda/Materials
Documents
Charter

lwig (Light-Weight Implementation Guidance) WG
Wednesday, 15 November, 9:30-12:00, Olivia
Agenda/Materials
Documents
Charter

ipwave (IP Wireless Access in Vehicular Environments) WG
Monday, 13 November, 17:40-18:40, Sophia
Agenda/Materials
Documents
Charter

Follow Us

There’s a lot going on in Singapore, and whether you plan to be there or join remotely, there’s much to monitor. To follow along as we dole out this series of Rough Guide to IETF blog posts, follow us on the Internet Society BlogTwitterFacebook, or see https://dev.internetsociety.org/events/ietf/ietf-100/.

Categories
Identity Privacy

TIIME to Pay Attention to Identity

My colleague Robin Wilton and I participated in the recent Trust and Internet Identity Meeting Europe (TIIME) in Vienna, Austria, co-sponsored by the Internet Society and organized by long-time notable identeratus Rainer Hörbe.

This meeting brought together approximately 100 people who are engaged in advancing the state of the art and strengthening trust around online identity. Structured as an “unconference,” it was up to the attendees to set the agenda and lead the sessions. As you can see from the session list the meeting covered a lot of ground.

I led sessions on IoT Security and Privacy and Blockchain and Identity, two topics of particular interest to me and to the Internet Society. My colleagues and I have written in the past about IoT Security and Privacy, and we plan to write more on both topics.

One of the key themes of the meeting was Federated Identity and Access Management (IAM). This is something that many are not familiar with, at least not by that name, although it plays a significant role in the lives of many, and will widen its reach as time goes on. One of the paradoxes of this technology, like many others, is that when it is working well it “gets out of the way” and is not very visible to people using it. It is only when things break down that it becomes noticeable.

Essentially, it’s when you log on at one organization (e.g., a book publisher’s site) using an ID and password that was issued to you by another (for instance, the university at which you are a student).

For anyone who would like to learn more about Federated IAM, there are many good resources. Some to get you started include:

The global Research and Education (R&E) community has led the way in developing and fine-tuning the technologies and associated policies that enable Federated IAM to work well, and the technology has become core infrastructure for R&E worldwide. Industries and governments around the world have adopted various aspects of Federated IAM around the world, with more certain to follow. Federations tend to be set up around logical constituencies, such as a local or federal government offering services to its constituents, or vertical industries such as automotive or pharmaceuticals. In the R&E sector federations tend to be national or built around particular fields of study, and in many cases they are run by or at least closely associated with National Research and Education Networks (NRENs).

Federated IAM simplifies things for users, because it reduces the number of IDs and passwords they need to manage, while still securing their access to multiple services. At this point in its evolution, though, having solved many of the easier “low-hanging fruit” problems, it has exposed more challenging ones.

Developing and refining the policies and processes regarding what attributes about its users an Identity Provider (IdP) releases to a Service Provider (SP) has been and continues to be a challenge. An SP relies on user attributes conveyed in a trustworthy manner from the IdP to make access control decisions. The required attributes will vary along a spectrum from those that are not at all revealing about the user’s identity to those that very explicitly and uniquely identify the person, based upon the risk profile of the resource being accessed. E.g. for a digital library resource licensed to an educational institution, all that might be required is an assertion that the user is currently affiliated with the institution, or perhaps also enrolled in a particular class for the current session. For access to your health or financial records, enough identifying information will need to be conveyed to fully convince the resource holder that you are in fact you. And of course this is what we want. I tend to think of privacy controls in this context as a virtual knob that can be turned from 0-10, depending on what is actually needed in a particular context. Unfortunately there is a tendency among some SPs to require much more than they legitimately need, in some cases because they want to use the additional information for financial gain (monetization) either currently or reserving for some possible future use. A common monetization strategy is using profile information for marketing, including packaging and selling to third parties.

The specific set of attributes required by the SP is something that it can negotiate with the IdP on a bilateral basis, often in association with a contract for services. Or a particular bundle of attributes may be released by IdPs to particular classes of SPs. However, users cannot always rely upon IdPs to protect their privacy. It is up to the manager(s) of the IdP to represent the interests of their users and negotiate the release of only those attributes for which the SP can make a legitimate case for being necessary for its purposes in making access decisions. This is essentially the trade-off – users get simplicity because they are relying upon the IdP to negotiate on their behalf.

In this age of data monetization, it is more important than ever for us all to be conscious of what information about us is being sent, where, for what purposes, and how it is being protected. As Federated IAM continues to advance and become more ubiquitous, it is incumbent upon us all to ask the questions of those entrusted with shepherding and protecting our data. This starts with looking at how your IdPs use your data, and why. In some cases this is easy to learn from publicly available information, such as privacy policies or terms of service, but in other cases it will require some digging. Ultimately it is up to us as the stewards of our information and to be on the lookout for possible misuse, and to take steps to protect ourselves.

Although I have used examples from the higher education sector, you have probably encountered federated authentication in another form: the growing trend to invite you to log in to sites using your social media identity.

Using social networking or similar IdPs to login to other sites is very convenient, which is the fundamental value proposition, but in the process of doing so users may be revealing much more about themselves and their activities to that IdP than they intend to, to their detriment. The things you trust an IdP to do are not necessarily the things you trust your social media provider to do. There is a saying: if you are not paying for the service then you are the product. This is true for “free” services such as social networks and email, which use data collected about users to market and sell to others.

An encouraging trend is that of non-commercial IdPs that explicitly promise not to use or abuse your data, and in particular not to sell it. A good example of this is UnitedID.org, which can be used broadly in the R&E sector as well as with select broadly available commercial services, and which will be the subject of a separate blogpost.

For more information about choosing IdPs, see Robin Wilton’s excellent white paper: Have you chosen an Identity Provider Lately?

Categories
Improving Technical Security Internet of Things (IoT)

US NTIA Multistakeholder Process: Internet of Things (IoT) Security Upgradability and Patching

What happens when smart device manufacturers don’t pay (enough) attention to basic security principles? How do we support, upgrade, and patch existing devices when security issues are identified after they’ve hit the market? These are some of the questions we tackled at the kickoff meeting of the US NTIA “Multistakeholder Process: Internet of Things (IoT) Security Upgradability and Patching” held on 19 October in Austin, Texas.

The Internet of Things, or IoT, has been widely referred to as the “Internet of Insecure Things.” This has been brought into sharp focus in recent weeks as the Mirai botnet was apparently used to launch high profile and very disruptive Distributed Denial of Service (DDoS) attacks. These attacks were notable in that compromised IoT devices were the dominant part of a botnet used to send unprecedented levels of traffic.

The source code for the Mirai botnet was subsequently released to the public and it turns out that it is not particularly sophisticated. In large part, it takes advantage of well-known default usernames and passwords and simply scans the Internet looking for devices it can log into and infect. While in the past this has been an issue with home routers, IoT brings another dimension to the problem space since many of the devices on the market and in use also use well-known default passwords, many of which cannot be easily changed.

This is an example of what happens when vendors ignore basic security principles, which need to be part of development and design processes from the beginning and all the way through until products reach the market. But the responsibilities do not end there in terms of supporting, upgrading, and patching them in the field. The Internet is a vast and complex ecosystem, and as these recent attacks have demonstrated very clearly, security choices made by vendors can and will have profound impacts on us all. It is the responsibility of all vendors in this space to ensure that they are good Internet “citizens.”

More to the point, security is a never-ending process and not simply a “once and done” part of the design cycle. In essence it is an ongoing arms race with those who would seek to exploit Internet-connected devices to do harm. Note that “harm” can extend far beyond simple DDoS attacks when it comes to IoT since many healthcare, building automation systems, and SCADA (Supervisory Control And Data Acquisition) systems used in industrial and utility settings can cause real and significant damage to life and property if misused.

As security issues and vulnerabilities become known, they need to be corrected by installing patches or upgrades to the software and firmware running these devices. In many cases in the IoT this is extremely challenging due to a variety of factors, including:

  • difficulty in accessing devices, whether physically or through the network
  • limited capacity on the device, including memory and processing power needed to receive and perform the upgrade or patch

The Internet Society (namely Olaf Kolkman, Chief Internet Technology Officer, and myself) was pleased to participate in the kickoff meeting of the US NTIA “Multistakeholder Process: Internet of Things (IoT) Security Upgradability and Patching” held 19 October 2016 in Austin, Texas. It was chaired by Allan Friedman, Director of Cybersecurity Initiatives, NTIA Office of Policy Analysis and Development.

This meeting spurred excellent discussion among a diverse group of participants, and led to the formation of five working groups (detailed below). This meeting was well aligned with the Internet of Things Software Update (IoTSU) workshop [1] held earlier this year, and represented a good first step toward stakeholders working together to solve common problems.

Overall observations:

  • We need to think about unexpected consequences of the behavior, and misbehavior, of devices when they are part of a bigger ecosystem
  • There are challenges in different ways of defining and describing the issues, which lead to potential area of ambiguity
  • While there are and have been efforts to address device security, upgradability and patchability haven’t received a lot of attention until recently

There was a general recognition of the seriousness of this issue among the meeting participants, and consensus in the room that the stakeholders want and need to self-regulate to avoid what all agreed would likely be regulatory and/or legislative intervention that none would like. Thus there was significant incentive to move, and to move quickly if at all possible. Time will tell if this is successful, but we are cautiously optimistic.

The workstreams coming from the initial meeting:

  1. Review of existing standards and Initiatives: What are existing standards and tools for IoT security upgradability that can inform or should be part of this initiative?
  2. Maximum capability and minimum expectations: For each defined class of device, what is the least we might expect and the most we might expect for upgradability?
  3. Communicating IoT upgradability: This working group will examine ways for IoT product makers to describe the why/how/what/who of updatability to buyers.
  4. Incentives and Barriers: How do we foster greater adoption of good patching and updating practices?
  5. Shared open upgrade framework: What are the benefits, requirements, barriers, and existing components of a shared open upgrade framework to support smaller producers or end-of-life products?

The group is working on arranging a next meeting in early- to mid-December 2016, location not yet determined. The Internet Society welcomes this effort and we will be monitoring it as it progresses, but we will not be active participants in it.

This is intended to be an open and inclusive process. If you are a producer, retailer or consumer of “Things” your voice is important, so please consider participating.

Meeting website, including unedited notes taken in real time and information about how to participate in the workstreams: https://www.ntia.doc.gov/other-publication/2016/multistakeholder-process-iot-security

[1] Internet of Things Software Update (IoTSU) workshop site, including position papers:

https://down.dsg.cs.tcd.ie/iotsu/

Draft workshop report:

https://tools.ietf.org/html/draft-farrell-iotsu-workshop-00