1. How to secure the Internet of Things?
Hannes Tschofenig
21th January 2015

2. 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.

3. Agenda What is Internet of Things (for ARM)?
Methodologies for Developing an IoT Security Solution
Classical Threat Analysis
Generic Security Recommendations
Attacks
Design Patterns
From Theory to Practice
Performance
Ongoing Work/Missing Parts
Outlook

4. What is Internet of Things?

5. 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.

6. ARM Processor Families
Cortex-A57
Cortex-A53
Cortex-A15
Cortex-A9
Cortex-A8
Cortex-A7
Cortex-A5
Cortex-R7
Cortex-R5
Cortex-R4
Cortex-M4
Cortex-M3
Cortex-M1
Cortex-M0+
Cortex-M0
SC000
SC100
SC300
ARM11
ARM9
ARM7
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
Cortex-A
Cortex-R
Cortex-M
SecurCore
Classic
Figure as of Sept 2013
(i.e., does not include the Cortex M7 yet)

7. Cortex-M Processors: Our Focus for IoT
Recently released
Best performance
Digital Signal Control (DSC) Processor with DSP Accelerated SIMD Floating point (FP)
Performance efficiency Feature rich connectivity
Lowest power Outstanding energy efficiency
Lowest cost Low power
Processors use the 32-bit RISC architecture 7

8. What is so special about IoT device?
Constrained Node
Constrained Networks
Text copied from RFC 7228 “Terminology for Constrained-Node Networks”

9. = + + Cost Distribution Total Cost Hardware Cost Energy Cost
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.
… and here.
(e.g. firmware update, manageability)
But it can make sense to spend more here …
(e.g., on flash/RAM, CPU, BOM)
… 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?” 9

10. Methodologies for Developing an IoT Security Solution

11. Which approach to take? Examples Perform Classical Threat Analysis
RFC 3552
Following Generic Security Recommendations
NIST SP, IETF BCPs,
National standards
Which approach to take?
Learn from Attacks
‘Bash’ bug
Follow Design Patterns
Device-to-Cloud Model

12. Areas of Responsibility
Factors influencing Outcome
Negative Examples
Cryptographic Primitives
Improved algorithms for integer factorization, too small key size.
Experience of designers, years of cryptanalysis, intention of designers.
Flawed standards, no end-to-end security, unpractical security architecture, insecure authentication mechanisms, inflexibility
Structure of standardization process and membership policy, skills and reviewer culture, technical content of the specification and architecture.
Protocol Specifications and Architecture
Software development process, testing methodology, developer skills, compiler and hardware features.
Implementation
Buffer overflow attacks, poor UI or other usability problems.
Accountability, organizational processes, vulnerability management, software update approach, secure configuration, skills and training, policies.
Deployment
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.

13. Classical Threat Analysis

14. 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.

15. Generic Security Recommendations

16. 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:
DTLS In Constrained Environments (dice) working group:

17. 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
Examples are:
Recommendation for random number generation (SP series)
WLAN security / EAP method recommendations (SP , SP )
Recommendations for key management (SP )
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

18. 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 See also RFC 3766 for "Determining Strengths For Public Keys Used For Exchanging Symmetric Keys”

19. Attacks

20. 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.

21. Inadequate Software Update Mechanism
”Too Many Cooks - Exploiting the Internet-of-TR-069-Things”
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 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. Read also Bruce Schneier article published January 2014.

22. 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.
Pictures taken from

23. 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.
Insteon LED Bulbs

24. 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!”
MMU is the abbreviation for ”Malfunction Management Unit” – not for Memory Management Unit.

25. 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 thermostat-googles-nest-gets-hacked/ and
JTAGulator
Bus Pirate
Chip Whisperer

26. 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).

27. Design Patterns
Reference:

