5.  Challenges for a Secure IoT

   In this section, we take a closer look at the various security
   challenges in the operational and technical features of IoT and then
   discuss how existing Internet security protocols cope with these
   technical and conceptual challenges through the lifecycle of a thing.
   This discussion should not be understood as a comprehensive
   evaluation of all protocols, nor can it cover all possible aspects of
   IoT security.  Yet, it aims at showing concrete limitations and
   challenges in some IoT design areas rather than giving an abstract
   discussion.  In this regard, the discussion handles issues that are
   most important from the authors' perspectives.

5.1.  Constraints and Heterogeneous Communication

   Coupling resource-constrained networks and the powerful Internet is a
   challenge, because the resulting heterogeneity of both networks
   complicates protocol design and system operation.  In the following
   subsections, we briefly discuss the resource constraints of IoT
   devices and the consequences for the use of Internet protocols in the
   IoT domain.

5.1.1.  Resource Constraints

   IoT deployments are often characterized by lossy and low-bandwidth
   communication channels.  IoT devices are also often constrained in
   terms of the CPU, memory, and energy budget available [RFC7228].
   These characteristics directly impact the design of protocols for the
   IoT domain.  For instance, small packet-size limits at the physical
   layer (127 Bytes in IEEE 802.15.4) can lead to (i) hop-by-hop
   fragmentation and reassembly or (ii) small IP-layer maximum
   transmission unit (MTU).  In the first case, excessive fragmentation
   of large packets that are often required by security protocols may
   open new attack vectors for state-exhaustion attacks.  The second
   case might lead to more fragmentation at the IP layer, which commonly
   downgrades the overall system performance due to packet loss and the
   need for retransmission.

   The size and number of messages should be minimized to reduce memory
   requirements and optimize bandwidth usage.  In this context, layered
   approaches involving a number of protocols might lead to worse
   performance in resource-constrained devices since they combine the
   headers of the different protocols.  In some settings, protocol
   negotiation can increase the number of exchanged messages.  To
   improve performance during basic procedures such as, for example,
   bootstrapping, it might be a good strategy to perform those
   procedures at a lower layer.

   Small CPUs and scarce memory limit the usage of resource-expensive
   cryptographic primitives such as public key cryptography as used in
   most Internet security standards.  This is especially true if the
   basic cryptographic blocks need to be frequently used or the
   underlying application demands low delay.

   There are ongoing efforts to reduce the resource consumption of
   security protocols by using more efficient underlying cryptographic
   primitives such as Elliptic Curve Cryptography (ECC) [RFC8446].  The
   specification of elliptic curve X25519 [ecc25519], stream ciphers
   such as ChaCha [ChaCha], Diet HIP [HIP-DEX], and ECC groups for IKEv2
   [RFC5903] are all examples of efforts to make security protocols more
   resource efficient.  Additionally, most modern security protocols
   have been revised in the last few years to enable cryptographic
   agility, making cryptographic primitives interchangeable.  However,
   these improvements are only a first step in reducing the computation
   and communication overhead of Internet protocols.  The question
   remains if other approaches can be applied to leverage key agreement
   in these heavily resource-constrained environments.

   A further fundamental need refers to the limited energy budget
   available to IoT nodes.  Careful protocol (re)design and usage are
   required to reduce not only the energy consumption during normal
   operation but also under DoS attacks.  Since the energy consumption
   of IoT devices differs from other device classes, judgments on the
   energy consumption of a particular protocol cannot be made without
   tailor-made IoT implementations.

