class: title, smokescreen, shelf, bottom, no-footer background-image: url(images/cortextrustzone.png) # 181U Spring 2020 ## Security Solutions <style> h1 { border-bottom: 8px solid rgb(32,67,143); border-radius: 2px; width: 90%; } .smokescreen h1 { border-bottom: none; } .small {font-size: 80%} .smaller {font-size: 70%} .small-code.remark-slide-content.compact code {font-size:1.0rem} .very-small-code.remark-slide-content.compact code {font-size:0.9rem} .line-numbers{ /* Set "line-numbers-counter" to 0 */ counter-reset: line-numbers-counter; } .line-numbers .remark-code-line::before { /* Increment "line-numbers-counter" by 1 */ counter-increment: line-numbers-counter; content: counter(line-numbers-counter); text-align: right; width: 20px; border-right: 1px solid #aaa; display: inline-block; margin-right: 10px; padding: 0 5px; } </style> --- layout: true .footer[ - 181U - See acknowledgements ] --- class: compact # Agenda * Overcoming Insecure Design Patterns * Crypto building blocks * Key exchange, Certificates * Tokens * TLS/DTLS * Certificates * Hardware level protections --- class: compact # Insecure Design Patterns * Doing too much * Coding blunders * Authentication and authorization blunders * Cryptography blunders --- class: compact # Doing too much * A standard source of insecurity is system interfaces that provide more functionalility than they are supposed to - failure of input validation: interfaces often assume inputs are properly validated and accept invalid inputs which provides an attack vector - classic instance is *buffer overflow attack* - sql attacks - devious URLs * Excess power - Giving more power than necessary - running a full linux kernel (e.g. does it need to support NFS) - extra established components provides more attacks - "every IoT device will eventually run full linux 'because it can'" --- class: compact # Coding Blunders * We've grown to expect that desktops and servers depend upon "penetrate and patch" - But, IoT devices may not be updated leading to "forever days" * IoT devices shipped with malware installed * Debug code left in product Coding blunders in IoT have greater long-term consequences ! --- class: compact # Authentication Blunders * It is important that a system verify who is claiming to send it an update or confiuration change * A service may require *no authentication* whatsoever * A service may have a *permanent credential* that is never changeable * A service may fail to allow for *revocation* of a credential or privilege * A service may fail to allow for *delegation* of a privilege to another legitimate party (thus engendering workarounds) --- class: compact # Authentication Blunders (None) * The controller area bus (CAN) in modern cars - this is the central IT system in a car - components listen for messages, but can't determine the sender -- for example, the engine control unit is *supposed* to tell the brakes to engage, but anything can - Stefan Savage showed how to use the CD player to inject malware * Some devices permit updating firmware with no authentication - Progressive insurance's "snapshot" device * "Hello Barbie" would accept anything with the name "Barbie" * School application systems that use URLs to select students - 2/4/19 -- "An official IU GPA calculator allowed students, faculty and staff to access the grades of at least 100,000 current and former students in apparent violation of federal privacy law" --- class: compact # Authentication Blunders (Default credentials) * Design challenge -- what should a system do when it first comes out of the box - common approach is to ship with a default password - often default passwords are never changed * Default SSH backdoors have been found in Cisco security products * Two high-school students hacked Bank of Montreal ATMs using a default administrator password --- class: compact # Permanent Credentials An authentication credential is an electronic embodiment of the right of an entity to invoke some service * A binding between an entity and right * A binding between an entity and credential * A binding between credential and right Errors: * Right permenantly bound to a right - a hardcoded password - An entity posses a right but loses it in the future, but the right is not *revoked* - Suppose you have a smart thermostat and sell the house, is the right to control the thermostat revoked ? - What about the right to track a car's location ? --- class: compact # Easy exposure * websites that require user ID and password, but collect them over a plain-text channel * storing credentials in easily hacked form --- class: compact # Cryptography Blunders * Bad randomness -- key generation depends upon "good" random numbers - A study of TLS and SSH found a large number of internet-facing machines with the same key-pairs or sharing a large prime factor * Common keys -- LIFX internet-connected lightbulbs al used the same common key * Bad public key encryption * Aging of cryptography and protocols --- class: compact # Mitigating forever-days * Make sure vulnerabilities can be discovered and patches created * Make sure patches can be pushed * Make sure someone exists to push patches * Make sure systems automatically die off if they are not patched --- class: compact # Secret-key encryption and decryption   --- class: compact # Public-key encryption   --- class: compact # Key Distribution * predistributed keys (long-lived) - public keys distributed "out of band" - used to bootstrap - * session keys (short-lived) - each session uses a new session key, generated when the session is created * Diffie-Hellman key exchange -- works without using predsistributed keys * Certificates and tree of cerificate authorities (CA) used to help build trust. --- class: compact # Tokens * Flespi, AWS and others use "security tokens" to grant access privileges. For flespi/azure they must be "pre-distributed" AWS has a distribution protocol   --- class: compact # TLS Overview * SSL = Secure Sockets Layer. - Developed by Netscape * TLS = Transport Layer Security. - IETF-standardised version of SSL. - TLS 1.0=SSLv3 with minor tweaks, RFC 2246 (1999). – TLS 1.1=TLS 1.0 + tweaks, RFC 4346 (2006). - TLS 1.2=TLS 1.1 + more tweaks, RFC 5246 (2008). - TLS 1.3= simplification/optimization of TLS 1.2 plus removal of obsolete security * SSL/TLS provides security ‘at TCP layer’. - Runs over TCP, using TCP to provide reliable, end-to-end transport. - Widely deployed in Web browsers and servers to support ‘secure e-commerce’ over HTTP. --- class: compact # TLS Protocol Architecture   --- class: compact # TLS Record Protocol * TLS Record Protocol provides: - Data origin authentication and integrity using a MAC. - Confidentiality using a symmetric encryption algorithm. - Anti-replay using sequence numbers protected by the MAC. * Keys for the algorithms are supplied by the TLS Handshake Protocol. - agree on crypto method to use - generate session keys --- class: compact # TLS Record Protocol: MAC-Encode-Encrypt   --- class: compact # TLS Record Processing 1. Decrypt; 2. Remove padding; 3. Check MAC on header data, sequence number and plaintext. * Each of these steps can fail. * Additional sanity checking may be needed. * Any failure results in an error message being sent and immediate termination of the TLS connection. * Great care is needed in implementations to avoid attacks based on analyzing error conditions. --- class: compact # DTLS Overview * DTLS = Datagram Transport Layer Security. - A tweak to TLS. - Runs over UDP, using UDP to provide end-to-end transport. – Becoming more widely used, e.g. Cisco VPN products. * Some modifications to TLS are needed to handle unreliable nature of UDP. - Allow for retransmission of handshake messages. - Allow out-of-order arrival of messages. * Use explicit sequence numbers rather than implicit sequence numbers and keep a sliding window of received messages. - Tolerance of errors during decryption, but no error messages and no session termination. * Versions: - DTLS 1.0, based on TLS 1.1, RFC 4347 (2006). - DTLS 1.2, based on TLS 1.2, RFC 6347 (2012). - DTLS 1.3 in draft form --- class: compact # DTLS Protocol Architecture   --- class: compact # Attacks on IoT Devices   --- class: compact # Attacking the hardware directly  * JTAG Interface (a simplified version called SWD is used on ARM processors) - All embedded devices have a serial interface based upon JTAG that is used in manufacturing for - programming the device - testing the hardware - By attaching to this interface it *may* be possible to - download the processor code - reprogram the device --- class: compact # JTAG  A Netgear DG632 ADSL Modem with JTAG header at location 5. * Ways to mitigate attacks - disable flash erase - lock flash read - disable jtag (swd) port * But - For ARM parts it is still possible to connect "under reset" which enables the flash port - For STM32 parts, it's easy to work around -- "Shedding too much Light on a Microcontroller’s Firmware Protection", Obermaier and Tatschner --- class: compact # Crypto support in STM32 processors  * Some STM32 processors have hardware accelerators for cryptographic protocols * Recent STM32 processors have a random number generator based upon a "noisy source". --- class: compact # Embedded hardware security features are evolving rapidly [STM32 Security Protections](https://www.st.com/content/ccc/resource/technical/document/application_note/group1/9f/0b/e4/b6/75/15/4f/e2/DM00493651/files/DM00493651.pdf/jcr:content/translations/en.DM00493651.pdf)   --- class: compact # Even "smaller" processors are getting security hardware   --- class: compact # Summary * cover image -- [ARM](https://community.arm.com/resized-image/__size/640x480/__key/communityserver-discussions-components-files/430/1803.M23-with-dialog-boxes.png) * Material drawn from "The Internet of Risky Things" by Sean Smith * Material drawn from " TLS and DTLS: A Tale of Two Protocols Kenny Paterson" * Material drawn from "Computer Networks: A Systems Approach"