TEEP WG S. Faibish
Internet-Draft Dell EMC
Intended status: Informational July 7, 2019
Expires: January 7, 2020
Usecases definition for IoT DDoS attacks prevention
draft-faibish-iot-ddos-usecases-00
Abstract
This document specifies several usecases related to the different
ways IoT devices are exploited by malicious adversaries to
instantiate Distributed Denial of Services (DDoS) attacks. The
attacks are generted from IoT devices that have no proper protection
against generating unsolicited communication messages targeting a
certain network and creating large amounts of network traffic. The
attackers take advantage of breaches in the configuration data in
unprotected IoT devices exploited for DDoS attacks. The attackers
take advantage of the IoT devices that can send network packets
that were generated by malicious code that interacts with an OS
implementation that runs on the IoT devices. The prupose of this
draft is to prsent possible IoT DDoS usecases that need to be
prevented by TEE. The major enabler of such attacks is related to
IoT devices that have no OS or unprotected EE OS and run
code that is downloaded to them from the TA and modified by
man-in-the-middle that inserts malicious code in the OS.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of Internet-Draft Shadow Directories can be accessed at
https://www.ietf.org/standards/ids/internet-draft-mirror-sites/.
This Internet-Draft will expire on January 7, 2020.
Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved.
Faibish Expires January 7, 2020 [Page 1]
Internet-Draft Usecases definition for IoT DDoS attacks July 2019
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Usecases . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. Upgradable OS less IoT devices . . . . . . . . . . . . . . 4
4.2. IoT devices connected to a gateway server . . . . . . . . 5
4.3. Smart IoT devices with full OS . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
10.1. Normative References . . . . . . . . . . . . . . . . . . 8
10.2. Informative References . . . . . . . . . . . . . . . . . 8
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction
Applications executing in an IoT device are exposed to many different
attacks intended to compromise the execution of the application, or
reveal the data upon which those applications are operating. The
problem is more acute for IoT devices that run low level of OS or no
OS at all and have limited ability to prevent malicious network
traffic leading to DDoS. These attacks increase with the number of
applications running on the device, with such other applications
coming from potentially untrustworthy sources or due to
man-in-the-middle mangling with the application code inserting
random packets in the communication of the IoT back to operator.
The potential for attacks generated by these devices further
increases with the complexity of features and applications on
devices, with limited OS capabilities, running code that is
downloaded from untrustworthy operators. The
danger of attacks on a OS less system increases as the data
transmitted by the devices to the operator increases.
Faibish Expires January 7, 2020 [Page 2]
Internet-Draft Usecases definition for IoT DDoS attacks July 2019
As an example, an IoT device that sends pollution data each minute
from city wide sensors to a cloud application that analyses city air
quality and generate reports and warning to the public can be used
to send random data at much higher frequency like 1000 per second.
This malicious transmission can shut down the cloud receiving this
data. The worst part of this is that the IoT device OS has no idea
that the transmission is wrong and is creating DDoS for the cloud
used by the IoT devices. Additional there could be coordinated
attacks coming from many IoT devices connected to the same cloud
and shut down all the cloud services.
In general case there is an edge server to which the IoT devices
are connected and the server is managing the management of the
data transmitted to the OA. In this case the edge server has an
OS and a TEE that can prevent DDoS attacks that were generated
by the IoT devices if the transmission is malicious. Moreover
the edge server will facilitate the code upgrade and prevent
malicious code being stored on the device code. So, the edge
server will become the TEE for all the devices connected to it.
Moreover if the code of the device is compromised the edge
server will block the packets that were generated by the IoT
devices connected to it.
According to analysts study DDoS originated from IoT devices
accounted for 90% of all the DDoS attacks and increased 10x
in 2018 ([1]) and the majority of the attacks were from devices
with limited compute and OS resources as well as webcams with REE.
This will require special TEE protocol support preventing the use
of these devices for DDoS attacks. This draft is trying to present
the usecases that enable such attacks with the intention to request
that TEEP WG addresses this special security loophole. And the major
problem resides in the inability of IoT devices to prevent
broadcasting network packets generated by unauthorized code, inserted
at upgrade time, to execute on devices with low compute capabilities.
Trusted Execution Environments (TEEs), including Intel SGX, ARM
TrustZone, Secure Elements, and others, can enforce that only
authorized code can execute within the TEE, and any memory used by
such code is protected against tampering or disclosure outside the
TEE. This observation is only true if there is awareness that IoT
devices are enabled to send data back to the cloud and or the SP
that did the upgrade. In such environments malicious code includes
a method of external triggered or time based attacks.
In most such devices there is none or limited "Trusted Agent" or
"Trusted Application Manager (TAM)" on the client side running
inside the TEE. The purpose of this draft is to present 3 DDoS
usecases that TEEP needs to address prevention of using the IoT
devices as the origin of such attacks.
Faibish Expires January 7, 2020 [Page 3]
Internet-Draft Usecases definition for IoT DDoS attacks July 2019
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
This document also uses various terms defined in
[I-D.ietf-teep-architecture], including Trusted Execution Environment
(TEE), Trusted Application (TA), Trusted Application Manager (TAM),
Agent, and Broker.
3. Assumptions
This draft assumes that an applicable device may or may not be
equipped with any TEEs nor pre-provisioned with a device-unique
public/private key pair, which is securely stored.
A TEE uses an isolation mechanism between Trusted Applications to
ensure that one TA cannot read, modify or delete the data and code of
another TA. We also assume that there can be a TEE running in a edge
server to which the devices may be connected. The edge server will
include such a TEE and will become the secure gateway as
client/agent.
4. Usecases
4.1 Upgradable OS less IoT devices
The simplest IoT device we refer to here is a device that has enough
OS and EE to perform a single function like sending back to the
broker time series at given time intervals, Figure 1. As an example
an IoT device that monitors the air quality in a city and send back
to the cloud this data that will be aggregated with many sensors
around the city. The device will run simple code that can be executed
on the device and at a minimum it will be capable to receive and
install code upgrades from the Broker. Such devices have very
limited or no security or trust protection and it can be exposed
to man-in-the-middle attacks target by malicious actors that are
trying to insert malicious code MA (Malicious Application) in the
upgraded code.
Faibish Expires January 7, 2020 [Page 4]
Internet-Draft Usecases definition for IoT DDoS attacks July 2019
One example of such code may include a trigger, that can be activated
in a similar manner as the code upgrade request, and used to start
DDoS attacks coordinated as a cluster. As the device function is to
send time series data to the cloud the malicious code can send same
data 1000s of times fludding the recipient cloud from all the devices
in the cluster. As a second example the malicious code can use a
timer and start sending empty network packets back to the provider
network and also targeting a given IP address of a victim. Such
examples are attackes related to Mirai botnets also in [2] as
similar attacks were uncovered tergeting for example financial
institutions in order to hide cyberattacks for stilling money or
even crypto-currency.
+-------------------------------------------+
| Device |
| | Service Provider
| | |
| +-------------+ | +--------+ |
| | TEE |<------------------------------| |<-+
| | | | | TAM |
| | | | | |<-+
| | +---+ +---+ | | +---+----+ |
| | |MA | |TA | | | | |
| | | | | | | +-------+ | | |
| | | | | |<---------| App |<-----------------+ |
| | +-+-+ +-+-+ | | | | Device
| +---|-----|---+ +-------+ | Administrator
+--------|-----|----------------------------+
| +---------------------------------> Legitimate traffic
|
+---------------------------------------> DDoS traffic
Figure 1: OS less IoT devices diagram
4.2 IoT devices connected to a gateway server
In this case the OS less IoT device is connected to a local edge
TEEP server which has rich execution OS and acts as a bridge between
the device and the cloud collecting the time series from the device.
In this usecase the upgrades are done via the edge gateway server
that has full TEEP capabilities and can detect DDoS attacks and
prevent the DDoS traffic to escape outside the edge server. For
example the edge gateway server could be a computer with full
security protection or a mobile device such as a tablet or even a
cell phone. We assume that in this case the edge server has a full
TEE and can manage several IoT devices running multiple different
applications. We also assume that the edge server is connected to
a TEEP Broker. For example webcams can be such IoT devices connected
to gateway server used for DDoS attacks [1].
Faibish Expires January 7, 2020 [Page 5]
Internet-Draft Usecases definition for IoT DDoS attacks July 2019
+--------------> Legitimate traffic
+-------------------------------|-----------+
| Edge gateway | |
| +----+---+ | Service Provider
| | |----------+ |
| +-------------+ | TEEP | | | |
| | Device |<------| Broker | | | +--------+ |
| | DDoS | | | | +-->| |<-+
| | +---------------->|blocked | | | TAM-1 |
| | | traffic|blocked| |<-+ | | |<-+
| | +-+-+ +---+ | +--------+ | | +--------+ |
| | |MA | |TA | | | | |
| | | | | | | +-------+ | | |
| | | | | |<---------| App |--+ | |
| | +---+ +---+ | | | | Device Administrator
| +-------------+ | | |
| | | |
| +-------+ |
| |
| |
+-------------------------------------------+
Figure 2: OS less IoT devices connected to gateway server
In this scenario the DDoS traffic is only generating network traffic
inside the edge limits and can be stopped by the TEE inside the
server. For example when an edge server is connected to home
appliances such as home temperature control or electricity and water
meters that are supposed to send time series to the cloud,
triggering a DDoS will not be allowed to send packets outside the
gateway limits. It can still prevent sending the sensing data to
the cloud destination but TEEP will prevent DDoS traffic outside
the edge server. Additional to this using TEEP will prevent
code upgrades done from untrusted sources and even detect
malicious code to install on the device. In this configuration
(Figure 2) SPs do not directly interact with devices. DAs may
elect to use a TAM for remote administration of TAs instead of
managing each device directly. Moreover the Legitimate traffic
can be sanitized to prevent malicious code spread to other devices.
4.3 Smart IoT devices with full OS
The Internet of Things (IoT) has been posing threats to networks and
national infrastructures because of existing weak security in
devices. But there are IoT devices and systems that have the OS
and compute power to detect and prevent malware for generation DDoS
attacks. It is possible that for such devices can implement measures
to prevent malware from manipulating actuators (e.g., IoT controlling
computer assisted automobiles or self driving cars), or forcing such
cars into accidents and damage infrastructures and even lose life.
Faibish Expires January 7, 2020 [Page 6]
Internet-Draft Usecases definition for IoT DDoS attacks July 2019
Such an experiment was done in the research communities and there was
even a contest about how fast hackers can take control of a car
using automatic driving. The results were that the current security
of such cars is not strong enough to prevent taking control over the
internet. A TEE can be the best way to implement such IoT security
functions for "smart" environments using advanced OSes such as cars.
TEEs could be used to store variety of sensitive data for IoT
devices. For example, a TEE could be used in smart cars to
store a driver's biometric information for identification, available
in some new cars, and for protecting access driving wheel control
mechanism. Figure 3 presents the architecture of such a self
driving car. In this usecase the applications run inside the TEE and
are connected to the service provider's cloud similar to some
"connected" cars (BMW for example). The applications running inside
the TEE can be either monitoring functions or car status (TA1) or
diagnostic malfunctions (TA2). All these applications can be vital to
the operation of the car and the safety of the drivers and roads.
In general in this usecase the Service provider and the Device
Administrator are represented by the vehicle manufacturer during
the warranty time and after that they can be a different service
provider doing maintenance.
+-------------------------------------------+
| Device | Car Manufacturer
| +--------+ | or Service Provider
| | |----------+ |
| +-------------+ | TEEP |---------+| |
| | TEE-1 |<------| Broker | | || +--------+ |
| | | | |<---+ | |+-->| |<-+
| | | | | | | | +-| TAM-1 |
| | | | |<-+ | | +->| | |<-+
| | +---+ +---+ | +--------+ | | | | +--------+ |
| | |TA1| |TA2| | | | | | TAM-2 | |
| +-->| | | | | +-------+ | | | +--------+ |
| | | | | | |<---------| App-2 |--+ | | |
| | | +---+ +---+ | +-------+ | | | Car Manufacturer
| | +-------------+ | App-1 | | | |
| | | | | | |
| +--------------------| |---+ | |
| | |--------+ |
| +-------+ |
+-------------------------------------------+
Figure 3: OS capable IoT devices for connected cars
There are additional usecases similar to this one like electric
power and grid monitoring and control that have rich compute and
memory resources running in a centralized location (secure) or
in the cloud (unsecure) but need high levels of security.
Faibish Expires January 7, 2020 [Page 7]
Internet-Draft Usecases definition for IoT DDoS attacks July 2019
There are additional security models of IoT devices that can fit
in these 3 examples and we will extend the protocols to apply to
as many as we can consider as useful.
8. Security Considerations
Although TEEP architecture document [I-D.ietf-teep-architecture]
addresses some IoT devices examples there are IoT usecases that
require more detailed design and better definitions of the Broker
behavior in different usecases discussed in this draft. As such,
Broker implementations MUST support many of this usecases critical
for security and safety.
9. IANA Considerations
This document does not require actions by IANA.
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, <https://www.rfc-
editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
10.2. Informative References
[1] Vlajic, N., and Zhou, D., "IoT as a Land of Opportunity
for DDoS Hackers", Computer Magazine, July 2018, pp.
26-34.
[2] Kolias, C., Kambourakis, G., Stavrou, A., and Voas, J.,
"DDoS in the IoT: Mirai and Other Botnets", Computer
Magazine, July 2017, pp. 80-84.
[I-D.ietf-teep-architecture]
Pei, M., Tschofenig, H., Wheeler, D., Atyeo, A., and D.
Liu, "Trusted Execution Environment Provisioning (TEEP)
Architecture", draft-ietf-teep-architecture-02 (work in
progress), March 2019.
[GPTEE] Global Platform, "GlobalPlatform Device Technology: TEE
System Architecture, v1.1", Global Platform GPD_SPE_009,
January 2017, <https://globalplatform.org/specs-library/
tee-system-architecture-v1-1/>.
Faibish Expires January 7, 2020 [Page 8]
Internet-Draft Usecases definition for IoT DDoS attacks July 2019
Acknowledgments
This draft has attempted to capture many IoT security usecases known
to the author and presented in the literature as well as discussed
in the security forums. These usecases present challenges both for
DDoS attacks that became critical as well as applied security for
new autonomous devices. We proposed to add these usecases to the
TEEP Architecture draft.
Author's Address
Sorin Faibish
Dell EMC
228 South Street
Hopkinton, MA 01774
United States of America
Phone: +1 508-249-5745
Email: faibish.sorin@dell.com
Faibish Expires January 7, 2020 [Page 9]