5.1.2.  Denial-of-Service Resistance

   The tight memory and processing constraints of things naturally
   alleviate resource-exhaustion attacks.  Especially in unattended T2T
   communication, such attacks are difficult to notice before the
   service becomes unavailable (for example, because of battery or
   memory exhaustion).  As a DoS countermeasure, DTLS, IKEv2, HIP, and
   Diet HIP implement return routability checks based on a cookie
   mechanism to delay the establishment of state at the responding host
   until the address of the initiating host is verified.  The
   effectiveness of these defenses strongly depends on the routing
   topology of the network.  Return routability checks are particularly
   effective if hosts cannot receive packets addressed to other hosts
   and if IP addresses present meaningful information as is the case in
   today's Internet.  However, they are less effective in broadcast
   media or when attackers can influence the routing and addressing of
   hosts (for example, if hosts contribute to the routing infrastructure
   in ad hoc networks and meshes).

   In addition, HIP implements a puzzle mechanism that can force the
   initiator of a connection (and potential attacker) to solve
   cryptographic puzzles with variable difficulties.  Puzzle-based
   defense mechanisms are less dependent on the network topology but
   perform poorly if CPU resources in the network are heterogeneous (for
   example, if a powerful Internet host attacks a thing).  Increasing
   the puzzle difficulty under attack conditions can easily lead to
   situations where a powerful attacker can still solve the puzzle while
   weak IoT clients cannot and are excluded from communicating with the
   victim.  Still, puzzle-based approaches are a viable option for
   sheltering IoT devices against unintended overload caused by
   misconfiguration or malfunctioning things.

5.1.3.  End-to-End Security, Protocol Translation, and the Role of
        Middleboxes

   The term "end-to-end security" often has multiple interpretations.
   Here, we consider end-to-end security in the context of end-to-end IP
   connectivity from a sender to a receiver.  Services such as
   confidentiality and integrity protection on packet data, message
   authentication codes, or encryption are typically used to provide
   end-to-end security.  These protection methods render the protected
   parts of the packets immutable as rewriting is either not possible
   because (i) the relevant information is encrypted and inaccessible to
   the gateway or (ii) rewriting integrity-protected parts of the packet
   would invalidate the end-to-end integrity protection.

   Protocols for constrained IoT networks are not exactly identical to
   their larger Internet counterparts, for efficiency and performance
   reasons.  Hence, more or less subtle differences between protocols
   for constrained IoT networks and Internet protocols will remain.
   While these differences can be bridged with protocol translators at
   middleboxes, they may become major obstacles if end-to-end security
   measures between IoT devices and Internet hosts are needed.

   If access to data or messages by the middleboxes is required or
   acceptable, then a diverse set of approaches for handling such a
   scenario is available.  Note that some of these approaches affect the
   meaning of end-to-end security in terms of integrity and
   confidentiality, since the middleboxes will be able to either decrypt
   or partially modify the exchanged messages:

   1.  Sharing credentials with middleboxes enables them to transform
       (for example, decompress, convert, etc.) packets and reapply the
       security measures after transformation.  This method abandons
       end-to-end security and is only applicable to simple scenarios
       with a rudimentary security model.

   2.  Reusing the Internet wire format for IoT makes conversion between
       IoT and Internet protocols unnecessary.  However, it can lead to
       poor performance in some use cases because IoT-specific
       optimizations (for example, stateful or stateless compression)
       are not possible.

   3.  Selectively protecting vital and immutable packet parts with a
       message authentication code or encryption requires a careful
       balance between performance and security.  Otherwise, this
       approach might either result in poor performance or poor
       security, depending on which parts are selected for protection,
       where they are located in the original packet, and how they are
       processed.  [OSCORE] proposes a solution in this direction by
       encrypting and integrity protecting most of the message fields
       except those parts that a middlebox needs to read or change.

   4.  Homomorphic encryption techniques can be used in the middlebox to
       perform certain operations.  However, this is limited to data
       processing involving arithmetic operations.  Furthermore, the
       performance of existing libraries -- for example, Microsoft SEAL
       [SEAL] -- is still too limited, and homomorphic encryption
       techniques are not widely applicable yet.

   5.  Message authentication codes that sustain transformation can be
       realized by considering the order of transformation and
       protection (for example, by creating a signature before
       compression so that the gateway can decompress the packet without
       recalculating the signature).  Such an approach enables IoT-
       specific optimizations but is more complex and may require
       application-specific transformations before security is applied.
       Moreover, the usage of encrypted or integrity-protected data
       prevents middleboxes from transforming packets.

   6.  Mechanisms based on object security can bridge the protocol
       worlds but still require that the two worlds use the same object-
       security formats.  Currently, the object-security format based on
       COSE [RFC8152] is different from JSON Object Signing and
       Encryption (JOSE) [RFC7520] or Cryptographic Message Syntax (CMS)
       [RFC5652].  Legacy devices relying on traditional Internet
       protocols will need to update to the newer protocols for
       constrained environments to enable real end-to-end security.
       Furthermore, middleboxes do not have any access to the data, and
       this approach does not prevent an attacker who is capable of
       modifying relevant message header fields that are not protected.

   To the best of our knowledge, none of the mentioned security
   approaches that focus on the confidentiality and integrity of the
   communication exchange between two IP endpoints provide the perfect
   solution in this problem space.

