The document discusses various security challenges at different levels of IoT architecture. At the sensor level, authentication of small devices with limited resources is challenging. GPS spoofing and hardware attacks are also risks. Networking components like the baseband processor can be vulnerable if firmware exploits exist. Hardening devices like Raspberry Pi that act as IoT hubs is important. When integrating with cloud services and APIs, authentication, privacy, and security configurability need attention.
6. OF TODAY
• Smart sensors which tells us for how long
our employees/students were on their seat
My boss on
seat or not ??
7. AND REALITY OF TOMORROW
4)Smart beds which automatically wake us up
(in case we have something urgent to do)
5)Smart utensils which tells our doctors about
what we ate in last 3 months
6)Smart meters to regulate flow of electricity in
our houses and buildings
7)Well today we have technology much beyond
what we usually imagine . . . .
9. IOT relies on satellites, Cellular networks and all the telecommunication system apart
From cloud, conventional networking and computing systems.
Implementation of IOT also relies on:
10. WHAT IOT SECURITY MEANS
• IOT Security is really about understanding
threats at all the different layers included at all
the different levels
• Threat modeling in IOT is really about
understanding threats at different levels and
then designing the security of application
based on it’s required functionality.
11. LEVEL-1
• How do I authenticate my sensors and what
could be the possible risk?
• Challenges:
• Small size
• No memory or processing power
• Physical security
• Example: temperature sensor, alcohol sensor,
pir sensor
12. MITIGATION
• Possible solutions:
• Use of micro-controllers (which then come
with their own challenges of course)
• Authentication problems can be solved
• Encryption can be used
14. OTHER SENSORS
• There are some sensors whose operation
depends on Physical Quantities like
(temperature, sound) etc.
• And on the other hand, there are sensors
which don’t directly use physical quantities.
Rather they rely on other equipment(like
satellites for their operation)
• Example is GPS technology
16. Problem
• What is GPS spoofing?
• The problem traces it’s route back to the basic
working of the GPS
• A GPS receiver constantly talks to the satellites
GPS
RECIEVER
SATELLITE
FREQUENCY
17. HOW ATTACK WORKS
• A GPS spoofing attack attempts to deceive a GPS
receiver by broadcasting counterfeit GPS signals,
structured to resemble a set of normal GPS
signals, or by rebroadcasting genuine signals
captured elsewhere or at a different time
• These spoofed signals may be modified in such a
way as to cause the receiver to estimate its
position to be somewhere other than where it
actually is, or to be located where it is but at a
different time, as determined by the attacker
18. PROOF OF CONCEPT
• A "proof-of-concept" attack was successfully
performed in June, 2013, when the luxury yacht
"White Rose" was misdirected with spoofed GPS
signals from Monaco to the island of Rhodes by a
group of aerospace engineering students from
the Cockrell School of Engineering at the
University of Texas in Austin
• It has been suggested that the capture of a
Lockheed RQ-170 drone aircraft in
northeastern Iran in December, 2011, was the
result of such an attack
19. Possible Solutions
• RAIM (Receiver autonomous integrity
monitoring)
• Use of Artificial Intelligent Algorithms to catch
the difference in patterns (Only applicable if
the path to be taken by a device is know in
advance and measure of deviation from
original path is monitored)
20. LEVEL-2
Let’s look at the Hardware technology on which IOT
architecture Relies. (taking only gateway hardware
into consideration)
Apps
OS/Services
Hardware/Firmware e.g. ARM, INTEL, QUALCOMM,
BROADCOM, AVR, FREESCALE etc
e.g. LINUX, RTOS etc and services provided
By them
Custom IOT applications written in either
Python, Java or C/C++ or any other language
21. Possible Attacks on Processor
• What are the different ways in which a
hardware is compromised?
• ARM (Advanced Risk Machines) has outlined 3
types of Hardware Attacks
22. Hardware Threats to IOT
• Hack attack
• A hack attack is one where the hacker is only capable of executing a
software attack. Examples of hack attacks include viruses and malware
which are downloaded to the device via a physical or a wireless
connection.
• In many cases of a successful hack attack the device user inadvertently
approves the installation of the software that then executes the attack.
This is either because the malware pretends to be a piece of the software
that the user does want to install, or because the user does not
understand the warning messages displayed by the operating
environment.
• In the book “Securing Java” there is a section which sums up the decision
making capability of the typical user when it comes to choosing between
security and desirable functionality:
• “Given a choice between dancing pigs and security, users will pick dancing
pigs every time.”
23. IOT Security Risks
• Shack attack
• A shack attack is a low-budget hardware attack, using equipment
that could be bought on the high street from a store such as Radio
Shack. In these scenarios the attackers have physical access to the
device, but not enough equipment or expertise to attack within the
integrated circuit packages.
• The attackers can attempt to connect to the device using JTAG
debug and built-in self test facilities. They can passively monitor the
system using logic probes and network analyzers to snoop bus lines,
pins and system signals. The attackers may also be able to perform
simple active hardware attacks, such as forcing pins and bus lines to
be at a high or low voltage, reprogramming memory devices, and
replacing hardware components with malicious alternatives.
24. Unique Secret per Device
• Lab attack
• The lab attack vector is the most comprehensive and invasive. If the attacker has
access to laboratory equipment, such as electron microscopes, they can perform
unlimited reverse engineering of the device. It must be assumed that the attacker
can reverse engineer transistor-level detail for any sensitive part of the design -
including logic and memories.
• Attackers can reverse engineer a design, attach microscopic logic probes to silicon
metal layers, and glitch a running circuit using lasers or other techniques. Attackers
can also monitor analog signals, such as device power usage and electromagnetic
emissions, to perform attacks such as cryptographic key analysis.
• In most cases, considering the rule of thumb that states every device can be
broken, a device should not try and defend against lab attack directly, but should
take measures which limit the damage when a device is broken and therefore
make the lab attack uneconomical. Use of per-device unique secrets is one
example where reverse engineering a single device provides the attacker with no
useful information; they have the secret for the device that they already own, but
not any of the other devices in that class.
25. Feasibility of these attacks
• Hardware attacks are less common because:
• Not every attacker has access to a lab or
specialized skills and equipment required
• Firmware vulnerabilities can be patched
• OS’es can be made hard
• Attacker (in many cases) need to be physically
present to attack the hardware, which makes
it a little difficult
26. That’s it about hardware
attacks?
• The story of hardware hacking should have
ended here
27. But then came the base !!
• But the truth is that many people access
internet using cellular services
• IOT is possible with moving devices only if we
use GPRS, 3G, 4G services
And Baseband can act as the base for all
Hardware hacking to start.
It is the not the second but the first door
Used by hackers to come in.
28. • Most devices use baseband processors to talk
to BTS stations
• Mobile phones being the best example
• Baseband processor is different from
application processor
• But they are usually packaged into the same
SOC
29. What is the Problem?
• The problem is:
• Most baseband processors use proprietary
firmware from companies like ‘qualcomm,
broadcomm and so on.
• Researchers show that there are many
vulnerabilities in these firmwares
• And what makes things more interesting is
that they can be attacked remotely
30. • But we are using cell-phones from decades
without problems?
31. Problems with Cellular Setup
• Initially it was not possible for an attacker or
security researcher to set his own “BTS” just for
attack/research purpose
• Now it has become much easier with things like:
• OpenBTS (open software)
• IDA (used for reverse engineering)
• Raspberry pi ??? Why raspberry pi.
• Any radio front-end (to generate frequency
signals)
32. • What is the depth of penetration of these attacks??
• It depends upon:
• Whether app-processor and baseband processor share
ram or their communication is hardened??
• Moreover it depends upon what is allowed by the
vulnerability being exploited
• In some cases it is possible to hijack the system
completely bypassing all security mechanisms
implemented by app-processor
• Stack overflows and Heap overflows are most common
attacks
33. Impact
• What could be the impact of cellular based
attacks:
• Millions of devices could be compromised by a
single vulnerability
• GSM is still the most popular network in the
world
34. Suggested by Researchers
• Possible ways of mitigating the risk:
• Isolation of memory used by the processors
• In many cases use of a serial communication,
only AT cmd interface
• Scanning the data being received from the
baseband processors
35. Level-3
• After sensors and hardware, the next level is
protection at OS and software levels.
• This levels is most vulnerable to attacks
• Mostly attackers get into systems because of
vulnerable OS software or weakness in the
applications being served on the top of
different software stacks
36. When Raspberry is the
GAteway
• Raspberry Pi is becoming increasing popular
among IOT enthusiasts
• If we search ExploitDB with keyword
‘Raspberry PI’ we can easily find shell codes
targeted towards the ARM architecture
• Hardening the raspberry is therefore another
challenge while designing apps for the IOT
37. Hardening the PI
• What are some of the common ways of
hardening IOT hub (in general) and specifically
Raspberry PI (running the Rasbian OS)
38. Make it hard for attackers
• General Precautionary measures:
• Create a new user with your USERNAME and
set a strong PASSWORD (many scanners come
these days which try to login using
pi/raspberry pair)
• Delete the default pi/raspberry user account
from your system
• Use a strong password (Check for list of black-
listed password on internet and avoid them)
39. • Decide what you really want to do with your PI,
and disable any unused services
• Rasbian comes pre-configured with JDK, php,
python, perl and many such programming and
other tools which may not at all be required but
could be potential ATTACK VECTORS
• Disable all such un-used software
• E.g. Do you really need a web server running? If
not disable it
• If you don’t use java, just “purge the JDK” and all
related tools
40. • If Apache is required, then be sure to secure it
using the OWASP best practices on hardening
an apache server
• Make sure to do the same with other services
like MySQL, NGINX
• OWASP (http://owasp.org) is a good source of
information on how we can secure our servers
and services running.
41. • Decide whether you need to ssh into your PI
• If yes make sure to use public/private key pair
for authentication of use strong passwords
• Disable remote login as a root user
• Change the default ssh port
• Use Account Lockout after 3-5 failed attempts
• Add another layer of security using techniques
like PORT-KNOCKING
42. • Configure logging to monitor logins and failed
login attempts
• Install and configure iptables
• More defensive measures:
• Honeypots can be deployed.
• https://redmine.honeynet.org/projects/honeeepi
/wiki
• Honeeepi is a project based on setting up
honeynets with raspberry pi
43. • Encrypt only the folder which contain useful
data
• Full Disk Encryption could be an expensive
operation in context of Raspberry pi therefore
we should try to avoid it
• Execute application code from trusted sources
only
45. Web Interface Security
• Never use un-encrypted channel for data transfer
• Use of TLS is mandatory
• Use 2 factor (multi-factor where applicable and
appropriate) authentication for critical operations
• OTP is one the methods which can be used when
a user performs operations like:
• Changing password, deleting data, updating
permissions etc
46. Privacy Concerns
• Privacy Concerns among users is another
major challenge to the wide spread
acceptance of the IOT
• Providing sufficient controls to users so they
can allow/block who access their data is
important
• At the same time, it should not compromise
the user experience
47. Using 3rd party api’s
• With IOT, use of 3rd party API’s like Twitter,
Facebook, IFTTT, Google+ is very common and
expected to increase.
• It is important to make sure that
vulnerabilities in 3rd party api’s doesn’t
compromise our app’s data in any way
• Therefore when using 3rd pary api’s user’s data
should be exposed in a limited way
48. Security Configurability
• ‘Lack of Security Configurability’ is on of the
major reasons for weakness in IOT devices as
of today.
• Therefore user should be able to easily
configure the basic and advanced security
• Log’s collected from client (IOT hub) and web
+ mobile interface can be collected at one
place and co-related to raise alerts in case of
any abnormal patterns
49. Account Lock and Forgot
Password
• Forget password is one of the most popular
insecure being.
• Password reset attacks can be made difficult
by taking away the control from web-interface
all together (Number of users has to be taken
into account)
• Similarly alert can be raised if more than a
threshold number of failed login attempts are
observed.