Presentation on theme: "How to secure the Internet of Things?"— Presentation transcript:
1 How to secure the Internet of Things? Hannes Tschofenig21th January 2015
2 My GoalsIoT 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 SolutionClassical Threat AnalysisGeneric Security RecommendationsAttacksDesign PatternsFrom Theory to PracticePerformanceOngoing Work/Missing PartsOutlook
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-A57Cortex-A53Cortex-A15Cortex-A9Cortex-A8Cortex-A7Cortex-A5Cortex-R7Cortex-R5Cortex-R4Cortex-M4Cortex-M3Cortex-M1Cortex-M0+Cortex-M0SC000SC100SC300ARM11ARM9ARM7Cortex-A series (Application)High performance processorsApplications 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 seriesHigh security applications.Previous classic processorsInclude ARM7, ARM9, ARM11 familiesCortex-ACortex-RCortex-MSecurCoreClassicFigure as of Sept 2013(i.e., does not include the Cortex M7 yet)
7 Cortex-M Processors: Our Focus for IoT Recently releasedBest performanceDigital Signal Control (DSC) Processor with DSP Accelerated SIMD Floating point (FP)Performance efficiency Feature rich connectivityLowest power Outstanding energy efficiencyLowest cost Low powerProcessors use the 32-bit RISC architecture7
8 What is so special about IoT device? Constrained NodeConstrained NetworksText 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 CostHardware CostEnergy CostDevelopment 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 3552Following Generic Security RecommendationsNIST SP, IETF BCPs,National standardsWhich approach to take?Learn from Attacks‘Bash’ bugFollow Design PatternsDevice-to-Cloud Model
12 Areas of Responsibility Factors influencing OutcomeNegative ExamplesCryptographic PrimitivesImproved 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, inflexibilityStructure of standardization process and membership policy, skills and reviewer culture, technical content of the specification and architecture.Protocol Specifications and ArchitectureSoftware development process, testing methodology, developer skills, compiler and hardware features.ImplementationBuffer overflow attacks, poor UI or other usability problems.Accountability, organizational processes, vulnerability management, software update approach, secure configuration, skills and training, policies.DeploymentBad default configuration, enabled debug ports, default passwords, configuration problems.Understanding the distribute nature of the development process is essential for tackling Internet security problems.
14 RFC 3552Threat ModelingTypical 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) authenticationAuthorizationTraffic Security (confidentiality, data-origin authentication and integrity)Availability (denial of service countermeasures)Rarely non-repudiationThis 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.
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-01Protocol 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/
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 atExamples 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 3072192409768025657115360Values 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”
20 Learn from Attacks Selected attacks to illustrate common problems: Inadequate software update mechanismMissing Key ManagementInsecure configuration files and default passwordsMissing COMSECPhysical attacksDon’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 bulbThe 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 COMSECIn “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 AttacksTo 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/ andJTAGulatorBus PirateChip Whisperer
26 RemarksClassical 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).
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 (https://developer.bluetooth.org/TechnologyOverview/Pages/BLE.aspx)Vendors often extend existing profiles and sometimes publish them.Examples: Wearables with Bluetooth Smart
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
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/monitoringGateways 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
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 andStandardization: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 accessSecurity: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
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
39 From Theory to Practice GoalsLower the bar for developers.Allow for low cost, energy efficient solutions.Offer choice to developersPrinciplesRe-use available standardsRe-use codeEnd-to-end IP as much as possiblePut the user in controlDeference 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 forNonces for use with authentication and to avoid replay protectionKey transportAsymmetric key generation (e.g., ephemeral Diffie-Hellman key pairs)Signature algorithms based on El GamalSufficient 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 withCrypto 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 ApplicationsApplication abstraction through REST APIUses Resource Discovery and LinkingLWM2M ServerCoAP ProtocolSupports HTTP Caching ProxyResource DirectoryGateway and Cloud deployableLWM2M Clients are DevicesDevice abstraction through CoAPLWM2M Clients are CoAP ServersAny IP network connectionTutorial (Zach Shelby/ARM): https://www.youtube.com/watch?v=g-41ZdcTnXcSpecification available atCode? Have a look here: https://github.com/jvermillard/leshan
45 DTLS / TLSDTLS 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_8Example #2: TLS_PSK_WITH_AES_128_CCM_8TLS/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*, ServerHelloDoneCertificate*, ClientKeyExchange, CertificateVerify*, [ChangeCipherSpec], Finished[ChangeCipherSpec], FinishedApplication DataFull Handshake
47 But it can be very lightweight ClientServerClientHello (with Session ID)ServerHello, [ChangeCipherSpec], ServerHelloDone[ChangeCipherSpec], FinishedApplication DataSession Resumption
48 DTLS/TLS ProfileMany 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 useDescribes 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
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 curvesRun-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 84MHz512KB Flash, 96KB SRAMST Nucleo F103 (STM32F103RBT6)ARM Cortex-M4 CPU with FPU at 72MHz128KB Flash, 20KB SRAMST Nucleo L152RE (STM32L152RET6)ARM Cortex-M3 CPU at 32MHz512 KBytes Flash, 80KB RAMNordic LPC1768ARM Cortex-M3 CPU at 96MHz512KB Flash, 32KB RAMFreescale FRDM-KL25ZARM Cortex-M0+ CPU at 48MHz128KB Flash, 16KB RAMST NucleoFRDM-KL25ZLPC1768
53 ECC Curves & Optimizations NIST Curves:secp521r1, secp384r1, secp256r1, secp224r1, secp192r1Described 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, secp192k1Described by Standards for Efficient Cryptography Group (SECG), an international consortium founded by Certicom in 1998.Brainpool curvesbrainpoolP512r1, brainpoolP384r1, brainpoolP256r1Described 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: https://www.youtube.com/watch?v=l6jTFxQaUJA
54 ECDSA, ECDHE, and ECDHElliptic 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, secp192r1Koblitz curves: secp256k1, secp224k1, secp192k1
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.
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.
68 Ongoing ActivitiesWork 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 GambitGPIOSerialEthernetLoRa™
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 ServerClient
72 ProvisioningUmbrella 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.
75 OutlookLots 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.