5.1.4.  New Network Architectures and Paradigm

   There is a multitude of new link-layer protocols that aim to address
   the resource-constrained nature of IoT devices.  For example, IEEE
   802.11ah [IEEE802ah] has been specified for extended range and lower
   energy consumption to support IoT devices.  Similarly, LPWAN
   protocols such as LoRa [LoRa], Sigfox [sigfox], and NarrowBand IoT
   (NB-IoT) [NB-IoT] are all designed for resource-constrained devices
   that require long range and low bit rates.  [RFC8376] provides an
   informational overview of the set of LPWAN technologies being
   considered by the IETF.  It also identifies the potential gaps that
   exist between the needs of those technologies and the goal of running
   IP in such networks.  While these protocols allow IoT devices to
   conserve energy and operate efficiently, they also add additional
   security challenges.  For example, the relatively small MTU can make
   security handshakes with large X509 certificates a significant
   overhead.  At the same time, new communication paradigms also allow
   IoT devices to communicate directly amongst themselves with or
   without support from the network.  This communication paradigm is
   also referred to as Device-to-Device (D2D), Machine-to-Machine (M2M),
   or Thing-to-Thing (T2T) communication, and it is motivated by a
   number of features such as improved network performance, lower
   latency, and lower energy requirements.

5.2.  Bootstrapping of a Security Domain

   Creating a security domain from a set of previously unassociated IoT
   devices is a key operation in the lifecycle of a thing in an IoT
   network.  This aspect is further elaborated and discussed in the
   T2TRG draft on bootstrapping [BOOTSTRAP].

5.3.  Operational Challenges

   After the bootstrapping phase, the system enters the operational
   phase.  During the operational phase, things can use the state
   information created during the bootstrapping phase in order to
   exchange information securely.  In this section, we discuss the
   security challenges during the operational phase.  Note that many of
   the challenges discussed in Section 5.1 apply during the operational
   phase.

