Transcript How to secure the Internet of Things?

How to secure the Internet of Things?
Hannes Tschofenig
[email protected]
21th January 2015
1
My Goals
 IoT is a rather large topic: focus on a sub-field, namely security.
 Explain why it is difficult to offer a comprehensive security solution for
Internet of Things.
 Give you insight into what a microprocessor IP company is dealing with.
 List ongoing activities.
2
Agenda
 What is Internet of Things (for ARM)?
 Methodologies for Developing an IoT Security Solution








3
Classical Threat Analysis
Generic Security Recommendations
Attacks
Design Patterns
From Theory to Practice
Performance
Ongoing Work/Missing Parts
Outlook
What is Internet of Things?
4
Recent Example of “IoT” Announcement
 Ubuntu Core devices will requires
a 600MHz processor with 128MB
RAM and a 4GB flash for factory
reset and system rollback.
 Ubuntu Core itself will only take
up 40MB RAM leaving the rest for
applications.
 Not our understanding of IoT.
5
ARM Processor Families
 Cortex-A series (Application)
 High performance processors
 Applications include smartphones, tablets, digital TV, smart books, home
gateways.
 Cortex-R series (Real-time)
 Exceptional performance for real-time applications;
 Applications include automotive braking systems, trains, factory floors;
 Cortex-M series (Microcontroller)
 Cost-sensitive solutions for deterministic microcontroller applications;
 Applications include wearables, smart home, ….
 SecurCore series
 High security applications.
 Previous classic processors
 Include ARM7, ARM9, ARM11 families
6
Cortex-A57
Cortex-A53
Cortex-A15
Cortex-A9
Cortex-A8
Cortex-A7
Cortex-A5
Cortex-A
Cortex-R7
Cortex-R5
Cortex-R4
Cortex-R
Cortex-M4
Cortex-M3
Cortex-M1
Cortex-M0+
Cortex-M0
Cortex-M
SC000
SC100
SC300
SecurCore
ARM11
ARM9
ARM7
Classic
Figure as of Sept 2013
(i.e., does not include
the Cortex M7 yet)
Cortex-M Processors: Our Focus for IoT
Recently released
Best performance
Performance efficiency
Feature rich connectivity
Lowest power
Outstanding energy efficiency
Lowest cost
Low power
7
Processors use the 32-bit RISC architecture
http://www.arm.com/products/processors/cortex-m/index.php
Digital Signal Control (DSC)
Processor with DSP
Accelerated SIMD
Floating point (FP)
What is so special about IoT device?
Constrained Node
Constrained Networks
Text copied from RFC 7228 “Terminology for Constrained-Node Networks”
8
Cost Distribution
Reducing total system cost by enabling better system tradeoffs
=
Total Cost
+
+
Hardware Cost
Energy Cost
Development Cost
(amortized, inc. deployment cost)
We care about this.
But it can make sense to spend more here …
(e.g., on flash/RAM, CPU, BOM)
9
… if it results in savings here …
(e.g. sophisticated power management)
More detailed treatment of this topic in a webinar by Peter Aldworth about
“How to Select Hardware for Volume IoT Deployments?”
… and here.
(e.g. firmware update,
manageability)
Methodologies for Developing an
IoT Security Solution
10
Examples
Perform Classical Threat Analysis
Which approach to take?
Following Generic Security
Recommendations
Learn from Attacks
Follow Design Patterns
11
RFC 3552
NIST SP, IETF BCPs,
National standards
‘Bash’ bug
Device-to-Cloud Model
Areas of Responsibility
Factors influencing Outcome
Experience of designers, years of cryptanalysis,
intention of designers.
Structure of standardization process and
membership policy, skills and reviewer
culture, technical content of the specification
and architecture.
Software development process, testing
methodology, developer skills, compiler and
hardware features.
Accountability, organizational processes,
vulnerability management, software update
approach, secure configuration, skills and
training, policies.
12
Negative Examples
Cryptographic Primitives
Protocol Specifications and
Architecture
Implementation
Deployment
Improved algorithms for integer
factorization, too small key size.
Flawed standards, no end-to-end security,
unpractical security architecture, insecure
authentication mechanisms, inflexibility
Buffer overflow attacks, poor UI or other
usability problems.
Bad default configuration, enabled debug
ports, default passwords, configuration
problems.
Understanding the distribute nature of the development process is essential for tackling Internet security problems.
Classical Threat Analysis
13
RFC 3552
 Threat Modeling
 Typical internet communication threat assumptions where attacker has nearly complete control of the
