The Internet of Things (IoT) is rapidly spreading, reaching a multitude of different domains, including personal health care, environmental monitoring, home automation, smart mobility, and Industry 4.0. As a consequence, more and more IoT devices are being deployed in a variety of public and private environments, progressively becoming common objects of everyday life. It is hence apparent that, in such a scenario, cybersecurity becomes critical to avoid threats like leakage of sensible information, denial of service (DoS) attacks, unauthorized network access, and so on. Unfortunately, many low-end IoT commercial products do not usually support strong security mechanisms, and can hence be target of—or even means for—a number of security attacks. The aim of this article is to provide a broad overview of the security risks in the IoT sector and to discuss some possible counteractions. To this end, after a general introduction to security in the IoT domain, we discuss the specific security mechanisms adopted by the most popular IoT communication protocols. Then, we report and analyze some of the attacks against real IoT devices reported in the literature, in order to point out the current security weaknesses of commercial IoT solutions and remark the importance of considering security as an integral part in the design of IoT systems. We conclude this article with a reasoned comparison of the considered IoT technologies with respect to a set of qualifying security attributes, namely integrity, anonymity, confidentiality, privacy, access control, authentication, authorization, resilience, self organization.

IoT: Internet of Threats? A Survey of Practical Security Vulnerabilities in Real IoT Devices

Side-channel attacks are easy-to-implement whilst powerful attacks against cryptographic implementations, and their targets range from primitives, protocols, modules, and devices to even systems. These attacks pose a serious threat to the security of cryptographic modules. In consequence, cryptographic implementations have to be evaluated for their resistivity against such attacks and the incorporation of different countermeasures has to be considered. This paper surveys the methods and techniques employed in these attacks, the destructive effects of such attacks, the countermeasures against such attacks and evaluation of their feasibility and applicability. Finally, the necessity and feasibility of adopting this kind of physical security testing and evaluation in the development of FIPS 140-3 standard are explored. This paper is not only a survey paper, but also more a position paper.

/pdf/side-channel-attacks-ten-years-after-its-publication-and-the-1wh9pifdpf.pdf

Side-Channel Attacks: Ten Years After Its Publication and the Impacts on Cryptographic Module Security Testing.

Side-channel attacks pose a serious threat to implementations of cryptographic algorithms. In the pioneering article of Chari, Rao and Rohatgi, the general idea behind template attacks was introduced. Template attacks apply advanced statistical methods and can break implementations secure against other forms of side-channel attacks.

However, in our research it turned out that several details, which are essential to practical implementations of template attacks, still need to be answered. In this article we provide answers to open issues, such as how to select points of interest in an efficient way, or how to preprocess noisy data. In addition, we show the benefits of trial classifications and we point out that in practice so-called amplified template attacks have to be considered as a potential threat.

Practical template attacks

Implementations of the Transport Layer Security (TLS) protocol must handle a variety of protocol versions and extensions, authentication modes, and key exchange methods. Confusingly, each combination may prescribe a different message sequence between the client and the server. We address the problem of designing a robust composite state machine that correctly multiplexes between these different protocol modes. We systematically test popular open-source TLS implementations for state machine bugs and discover several critical security vulnerabilities that have lain hidden in these libraries for years, and have now finally been patched due to our disclosures. Several of these vulnerabilities, including the recently publicized FREAK flaw, enable a network attacker to break into TLS connections between authenticated clients and servers. We argue that state machine bugs stem from incorrect compositions of individually correct state machines. We present the first verified implementation of a composite TLS state machine in C that can be embedded into OpenSSL and accounts for all its supported cipher suites. Our attacks expose the need for the formal verification of core components in cryptographic protocol libraries, our implementation demonstrates that such mechanized proofs are within reach, even for mainstream TLS implementations.

/pdf/a-messy-state-of-the-union-taming-the-composite-state-pv3t0m6071.pdf

A Messy State of the Union: Taming the Composite State Machines of TLS

TLS is the most widely-used cryptographic protocol on the Internet. It comprises the TLS Handshake Protocol, responsible for authentication and key establishment, and the TLS Record Protocol, which takes care of subsequent use of those keys to protect bulk data. In this paper, we present the most complete analysis to date of the TLS Handshake protocol and its application to data encryption (in the Record Protocol). We show how to extract a key-encapsulation mechanism (KEM) from the TLS Handshake Protocol, and how the security of the entire TLS protocol follows from security properties of this KEM when composed with a secure authenticated encryption scheme in the Record Protocol. The security notion we achieve is a variant of the ACCE notion recently introduced by Jager et al. (Crypto ’12). Our approach enables us to analyse multiple different key establishment methods in a modular fashion, including the first proof of the most common deployment mode that is based on RSA PKCS #1v1.5 encryption, as well as Diffie-Hellman modes. Our results can be applied to settings where mutual authentication is provided and to the more common situation where only server authentication is applied.