5.3.1.  Group Membership and Security

   Group-key negotiation is an important security service for IoT
   communication patterns in which a thing sends some data to multiple
   things or data flows from multiple things towards a thing.  All
   discussed protocols only cover unicast communication and therefore do
   not focus on group-key establishment.  This applies in particular to
   (D)TLS and IKEv2.  Thus, a solution is required in this area.  A
   potential solution might be to use the Diffie-Hellman keys -- which
   are used in IKEv2 and HIP to set up a secure unicast link -- for
   group Diffie-Hellman key negotiations.  However, Diffie-Hellman is a
   relatively heavy solution, especially if the group is large.

   Symmetric and asymmetric keys can be used in group communication.
   Asymmetric keys have the advantage that they can provide source
   authentication.  However, doing broadcast encryption with a single
   public/private key pair is also not feasible.  Although a single
   symmetric key can be used to encrypt the communication or compute a
   message authentication code, it has inherent risks since the capture
   of a single node can compromise the key shared throughout the
   network.  The usage of symmetric keys also does not provide source
   authentication.  Another factor to consider is that asymmetric
   cryptography is more resource-intensive than symmetric key solutions.
   Thus, the security risks and performance trade-offs of applying
   either symmetric or asymmetric keys to a given IoT use case need to
   be well analyzed according to risk and usability assessments
   [RFC8387].  [MULTICAST] is looking at a combination of
   confidentiality using a group key and source authentication using
   public keys in the same packet.

   Conceptually, solutions that provide secure group communication at
   the network layer (IPsec/IKEv2, HIP/Diet HIP) may have an advantage
   in terms of the cryptographic overhead when compared to application-
   focused security solutions (TLS/DTLS).  This is due to the fact that
   application-focused solutions require cryptographic operations per
   group application, whereas network-layer approaches may allow sharing
   secure group associations between multiple applications (for example,
   for neighbor discovery and routing or service discovery).  Hence,
   implementing shared features lower in the communication stack can
   avoid redundant security measures.  However, it is important to note
   that sharing security contexts among different applications involves
   potential security threats, e.g., if one of the applications is
   malicious and monitors exchanged messages or injects fake messages.
   In the case of OSCORE, it provides security for CoAP group
   communication as defined in RFC 7390, i.e., based on multicast IP.
   If the same security association is reused for each application, then
   this solution does not seem to have more cryptographic overhead
   compared to IPsec.

   Several group-key solutions have been developed by the MSEC Working
   Group of the IETF [WG-MSEC].  The MIKEY architecture [RFC4738] is one
   example.  While these solutions are specifically tailored for
   multicast and group-broadcast applications in the Internet, they
   should also be considered as candidate solutions for group-key
   agreement in IoT.  The MIKEY architecture, for example, describes a
   coordinator entity that disseminates symmetric keys over pair-wise
   end-to-end secured channels.  However, such a centralized approach
   may not be applicable in a distributed IoT environment, where the
   choice of one or several coordinators and the management of the group
   key is not trivial.

5.3.2.  Mobility and IP Network Dynamics

   It is expected that many things (for example, user devices and
   wearable sensors) will be mobile in the sense that they are attached
   to different networks during the lifetime of a security association.
   Built-in mobility signaling can greatly reduce the overhead of the
   cryptographic protocols because unnecessary and costly re-
   establishments of the session (possibly including handshake and key
   agreement) can be avoided.  IKEv2 supports host mobility with the
   MOBIKE extension [RFC4555] [RFC4621].  MOBIKE refrains from applying
   heavyweight cryptographic extensions for mobility.  However, MOBIKE
   mandates the use of IPsec tunnel mode, which requires the
   transmission of an additional IP header in each packet.

   HIP offers simple yet effective mobility management by allowing hosts
   to signal changes to their associations [RFC8046].  However, slight
   adjustments might be necessary to reduce the cryptographic costs --
   for example, by making the public key signatures in the mobility
   messages optional.  Diet HIP does not define mobility yet, but it is
   sufficiently similar to HIP and can use the same mechanisms.  DTLS
   provides some mobility support by relying on a connection ID (CID).
   The use of connection IDs can provide all the mobility functionality
   described in [Williams] except sending the updated location.  The
   specific need for IP-layer mobility mainly depends on the scenario in
   which the nodes operate.  In many cases, mobility supported by means
   of a mobile gateway may suffice to enable mobile IoT networks, such
   as body-sensor networks.  Using message-based application-layer
   security solutions such as OSCORE [OSCORE] can also alleviate the
   problem of re-establishing lower-layer sessions for mobile nodes.

