Presentation is loading. Please wait.

Presentation is loading. Please wait.

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

Similar presentations

Presentation on theme: "1 How to secure the Internet of Things? Hannes Tschofenig 21 th January 2015."— Presentation transcript:

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

2 2  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. My Goals

3 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 4 What is Internet of Things?

5 5  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. Recent Example of “IoT” Announcement

6 6 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 Cortex-A 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-R Cortex-M SecurCore Classic Figure as of Sept 2013 (i.e., does not include the Cortex M7 yet)

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

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

9 9 Cost Distribution Reducing total system cost by enabling better system tradeoffs We care about this. … if it results in savings here … (e.g. sophisticated power management) But it can make sense to spend more here … (e.g., on flash/RAM, CPU, BOM) = + + Total CostHardware CostEnergy CostDevelopment Cost (amortized, inc. deployment cost) … and here. (e.g. firmware update, manageability) More detailed treatment of this topic in a webinar by Peter Aldworth aboutwebinar “How to Select Hardware for Volume IoT Deployments?”

10 10 Methodologies for Developing an IoT Security Solution

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

12 12 Areas of Responsibility Deployment Accountability, organizational processes, vulnerability management, software update approach, secure configuration, skills and training, policies. Implementation Software development process, testing methodology, developer skills, compiler and hardware features. Protocol Specifications and Architecture Cryptographic Primitives Structure of standardization process and membership policy, skills and reviewer culture, technical content of the specification and architecture. Experience of designers, years of cryptanalysis, intention of designers. 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. Factors influencing Outcome Negative Examples Understanding the distribute nature of the development process is essential for tackling Internet security problems.

13 13 Classical Threat Analysis

14 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 15 Generic Security Recommendations

16 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”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 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 18 Key Length SymmetricECCDH/DSA/RSA  Values based on recommendations from RFC  [I-D.ietf-uta-tls-bcp] recommends at least 112 bits symmetric keys.I-D.ietf-uta-tls-bcp  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 19 Attacks

20 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.OWASP  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 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 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. Read also Bruce Schneier article published January 2014.article published January 2014

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

23 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”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.ZMap  Similar problems have been seen with various other appliances, such as surveillance cameras and baby monitoring cameras.surveillance camerasbaby monitoring cameras  Lacking access control to configuration files can cause problems for the entire system, as demonstrated with attacks against industrial control systems.attacks against industrial control systems Insteon LED Bulbs

24 24 Missing COMSEC  In “Green Lights Forever: Analyzing the Security of Traffic Infrastructure” Ghena,et al. analzed the security of the traffic infrastructure.Green Lights Forever: Analyzing the Security of 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.similar attack  “I even tested the attack launched from a drone flying at over 650 feet, and it worked!”

25 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 (I 2 C).  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.power analysisfault injection (glitching)  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 thermostat-googles-nest-gets-hacked/ Bus Pirate Chip Whisperer JTAGulator

26 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).DragonFlyattack 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).hacked Femto home router used for spyingDDoS attacks using SNMP (used in printers)

27 27 Design Patterns Reference:

28 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 29 Beacons Cadence Sensor Parrot Hearing Aid Examples StickNFind Suunto Ambit 3

30 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 31 Examples Zepp Golf Sensor Oral-B Toothbrush Fitbit Garmin Forerunner 920XT

32 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 33 Examples Philips Hue NXP Janet-IP Revolv Smart Home Gateway SmartThings Nest

34 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.AlljoynOpen Interconnect Consortium  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 35 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

36 36 Examples LittlePrinter Withings Scale Tractive Dropcam

37 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 38 MapMyFitness Examples

39 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 40 Design patterns give developers an easy starting point. 1) Read through the list. 2) Pick the model that best resembles your ideas.

41 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 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 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).iRobot Create 2  Hardware-based crypto support. This could include crypto functions (such as AES) or even functionality like TrustZone.TrustZone  Memory protection unit (MPU) integration for Cortex M processors. The MPU allows separation of memory between different processes.

44 44 Software Updates: OMA LWM2M Architecture  M2M Applications  Application abstraction through REST API  Uses Resource Discovery and Linking  LWM2M Clients are Devices  Device abstraction through CoAP  LWM2M Clients are CoAP Servers  Any IP network connection  LWM2M Server  CoAP Protocol  Supports HTTP Caching Proxy  Resource Directory  Gateway and Cloud deployable Tutorial (Zach Shelby/ARM): Specification available at Code? Have a look here:

45 45 DTLS / TLS  DTLS is the datagram version of TLS. DTLS 1.2 is described in RFC 6347.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 46 DTLS may look complex… Server Client ClientHello HelloVerifyRequest(contains Cookie) ClientHello (with Cookie) ServerHello, Certificate*, ServerKeyExchange*, CertificateRequest*, ServerHelloDone Certificate*, ClientKeyExchange, CertificateVerify*, [ChangeCipherSpec], Finished [ChangeCipherSpec], Finished Application Data Full Handshake

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

48 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 49 Performance

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

51 51  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.PolarSSL stack  Random number generation not included in the tests Assumptions

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

53 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.FIPS  “Koblitz curves”:  secp256k1, secp224k1, secp192k1  Described by Standards for Efficient Cryptography Group (SECG), an international consortium founded by Certicom in 1998.Standards for Efficient Cryptography Group (SECG)  Brainpool curves  brainpoolP512r1, brainpoolP384r1, brainpoolP256r1  Described in RFC 5639.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 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 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 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 57 NIST curves: secp521r1, secp384r1, secp256r1, secp224r1, secp192r1 Koblitz curves: secp256k1, secp224k1, secp192k1 Performance of various NIST/Koblitz ECC Curves

58 58 Performance of various NIST/Koblitz ECC Curves For comparison: secp192r1 (signature) needs 66msec. NIST curves: secp521r1, secp384r1, secp256r1, secp224r1, secp192r1 Koblitz curves: secp256k1, secp224k1, secp192k1

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

60 60 Performance of ECDHE: F401RE vs.LPC1768 secp192r1 (ECDHE): 276 msec (F401RE) vs. 229 msec (LPC1768)

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

62 62 ECDHE Performance of the KL25Z

63 63 Performance Comparison: Prototyping Boards

64 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 65 Symmetric Key Crypto: Performance of the KL25Z

66 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 67 Ongoing Work / Missing parts

68 68 Ongoing Activities  Work in the IRTF Crypto Forum Research Group on new ECC curves.IRTF Crypto Forum Research Group  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.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 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).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 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 71 Fine-Grained Access Control Resource Server Client  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).use case document  Ongoing standardization work in the IETF ACE working group.IETF ACE working group

72 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 73 Provisioning, cont. “Factory” Provisioned Secrets IoT Device Vendor Per-Device Specific Firmware Application Server DTLS/TLS Third Party-Provisioned Secrets IoT Device Vendor Firmware Application Server DTLS/ TLS Provisioning Server Provisioning Server Bootstrapping (e.g., OMA LWM2M)

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

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

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

Similar presentations

Ads by Google