/pdf/on-the-security-of-the-tls-protocol-a-systematic-analysis-5feqjwoul4.pdf

On the Security of the TLS Protocol: A Systematic Analysis

In this paper we present a practically feasible attack on RSA-based sessions in SSL/TLS protocols. We show that incorporating a version number check over PKCS#1 plaintext used in the SSL/TLS creates a side channel that allows an attacker to invert the RSA encryption. The attacker can then either recover the premaster-secret or sign a message on behalf of the server. Practical tests showed that two thirds of randomly chosen Internet SSL/TLS servers were vulnerable. The attack is an extension of Bleichenbacher’s attack on PKCS#1 (v. 1.5). We introduce the concept of a bad-version oracle (BVO) that covers the side channel leakage, and present several methods that speed up the original algorithm. Our attack was successfully tested in practice and the results of complexity measurements are presented in the paper.

/pdf/attacking-rsa-based-sessions-in-ssl-tls-vzuln45hch.pdf

Attacking RSA-Based Sessions in SSL/TLS

The threat of relay attacks on authentication protocols is often well recognized, especially for contactless applications like RFID chips. It is, therefore, a bit surprising to meet an implementation that actually encourages rather than eliminates these attacks. We present our experimental observations concerning Czech e-passports. These show clearly an inherent weakness rooted in lower layers of ISO 14443. As the behavior is unavoidable, it induces a question on whether the e- passport should not have used a dierent communication protocol or authentication scheme.

/pdf/a-note-on-the-relay-attacks-on-e-passports-the-case-of-czech-1mr9q63sqo.pdf

A Note on the Relay Attacks on e-passports: The Case of Czech e-passports.

Vaudenay has shown in [5] that a CBC encryption mode ([2], [9]) combined with the PKCS#5 padding [3] scheme allows an attacker to invert the underlying block cipher, provided she has access to a valid-padding oracle which for each input ciphertext tells her whether the corresponding plaintext has a valid padding or not. Having on mind the countermeasures against this attack, different padding schemes have been studied in [1]. The best one is referred to as the ABYT-PAD. It is designed for byte-oriented messages. It removes the validpadding oracle, thereby defeating Vaudenay's attack, since all deciphered plaintexts are valid in this padding scheme. In this paper, we try to combine the well-known cryptographic message syntax standard PKCS#7 [8] with the use of ABYT-PAD instead of PKCS#5. Let us assume that we have access to a PKCS#7CONF oracle that tells us for a given ciphertext (encapsulated in the PKCS#7 structure) whether the deciphered plaintext is correct or not according to the PKCS#7 (v1.6) syntax. This is probably a very natural assumption, because applications usually have to reflect this situation in its behavior. It could be a message for the user, an API error message, an entry in the log file, different timing behavior, etc. We show that access to such an oracle again enables an attacker to invert the underlying block cipher. The attack requires single captured ciphertext and approximately 128 oracle calls per one ciphertext byte. It shows that we cannot hope to fully solve problems with side channel attacks on the CBC encryption mode by using a “magic” padding method or an obscure message-encoding format. Strong cryptographic integrity checks of ciphertexts should be incorporated instead.

/pdf/side-channel-attacks-on-cbc-encrypted-messages-in-the-pkcs-7-52c573rnr8.pdf

Side Channel Attacks on CBC Encrypted Messages in the PKCS#7 Format

Since the attack runs on the Security Manager layer [1], it can reuse a lot of the existing network stack that is already in place for this approach. This namely concerns everything bellow Host Controller Interface (HCI) [1]. Actually, the whole procedure starting with the authentication bypass and continuing to data injection (which would be a regular communication anyway) can be done using a general Bluetooth 4.0 Smart Ready USB dongle via HCI commands.

/pdf/bypassing-passkey-authentication-in-bluetooth-low-energy-mgxvel8am4.pdf

Bypassing Passkey Authentication in Bluetooth Low Energy.

/pdf/attack-on-private-signature-keys-of-the-openpgp-format-pgp-4hkik3s6cy.pdf

Tomás Rosa

Papers

Attacking RSA-Based Sessions in SSL/TLS

A Note on the Relay Attacks on e-passports: The Case of Czech e-passports.

Side Channel Attacks on CBC Encrypted Messages in the PKCS#7 Format

Bypassing Passkey Authentication in Bluetooth Low Energy.

Attack on Private Signature Keys of the OpenPGP Format, PGP(TM) Programs and Other Applications Compatible with OpenPGP.