5.4.  Secure Software Update and Cryptographic Agility

   IoT devices are often expected to stay functional for several years
   or decades, even though they might operate unattended with direct
   Internet connectivity.  Software updates for IoT devices are
   therefore required not only for new functionality but also to

   eliminate security vulnerabilities due to software bugs, design
   flaws, or deprecated algorithms.  Software bugs might remain even
   after careful code review.  Implementations of security protocols
   might contain (design) flaws.  Cryptographic algorithms can also
   become insecure due to advances in cryptanalysis.  Therefore, it is
   necessary that devices that are incapable of verifying a
   cryptographic signature are not exposed to the Internet, even
   indirectly.

   In his essay, Schneier highlights several challenges that hinder
   mechanisms for secure software update of IoT devices
   [SchneierSecurity].  First, there is a lack of incentives for
   manufacturers, vendors, and others on the supply chain to issue
   updates for their devices.  Second, parts of the software running on
   IoT devices is simply a binary blob without any source code
   available.  Since the complete source code is not available, no
   patches can be written for that piece of code.  Lastly, Schneier
   points out that even when updates are available, users generally have
   to manually download and install them.  However, users are never
   alerted about security updates, and many times do not have the
   necessary expertise to manually administer the required updates.

   The US Federal Trade Commission (FTC) staff report on "Internet of
   Things - Privacy & Security in a Connected World" [FTCreport] and the
   Article 29 Working Party's "Opinion 8/2014 on the Recent Developments
   on the Internet of Things" [Article29] also document the challenges
   for secure remote software update of IoT devices.  They note that
   even providing such a software-update capability may add new
   vulnerabilities for constrained devices.  For example, a buffer
   overflow vulnerability in the implementation of a software update
   protocol (TR69) [TR69] and an expired certificate in a hub device
   [wink] demonstrate how the software-update process itself can
   introduce vulnerabilities.

   Powerful IoT devices that run general-purpose operating systems can
   make use of sophisticated software-update mechanisms known from the
   desktop world.  However, resource-constrained devices typically do
   not have any operating system and are often not equipped with a
   memory management unit or similar tools.  Therefore, they might
   require more specialized solutions.

   An important requirement for secure software and firmware updates is
   source authentication.  Source authentication requires the resource-
   constrained things to implement public key signature verification
   algorithms.  As stated in Section 5.1.1, resource-constrained things
   have limited computational capabilities and energy supply available,
   which can hinder the amount and frequency of cryptographic processing
   that they can perform.  In addition to source authentication,

   software updates might require confidential delivery over a secure
   (encrypted) channel.  The complexity of broadcast encryption can
   force the usage of point-to-point secure links; however, this
   increases the duration of a software update in a large system.
   Alternatively, it may force the usage of solutions in which the
   software update is delivered to a gateway and then distributed to the
   rest of the system with a network key.  Sending large amounts of data
   that later needs to be assembled and verified over a secure channel
   can consume a lot of energy and computational resources.  Correct
   scheduling of the software updates is also a crucial design
   challenge.  For example, a user of connected light bulbs would not
   want them to update and restart at night.  More importantly, the user
   would not want all the lights to update at the same time.

   Software updates in IoT systems are also needed to update old and
   insecure cryptographic primitives.  However, many IoT systems, some
   of which are already deployed, are not designed with provisions for
   cryptographic agility.  For example, many devices come with a
   wireless radio that has an AES128 hardware coprocessor.  These
   devices solely rely on the coprocessor for encrypting and
   authenticating messages.  A software update adding support for new
   cryptographic algorithms implemented solely in software might not fit
   on these devices due to limited memory, or might drastically hinder
   its operational performance.  This can lead to the use of old and
   insecure software.  Therefore, it is important to account for the
   fact that cryptographic algorithms would need to be updated and
   consider the following when planning for cryptographic agility:

   1.  Would it be secure to use the existing cryptographic algorithms
       available on the device for updating with new cryptographic
       algorithms that are more secure?

   2.  Will the new software-based implementation fit on the device
       given the limited resources?

   3.  Would the normal operation of existing IoT applications on the
       device be severely hindered by the update?

   Finally, we would like to highlight the previous and ongoing work in
   the area of secure software and firmware updates at the IETF.
   [RFC4108] describes how Cryptographic Message Syntax (CMS) [RFC5652]
   can be used to protect firmware packages.  The IAB has also organized
   a workshop to understand the challenges for secure software update of
   IoT devices.  A summary of the recommendations to the standards
   community derived from the discussions during that workshop have been
   documented [RFC8240].  A working group called Software Updates for
   Internet of Things (SUIT) [WG-SUIT] is currently working on a new
   specification to reflect the best current practices for firmware

   update based on experience from IoT deployments.  It is specifically
   working on describing an IoT firmware update architecture and
   specifying a manifest format that contains metadata about the
   firmware update package.  Finally, the Trusted Execution Environment
   Provisioning Working Group [WG-TEEP] aims at developing a protocol
   for lifecycle management of trusted applications running on the
   secure area of a processor (Trusted Execution Environment (TEE)).