communications channel.
 Active vs. passive attackers; on-path vs. off-path.
 Focus of RFC 3552 is (due to the nature of a standardization organization) on COMSEC rather than SYSTEM
SECURITY.
 Risk analysis then leads to a list of security requirements.
 Finally, requirements need to be fulfilled with security solutions. Not all potential threats may be
addressed with solutions.
 Typically, the following security services will be needed:





(Entity) authentication
Authorization
Traffic Security (confidentiality, data-origin authentication and integrity)
Availability (denial of service countermeasures)
Rarely non-repudiation
 This list still leaves a fair number of options
(e.g., at which layer to apply security protection, which security frameworks to re-use).
 Note: It is useful to document the communication interaction first, as described in RFC 4101.
14
Generic Security Recommendations
15
Generic Recommendations
(IETF)
 Key management requirements:
 RFC 4107 “Guidelines for Cryptographic Key Management” discusses the trade-off between manual and automatic
key management.
 RFC 4962 “Guidance for Authentication, Authorization, and Accounting (AAA) Key Management” offers guidance
for a three party key management architecture often used for network access authentication.
 Key length recommendations (see next slide)
 Randomness requirements (RFC 4086). See also “Mining Your Ps and Qs: Detection of Widespread Weak
Keys in Network Devices”
 Pervasive monitoring (PM) - RFC 7258 argues that protocols should be designed such that they make PM
significantly more expensive or infeasible (such as by using opportunistic security, see RFC 7435).
 Guidelines for Cryptographic Algorithm Agility - draft-iab-crypto-alg-agility-01
 Protocol or domain-specific recommendations (including choice of algorithms) also available:
 Using TLS in Applications (uta) working group: https://datatracker.ietf.org/wg/uta/charter/
 DTLS In Constrained Environments (dice) working group: https://datatracker.ietf.org/wg/dice/charter/
16
Generic Recommendations
(NIST)
 Authority of NIST for procurement of IT systems by the US government. However, due
to the quality of their documents they have been used in the private sector as well.
 The NIST special publication series can be found at
http://csrc.nist.gov/publications/PubsSPs.html
 Examples are:
 Recommendation for random number generation (SP 800-90 series)
 WLAN security / EAP method recommendations (SP 800-153, SP 800-120)
 Recommendations for key management (SP 800-57)
 Also widely known are the Federal Information Processing Standards (FIPS) standards,
particularly cryptographic algorithms (such as DSS) and FIPS-140 outlining “Security
Requirements for Cryptographic Modules”.
 FIPS standards can be found at http://csrc.nist.gov/publications/PubsFIPS.html
17
Key Length
Symmetric
ECC
DH/DSA/RSA
80
163
1024
112
233
2048
128
283
3072
192
409
7680
256
571
15360
 Values based on recommendations from RFC 4492.
 [I-D.ietf-uta-tls-bcp] recommends at least 112 bits symmetric keys.
 A 2013 ENISA report states that an 80bit symmetric key is sufficient for legacy applications but
recommends 128 bits for new systems.
 More references at http://www.keylength.com. See also RFC 3766 for "Determining Strengths For Public
Keys Used For Exchanging Symmetric Keys”
18
Attacks
19
Learn from Attacks
 Selected attacks to illustrate common problems:





Inadequate software update mechanism
Missing Key Management
Insecure configuration files and default passwords
Missing COMSEC
Physical attacks
 Don’t forget to secure the server-side as well. According to OWASP this is the #1
security vulnerability.
 Note: OWASP might be biased in their assessment since the organization deals mostly with Web-based
vulnerabilities.
 Even more risky is it to run a server on your IoT / embedded device.
20
Inadequate Software Update Mechanism
 ”Too Many Cooks - Exploiting the Internet-of-TR-069-Things”
 http://events.ccc.de/congress/2014/Fahrplan/events/6166.html
 Popular embedded web server (called RomPager from AllegroSoft) installed on home