28. 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 (
Vendors often extend existing profiles and sometimes publish them.
Examples: Wearables with Bluetooth Smart

29. Examples StickNFind Suunto Ambit 3 Beacons Hearing Aid Cadence Sensor
Parrot

30. 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

31. Examples Fitbit Zepp Golf Sensor Garmin Forerunner 920XT
Oral-B Toothbrush

32. 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 , WiFi, Z-Wave, Bluetooth (Smart)
Examples: Smart Home, smart meters

33. Examples NXP Janet-IP Philips Hue Nest SmartThings
Revolv Smart Home Gateway

34. 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.

35. Device-to-Cloud Characteristics: Security: Standardization:
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

36. Examples
Withings Scale
LittlePrinter
Tractive
Dropcam

37. 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

38. Examples
MapMyFitness

39. From Theory to Practice
Goals
Lower the bar for developers.
Allow for low cost, energy efficient solutions.
Offer choice to developers
Principles
Re-use available standards
Re-use code
End-to-end IP as much as possible
Put the user in control
Deference in depth

40. Design patterns give developers an easy starting point.
1) Read through the list.
2) Pick the model that best resembles your ideas.

41. The Pieces: Following Recommendations
Follow key length recommendation (112-bit symmetric key equivalent)
Always encrypt to improve resistance against pervasive monitoring (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.

42. 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.

43. 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.

44. 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
Tutorial (Zach Shelby/ARM):
Specification available at
Code? Have a look here:

45. 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.

46. DTLS may look complex… Client Server Full Handshake ClientHello
HelloVerifyRequest(contains Cookie)
ClientHello (with Cookie)
ServerHello, Certificate*, ServerKeyExchange*, CertificateRequest*, ServerHelloDone
Certificate*, ClientKeyExchange, CertificateVerify*, [ChangeCipherSpec], Finished
[ChangeCipherSpec], Finished
Application Data
Full Handshake

47. But it can be very lightweight
Client
Server
ClientHello (with Session ID)
ServerHello, [ChangeCipherSpec], ServerHelloDone
[ChangeCipherSpec], Finished
Application Data
Session Resumption

48. 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:
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

49. Performance

50. Looking for Answers to these Questions
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.

51. 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

52. 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
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
ST Nucleo
FRDM-KL25Z
LPC1768

53. ECC Curves & Optimizations
NIST Curves:
secp521r1, secp384r1, secp256r1, secp224r1, secp192r1
Described in FIPS 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.
Is ECC unfamiliar to you? Here is a good tutorial:

54. 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.

55. 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.

56. 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.

57. Performance of various NIST/Koblitz ECC Curves
NIST curves: secp521r1, secp384r1, secp256r1, secp224r1, secp192r1
Koblitz curves: secp256k1, secp224k1, secp192k1

58. 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.

59. Secp256r1 (signature) needs 122msec.
Performance of Brainpool Curves
For comparison:
Secp256r1 (signature) needs 122msec.

60. Performance of ECDHE: F401RE vs.LPC1768
secp192r1 (ECDHE):
276 msec (F401RE) vs. 229 msec (LPC1768)
NIST optimization enabled.
Fixed-point speed-up enabled.

61. The Performance Impact of the NIST Optimization
secp192r1 (ECDHE):
5986 msec (F401RE, optimization disabled)
vs.
638 msec (optimization enabled)

62. ECDHE Performance of the KL25Z

63. Performance Comparison: Prototyping Boards

64. 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.

65. Symmetric Key Crypto: Performance of the KL25Z

66. 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.

67. Ongoing Work / Missing parts

68. 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 multicast solution.
Standardization activities in the area of network access authentication for IEEE mesh networks (Thread)
Authorization  IETF ACE working group.
Provisioning.
Libraries that are easy to use.

69. Network Access Authentication
Radio technology often defines security procedures for accessing networks.
Examples:
WiFi uses IEEE i/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 (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.

70. 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™

71. 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).
Ongoing standardization work in the IETF ACE working group.
Resource Server
Client

72. 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.

73. Provisioning, cont. IoT Device IoT Device
“Factory” Provisioned Secrets
Third Party-Provisioned Secrets
Application Server
Vendor
Application Server
Provisioning
Server
Vendor
Bootstrapping
(e.g., OMA
LWM2M)
Per-Device
Specific
Firmware
DTLS/TLS
Firmware
DTLS/
TLS
IoT Device
IoT Device

74. Provisioning, cont. IoT Device Pairing Application Server
Out-of-Band Channel
Application Server
IoT Device

75. Outlook
Lots of innovation happening in the Internet of Things area, which is mostly driven by 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.

76. 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.