5.5.  End-of-Life

   Like all commercial devices, IoT devices have a given useful
   lifetime.  The term "end-of-life" (EOL) is used by vendors or network
   operators to indicate the point of time at which they limit or end
   support for the IoT device.  This may be planned or unplanned (for
   example, when the manufacturer goes bankrupt, the vendor just decides
   to abandon a product, or a network operator moves to a different type
   of networking technology).  A user should still be able to use and
   perhaps even update the device.  This requires for some form of
   authorization handover.

   Although this may seem far-fetched given the commercial interests and
   market dynamics, we have examples from the mobile world where the
   devices have been functional and up to date long after the original
   vendor stopped supporting the device.  CyanogenMod for Android
   devices and OpenWrt for home routers are two such instances where
   users have been able to use and update their devices even after the
   official EOL.  Admittedly, it is not easy for an average user to
   install and configure their devices on their own.  With the
   deployment of millions of IoT devices, simpler mechanisms are needed
   to allow users to add new trust anchors [RFC6024] and install
   software and firmware from other sources once the device is EOL.

5.6.  Verifying Device Behavior

   Users using new IoT appliances such as Internet-connected smart
   televisions, speakers, and cameras are often unaware that these
   devices can undermine their privacy.  Recent revelations have shown
   that many IoT device vendors have been collecting sensitive private
   data through these connected appliances with or without appropriate
   user warnings [cctv].

   An IoT device's user/owner would like to monitor and verify its
   operational behavior.  For instance, the user might want to know if
   the device is connecting to the server of the manufacturer for any
   reason.  This feature -- connecting to the manufacturer's server --
   may be necessary in some scenarios, such as during the initial
   configuration of the device.  However, the user should be kept aware

   of the data that the device is sending back to the vendor.  For
   example, the user might want to know if his/her TV is sending data
   when he/she inserts a new USB stick.

   Providing such information to the users in an understandable fashion
   is challenging.  This is because IoT devices are not only resource
   constrained in terms of their computational capability but also in
   terms of the user interface available.  Also, the network
   infrastructure where these devices are deployed will vary
   significantly from one user environment to another.  Therefore, where
   and how this monitoring feature is implemented still remains an open
   question.

   Manufacturer Usage Description (MUD) files [RFC8520] are perhaps a
   first step towards implementation of such a monitoring service.  The
   idea behind MUD files is relatively simple: IoT devices would
   disclose the location of their MUD file to the network during
   installation.  The network can then retrieve those files and learn
   about the intended behavior of the devices stated by the device
   manufacturer.  A network-monitoring service could then warn the user/
   owner of devices if they don't behave as expected.

   Many devices and software services that automatically learn and
   monitor the behavior of different IoT devices in a given network are
   commercially available.  Such monitoring devices/services can be
   configured by the user to limit network traffic and trigger alarms
   when unexpected operation of IoT devices is detected.

5.7.  Testing: Bug Hunting and Vulnerabilities

   Given that IoT devices often have inadvertent vulnerabilities, both
   users and developers would want to perform extensive testing on their
   IoT devices, networks, and systems.  Nonetheless, since the devices
   are resource constrained and manufactured by multiple vendors, some
   of them very small, devices might be shipped with very limited
   testing, so that bugs can remain and can be exploited at a later
   stage.  This leads to two main types of challenges:

   1.  It remains to be seen how the software-testing and quality-
       assurance mechanisms used from the desktop and mobile world will
       be applied to IoT devices to give end users the confidence that
       the purchased devices are robust.  Bodies such as the European
       Cyber Security Organization (ECSO) [ECSO] are working on
       processes for security certification of IoT devices.

   2.  It is also an open question how the combination of devices from
       multiple vendors might actually lead to dangerous network
       configurations -- for example, if the combination of specific

       devices can trigger unexpected behavior.  It is needless to say
       that the security of the whole system is limited by its weakest
       point.