gateways that use the TR 69 standard. Version 4.07 of RomPaper released in 2002
contains various vulnerabilities (buffer overflow, etc.).
 Real problem: Fix released in 2005 by AllegroSoft already but has not been distributed
along the value chain of chip manufacturers, gateway manufacturers, Internet service
providers.
 Sad side remark: TR 69 is a protocol for automatically distributing software updates.
21 Read also Bruce Schneier article published January 2014.
Missing Key Management Problem
 Example: LIFX - Internet connected light bulb
 The attack revealed that an AES key shared among all devices to simplify key
management. The firmware image was extracted via JTAG connected to the device using
a Bus Blaster. Then, the firmware was analyzed using IDA Pro.
22
Pictures taken from http://contextis.co.uk/resources/blog/hacking-internet-connected-light-bulbs
Insecure Configuration Files and
Default Passwords
 Default passwords or insecure default settings have caused
problems with Insteon LED Bulbs, as reported in
“When 'Smart Homes' Get Hacked: I Haunted A Complete
Stranger's House Via The Internet”
 To find IoT devices connected to the Internet global scans have
been used, for example, using ZMap.
 Similar problems have been seen with various other appliances,
such as surveillance cameras and baby monitoring cameras.
 Lacking access control to configuration files can cause
problems for the entire system, as demonstrated with attacks
against industrial control systems.
23
Insteon LED Bulbs
Missing COMSEC
 In “Green Lights Forever: Analyzing the Security of Traffic Infrastructure” Ghena,et al.
analzed the security of the traffic infrastructure.
 Results:
 “The wireless connections are unencrypted and
the radios use factory default usernames and
passwords.”
 “All of the settings on the controller may be configured
via the physical interface on the controller, but they may
also be modified though the network. An FTP connection
to the device allows access to a writable configuration
database. This requires a username and password, but
they are fixed to default values which are published online
by the manufacturer.”
 A similar attack also exploited the unencrypted communication.
 “I even tested the attack launched from a drone flying at over 650 feet, and it worked!”
24
Physical Attacks
 To extract keys, configuration data, or firmware images it might