5.8.  Quantum-Resistance

   Many IoT systems that are being deployed today will remain
   operational for many years.  With the advancements made in the field
   of quantum computers, it is possible that large-scale quantum
   computers will be available in the future for performing
   cryptanalysis on existing cryptographic algorithms and cipher suites.
   If this happens, it will have two consequences.  First,
   functionalities enabled by means of primitives such as RSA or ECC --
   namely, key exchange, public key encryption, and signature -- would
   not be secure anymore due to Shor's algorithm.  Second, the security
   level of symmetric algorithms will decrease, for example, the
   security of a block cipher with a key size of b bits will only offer
   b/2 bits of security due to Grover's algorithm.

   The above scenario becomes more urgent when we consider the so-called
   "harvest and decrypt" attack in which an attacker can start to
   harvest (store) encrypted data today, before a quantum computer is
   available, and decrypt it years later, once a quantum computer is
   available.  Such "harvest and decrypt" attacks are not new and were
   used in the VENONA project [venona-project].  Many IoT devices that
   are being deployed today will remain operational for a decade or even
   longer.  During this time, digital signatures used to sign software
   updates might become obsolete, making the secure update of IoT
   devices challenging.

   This situation would require us to move to quantum-resistant
   alternatives -- in particular, for those functionalities involving
   key exchange, public key encryption, and signatures.  [C2PQ]
   describes when quantum computers may become widely available and what
   steps are necessary for transitioning to cryptographic algorithms
   that provide security even in the presence of quantum computers.
   While future planning is hard, it may be a necessity in certain
   critical IoT deployments that are expected to last decades or more.
   Although increasing the key size of the different algorithms is
   definitely an option, it would also incur additional computational
   overhead and network traffic.  This would be undesirable in most
   scenarios.  There have been recent advancements in quantum-resistant
   cryptography.  We refer to [ETSI-GR-QSC-001] for an extensive
   overview of existing quantum-resistant cryptography, and [RFC7696]
   provides guidelines for cryptographic algorithm agility.

5.9.  Privacy Protection

   People will eventually be surrounded by hundreds of connected IoT
   devices.  Even if the communication links are encrypted and
   protected, information about people might still be collected or
   processed for different purposes.  The fact that IoT devices in the
   vicinity of people might enable more pervasive monitoring can
   negatively impact their privacy.  For instance, imagine the scenario
   where a static presence sensor emits a packet due to the presence or
   absence of people in its vicinity.  In such a scenario, anyone who
   can observe the packet can gather critical privacy-sensitive
   information.

   Such information about people is referred to as personal data in the
   European Union (EU) or Personally identifiable information (PII) in
   the US.  In particular, the General Data Protection Regulation (GDPR)
   [GDPR] defines personal data as: "any information relating to an
   identified or identifiable natural person ('data subject'); an
   identifiable natural person is one who can be identified, directly or
   indirectly, in particular by reference to an identifier such as a
   name, an identification number, location data, an online identifier
   or to one or more factors specific to the physical, physiological,
   genetic, mental, economic, cultural or social identity of that
   natural person".

   Ziegeldorf [Ziegeldorf] defines privacy in IoT as a threefold
   guarantee:

   1.  Awareness of the privacy risks imposed by IoT devices and
       services.  This awareness is achieved by means of transparent
       practices by the data controller, i.e., the entity that is
       providing IoT devices and/or services.

   2.  Individual control over the collection and processing of personal
       information by IoT devices and services.

   3.  Awareness and control of the subsequent use and dissemination of
       personal information by data controllers to any entity outside
       the subject's personal control sphere.  This point implies that
       the data controller must be accountable for its actions on the
       personal information.

   Based on this definition, several threats to the privacy of users
   have been documented [Ziegeldorf] [RFC6973], in particular
   considering the IoT environment and its lifecycle:

   1.  Identification - refers to the identification of the users, their
       IoT devices, and generated data.

   2.  Localization - relates to the capability of locating a user and
       even tracking them, e.g., by tracking MAC addresses in Wi-Fi or
       Bluetooth.

   3.  Profiling - is about creating a profile of the user and their
       preferences.

   4.  Interaction - occurs when a user has been profiled and a given
       interaction is preferred, presenting (for example, visually) some
       information that discloses private information.

   5.  Lifecycle transitions - take place when devices are, for example,
       sold without properly removing private data.

   6.  Inventory attacks - happen if specific information about IoT
       devices in possession of a user is disclosed.

   7.  Linkage - is about when information of two of more IoT systems
       (or other data sets) is combined so that a broader view of the
       personal data captured can be created.

   When IoT systems are deployed, the above issues should be considered
   to ensure that private data remains private.  These issues are
   particularly challenging in environments in which multiple users with
   different privacy preferences interact with the same IoT devices.
   For example, an IoT device controlled by user A (low privacy
   settings) might leak private information about another user B (high
   privacy settings).  How to deal with these threats in practice is an
   area of ongoing research.

5.10.  Reverse-Engineering Considerations

   Many IoT devices are resource constrained and often deployed in
   unattended environments.  Some of these devices can also be purchased
   off the shelf or online without any credential-provisioning process.
   Therefore, an attacker can have direct access to the device and apply
   advanced techniques to retrieve information that a traditional black-
   box model does not consider.  Examples of those techniques are side-
   channel attacks or code disassembly.  By doing this, the attacker can
   try to retrieve data such as:

   1.  Long-term keys.  These long-term keys can be extracted by means
       of a side-channel attack or reverse engineering.  If these keys
       are exposed, then they might be used to perform attacks on
       devices deployed in other locations.

   2.  Source code.  Extraction of source code might allow the attacker
       to determine bugs or find exploits to perform other types of
       attacks.  The attacker might also just sell the source code.

   3.  Proprietary algorithms.  The attacker can analyze these
       algorithms gaining valuable know-how.  The attacker can also
       create copies of the product (based on those proprietary
       algorithms) or modify the algorithms to perform more advanced
       attacks.

   4.  Configuration or personal data.  The attacker might be able to
       read personal data, e.g., healthcare data, that has been stored
       on a device.

   One existing solution to prevent such data leaks is the use of a
   secure element, a tamper-resistant device that is capable of securely
   hosting applications and their confidential data.  Another potential
   solution is the usage of a Physical Unclonable Function (PUF) that
   serves as unique digital fingerprint of a hardware device.  PUFs can
   also enable other functionalities such as secure key storage.
   Protection against such data leakage patterns is not trivial since
   devices are inherently resource-constrained.  An open question is
   whether there are any viable techniques to protect IoT devices and
   the data in the devices in such an adversarial model.

5.11.  Trustworthy IoT Operation

   Flaws in the design and implementation of IoT devices and networks
   can lead to security vulnerabilities.  A common flaw is the use of
   well-known or easy-to-guess passwords for configuration of IoT
   devices.  Many such compromised IoT devices can be found on the
   Internet by means of tools such as Shodan [shodan].  Once discovered,
   these compromised devices can be exploited at scale -- for example,
   to launch DDoS attacks.  Dyn, a major DNS service provider, was
   attacked by means of a DDoS attack originating from a large IoT
   botnet composed of thousands of compromised IP cameras [Dyn-Attack].
   There are several open research questions in this area:

   1.  How to avoid vulnerabilities in IoT devices that can lead to
       large-scale attacks?

   2.  How to detect sophisticated attacks against IoT devices?

   3.  How to prevent attackers from exploiting known vulnerabilities at
       a large scale?

   Some ideas are being explored to address this issue.  One of the
   approaches relies on the use of Manufacturer Usage Description (MUD)
   files [RFC8520].  As explained earlier, this proposal requires IoT
   devices to disclose the location of their MUD file to the network
   during installation.  The network can then (i) retrieve those files,
   (ii) learn from the manufacturers the intended usage of the devices
   (for example, which services they need to access), and then (iii)
   create suitable filters and firewall rules.