be necessary to use additional hardware tools.
 The attacks range from using open debug / test interfaces (like
Joint Test Action Group (JTAG) or Universal Asynchronous
Receiver/Transmitter (UART), sniffing on inter-bus
communication interfaces like Serial Peripheral Interface (SPI) or
Inter-Integrated Circuit (I2C).
 In some cases it might be necessary to extract keying contained
within a trusted execution environment. This can be accomplished
using power analysis, or fault injection (glitching) attacks.
 Note: Not all “hacks” are really security attacks (although often
advertised as such). For example, replacing the firmware of your
thermostat requiring physical access is not a security attack
IMHO (as demonstrated with Nest devices at
http://venturebeat.com/2014/08/10/hello-dave-i-control-yourthermostat-googles-nest-gets-hacked/ and
http://www.engadget.com/2014/06/23/nest-thermostat-rooted/).
25
JTAGulator
Bus Pirate
Chip Whisperer
Remarks
 Classical approach with threat analysis, security requirements, and security architecture
design often leads to lots of “paper” but few surprising results since 90% of the threats
are common among all Internet protocols.
 Still, most of the security vulnerabilities are rather basic, i.e., there is often no need to
focus on more sophisticated attacks.
 Many exploits of IoT systems todays (particularly in the consumer space) are hoaxs.
 Once there is a reliable way to make money from exploiting them more attacks will surface.
 For SCADA systems many attacks are already scary (see DragonFly, and attack against German steel
factory).
 Risk analysis is often complex since hacked devices may be used for further attacks.
Hence, indirect consequences also need to be taken into account.
 Examples: hacked Femto home router used for spying, DDoS attacks using SNMP (used in printers).
26
Design Patterns
27
Reference: https://tools.ietf.org/html/draft-iab-smart-object-architecture
Device-to-Device Communication
 Characteristics:
 Device talks directly to other device (often smart phone or a wearable).
 Communication rarely uses IP but instead relies on link layer protocol mechanism.
 Users almost always have to download smart phone apps to access full range of supported device
functionality.
 Security:
 Security based on direct relationship between the devices (pairing).
 Channel security provided mostly at the link layer.
 Standardization:
 RFID, ANT+
 Bluetooth Smart Profiles (https://developer.bluetooth.org/TechnologyOverview/Pages/BLE.aspx)
 Vendors often extend existing profiles and sometimes publish them.
 Examples: Wearables with Bluetooth Smart
28
Examples
StickNFind
Suunto Ambit 3
Beacons
Hearing Aid
29
Parrot
Cadence Sensor
Device via Smart Phone to Cloud
 Characteristics:
 Extension of the device-to-device communication pattern.
 Device uploads data to cloud service indirectly via the smart phone.
 Device interacts with smart phone up and a specific cloud service. Users have to download app for
specific device/cloud service.
 Security:
 Classical smart phone app / Web development.
 Rarely end-to-end security between the IoT device and the cloud service.
 Standardization:
 Bluetooth Smart (dominant), maybe NFC.
 Examples: Wearables and Bluetooth Smart devices
30
Examples
Fitbit
Zepp Golf
Sensor
Oral-B Toothbrush
31
Garmin
Forerunner 920XT
Device via Gateway to Cloud
 Characteristics:
 Device uploads data to cloud service indirectly via a network gateway (which often implements several
radio technologies).
 Device is pre-configured to work with specific gateway manufacturer and specific cloud service, including
security credentials.
 Apps/websites allow user-friendly, remote access/monitoring
 Gateways have various degree of application layer understanding. Could do some form of filtering like Cisco
Krikkit/IOx.
 Security:
 Network access authentication need. Technologies like EAP, PANA, AAA, Thread are relevant in this context.
 Standardization:
 IEEE 802.15.4, WiFi, Z-Wave, Bluetooth (Smart)
 Examples: Smart Home, smart meters
32
Examples
NXP Janet-IP
Philips Hue
Nest
SmartThings
33
Revolv Smart Home Gateway
P2P Communication in Local Network
 Characteristics:
 Variant of “device via gateway to cloud” with local-only operation.
 Peer-to-peer model available as well.
 Projects like Alljoyn and Open Interconnect Consortium aim to focus on this sector.
 Security:
 Communication assumed to be local in the network.
 Conceptually similar to UPNP and
 Standardization:
 UPnP and DNS Service Discovery / Bonjour exist. Some of the work has been re-used in Zigbee
IP.
 Examples: Commercial products using UPnP and earlier standards exist.
34
Device-to-Cloud
 Characteristics:
 Device uploads data to cloud service directly using available network infrastructure without special
gateways.
 Device is pre-configured to work with specific cloud service only.
 Devices often require always-on reachability. Often an evolution of the “device-to-gateway”
scenario.
 Radio technology and IP-connectivity to local network for Internet access
 Security:
 Network access authentication + end-to-end security for cloud access.
 Standardization:
 WiFi (dominant), cellular, special radio technologies (e.g., SigFox).
 Network access / IP connectivity.
 Example: Smart home / Industry environment
35
Examples
Withings Scale
LittlePrinter
36
Dropcam
Tractive
Backend Data Portability
 Characteristics:
 Devices upload data to the cloud operated by a specific vendor.
 Analyzing different data from various sources is, however, valuable. End users also want to export
their data.
 Backend data sharing of protected data via OAuth-alike mechanisms and RESTful APIs.
 Security: Protection against unauthorized access requires registration of users and their devices.
Consent mechanism for sharing.
 Interoperability need:
 Today, proprietary APIs are used although Web design patterns, UIs, and security mechanisms
(OAuth) are re-used.
 Standardization:
 Information and data models, OAuth / OpenID Connect.
 Examples:Very common among cloud services
37
Examples
MapMyFitness
38
https://www.mapmyapi.com/docs/OAuth_2_Intro
From Theory to Practice
Principles
Goals
 Lower the bar for developers.
 Allow for low cost, energy efficient solutions.
 Offer choice to developers
39





Re-use available standards
Re-use code
End-to-end IP as much as possible
Put the user in control
Deference in depth
Design patterns give developers an easy starting
point.
1) Read through the list.
2) Pick the model that best resembles your ideas.
40
The Pieces: Following Recommendations
 Follow key length recommendation (112-bit symmetric key equivalent)
 Always encrypt to improve resistance against pervasive monitoring




41
(it also does not cost a lot).
Support automatic key management (instead of relying on manually provisioned keys).
To support crypto-algorithm agility consider even update of cryptographic library.
Leave enough “head room” for software updates.
Follow protocol-specific recommendations, such as those for DTLS/TLS.
Random Number Generation
 Security protocols frequently use random numbers for




Nonces for use with authentication and to avoid replay protection
Key transport
Asymmetric key generation (e.g., ephemeral Diffie-Hellman key pairs)
Signature algorithms based on El Gamal
 Sufficient entropy needs to be available as input to a pseudo-random number
generator, which expands the random number to a size needed for cryptographic
protocols.
 Unfortunately, most sources of randomness available at laptops and desktop PCs are
not available at embedded systems.
 Include random number generator in the microcontroller.
For example, the STM32F2xx and STM32F4xx series come
with a hardware-based random number generator.
 Another option is to use dedicated crypto hardware.
42
The Pieces: Learn from Attacks
 Add a software update mechanism based on  OMA Lightweight M2M.
 Provide authentication and authorization solution  LWM2M + DTLS/TLS
+ IETF ACE.
 Offer channel security  DTLS/TLS (+ maybe JOSE for the application
layer).
 Reduce physical attack surface with
 Crypto implementations that take side channel attacks into account.
 Disabled debug facilities before launching product (unless you want this to be a unique selling point,
see iRobot Create 2 or earlier LinkSys home routers).
 Hardware-based crypto support. This could include crypto functions (such as AES) or even
functionality like TrustZone.
 Memory protection unit (MPU) integration for Cortex M processors. The MPU allows separation of
memory between different processes.
43
Software Updates: OMA LWM2M Architecture
 M2M Applications
 Application abstraction through
REST API
 Uses Resource Discovery and
Linking
 LWM2M Server
 CoAP Protocol
 Supports HTTP Caching Proxy
 Resource Directory
 Gateway and Cloud deployable
 LWM2M Clients are Devices
 Device abstraction through CoAP
 LWM2M Clients are CoAP Servers
 Any IP network connection
44
Tutorial (Zach Shelby/ARM): https://www.youtube.com/watch?v=g-41ZdcTnXc
Specification available at http://openmobilealliance.org/about-oma/work-program/m2m-enablers/
Code? Have a look here: https://github.com/jvermillard/leshan
DTLS / TLS
 DTLS is the datagram version of TLS. DTLS 1.2 is described in RFC 6347.
 The design of DTLS is intentionally aligned with TLS but several features had to be
added: DDoS protection, fragmentation & reliability for the handshake.
 TLS and DTLS use several “sub-”protocols: the handshake and the record layer protocol
are the most important.
 Handshake layer negotiates parameters for the session and authenticates the endpoints.
 Record uses negotiated parameters obtained via the handshake layer to apply encryption, integrity
protection, and data origin authentication.
 DTLS/TLS should be seen as an authentication framework rather than a single protocol
since the properties of the protocol are heavily influenced by the selected ciphersuite.
 Example #1: TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8
 Example #2: TLS_PSK_WITH_AES_128_CCM_8
 TLS/DTLS provides a convenient level of abstraction for a developer. Authorization is,
however, still necessary at the application layer.
45
DTLS/TLS Profile
 Many extensions, ciphersuites, and algorithm choices for DTLS/TLS exist.
Which of those should be used?
 Ongoing standardization work to specify profiles: http://tools.ietf.org/html/draft-ietf-dice-profile
 Contains profiles for pre-shared secrets, raw public keys, and certificate use
 Describes classical IoT client-server interaction but also client-to-IoT
server interaction.
 Discusses suitability and use of various extensions.
 Suggests the use of specific algorithms:
 AES Counter with Cipher Block Chaining - Message Authentication Code (CBC-MAC) (AES-CCM)
mode with 128 bit keys and an 8-bit authentication tag, Ephemeral Elliptic Curve Diffie-Hellman
(ECDHE) as the key establishment mechanism and an Elliptic Curve Digital Signature Algorithm
(ECDSA) for authentication
48
Performance
49
Looking for Answers to these Questions




50
Can crypto be done on processors used in IoT devices?
Can Internet security protocols be run on IoT processors?
Where are the limits?
It makes sense to focus on public key cryptography since it is computationally
most demanding.
Assumptions
 Focus of the measurement was on
 Raw crypto (and not on protocol exchanges)
 ECC rather than RSA
(since ECC is preferred for IoT due to the smaller key size)
 Different ECC curves
 Run-time performance and not energy consumption, RAM usage, or code size.
 No hardware acceleration was used.
 Open source software (PolarSSL stack) used so that others can verify the
results easily.
 Random number generation not included in the tests
51
Prototyping Boards used in Performance Tests
 ST Nucleo F401RE (STM32F401RET6)
 ARM Cortex-M4 CPU with FPU at 84MHz
 512KB Flash, 96KB SRAM
 ST Nucleo F103 (STM32F103RBT6)
 ARM Cortex-M4 CPU with FPU at 72MHz
 128KB Flash, 20KB SRAM
 ST Nucleo L152RE (STM32L152RET6)
 ARM Cortex-M3 CPU at 32MHz
 512 KBytes Flash, 80KB RAM
ST Nucleo
 Nordic LPC1768
 ARM Cortex-M3 CPU at 96MHz
 512KB Flash, 32KB RAM
 Freescale FRDM-KL25Z
 ARM Cortex-M0+ CPU at 48MHz
 128KB Flash, 16KB RAM
FRDM-KL25Z
52
LPC1768
ECC Curves & Optimizations
 NIST Curves:
 secp521r1, secp384r1, secp256r1, secp224r1, secp192r1
 Described in FIPS 186-4. Note that FIPS186-4 refers to secp192r1 as P-192, secp224r1 as P-224,
secp256r1 as P-256, secp384r1 as P-384, and secp521r1 as P-521.
 “Koblitz curves”:
 secp256k1, secp224k1, secp192k1
 Described by Standards for Efficient Cryptography Group (SECG), an international consortium
founded by Certicom in 1998.
 Brainpool curves
 brainpoolP512r1, brainpoolP384r1, brainpoolP256r1
 Described in RFC 5639.
 Fast reduction (for NIST curves) with POLARSSL_ECP_NIST_OPTIM directive.
 Additionally use the "window" size to impact the amount of pre-computation (min=2,
max=7). Configurable via ECP_WINDOW_SIZE directive.
53
Is ECC unfamiliar to you? Here is a good tutorial: https://www.youtube.com/watch?v=l6jTFxQaUJA
ECDSA, ECDHE, and ECDH
 Elliptic Curve Digital Signature Algorithm (ECDSA) is the elliptic curve variant of the
Digital Signature Algorithm (DSA) or, as it is sometimes called, the Digital Signature
Standard (DSS).
 It is used in TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 ciphersuite
recommended in CoAP (and consequently also in the DTLS profile draft).
 ECDSA, like DSA, has the property that poor randomness used during signature
generation can compromise the long-term signing key.
 For this reason the deterministic variant of (EC)DSA (RFC 6979) is implemented, which uses the
private key as a source or “entropy” to seed a PRNG.
 CoAP recommends this ciphersuite TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8
that makes use of the Ephemeral Elliptic Curve Diffie-Hellman (ECDHE).
 The Elliptic Curve Diffie-Hellman (ECDH) is only used for comparison purposes in this slide deck
but not used in the recommended ciphersuites.
54
Observations: Performance Figures
 Brainpool curves are slower than NIST curves because Brainpool curves
use random primes.
 ECC key sizes above 256 bits delivers weaker performance on Cortex M
class CPUs. ECC curves with key size 192, 224, and 256 have roughly
similar performance.
 ECDH is only slightly faster than ECDHE (when fixed point optimization is
enabled).
 ECDSA signature operation is faster than ECDSA verify operation.
 CPU speed has a significant impact on the performance.
 The performance of symmetric key cryptography (keyed hash functions,
encryption functions) is neglectable.
55
Observations: Optimizations
 NIST curve optimization provides substantial benefit for NIST secp*r1
curves (~ factor 8).
 Pre-computing values (based on the window size setting) has a significant
influence on the performance (~factor 2+).
 There is a performance – RAM usage tradeoff: increased performance
comes at the expense of additional RAM usage.
 ECC library increases code size but also requires a fair amount of RAM.
 The ECC test program only works on devices with 16KB RAM when all
optimizations are disabled and the number of curves are limited to a single type.
 Also on devices with 20KB functionality has to be reduced.
 Many Cortex M0/M0+ boards do not come with more than 16KB of RAM.
56
Performance of various NIST/Koblitz ECC Curves
NIST curves: secp521r1, secp384r1, secp256r1, secp224r1, secp192r1
Koblitz curves: secp256k1, secp224k1, secp192k1
57
Performance of various NIST/Koblitz ECC Curves
NIST curves: secp521r1, secp384r1, secp256r1, secp224r1, secp192r1
Koblitz curves: secp256k1, secp224k1, secp192k1
For comparison:
secp192r1 (signature)
needs 66msec.
58
Performance of Brainpool Curves
For comparison:
Secp256r1 (signature)
needs 122msec.
59
Performance of ECDHE: F401RE vs.LPC1768
secp192r1 (ECDHE):
276 msec (F401RE) vs. 229 msec (LPC1768)
60
The Performance Impact of the NIST Optimization
secp192r1 (ECDHE):
5986 msec (F401RE, optimization disabled)
vs.
638 msec (optimization enabled)
61
ECDHE Performance of the KL25Z
62
Performance Comparison: Prototyping Boards
ECDSA Performance (Signature Operation, w=7, NIST Optimization Enabled)
2000,00
1800,00
Time (msec)
1600,00
1400,00
secp192r1
1200,00
secp224r1
1000,00
secp256r1
800,00
secp384r1
600,00
secp521r1
400,00
200,00
0,00
LPC1768, 96 MHz,
Cortex M3
L152RE, 32 MHz,
Cortex M3
F103RB, 72 MHz,
Cortex M4
Prototyping Boards
63
F401RE, 84 MHz,
Cortex M4
Symmetric Key Cryptography
 Secure Hash Algorithm (SHA) creates a fixed length fingerprint based on an arbitrarily long input. The
output length of the fingerprint is determined by the hash function itself. For example, SHA256 produces
an output of 256 bits.
 Advanced Encryption Standard (AES) is an encryption algorithm, which has a fixed block size of 128 bits,
and a key size of 128, 192, or 256 bits.
 A mode of operation describes how to repeatedly apply a cipher's single-block operation to securely transform
amounts of data larger than a block.
 Examples of modes of operation: CCM, GCM, CBC.
 Test relevant information:
 SHA computes a hash over a buffer with a length of 1024 bytes.
 AES-CBC: 1024 input bytes are encrypted. No integrity protection is used. IV size is 16 bytes.
 AES-CCM and AES-GCM: 1024 input bytes are encrypted and integrity protected. No additional data is used. In
this version of the test a 12 bytes nonce value is used together with the input data. In addition to the encrypted
data a 16 byte tag value is produced.
64
Symmetric Key Crypto: Performance of the KL25Z
8
7,6
6,9
7
6
6
Time (msec)
6,7
6,5
5,8
5
4,2
4
3,6
3,2
2,8
3
2,2
2
1
0
SHA-256
SHA-512
AES-CBC128
AES-CBC192
AES-CBC256
AES-GCM- AES-GCM- AES-GCM- AES-CCM128
192
256
128
Cryptographic Operation
65
AES-CCM192
AES-CCM256
Performance Conclusion
 Overall, Cortex M CPUs offer good performance with ECC. Selecting the appropriate
hardware is, however, important!
 ECC requires performance-demanding computations. Those take time. What an
acceptable delay is depends on the application. Many applications only need to run public
key cryptographic operations during the initial (session) setup phase.
 Detailed performance figures depend on the enabled performance optimizations, the key
size, the type of curve, the number of MHz of the CPU, and the available RAM.
 To enable certain optimizations (such as pre-computation) sufficient RAM is needed.
 Devices with less than 20KB of RAM are very difficult to work with since the ECC libraries already
consume the available RAM. Devices below 16KB do not work at all. Devices with 16KB require
performance optimizations to be disabled, which leads to poor performance.
 Devices need to have a reasonable number of MHz to achieve an adequate ECC runtime.
 The NIST curve optimization and pre-computation pays off and should be used whenever possible.
 Symmetric key cryptography is not a problem at all.
66
Ongoing Work / Missing parts
67
Ongoing Activities
 Work in the IRTF Crypto Forum Research Group on new ECC curves.
 DTLS only works for unicast applications. For multicast applications (such as
lighting) enhancements to DTLS are needed.
 The work in the IETF DICE working group is charted to develop a DTLS-based




68
multicast solution.
Standardization activities in the area of network access authentication for IEEE 802.15.4
mesh networks (Thread)
Authorization  IETF ACE working group.
Provisioning.
Libraries that are easy to use.
Network Access Authentication
 Radio technology often defines security procedures for accessing networks.
 Examples:
 WiFi uses IEEE 802.11i/802.1X with EAP to offer authentication and wireless link security at the
link layer.
 Bluetooth Smart defines a pairing procedure and link layer security.
 In rare cases additional security is added on top of the link layer security mechanism to cover
multi-hop access network cases, as it is done with IEEE 802.15.4 (using EAP/PANA or with Thread).
 Most challenges arise from the desire to interwork with existing, already deployed
networks, such as WiFi.
 Example: WiFi networks rely on user provision some passwords for their local access network
(often by using a captive portal). This is, of course, not possible with IoT applications.
 This lead to many proprietary solutions, like TI Smart Config, that allows WiFi password
provisioning to be delegated to other devices.
69
Network Access Authentication, cont.
 Many IoT deployments today make use of dedicated, special purpose
gateways in home and enterprise networks.
 This increases the cost of deployments.
 These gateways often implement application layer functionality, additionally
increasing the cost and the need to provide regular updates.
 The availability of an application agnostic access point supporting multiple
low power radio technologies would stimulate deployments.
 Some developments ongoing, such as MultiTech Multiconnect Gambit
GPIO
Serial
Ethernet
LoRa™
70
Fine-Grained Access Control
 Pre-provisioning and pairing may be impractical for more complex environments.
 Number of resource servers is large.
 Resource server accessed by a large number devices.
 Resource server does not need to have always-on connectivity to the authorization server
(i.e., it can perform authorization checks locally).
 Centralized management is desired.
 Complex lifecycle management and interactions are more dynamic (see use case document).
71
Resource Server
Client
 Ongoing standardization work in the IETF ACE working group.
Provisioning
 Umbrella term for several tasks that configure a device for use with services. Includes
credential, access control, and software update provisioning.
 Example:
 DTLS offers the ability to use different credentials, such as pre-shared secrets, raw public keys, and
certificates.
 Pre-shared secrets requires an identifier and a symmetric key to be provisioned at the IoT device
and at the server. Additionally, the IoT device needs to know which server to contact.
 Goal:
 Provision product instance with unique key.
 Challenge:
 Decide when credentials and access control policies are configured to the communication partners.
 Depending on the level of indirection a number of different solutions are possible.
72
Provisioning, cont.
“Factory” Provisioned Secrets
Application
Server
Third Party-Provisioned Secrets
Vendor
Application
Server
Provisioning
Server
Vendor
Bootstrapping
(e.g., OMA
LWM2M)
Per-Device
Specific
Firmware
DTLS/TLS
IoT
Device
73
DTLS/
TLS
Firmware
IoT
Device
Provisioning, cont.
Pairing
Out-of-Band Channel
Application
Server
74
IoT
Device
Outlook
 Lots of innovation happening in the Internet of Things area, which is mostly driven by




75
small companies.
Resources of small companies is limited, particularly regarding security/privacy.
Concerns that we are building the future generation of insecure infrastructure right
now.
To offer security for the IoT deployments many existing Internet security standards can
be re-use and dedicated specifications are work in progress.
Availability of high-quality code and easy to use tools will, however, be essential.
What did I skip?
 Server and smart phone security application development considerations.
 Security testing (software development practices, testing guidance, recommended tools).
 Security processes (e.g., organizational measures, responsibilities, including security
vulnerability monitoring, education).
 User interface design.
 Privacy.
 There are also lots of protocol details.
76